¿Qué archivos hay que tocar para modificar una funcionalidad? Con un solo operationId, la respuesta aparece de inmediato.
El problema
En una aplicación fullstack, “una funcionalidad” no vive en un único archivo.
Supongamos que hay que modificar la función “aceptar propuesta” (AcceptProposal). Esa funcionalidad existe 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 estados, en las llamadas a funciones externas, en los escenarios de prueba y en el frontend.
Hasta ahora había dos formas de identificar ese alcance completo:
- Ejecutar grep decenas de veces
- Rastrear el código manualmente
Ambas son lentas y ambas producen omisiones. En particular, es prácticamente imposible que una persona rastree sin errores las referencias entre capas — de la especificación API al servicio, del servicio al esquema de base de datos, del servicio a la política de autorización.
Sin embargo, si cada capa referencia simbólicamente a las demás, basta con seguir esas referencias para que el alcance completo se revele de forma automática.
Qué es Feature Chain
Feature Chain extrae todos los nodos de código fuente conectados a una funcionalidad de API (operationId).
Tomando un operationId como punto de partida, sigue las referencias simbólicas entre fuentes y muestra de una vez todos los archivos y números de línea relacionados. Decenas de greps se reemplazan con un único comando.
fullend chain AcceptProposal specs/
── Feature Chain: AcceptProposal ──
OpenAPI api/openapi.yaml:296 POST /proposals/{id}/accept
SSaC service/proposal/accept_proposal.ssac:19 @get @empty @auth @state @put @call @post @response
DDL db/gigs.sql:1 CREATE TABLE gigs
DDL db/proposals.sql:1 CREATE TABLE proposals
DDL db/transactions.sql:1 CREATE TABLE transactions
Rego policy/authz.rego:3 resource: gig
StateDiag states/gig.md:7 diagram: gig → AcceptProposal
StateDiag states/proposal.md:6 diagram: proposal → AcceptProposal
FuncSpec func/billing/hold_escrow.go:8 @func billing.HoldEscrow
Gherkin scenario/gig_lifecycle.feature:4 Scenario: Happy Path - Full Gig Lifecycle
Gherkin scenario/gig_lifecycle.feature:42 Scenario: Unauthorized Access
La estructura completa de una funcionalidad aparece en una sola pantalla. Las capas que no están conectadas no se muestran.
Por qué es posible
Esto no es magia. Es posible porque las fuentes ya se referencian entre sí.
En el framework fullend, cada capa SSOT (Single Source of Truth) apunta simbólicamente a las demás:
- SSaC
@get Model.Method→ tabla DDL - SSaC
@auth action resource→ política de autorización Rego - SSaC
@state diagramID→ diagrama de estados Mermaid - SSaC
@call pkg.Func→ implementación Func Spec - OpenAPI operationId → nombre de archivo SSaC
- Gherkin action step → operationId
- STML endpoint → path OpenAPI
Estas referencias fueron diseñadas originalmente para crosscheck — la herramienta que valida la coherencia entre SSOT. Como crosscheck ya parsea estas referencias, reutilizar la misma infraestructura permite extraer el feature chain mediante un simple recorrido de grafo.
Rutas de exploración
Tomando el operationId como punto de partida, el grafo de referencias se despliega así:
operationId (punto de partida)
├── OpenAPI → path + method
├── SSaC → archivo de función de servicio
│ ├── @get → tablas DDL
│ ├── @auth → reglas de política Rego
│ ├── @state → transiciones stateDiagram Mermaid
│ ├── @call → implementaciones Func Spec
│ └── @publish → suscriptores de cola
├── Gherkin → escenarios que referencian el operationId
└── STML → archivos frontend que referencian el endpoint
Cada rama sigue solo un nivel de referencia simbólica. La exploración es en anchura, no en profundidad. Se revela en qué capas deja huella una funcionalidad.
Lo que cambia
Identificar el alcance de una modificación
“¿Dónde tengo que tocar para arreglar esta funcionalidad?”
Para responder esa pregunta leemos código, ejecutamos grep y preguntamos a compañeros. Feature Chain reemplaza esa pregunta con un único comando. No se escapa ningún archivo — mientras exista una referencia simbólica.
Modificaciones de código con IA
Cuando se delega a una IA la modificación de una funcionalidad, lo más difícil es “comunicarle el alcance”. Para que la IA modifique con precisión, hay que meter en la ventana de contexto todos los archivos relacionados, y es el humano quien tiene que determinar cuáles lo son.
Con Feature Chain, eso cambia. Basta con indicar un operationId para que el alcance completo de la modificación se identifique automáticamente. El contexto que se pasa a la IA queda completo, sin omisiones.
Code review
Al revisar un PR, si surge la duda “si se modificó esta funcionalidad, ¿no debería haber cambiado también ese archivo?”, basta con contrastar con el chain para comprobarlo al momento. La estructura detecta inconsistencias entre capas en lugar de depender de que las detecte una persona.
Onboarding
Cuando un desarrollador recién incorporado dice “quiero entender cómo funciona AcceptProposal”, basta con mostrarle un Feature Chain. Desde la API hasta la base de datos, desde la política de autorización hasta los escenarios de prueba — toda la arquitectura de la funcionalidad queda visible de un vistazo.
Por qué operationId
El punto de partida es importante. Feature Chain elige el operationId.
La razón es sencilla. En una aplicación fullstack, la unidad de una funcionalidad es el endpoint de API. El usuario pulsa un botón, se llama a la API, esa API ejecuta la lógica de servicio, lee la base de datos, verifica la autorización y ejecuta las transiciones de estado. El operationId es el punto de inicio de todo ese flujo.
El operationId ya está definido en la especificación OpenAPI y es el nombre que comparte todo el equipo. Cuando alguien dice “hay que modificar AcceptProposal”, tanto el desarrollador backend como el frontend como QA evocan lo mismo. El diseño de Feature Chain consiste en atravesar todo el stack con ese único nombre universal.
Requisitos previos
Para que Feature Chain funcione, hay condiciones previas:
Las fuentes deben referenciarse simbólicamente entre sí. Las directivas
@get,@auth,@statey@callde SSaC deben apuntar explícitamente a otros SSOT. Si las referencias son implícitas — por ejemplo, si el nombre de una tabla de base de datos existe solo como cadena dentro del código — no es posible rastrearlas.Debe pasar crosscheck. Feature Chain sigue referencias simbólicas, por lo que si una referencia no es válida, el resultado será incorrecto. Crosscheck garantiza la coherencia de las referencias, y Feature Chain explora sobre esa base.
Por eso Feature Chain no es una herramienta de propósito general. No se puede aplicar a cualquier proyecto. Solo funciona en proyectos donde las referencias entre fuentes están diseñadas — estructuras donde los SSOT se apuntan explícitamente entre sí, como ocurre en fullend.
El futuro: GEUL + SILK
Actualmente Feature Chain recorre los parsers de cada SSOT para explorar. Llama al parser de SSaC, al parser de DDL, al parser de Rego y al parser de Mermaid por separado, y luego combina los resultados.
Cuando todos los SSOT se conviertan en un grafo GEUL, Feature Chain pasará a ser una consulta de índice único. Mediante una operación AND bit a bit del SIDX de SILK, todos los nodos conectados a un operationId podrán extraerse con una sola consulta.
Del recorrido por parsers a la consulta de grafo. La interfaz de Feature Chain será la misma, pero el interior cambiará de forma radical.
Resumen
En una aplicación fullstack, una “funcionalidad” no está en un único archivo. Se extiende por varias capas, y esas capas se referencian entre sí. Feature Chain sigue esas referencias y extrae automáticamente el alcance completo de una funcionalidad.
Con un solo operationId, desde la especificación API hasta el esquema de base de datos, desde la política de autorización hasta los escenarios de prueba — decenas de greps se reemplazan con un único comando.
Código: github.com/park-jun-woo/fullend