opcode-lucho es un fork de winfunc/opcode (AGPL-3.0) que llevé a
workspace propio: 250 commits míos sobre un repo que hoy tiene 522, hechos entre el 2 y el 11 de julio de
2026. Lo que sigue no es sobre lo que rehice, sino sobre el problema previo: cómo hacés para poder tocar
código que no escribiste.
El punto de partida: 74 componentes y 11 módulos que heredé
Cuando importé el historial del upstream me encontré con un frontend de 74 archivos en
src/components/ y un backend Rust con 11 módulos de comandos (agents, app_settings, claude,
claude_backups, claude_templates, mcp, proxy, slash_commands, storage, usage), más
checkpoint/, process/ y web_server.rs.
El README del proyecto original explica qué hace la app. No explica la anatomía interna de ninguna de esas piezas: qué vista es dueña de qué estado, quién renderiza a quién, dónde termina un componente y empieza el siguiente. Para usar la app eso alcanza. Para modificarla, no.
El orden invertido: tocar primero, documentar después
Hoy el repo tiene 16 documentos en docs/views/, uno por vista, escritos a mano y en inglés:
navigation-model.md, left-sidebar.md, tab-manager.md, titlebar.md, y así con el resto. No existían
en el upstream: los escribí yo, en los commits d307399 y fb7a049.
El detalle que importa es cuándo los escribí. Ninguno se escribió antes de tocar la vista que describe:
todos salieron después de que la feature ya estaba hecha. Primero rehacía la navegación —el sidebar
izquierdo, el tab strip por proyecto, la titlebar— y recién con eso funcionando me sentaba a escribir
navigation-model.md.
Es exactamente al revés de lo que suena razonable. La forma obvia de adoptar código ajeno es “primero entiendo todo, después toco”. Con 74 componentes ajenos, esa forma obvia no termina nunca: leer un componente sin cambiarlo te deja con una hipótesis de cómo funciona, no con una certeza, y 74 hipótesis encadenadas no son un mapa.
Por qué funcionó al revés
Un documento escrito antes de tocar el código es una promesa sobre código que todavía no entendiste. Uno escrito después es la descripción de algo que ya comprobaste que funciona, porque lo rompiste y lo volviste a armar.
Esa es la lógica, y es mi lectura del proceso, no un hallazgo que el repo demuestre solo: docs/views/
existe porque el codebase heredado no se entendía solo. El indicio es que son 16 documentos de vista,
escritos a mano, en inglés, con la anatomía de componentes que el upstream nunca escribió. Nadie documenta
así lo que ya tiene en la cabeza.
El costo de este orden es real y conviene decirlo: durante la primera feature de cada vista trabajás a ciegas, sin documento, apoyado nada más en lo que vas leyendo del código. El documento no te ayuda a hacer esa feature; te ayuda a hacer la siguiente, y a poder volver dos semanas después. En un repo de 522 commits donde la mayor parte del frontend la escribió otra gente, esa segunda vuelta llega siempre.