dev-plan

Prompt file imported from zekiriabd/SDD-Pro (.codex/prompts/dev-plan.md). Fill in {{arguments}} before use. Copyright stays with the author.

Arguments: {{arguments}}

/dev-plan — Génère les plans techniques d'1 FEAT sans coder

⚠️ Commande interne v7.0.0 — invoquée par /sdd-full STEP 3.6 (conditionnel). Utilisateur final : préférer /sdd-full ou /dev-run (gèrent pré-conditions, idempotence, état).

Pour chaque US de la FEAT {n}, invoque les agents dev-backend et dev-frontend en mode Plan Only : ils lisent l'US (+ mockup HTML en lecture texte directe pour le front), planifient inline les fichiers à produire, écrivent le plan dans workspace/plans/{n}-{m}-{Name}.{back|front}.md, et s'arrêtent — aucun fichier de code généré, aucun build.

L'humain peut relire et éditer ces fichiers de plan, puis lancer /dev-run {n} qui détectera les plans et les consommera tels quels au lieu de re-planifier.

Usage : /dev-plan {n} — où {n} est le numéro de la FEAT.

Cas d'emploi :

• Tu veux valider le découpage technique avant la génération
• Tu veux ajuster manuellement les fichiers à produire (retirer, ajouter, renommer)
• Tu veux tester un changement de stack et comparer ce que les agents prévoient avant d'effectivement coder

STEP 1 — Valider l'argument

Argument obligatoire : {n} (entier ≥ 1).

Si absent → demander :

Quel est le numéro de la FEAT à planifier ? (ex. : 1)

Si non numérique →

ERROR: /dev-plan — argument invalide
CAUSE: [INVALID_ARG] "{argument}" n'est pas un entier
FIX: relancer /dev-plan {n} (ex. /dev-plan 1)

STEP 2 — Lister les US à planifier

Glob workspace/us/{n}-*.md → liste US_LIST (basenames sans extension).

Si US_LIST est vide →

ERROR: /dev-plan — aucune US à planifier
CAUSE: [US_NOT_FOUND] aucun fichier workspace/us/{n}-*.md
FIX: lancer /us-generate {n} pour générer les US d'abord

Émettre 1 ligne :

FEAT {n} — {U} US à planifier (back + front en parallèle, mode Plan Only)

STEP 3 — Vérifier les stacks actifs

Lire workspace/stack/stack.md.

• Si aucun ## Active Tech Specs backend-* ET aucun frontend-* → ERROR comme dans /dev-run.

(Pas de validation des blocs ## Active Database / ## Active Auth Specs ici — la planification ne lit pas la DB, ne se connecte à rien.)

STEP 4 — Invocation parallèle dev-backend + dev-frontend (mode Plan Only)

CRITIQUE — exécution parallèle : pour chaque US {n}-{m}-{Name} de US_LIST, invoquer à la fois :

• dev-backend {n}-{m}:plan (suffixe :plan = Plan Only)
• dev-frontend {n}-{m}:plan

Toutes les invocations dans un SEUL message avec plusieurs appels d'outil Agent en parallèle (pas de boucle séquentielle).

Pour U US → 2 × U invocations parallèles.

Chaque agent en mode :plan :

• Charge l'US, le mockup HTML (front, texte direct), les stacks actifs et le CLAUDE.md projet (s'il existe)
• Construit le plan inline normal (STEPs 5/6 selon agent)
• Écrit le plan dans workspace/plans/{n}-{m}-{Name}.{back|front}.md au format défini (cf. .sdd/rules/build-and-loop.md §7.4)
• Émet UNE ligne :

  dev-backend {n}-{m}-{Name}: plan written → workspace/plans/{n}-{m}-{Name}.back.md (X fichiers)
  

• STOP — pas de génération de code, pas de build

Si l'US n'a pas de contrepartie pour la famille → exit silent (skipped (frontend-only US) ou inverse), pas de fichier plan écrit.

STEP 4.5 — Compactage des plans frontend (RETIRÉ v7.0.0)

⛔ Retiré v7.0.0 (script compact_front_plans.py supprimé du disque) — cf. CHANGELOG.

STEP 4.7 — Validation post-génération des plans (refactor v7.0.0-alpha audit P0-workflow 2026-06-05)

v7.0.0-alpha audit P0-workflow 2026-06-05 — historiquement appelé « strict-readiness ». Les variants d'agents dev-*-strict ont été retirés en v7.0.0 (cf. ADR governance-major-auditors-trim §3 + docs/CHANGELOG.md entrée v7.0.0), il n'y a donc plus de routing strict/classic. Le chemin de code --strict / validate_strict() a été supprimé de validate_plan.py (audit M5, 2026-08-29) ; le flag reste accepté en CLI en pur no-op pour ne pas casser un script ancien. Ce STEP ne décide plus de routing — uniquement validation structurelle (frontmatter v2, us-hash, AC coverage) pour détecter les plans stale avant matérialisation côté /dev-run.

