opcode-lucho is a fork of winfunc/opcode (AGPL-3.0) that I moved
into my own workspace: 250 commits of mine on top of a repository that now has 522, made between July 2
and July 11, 2026. What follows is not about what I rebuilt, but about the problem that came first: how
do you get to the point where you can change code you did not write?
The starting point: 74 components and 11 inherited modules
When I imported the upstream history, I found a frontend with 74 files under src/components/ and a
Rust backend with 11 command modules (agents, app_settings, claude, claude_backups,
claude_templates, mcp, proxy, slash_commands, storage, usage), plus checkpoint/, process/,
and web_server.rs.
The original project’s README explains what the app does. It does not explain the internal anatomy of any of those pieces: which view owns which state, what renders what, where one component ends and the next one begins. That is enough to use the app. It is not enough to modify it.
The reversed order: change first, document afterward
Today the repository has 16 hand-written documents under docs/views/, one per view, all in English:
navigation-model.md, left-sidebar.md, tab-manager.md, titlebar.md, and the rest. They did not exist
upstream: I wrote them in commits d307399 and fb7a049.
The detail that matters is when I wrote them. None came before I touched the view it describes: every
document came after the feature was already working. I would first rebuild navigation—the left
sidebar, the per-project tab strip, the title bar—and only once that worked would I sit down to write
navigation-model.md.
That is exactly the opposite of what sounds reasonable. The obvious way to adopt someone else’s code is “first understand everything, then make changes.” With 74 unfamiliar components, that obvious approach never ends: reading a component without changing it leaves you with a hypothesis about how it works, not certainty, and 74 chained hypotheses are not a map.
Why the reversed order worked
A document written before changing the code is a promise about code you do not yet understand. One written afterward describes something you already proved works, because you broke it and put it back together.
That is the logic, and it is my reading of the process rather than a finding the repository proves on its
own: docs/views/ exists because the inherited codebase did not explain itself. The evidence is those
16 hand-written view documents, in English, describing component anatomy the upstream project never
recorded. Nobody documents that way what they already carry in their head.
The cost of this order is real and worth stating: during the first feature in each view, you work blind, without a document, relying only on what you learn while reading the code. The document does not help you build that feature; it helps you build the next one, and return two weeks later. In a 522-commit repository where most of the frontend was written by other people, that second pass always comes.