Commandes SDD (13)

/sdd-init

Quand : Au démarrage d’un projet, après npx aiad-sdd init. Ce que ça fait : En première étape, affiche le message suivant : “Pour charger toutes les 27 commandes AIAD dans cette session, il est recommandé de relancer l’agent maintenant avec /exit puis de relancer la commande. Souhaitez-vous continuer sans redémarrage ?” Si l’utilisateur continue sans redémarrage, note en contexte que certaines skills pourraient ne pas être disponibles. Guide ensuite 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. Note (v1.7) : la commande implémente le pattern Interrogatory LLM (Fowler, 2026) — l’agent construit le contexte en interrogeant l’humain par questions ciblées plutôt qu’en recevant passivement un prompt. C’est aussi une optimisation technique : une intention claire en début de contexte réduit l’exploration de l’agent et la consommation de tokens (approches intent-based : jusqu’à −96 % de tokens, AWS Strands 2026). 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. Option REASONS Canvas (v1.6) : si l’utilisateur le souhaite, propose d’utiliser le REASONS Canvas (SPDD — Kevlin Henney) comme approche de structuration de la SPEC avant de passer au format standard — les deux sont compatibles, le REASONS Canvas enrichit la justification de l’intention sans remplacer le format de SPEC AIAD. 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. Légitimation empirique (v1.7) : l’Execution Gate n’est pas une précaution philosophique — c’est une réponse à un biais d’action mesuré de 35 à 65 % sur les agents de pointe (FixedBench, 2026) et au constat que l’autorité de fusion reste « presque exclusivement humaine » (29 585 PRs analysés). Effets irréversibles (v1.7) : si l’exécution implique des effets financiers ou opérationnels irréversibles (agent à autonomie financière, déploiement automatique, achat), la Gate valide en outre les plafonds d’autonomie et les points de contrôle (plafond documenté, journal d’audit, procédure de rollback). Mapping SQS ↔ révision graduée (v1.7) : la révision du code produit peut être outillée via /code-review de Claude Code, dont les niveaux d’effort se mappent sur le SQS — SQS 3/5 → effort low, 4/5 → medium, 5/5 → high. C’est une implémentation outillée de la « programmation agentique sérieuse » (Fowler) : l’humain valide, il ne délègue pas. 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.

/sdd-fact

Quand : Un écart est constaté entre le comportement livré et le comportement désiré, sans justifier un nouveau cycle Intent complet (bug mineur, comportement inattendu, drift partiel). Ce que ça fait : (1) Capture le fait technique — description précise de l’écart : livré vs. désiré. (2) Qualifie l’impact : fonctionnel / sécurité / performance / conformité spec. (3) Décide de l’action corrective parmi quatre options : patch immédiat / nouveau Intent Statement / ajustement SPEC existante / documentation comme dette technique connue. (4) Trace dans .aiad/facts/FACT-NNN.md avec lien vers la SPEC concernée — contribue au Drift Lock. Sortie : Fichier FACT-NNN.md dans .aiad/facts/ avec décision tracée et lien SPEC.

/sdd-security

Quand : Après implémentation d’une fonctionnalité impliquant des accès, des données utilisateur, des secrets, ou un composant IA. Recommandé avant toute PR critique. Ce que ça fait : (1) Recommande explicitement d’utiliser un modèle frontier (Opus 4.7 ou équivalent) pour cet audit. (2) Parcourt le code sur les axes OWASP Top 10, gestion des secrets, permissions des agents (Harness Engineering — minimal necessary permissions), exposition des données. (3) Vérifie la conformité avec AIAD-AI-ACT et AIAD-RGPD si le contexte le justifie. (4) Produit un rapport structuré : risques critiques / risques moyens / bonnes pratiques confirmées. (5) Persiste dans .aiad/metrics/security/. Sortie : Rapport sécurité structuré persisté dans .aiad/metrics/security/YYYY-MM-DD-SPEC-NNN.md.

/sdd-audit

Quand : Après implémentation, avant ou pendant la validation — notamment pour les fonctionnalités à fort enjeu technique ou après plusieurs itérations d’un même composant. Ce que ça fait : (1) Recommande un modèle performant pour l’analyse (Opus 4.7 ou Sonnet 4.6). (2) Vérifie la conformité code ↔ SPEC : couverture des critères d’acceptance, drift détecté. (3) Évalue la dette technique introduite : complexité, couplage, lisibilité. (4) Vérifie la cohérence avec les conventions du projet (AGENT-GUIDE). (5) Produit un rapport : conformité SPEC / qualité / dette / recommandations. (6) Persiste dans .aiad/metrics/audit/. Sortie : Rapport audit structuré persisté dans .aiad/metrics/audit/YYYY-MM-DD-SPEC-NNN.md.