¿Qué archivos hay que tocar para modificar una sola funcionalidad? Escribe un operationId y aparece la respuesta.
El problema
En una aplicación full-stack, una “funcionalidad” no vive en un solo archivo.
Supón que debes modificar una funcionalidad llamada “ExecuteWorkflow”. Esa funcionalidad está en la especificación API, en la lógica de servicio, en el esquema de base de datos, en la política de autorización, en el diagrama de transición de estados, en las llamadas a funciones externas, en los escenarios de prueba y en los componentes del frontend.
Históricamente ha habido dos maneras de captar todo ese alcance:
- Ejecutar grep decenas de veces
- Rastrear el código a mano
Las dos son lentas y las dos dejan cosas fuera. Las referencias entre capas en particular — del API al servicio, del servicio al esquema de BD, del servicio a la política de autorización — son prácticamente imposibles de rastrear de forma exhaustiva por un humano.
Es aún peor cuando delegas la edición a una IA. En 200 endpoints, la IA ya no puede sostener todo el contexto. El contexto colapsa, los patrones derivan y la funcionalidad número 201 cuesta 10× la número 21. Ese es el muro contra el que choca el vibe coding.
Pero si la fuente de cada capa referencia simbólicamente a otras capas, basta con seguir esas referencias para revelar todo el alcance automáticamente.
Qué es Feature Chain
Feature Chain es el conjunto de todos los nodos de fuente conectados a una sola funcionalidad API (operationId).
Partiendo de un operationId, sigue las referencias simbólicas entre fuentes e imprime de una sola vez todos los archivos y números de línea relacionados. Decenas de greps se reemplazan por un solo comando.
yongol chain ExecuteWorkflow specs/
── Feature Chain: ExecuteWorkflow ──
OpenAPI api/openapi.yaml POST /workflows/{id}/execute
SSaC service/workflow/execute_workflow.ssac @get @empty @auth @state @call @publish @response
DDL db/workflows.sql CREATE TABLE workflows
DDL db/execution_logs.sql CREATE TABLE execution_logs
Rego policy/authz.rego resource: workflow
StateDiag states/workflow.md diagram: workflow → ExecuteWorkflow
FuncSpec func/billing/check_credits.go @func billing.CheckCredits
FuncSpec func/billing/deduct_credit.go @func billing.DeductCredit
FuncSpec func/worker/process_actions.go @func worker.ProcessActions
FuncSpec func/webhook/deliver.go @func webhook.Deliver
Hurl tests/scenario-happy-path.hurl scenario: scenario-happy-path.hurl
La estructura completa de una funcionalidad aparece en una sola pantalla. Las capas no conectadas no se imprimen.
Por qué funciona
No es magia. Funciona porque las fuentes ya se referencian entre sí.
En el framework yongol, cada capa SSOT (Single Source of Truth) apunta simbólicamente a las demás:
@get Model.Methodde SSaC → tabla DDL@auth action resourcede SSaC → política de autorización Rego@state diagramIDde SSaC → diagrama de estados Mermaid@call pkg.Funcde SSaC → implementación FuncSpec@publish "topic"de SSaC → funciones que se suscriben al mismo topic- operationId de OpenAPI → nombre de archivo SSaC
- Escenario Hurl → endpoint OpenAPI
apiClient.<op>()de React TSX → operationId de OpenAPI
Estas referencias fueron diseñadas originalmente para yongol validate — la etapa que valida de forma cruzada la coherencia de 9 SSOT antes del tiempo de compilación. Como validate ya las parsea, reutilizar la misma infraestructura convierte la extracción del feature chain en una travesía de grafo.
El recorrido
Partiendo de un operationId, el grafo de referencias se despliega así:
operationId (punto de entrada)
├── OpenAPI → path + method
├── SSaC → archivo de función de servicio
│ ├── @get → tablas DDL
│ ├── @auth → reglas de política Rego
│ ├── @state → transiciones de Mermaid stateDiagram
│ ├── @call → implementaciones FuncSpec
│ └── @publish → suscriptores de cola
├── Hurl → escenarios de prueba que referencian el operationId
└── React TSX → archivos de frontend que llaman al endpoint vía apiClient
Cada rama sigue exactamente un paso de referencia simbólica. Es un recorrido en amplitud, no en profundidad. Cada capa en la que una funcionalidad deja huella aparece.
Lo que esto cambia
Acotar los cambios
“¿Dónde toco para cambiar esta funcionalidad?”
Para responder eso leemos código, corremos grep, preguntamos a un compañero. Feature Chain sustituye la pregunta por un solo comando. Ningún archivo se escapa — mientras exista la referencia simbólica.
Edición guiada por IA
Lo más difícil al delegar un cambio de funcionalidad a una IA es decirle “cuál es el alcance”. La IA solo puede editar correctamente cuando los archivos relevantes están en su ventana de contexto, y un humano tiene que decidir cuáles son relevantes.
Con Feature Chain es distinto. Le entregas un solo operationId y todo el alcance se identifica automáticamente. El contexto de la IA queda listo sin que falte nada. Como los 9 SSOT son especificaciones declarativas — mucho más compactas que el código Go generado — se puede meter toda la cadena en la ventana de contexto con margen.
Code review
Al revisar un PR, “si tocaron esta funcionalidad, ¿no debería cambiar también ese archivo?” se vuelve trivial de verificar — basta con contrastar con la cadena. La estructura captura la inconsistencia entre capas en lugar de las personas.
Onboarding
Cuando una persona que se acaba de unir dice “quiero entender cómo funciona ExecuteWorkflow”, le muestras una Feature Chain. Desde la API hasta la BD, desde la política de autorización hasta los escenarios de prueba — todo el terreno de una funcionalidad en una sola pantalla.
Por qué operationId
La elección del punto de entrada importa. Feature Chain eligió operationId.
La razón es simple. En una aplicación full-stack, la unidad de una funcionalidad es el endpoint API. Un usuario pulsa un botón, se llama a una API, se ejecuta la lógica de servicio, se lee la BD, se comprueba la autorización, ocurren transiciones de estado. El inicio de todo ese flujo es el operationId.
operationId ya está definido en la especificación OpenAPI y es un nombre compartido por todo el equipo. Di “hay que modificar ExecuteWorkflow” y el backend, el frontend y QA piensan en lo mismo. Feature Chain está diseñado alrededor de ese nombre universal como hilo que atraviesa todo el stack.
yongol lo llama “operationId es la piedra angular (keystone)”. Un solo identificador en PascalCase une físicamente las 9 capas.
Condiciones previas
Para que Feature Chain funcione hay supuestos:
Las fuentes deben referenciarse simbólicamente unas a otras. Las directivas
@get,@auth,@state,@call,@publishde SSaC deben apuntar explícitamente a otros SSOT. Si la referencia es implícita — por ejemplo, un nombre de tabla de BD solo existe como string dentro del código — no se puede rastrear.yongol validatedebe pasar. Feature Chain sigue referencias simbólicas, así que si las referencias no son válidas el resultado es incorrecto. validate garantiza la integridad de las referencias; Feature Chain atraviesa encima de eso.
Por eso Feature Chain no es una herramienta de propósito general. No se puede aplicar a proyectos cualesquiera. Solo funciona en proyectos donde las referencias entre fuentes están diseñadas explícitamente — estructuras como yongol, donde los SSOT se apuntan unos a otros de forma explícita.
Futuro: GEUL + SILK
Hoy, Feature Chain recorre invocando cada parser SSOT por turno. Llama al parser de SSaC, al de DDL, al de Rego, al de Mermaid, al de Hurl y al de TSX, y luego combina los resultados.
Cuando todos los SSOT se traduzcan a un grafo GEUL, Feature Chain se convertirá en una sola consulta de índice. Con la operación AND bit a bit de SIDX en SILK, todos los nodos conectados a un operationId pueden extraerse en una sola consulta.
Del recorrido por parser a la consulta de grafo. La interfaz de Feature Chain sigue siendo la misma, pero el interior cambia de raíz.
Cierre
En una aplicación full-stack, una “funcionalidad” no vive en un solo archivo. Se extiende por varias capas y esas capas se referencian entre sí. Feature Chain sigue esas referencias para extraer automáticamente el alcance completo de una sola funcionalidad.
Escribe un operationId y lo obtienes todo: desde la especificación API hasta el esquema de BD, desde la política de autorización hasta los escenarios de prueba, desde la implementación de funciones hasta los componentes del frontend. Decenas de greps reemplazados por un solo comando. La IA recibe un contexto sin nada faltante; la persona recibe libertad sobre raíles.
Código: github.com/park-jun-woo/yongol