Que arquivos precisam ser tocados para modificar uma única funcionalidade? Digite um operationId e a resposta aparece.
O problema
Em uma aplicação full-stack, uma “funcionalidade” não vive em um só arquivo.
Suponha que você precise modificar uma funcionalidade chamada “ExecuteWorkflow”. Essa funcionalidade existe na especificação API, na lógica de serviço, no schema do banco de dados, na política de autorização, no diagrama de transição de estados, nas chamadas a funções externas, nos cenários de teste e nos componentes de frontend.
Historicamente, há duas maneiras de abarcar todo esse escopo:
- Rodar grep dezenas de vezes
- Rastrear o código à mão
Ambas são lentas e ambas deixam coisas de fora. Referências entre camadas em particular — da especificação API ao serviço, do serviço ao schema de BD, do serviço à política de autorização — são praticamente impossíveis de rastrear exaustivamente por um humano.
Fica pior quando você delega a edição para uma IA. Aos 200 endpoints, a IA não consegue mais segurar o contexto inteiro. O contexto colapsa, padrões derivam e a 201ª funcionalidade custa 10× a 21ª. Essa é a parede em que o vibe coding bate.
Mas se a fonte de cada camada referencia simbolicamente as outras, basta seguir essas referências para revelar todo o escopo automaticamente.
O que é Feature Chain
Feature Chain é o conjunto de todos os nós de fonte conectados a uma única funcionalidade API (operationId).
Partindo de um operationId, ele segue as referências simbólicas entre fontes e imprime de uma só vez todos os arquivos e números de linha relacionados. Dezenas de greps são substituídos por um único 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
A estrutura completa de uma funcionalidade aparece em uma única tela. Camadas não conectadas não são impressas.
Por que funciona
Não é mágica. Funciona porque as fontes já se referenciam entre si.
No framework yongol, cada camada SSOT (Single Source of Truth) aponta simbolicamente para as outras:
@get Model.Methodde SSaC → tabela DDL@auth action resourcede SSaC → política de autorização Rego@state diagramIDde SSaC → diagrama de estados Mermaid@call pkg.Funcde SSaC → implementação FuncSpec@publish "topic"de SSaC → funções que assinam o mesmo topic- operationId de OpenAPI → nome de arquivo SSaC
- Cenário Hurl → endpoint OpenAPI
apiClient.<op>()de React TSX → operationId de OpenAPI
Essas referências foram projetadas originalmente para yongol validate — a etapa que valida cruzadamente a consistência de 9 SSOTs antes da compilação. Como validate já as parseia, reutilizar a mesma infraestrutura transforma a extração do feature chain em travessia de grafo.
O caminho de travessia
Partindo de um operationId, o grafo de referências se expande assim:
operationId (ponto de entrada)
├── OpenAPI → path + method
├── SSaC → arquivo de função de serviço
│ ├── @get → tabelas DDL
│ ├── @auth → regras de política Rego
│ ├── @state → transições de Mermaid stateDiagram
│ ├── @call → implementações FuncSpec
│ └── @publish → assinantes de fila
├── Hurl → cenários de teste que referenciam o operationId
└── React TSX → arquivos de frontend que chamam o endpoint via apiClient
Cada ramo segue exatamente um passo de referência simbólica. É uma travessia em largura, não em profundidade. Cada camada em que uma funcionalidade deixa rastro aparece.
O que isso muda
Delimitar o escopo
“Onde eu toco para mudar essa funcionalidade?”
Para responder a isso, lemos código, rodamos grep, perguntamos a um colega. Feature Chain substitui a pergunta por um único comando. Nenhum arquivo escapa — desde que a referência simbólica exista.
Edição guiada por IA
O mais difícil ao delegar uma mudança de funcionalidade a uma IA é lhe dizer “qual é o escopo”. A IA só consegue editar corretamente quando os arquivos relevantes estão em sua janela de contexto, e um humano precisa julgar quais são relevantes.
Com Feature Chain é diferente. Entregue um operationId e todo o escopo é identificado automaticamente. O contexto da IA é preparado sem faltas. Como os 9 SSOTs são especificações declarativas — bem mais compactas que o código Go gerado — a cadeia toda cabe na janela de contexto com folga.
Code review
Ao revisar uma PR, “se tocaram nessa funcionalidade, aquele arquivo também não deveria mudar?” se torna trivial verificar — basta comparar com a cadeia. Inconsistências entre camadas são capturadas pela estrutura em vez das pessoas.
Onboarding
Quando uma pessoa recém-chegada diz “quero entender como ExecuteWorkflow funciona”, mostre uma Feature Chain. Da API ao BD, da política de autorização aos cenários de teste — todo o terreno de uma funcionalidade em uma tela só.
Por que operationId
A escolha do ponto de entrada importa. Feature Chain escolheu operationId.
A razão é simples. Em uma aplicação full-stack, a unidade de uma funcionalidade é o endpoint API. Um usuário aperta um botão, uma API é chamada, a lógica de serviço executa, o BD é lido, a autorização é verificada, transições de estado acontecem. O início de todo esse fluxo é o operationId.
operationId já está definido na especificação OpenAPI e é um nome compartilhado por todo o time. Diga “precisamos modificar ExecuteWorkflow” e o engenheiro backend, o frontend e o QA pensam na mesma coisa. Feature Chain é projetado em torno desse nome universal como fio que atravessa o stack inteiro.
yongol chama isso de “operationId é a pedra angular (keystone)”. Um único identificador PascalCase une fisicamente 9 camadas.
Pré-condições
Para Feature Chain funcionar, há premissas:
As fontes devem se referenciar simbolicamente entre si. As diretivas
@get,@auth,@state,@call,@publishde SSaC precisam apontar explicitamente para outros SSOTs. Se a referência é implícita — por exemplo, um nome de tabela de BD que só existe como string dentro do código — ela não pode ser rastreada.yongol validatedeve passar. Feature Chain segue referências simbólicas; se as referências não forem válidas, o resultado está errado. validate garante a integridade das referências; Feature Chain atravessa em cima disso.
É por isso que Feature Chain não é uma ferramenta de uso geral. Não se aplica a qualquer projeto. Só funciona em projetos onde as referências entre fontes são projetadas explicitamente — estruturas como yongol, em que os SSOTs apontam uns para os outros explicitamente.
Futuro: GEUL + SILK
Hoje, Feature Chain atravessa invocando cada parser SSOT por vez. Chama o parser SSaC, o DDL, o Rego, o Mermaid, o Hurl e o TSX, depois combina os resultados.
Quando todos os SSOTs forem traduzidos em um grafo GEUL, Feature Chain virará uma única consulta de índice. Com a operação AND bit a bit de SIDX no SILK, todos os nós conectados a um operationId podem ser extraídos em uma única consulta.
Da travessia por parser para a consulta de grafo. A interface de Feature Chain permanece a mesma, mas o interior muda radicalmente.
Fechamento
Em uma aplicação full-stack, uma “funcionalidade” não vive em um só arquivo. Se estende por várias camadas, e essas camadas se referenciam entre si. Feature Chain segue essas referências para extrair automaticamente todo o escopo de uma única funcionalidade.
Digite um operationId e você recebe tudo: da especificação API ao schema de BD, da política de autorização aos cenários de teste, da implementação de função ao componente de frontend. Dezenas de greps substituídos por um único comando. A IA recebe contexto sem faltas; o humano recebe liberdade sobre trilhos.
Código: github.com/park-jun-woo/yongol