Pour chaque plan généré (back et front), invoquer validate_plan.py pour confirmer la conformité (frontmatter plan-schema-version: 2 recommandé, us-hash cohérent avec l'US source, section ## Inline Digest présente, AC coverage complète) :

python .sdd/python/sdd_scripts/validate_plan.py \
  --plan-path "workspace/plans/{n}-{m}-{Name}.{back|front}.md" \
  --us-path "workspace/us/{n}-{m}-{Name}.md" \
  --json

Exit 1 retiré (audit M5, 2026-08-29) — cette table publiait une ligne 1 = « plan v1 legacy » qui ne pouvait jamais se produire : exit 1 ([PLAN_NOT_STRICT_READY]) n'était émis que par validate_strict(), sous le flag --strict qu'aucune invocation documentée ne passe. Reliquat du retrait des variants dev-*-strict en v7.0.0. Le mode strict est maintenant retiré proprement côté script : ses checks utiles (digest, AC coverage, drift claude-md-hash) sont always-on, en warning ou en exit 2 selon qu'ils touchent la lisibilité ou la traçabilité.

Émettre un event state.jsonl par plan validé (si $RUN_ID disponible) :

python .sdd/python/sdd_scripts/sdd_state.py emit-event \
  --run-id $RUN_ID --event-type plan_validate_postgen \
  --payload-json '{"us":"{n}-{m}","family":"{back|front}","exit":N,"result":"v2|v1|invalid"}'

Non bloquant sur warnings : un plan exit 0 avec warnings (v1 legacy PLAN_DIGEST_ABSENT, etc.) reste utilisable par dev-* (Opus) en mode From-Plan classique. Exit 2 nettoie le plan pour éviter qu'un re-run ultérieur ne le consomme à tort.

Si tous les plans sont exit 0 → émettre 1 ligne récap :

FEAT {n} — plans v2 valides : {S_v2_back}/{P_back} back + {S_v2_front}/{P_front} front

Si au moins un plan porte le warning PLAN_DIGEST_ABSENT (plan v1 legacy, $S_v1 ≥ 1) → émettre WARNING 1 ligne :

🟡 FEAT {n} — {S_v1} plan(s) v1 legacy (utilisables par dev-* Opus, sans Inline Digest)

STEP 4.bis — Status flip US (v6.10.5, fix CRIT-2)

Pour chaque US dont un plan a été écrit avec succès (.back.md ou .front.md), flipper Ready → InProgress. Idempotent et non-bloquant.

for plan_file in workspace/plans/{n}-*.{back,front}.md; do
  [ -f "$plan_file" ] || continue
  us_id=$(basename "$plan_file" | grep -oE '^[0-9]+-[0-9]+')
  python .sdd/python/sdd_scripts/set_us_status.py \
    --us "$us_id" --status InProgress 2>/dev/null || true
done

Skip pour les US sans plan écrit (erreur isolée, cf. STEP 4).

STEP 4.ter — Auto-ingest plans dans console.db (depuis 2026-05-21)

Invoquer systématiquement le script déterministe ingest_plans.py pour populer la table plans de workspace/db/console.db (parsing frontmatter v2 + count entrées section ## Files).

python .sdd/python/sdd_scripts/ingest_plans.py 2>&1 | tail -1

Idempotent : ON CONFLICT(plan_id) DO UPDATE — re-exécution sans effet.

Coût : 0 token LLM, ~50 ms, parse YAML frontmatter + regex.

Schéma populé : plan_id (= {us_id}-{family}), us_id, family, file_path, schema_version (1|2), strict_ready (0|1), us_hash (SHA-256 US au moment du plan), capabilities_json (liste), file_count (entrées - path: dans ## Files), generated_at.

Non bloquant : un échec de l'ingest n'invalide pas la génération des plans. Les fichiers .back.md / .front.md sur disque restent la SSoT.

STEP 5 — Récap final

Émettre un seul bloc final :

✅ FEAT {n} — plans techniques écrits

Plans backend  : workspace/plans/{n}-*-*.back.md  ({Tb_ok} US, {Tb_skip} skipped)
Plans frontend : workspace/plans/{n}-*-*.front.md ({Tf_ok} US, {Tf_skip} skipped)

Prochaine étape :
  - relire et éditer si besoin workspace/plans/{n}-*-*.{back,front}.md
  - lancer /dev-run {n} (les plans seront détectés et consommés sans
    re-planification)
  - ou /dev-plan {n} pour régénérer les plans (idempotent)

Si tout passe sans accroc :

✅ FEAT {n} — {Tb_ok} plans backend + {Tf_ok} plans frontend écrits dans workspace/plans/.

Règles de cette commande

• Autonome — pas de Q/R utilisateur.
• Idempotent — relancer écrase les plans précédents.
• Pas de génération de code — c'est le rôle de /dev-run.
• Pas de build, pas de DB connexion, pas d'install.
• Erreur isolée par US : un échec sur 1 US ne casse pas les autres.
• Le format des fichiers de plan est défini par les agents (cf. agents/dev-backend.md et agents/dev-frontend.md). Toute édition manuelle DOIT respecter ce format pour que /dev-run puisse le consommer.