Solutions

Gardez les raisons derrière le code là où on peut les retrouver.

Pourquoi le système est ce qu'il est vit dans les têtes, les fils de discussion et les billets fermés. Une nouvelle personne dans l'équipe, ou un agent à qui l'on demande de changer le code, travaille à partir du code seul et redécide ce qui était déjà décidé.

Pourquoi cela se répète

Le code porte la décision, pas sa raison.

Une décision de conception se prend dans un fil de revue ou un appel, et le code qui suit porte le résultat mais pas la raison. Des mois plus tard, c'est la raison qui compte, et elle est dans un billet fermé que personne ne rouvre.

Écrire la conception dans le dépôt de code ne règle rien. Le code source change à chaque commit, donc un document à côté est soit périmé, soit relu à chaque changement, et un index reconstruit à chaque commit est un index auquel personne ne fait confiance.

Les agents rendent l'écart visible. À qui l'on demande en même temps ce que fait le code et ce qu'il devrait faire, un assistant qui travaille à partir de la source seule répond à la première question et devine la seconde.

Comment nous le résolvons

Un dépôt de spécifications à côté de la source, validé et indexé.

sdd conserve l'intention de conception dans un dépôt de spécifications dédié, séparé de la source à dessein : architecture, registres de décisions, conceptions de fonctionnalités et une fiche pour chaque élément de travail qui prend une décision. Le corpus est validé en CI, indexé par vecteurs et par les relations entre spécifications, et consulté par les personnes et les agents qui font le travail.

Configurer le dépôt

Exécutez la commande d'initialisation dans un dépôt source. Elle écrit la configuration du projet et du développeur, génère les compétences d'agent et ajoute un bloc délimité par des marqueurs aux instructions de l'assistant. Une commande de diagnostic prouve ensuite que la chaîne fonctionne : endpoint, authentification, enregistrement MCP.

sdd init · sdd doctor

Écrire la spécification avant le code

Un élément de travail qui n'est pas prêt pour une spécification est renvoyé plutôt que deviné : il lui faut un type, un objectif testable, des critères d'acceptation sous forme de liste et un énoncé utilisateur. Le conseiller de spécification récupère les décisions antérieures dans l'index et rédige la spécification à leur lumière avant que l'implémentation ne commence.

spec.md

Confronter les spécifications au code

La CI du dépôt de spécifications valide le format à chaque changement. Une tâche de CI dans le dépôt source vérifie que les spécifications décrivent toujours du code réel, et la compétence de revue signale un changement qui touche une spécification en vigueur sans la modifier, pendant que ce n'est encore qu'un commentaire.

sdd validate --refs

Indexer et consulter

L'index ingère le dépôt de spécifications quand sa révision change, stocke les segments comme vecteurs et les liens entre spécifications comme graphe, et sert les deux aux compétences et aux développeurs par un endpoint MCP avec authentification. Une compétence d'entretien, exécutée chaque jour, compare l'index, les spécifications et les billets fermés.

vecteurs · graphe · MCP
Ce que vous obtenez

Des décisions qui survivent au fil de discussion où elles ont été prises.

Chaque changement significatif a une spécification, ou en modifie une, qui dit à quoi il servait, ce qu'il doit satisfaire et à quoi il se rattache, et la spécification est consultable au moment où le changement suivant commence.

  • Une spécification pour chaque élément de travail qui prend une décision, avec des critères d'acceptation à partir desquels les tests sont écrits.
  • Les spécifications en vigueur portent des références au code qu'elles décrivent, vérifiées en CI, de sorte qu'une dérive apparaît comme une tâche échouée plutôt que comme une surprise.
  • Un agent à qui l'on demande de changer le système récupère d'abord les décisions antérieures, au lieu de les déduire du code.
  • Le format n'a qu'une implémentation, dans la CLI, de sorte que les frontières de segments vues par l'auteur sont celles que l'index intègre.
Fiche de spécification
  • type feature-design
  • objectif un énoncé testable
  • refs src/api/upload.ts · valide
  • liens remplace ADR-upload-limits
Où cela s'exécute

Open source, auto-hébergé.

sdd est open source, publié sur npm sous @dependably/sdd, et s'adopte dans un dépôt en une commande. L'index tourne sur votre propre infrastructure à partir d'un ensemble Docker Compose fourni dans le même dépôt : un magasin de vecteurs, un magasin de graphe, la tâche d'ingestion et l'API de requête exposée comme serveur MCP, avec des plongements locaux en option.