Commandes SDD (10)

/sdd-init

Quand : Au démarrage d’un projet, après npx aiad-sdd init. Ce que ça fait : Guide la rédaction interactive de PRD.md, ARCHITECTURE.md et AGENT-GUIDE.md. Pose les questions de cadrage, génère les documents, vérifie leur complétude. Sortie : 3 artefacts fondamentaux complétés et prêts à être committés dans .aiad/.

/sdd-intent

Quand : Avant de rédiger une SPEC, pour chaque user story à implémenter. Ce que ça fait : Guide la rédaction de l’Intent Statement en 5 champs (POURQUOI MAINTENANT, POUR QUI, OBJECTIF, CONTRAINTES, CRITÈRE DE DRIFT). Vérifie la complétude et crée le fichier dans .aiad/intents/. Le champ Auteur humain est obligatoire — principe Human Authorship. Sortie : Fichier INTENT-XXX-[nom].md dans .aiad/intents/ + mise à jour _index.md.

/sdd-spec

Quand : Une fois l’Intent Statement validé par le PM. Ce que ça fait : Vérifie qu’un Intent Statement parent existe, propose la décomposition en tâches atomiques, rédige la SPEC au format standardisé (scope, objectif, fichiers impactés, interface, comportement, cas limites, tests, critère de drift). Met à jour les index. Sortie : Fichier SPEC-XXX-[nom].md dans .aiad/specs/ + mise à jour _index.md.

/sdd-gate

Quand : Avant tout lancement d’agent de code, pour valider la SPEC. Ce que ça fait : Évalue les 5 critères SQS (atomicité, précision, testabilité, non-ambiguïté, scope défini) + le Critère 6 non-scorable “Test de l’Étranger”. Score ≥ 4/5 : gate ouverte. Score < 4/5 : retour en révision. Si gate ouverte, prépare le Context Engineering Budget. Sortie : Score SQS + décision gate ouverte/fermée + contexte d’injection préparé.

/sdd-exec

Quand : Gate ouverte, SPEC committée, contexte préparé. Ce que ça fait : Structure le prompt de lancement avec le bon contexte (AGENT-GUIDE + ARCHITECTURE condensée + SPEC active uniquement). Exige un plan d’implémentation avant le code. Maintient l’agent dans le scope de la SPEC. Sortie : Plan d’implémentation validé puis code + tests conformes à la SPEC.

/sdd-resume

Quand : Session agent interrompue (timeout, erreur, limite de contexte). Ce que ça fait : Reconstruit un contexte propre depuis le résumé de la session précédente. Évite de réinjecter tout le contexte depuis zéro. Reprend à l’étape exacte où la session s’est arrêtée. Sortie : Nouvelle session agent opérationnelle avec contexte minimal et précis.

/sdd-split

Quand : SPEC trop volumineuse pour une session, ou échec d’atomicité à la Gate. Ce que ça fait : Guide la décomposition d’une SPEC en sous-SPECs atomiques selon les patterns Vertical (par couche), Flux (happy path / edge cases / errors) ou Contrat (interface d’abord). Maintient la traçabilité vers l’Intent parent. Sortie : 2 à N nouvelles SPECs atomiques avec dépendances explicites, SPEC originale archivée.

/sdd-context

Quand : Après une session agent, pour améliorer le Context Engineering Budget. Ce que ça fait : Boucle de feedback post-session. Compare l’estimation de contexte avec la réalité (tokens consommés, dégradation observée, durée effective). Produit des recommandations pour la prochaine session. Sortie : Rapport d’audit contexte avec recommandations d’optimisation pour le PE.

/sdd-validate

Quand : À la fin de chaque session d’implémentation, avant le Drift Lock. Ce que ça fait : Validation sur 3 axes — technique (lint, types, tests, build), fonctionnel (conformité aux cas de test de la SPEC), gouvernance (4 agents Tier 1 : AI-ACT, RGPD, RGAA, RGESN). Produit un rapport actionnable. Sortie : Rapport VALIDÉ / CORRECTIONS / REJET avec liste des non-conformités.

/sdd-drift-check

Quand : Avant chaque PR, et en rituel de fin d’itération (Anti-Drift Check). Ce que ça fait : Scanne les fichiers modifiés, compare chaque SPEC active avec le code, détecte les drifts, vérifie le CRITÈRE DE DRIFT de l’Intent Statement d’origine. Propose les mises à jour nécessaires. Sortie : Liste des SPECs synchronisées / en drift + mises à jour proposées + commit Drift Lock prêt.