Welche Dateien muss man anfassen, um eine einzelne Funktionalitaet zu aendern? Tippe eine operationId ein und die Antwort erscheint.
Das Problem
In einer Fullstack-Anwendung lebt eine „Funktionalitaet" nicht in einer einzigen Datei.
Angenommen, du musst eine Funktionalitaet namens „ExecuteWorkflow" aendern. Diese Funktionalitaet liegt in der API-Spezifikation, in der Service-Logik, im Datenbankschema, in der Autorisierungspolitik, im Zustandsuebergangsdiagramm, in externen Funktionsaufrufen, in Testszenarien und in Frontend-Komponenten.
Bisher gab es zwei Wege, den Gesamtumfang zu erfassen:
- Dutzende Male grep ausfuehren
- Den Code von Hand nachverfolgen
Beides ist langsam und beides laesst Dinge aus. Besonders schichtuebergreifende Referenzen — von der API-Spezifikation zum Service, vom Service zum DB-Schema, vom Service zur Autorisierungspolitik — sind fuer einen Menschen praktisch unmoeglich vollstaendig zu verfolgen.
Noch schlimmer wird es, wenn man die Aenderung einer KI uebergibt. Bei 200 Endpoints kann die KI den Gesamtkontext nicht mehr halten. Der Kontext kollabiert, Patterns driften ab, und die 201. Funktionalitaet kostet das Zehnfache der 21. Das ist die Wand, gegen die Vibe Coding prallt.
Aber wenn jede Schicht in ihren Quellen symbolisch auf andere Schichten verweist, reicht es, diesen Verweisen zu folgen, um den gesamten Umfang automatisch offenzulegen.
Was Feature Chain ist
Feature Chain ist die Menge aller Quellknoten, die mit einer einzelnen API-Funktionalitaet (operationId) verbunden sind.
Ausgehend von einer operationId folgt es den symbolischen Referenzen zwischen Quellen und gibt alle zusammenhaengenden Dateien und Zeilennummern in einem Rutsch aus. Dutzende grep-Aufrufe werden durch einen einzigen Befehl ersetzt.
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
Die gesamte Struktur einer Funktionalitaet erscheint auf einem Bildschirm. Nicht verbundene Schichten werden nicht ausgegeben.
Warum es funktioniert
Das ist keine Magie. Es funktioniert, weil die Quellen sich bereits gegenseitig referenzieren.
Im yongol-Framework zeigt jede SSOT-Schicht (Single Source of Truth) symbolisch auf die anderen:
@get Model.Methodvon SSaC → DDL-Tabelle@auth action resourcevon SSaC → Rego-Autorisierungspolitik@state diagramIDvon SSaC → Mermaid-Zustandsdiagramm@call pkg.Funcvon SSaC → FuncSpec-Implementierung@publish "topic"von SSaC → Funktionen, die dasselbe Topic abonnieren- operationId von OpenAPI → SSaC-Dateiname
- Hurl-Szenario → OpenAPI-Endpoint
apiClient.<op>()von React TSX → OpenAPI operationId
Diese Referenzen wurden urspruenglich fuer yongol validate entworfen — den Schritt, der die Konsistenz von 9 SSOTs vor der Kompilierung kreuzweise validiert. Da validate sie bereits parst, wird durch Wiederverwendung derselben Infrastruktur die Feature-Chain-Extraktion zur Graph-Traversierung.
Der Traversierungspfad
Wenn man eine operationId als Startpunkt nimmt, entfaltet sich der Referenzgraph so:
operationId (Einstiegspunkt)
├── OpenAPI → path + method
├── SSaC → Service-Funktionsdatei
│ ├── @get → DDL-Tabellen
│ ├── @auth → Rego-Regeln
│ ├── @state → Mermaid-stateDiagram-Uebergaenge
│ ├── @call → FuncSpec-Implementierungen
│ └── @publish → Queue-Abonnenten
├── Hurl → Testszenarien, die auf operationId verweisen
└── React TSX → Frontend-Dateien, die den Endpoint ueber apiClient aufrufen
Jeder Zweig folgt genau einem Schritt symbolischer Referenz. Es ist eine Breiten-, keine Tiefensuche. Jede Schicht, in der eine Funktionalitaet Spuren hinterlaesst, taucht auf.
Was sich dadurch aendert
Aenderungsumfang erfassen
„Wo muss ich anfassen, um diese Funktionalitaet zu aendern?"
Um das zu beantworten, lesen wir Code, lassen grep laufen, fragen Kolleg:innen. Feature Chain ersetzt die Frage durch einen einzigen Befehl. Keine Datei rutscht durch — solange die symbolische Referenz existiert.
KI-gestuetzte Code-Aenderung
Das Schwierigste beim Delegieren einer Funktionsaenderung an eine KI ist, ihr „den Umfang" zu sagen. Die KI kann nur dann korrekt aendern, wenn die relevanten Dateien im Kontextfenster sind, und ein Mensch muss entscheiden, welche relevant sind.
Mit Feature Chain ist das anders. Man gibt eine operationId und der gesamte Umfang wird automatisch identifiziert. Der Kontext fuer die KI wird lueckenlos vorbereitet. Weil die 9 SSOTs deklarative Spezifikationen sind — weit kompakter als der generierte Go-Code — passt die gesamte Kette ins Kontextfenster mit Luft nach oben.
Code Review
Beim Reviewen einer PR wird „Wenn sie diese Funktionalitaet angefasst haben, muesste sich nicht auch jene Datei aendern?" trivial zu pruefen — einfach mit der Kette abgleichen. Schichtuebergreifende Inkonsistenzen faengt die Struktur statt Menschen.
Onboarding
Wenn eine neue Person sagt „Ich will verstehen, wie ExecuteWorkflow funktioniert", zeigst du ihr einfach eine Feature Chain. Von der API bis zur DB, von der Autorisierungspolitik bis zu den Testszenarien — das gesamte Gelaende einer Funktionalitaet auf einem Bildschirm.
Warum operationId
Die Wahl des Startpunkts zaehlt. Feature Chain hat sich fuer operationId entschieden.
Der Grund ist einfach. In einer Fullstack-Anwendung ist die Einheit einer Funktionalitaet der API-Endpoint. Jemand drueckt einen Button, eine API wird aufgerufen, Service-Logik laeuft, die DB wird gelesen, die Autorisierung geprueft, Zustaende werden gewechselt. Der Anfang dieses gesamten Flusses ist die operationId.
operationId ist in der OpenAPI-Spezifikation bereits definiert und ein vom ganzen Team geteilter Name. Sagt jemand „wir muessen ExecuteWorkflow aendern", denken Backend, Frontend und QA an dasselbe. Feature Chain ist um diesen universellen Namen als Durchgang durch den gesamten Stack konzipiert.
yongol nennt das „operationId ist der Schlussstein (keystone)". Ein einziger PascalCase-Bezeichner bindet 9 Schichten physisch zusammen.
Voraussetzungen
Damit Feature Chain funktioniert, gelten Annahmen:
Quellen muessen sich symbolisch gegenseitig referenzieren. Die Direktiven
@get,@auth,@state,@call,@publishvon SSaC muessen explizit auf andere SSOTs zeigen. Ist die Referenz implizit — etwa ein DB-Tabellenname, der nur als String im Code existiert — ist sie nicht nachverfolgbar.yongol validatemuss durchlaufen. Feature Chain folgt symbolischen Referenzen; sind die Referenzen nicht valide, ist das Ergebnis falsch. validate garantiert die Referenzintegritaet; Feature Chain traversiert darueber.
Deshalb ist Feature Chain kein Allzweckwerkzeug. Es laesst sich nicht auf beliebige Projekte anwenden. Es funktioniert nur in Projekten, in denen quellenuebergreifende Referenzen by design sind — Strukturen wie yongol, in denen SSOTs explizit aufeinander zeigen.
Zukunft: GEUL + SILK
Aktuell traversiert Feature Chain, indem es jeden SSOT-Parser der Reihe nach aufruft. Es ruft den SSaC-Parser, den DDL-Parser, den Rego-Parser, den Mermaid-Parser, den Hurl-Parser und den TSX-Parser auf und kombiniert die Ergebnisse.
Sobald alle SSOTs in einen GEUL-Graphen uebersetzt sind, wird Feature Chain zu einer einzigen Index-Abfrage. Mit der bitweisen AND-Operation von SIDX in SILK lassen sich alle mit einer operationId verbundenen Knoten in einer einzigen Abfrage extrahieren.
Von der parserweisen Traversierung zur Graph-Abfrage. Die Schnittstelle von Feature Chain bleibt gleich, die Interna aendern sich aber grundlegend.
Fazit
In einer Fullstack-Anwendung lebt eine „Funktionalitaet" nicht in einer einzigen Datei. Sie erstreckt sich ueber mehrere Schichten, und diese Schichten verweisen aufeinander. Feature Chain folgt diesen Verweisen, um den gesamten Umfang einer einzelnen Funktionalitaet automatisch zu extrahieren.
Tippe eine operationId und du bekommst alles: von der API-Spezifikation bis zum DB-Schema, von der Autorisierungspolitik bis zu den Testszenarien, von der Funktionsimplementierung bis zur Frontend-Komponente. Dutzende grep-Aufrufe ersetzt durch einen einzigen Befehl. Die KI bekommt lueckenlosen Kontext; der Mensch bekommt Freiheit auf Schienen.