Quels fichiers faut-il toucher pour modifier une fonctionnalité ? Donnez un operationId, vous obtenez la réponse.
Le problème
Dans une application fullstack, « une fonctionnalité » ne tient pas dans un seul fichier.
Imaginons qu’il faille modifier la fonctionnalité « AcceptProposal ». Elle existe dans la spec API, dans la logique de service, dans le schéma de base de données, dans la politique d’autorisation, dans le diagramme d’état, dans les appels de fonctions externes, dans les scénarios de test et dans le frontend.
Jusqu’ici, deux approches permettaient d’en cerner la portée complète :
- Lancer Grep des dizaines de fois
- Tracer le code manuellement
Les deux sont lentes, les deux laissent passer des oublis. En particulier, suivre à la main toutes les références qui traversent les couches — de la spec API au service, du service au schéma DB, du service à la politique d’autorisation — est en pratique très difficile.
Pourtant, si chaque couche référence symboliquement les autres, il suffit de suivre ces références pour que la portée complète se révèle automatiquement.
Qu’est-ce que Feature Chain
Feature Chain extrait tous les nœuds sources liés à une fonctionnalité API (operationId).
En partant d’un operationId, il parcourt les références symboliques entre sources et affiche en une seule fois tous les fichiers concernés avec leurs numéros de ligne. Des dizaines de Grep remplacés par une seule commande.
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 structure complète d’une fonctionnalité tient sur un seul écran. Les couches sans connexion ne sont pas affichées.
Pourquoi c’est possible
Ce n’est pas de la magie. C’est possible parce que les sources se référencent déjà mutuellement.
Dans le framework fullend, chaque couche SSOT (Single Source of Truth) pointe symboliquement vers les autres :
- SSaC
@get Model.Method→ table DDL - SSaC
@auth action resource→ politique d’autorisation Rego - SSaC
@state diagramID→ diagramme d’état Mermaid - SSaC
@call pkg.Func→ implémentation Func Spec - OpenAPI operationId → nom de fichier SSaC
- Gherkin action step → operationId
- STML endpoint → chemin OpenAPI
Ces références ont été conçues à l’origine pour le crosscheck — un outil de validation de la cohérence entre les SSOT. Comme crosscheck les parse déjà, réutiliser la même infrastructure permet d’extraire la feature chain par simple parcours de graphe.
Chemin de parcours
En prenant l’operationId comme point de départ, le graphe de références se déploie ainsi :
operationId (point de départ)
├── OpenAPI → path + method
├── SSaC → fichier de fonction de service
│ ├── @get → tables DDL
│ ├── @auth → règles de politique Rego
│ ├── @state → transitions stateDiagram Mermaid
│ ├── @call → implémentations Func Spec
│ └── @publish → abonnés à la file
├── Gherkin → scénarios référençant l'operationId
└── STML → fichiers frontend référençant l'endpoint
Chaque branche ne suit qu’un seul niveau de référence symbolique. L’exploration est large, pas profonde. Toutes les couches où une fonctionnalité laisse une trace sont révélées.
Ce que cela change
Évaluation de la portée d’une modification
« Où doit-on intervenir pour corriger cette fonctionnalité ? »
Pour répondre à cette question, on lit du code, on lance des Grep, on demande à un collègue. Feature Chain remplace cette question par une seule commande. Aucun fichier ne passe à travers les mailles — tant qu’il existe une référence symbolique.
Modification de code par IA
Quand on confie une modification à une IA, la difficulté principale est de lui communiquer la portée. L’IA ne peut modifier correctement que si tous les fichiers concernés sont dans sa fenêtre de contexte — et c’est à l’humain de déterminer lesquels.
Avec Feature Chain, c’est différent. Il suffit de fournir un operationId pour que la portée complète soit identifiée automatiquement. Le contexte à transmettre à l’IA est prêt, sans omission.
Code review
Lors de la revue d’une PR, si le doute surgit — « cette fonctionnalité a été modifiée, mais tel fichier n’aurait-il pas dû changer aussi ? » — il suffit de croiser avec la chain pour le vérifier immédiatement. C’est la structure, et non l’humain, qui repère les incohérences entre couches.
Onboarding
Quand un développeur nouvellement arrivé demande « comment fonctionne AcceptProposal ? », montrez-lui une Feature Chain. De l’API à la DB, de la politique d’autorisation aux scénarios de test — toute la topographie de la fonctionnalité est visible d’un seul coup d’œil.
Pourquoi operationId
Le choix du point de départ est crucial. Feature Chain a opté pour l’operationId.
La raison est simple. Dans une application fullstack, l’unité d’une fonctionnalité est l’endpoint API. L’utilisateur clique sur un bouton, l’API est appelée, elle exécute la logique de service, lit la DB, vérifie les autorisations, effectue les transitions d’état. L’operationId est le point de départ de tout ce flux.
L’operationId est déjà défini dans la spec OpenAPI et c’est un nom partagé par toute l’équipe. Quand on dit « il faut modifier AcceptProposal », le développeur backend, le développeur frontend et le QA pensent tous à la même chose. Traverser toute la stack avec ce nom universel unique, c’est le principe de conception de Feature Chain.
Prérequis
Feature Chain impose des conditions préalables :
Les sources doivent se référencer symboliquement. Les directives
@get,@auth,@state,@callde SSaC doivent pointer explicitement vers d’autres SSOT. Si les références sont implicites — par exemple, un nom de table DB qui n’existe qu’en chaîne de caractères dans le code — le traçage est impossible.Le crosscheck doit être validé. Feature Chain suit les références symboliques ; si une référence est invalide, le résultat sera incorrect. Le crosscheck garantit la cohérence des références, et Feature Chain explore sur cette base.
C’est pourquoi Feature Chain n’est pas un outil généraliste. Il ne s’applique pas à n’importe quel projet. Il fonctionne uniquement dans les projets où les références entre sources sont conçues explicitement — comme fullend, où les SSOT se pointent mutuellement.
Perspectives : GEUL + SILK
Actuellement, Feature Chain parcourt les parsers de chaque SSOT successivement. Il appelle le parser SSaC, le parser DDL, le parser Rego, le parser Mermaid séparément, puis combine les résultats.
Quand tous les SSOT seront convertis en graphe GEUL, Feature Chain deviendra une requête sur un index unique. Par opération AND bit à bit sur les SIDX de SILK, tous les nœuds liés à un operationId pourront être extraits en une seule requête.
Du parcours par parsers à la requête de graphe. L’interface de Feature Chain reste la même, mais le fonctionnement interne change radicalement.
En résumé
Dans une application fullstack, une « fonctionnalité » ne tient pas dans un seul fichier. Elle s’étend sur plusieurs couches qui se référencent mutuellement. Feature Chain suit ces références et extrait automatiquement la portée complète d’une fonctionnalité.
Donnez un operationId en entrée — de la spec API jusqu’au schéma DB, de la politique d’autorisation jusqu’aux scénarios de test — des dizaines de Grep remplacés par une seule commande.