feat(aidd-orchestrator): add an interactive SDLC mode

README.md

@@ -193,7 +193,7 @@ Three ways in — pick one:
 | --- | --- | --- |
 | 🧭 **Guided onboarding** | `/aidd-context:00-onboard` | First time, or unsure what to run — it inspects the project and routes you. |
 | 🧠 **Project memory** | `/aidd-context:02-project-memory` | Build the project memory bank by hand. |
-| ⚙️ **Feature flow** | `/aidd-orchestrator:01-sdlc` | Autonomously ship a feature end to end (frame → deliver → check → PR). |
+| ⚙️ **Feature flow** | `/aidd-orchestrator:01-sdlc` | Ship a feature end to end, autonomous by default or supervised with `interactive` (frame → deliver → check → PR). |
 
 The full loop, and how onboarding sets it up:
 

aidd_docs/tasks/2026_09/2026_09_17_sdlc-interactive-mode/brainstorm.md

@@ -0,0 +1,82 @@
+# SDLC : rendre le mode `interactive` à l'orchestrateur
+
+Le SDLC va aujourd'hui du besoin à la pull request sans jamais s'arrêter. Avant un refactor il
+avait un mode `interactive` par défaut et `auto` sur demande ; le refactor a gardé l'autonomie et
+jeté le reste. On veut l'inverse de l'ancien réglage : autonome par défaut, `interactive` sur
+demande. Pour quelqu'un qui lance une vraie livraison et veut valider le contrat, la spec et le
+plan avant que ça parte, mais qui n'a aucune envie d'arbitrer chaque agent lancé.
+
+La bascule qui évite la sur-ingénierie : on ne s'arrête pas à chaque délégation, on s'arrête là où
+un artefact corrigible vient d'être produit. Quatre points, pas dix. Et ces quatre points sont un
+seul comportement de l'orchestrateur, pas quatre mécaniques : aucune des étapes appelées ne change.
+
+## Ce qui est clair
+
+- Le mot est `interactive`, jamais `manual`. Il est déjà employé par `aidd-vcs:01-commit:29`,
+  `aidd-dev:01-plan/actions/04-plan.md:29`, `aidd-context:04-skill-generate/references/scope-frame.md:9`
+  et `aidd-orchestrator:02-backlog/references/modes.md:5`. Un `manual` serait le doublon que
+  `CLAUDE.md` interdit.
+- Mot à l'invocation, rien de persisté : `<besoin|ticket>` seul, ou `auto <...>`, ou
+  `interactive <...>`. Le frontmatter devient `argument-hint: request | auto | interactive`.
+- Quatre arrêts en `interactive` : le contrat, la spec, le plan, le verdict.
+- Aucune skill appelée ne change. `01-plan` lit déjà le contexte et bascule seul dès que
+  l'orchestrateur cesse de se déclarer autonome (`04-plan.md:29`). `04-spec` n'a pas de branche
+  interactive, donc son arrêt appartient à l'orchestrateur, qui s'arrête quand la spec lui revient.
+- La boucle implement, assert, review, challenge tourne seule dans les deux modes.
+- Un refus à un arrêt est un finding. `03-check.md` sait déjà renvoyer un finding vers Frame ou
+  vers Deliver et repasser ; le refus humain emprunte ces chemins au lieu d'en créer.
+- Le commit reste local en fin de Deliver, à chaque passage. Le push part une seule fois, après un
+  verdict propre, dans les deux modes. Règle unique : le travail ne sort de la machine que validé,
+  que le validateur soit humain ou autonome.
+- Le push revient à `aidd-vcs:02-pull-request`. Une PR sur une branche absente du remote est
+  impossible : cette skill a toujours eu cette précondition, tenue jusqu'ici par accident de
+  séquence. Son « Never commit, push, or branch here » devient « Never commit or branch here »,
+  plus une ligne qui pousse la branche quand le remote ne l'a pas, jamais en `--force`.
+- Ce n'est pas un choix de confort : la recette livrée `ship-a-feature.md` enchaîne
+  `/aidd-vcs:01-commit` puis `/aidd-vcs:02-pull-request` sans option `push`, et
+  `02-pull-request/actions/03-create.md` ouvre la PR sans jamais vérifier que la head existe sur
+  le remote. Aucune étape de la recette ne pousse, et rien dans le texte de la skill ne tient
+  cette précondition : elle repose entièrement sur ce que fait l'outil configuré, ce qui tient
+  ou casse selon qu'il est interactif ou non. Donner le push à la skill PR ferme ce trou.
+- Garde-fou à ajouter en plus, pas à la place : `01-collect` vérifie que la head est sur le remote
+  et échoue clairement sinon.
+
+## Ce qui reste ouvert
+
+- Le déplacement du push est la seule décision de ce brief qui ne sert pas le mode interactif.
+  Elle vient d'une règle voulue explicitement : le travail ne sort de la machine que validé, que
+  le validateur soit humain ou autonome. Elle change donc aussi le mode auto, pour tout le monde,
+  et c'est le seul changement dont le périmètre dépasse `01-sdlc`.
+- Reculer le push coûte la sauvegarde hors machine pendant tout Check, qui peut reboucler
+  plusieurs fois vers Deliver. Le travail est committé, donc rien n'est perdu ; ce qu'on perd est
+  la visibilité et la copie distante. Prix jugé acceptable, à écrire dans la référence plutôt qu'à
+  redécouvrir plus tard.
+- La description du skill ouvre sur « Autonomously orchestrates », faux dès qu'un second mode
+  existe. Formulation à trouver. `CATALOG.md` et `README.md` en sont générés par hook et suivront,
+  et le frontmatter est contrôlé au pre-commit, donc `argument-hint` n'est pas décoratif.
+- `aidd-context:00-onboard/references/run/tiers.md:12` affirme « `01-sdlc` is autonomous by
+  contract; do not downgrade it to `GUIDED` », à réconcilier. Et `flow.md:27` propose déjà
+  « walk with me, step by step » contre « hand the whole flow to sdlc » : les deux branches se
+  recouvrent en partie une fois `interactive` disponible.
+- Reste à décider si les points d'arrêt s'écrivent une fois, en règle transversale du `SKILL.md`,
+  ou zone par zone dans les trois références.
+
+## Périmètre attendu
+
+| Fichier | Change |
+| --- | --- |
+| `plugins/aidd-orchestrator/skills/01-sdlc/SKILL.md` | le mode, l'`argument-hint`, la description |
+| `plugins/aidd-orchestrator/skills/01-sdlc/references/02-deliver.md` | le commit ne pousse plus |
+| `plugins/aidd-orchestrator/skills/01-sdlc/references/03-check.md` | le push après un verdict propre |
+| `plugins/aidd-vcs/skills/02-pull-request/SKILL.md` | le push, et sa vérification dans `01-collect` |
+| `01-plan`, `04-spec`, `01-commit` | rien |
+
+Les deux références changent pour le déplacement du push, qui est tranché. Où s'écrivent les
+points d'arrêt, dans le `SKILL.md` ou dans chaque référence, reste ouvert et peut élargir ce
+tableau.
+
+## Prochain pas
+
+Écrire la phrase de mode dans le `SKILL.md` du SDLC, puisque c'est elle qui fait basculer les
+étapes appelées sans les toucher, et vérifier sur un run réel que `01-plan` prend bien sa branche
+interactive quand l'orchestrateur ne se déclare plus autonome.

aidd_docs/tasks/2026_09/2026_09_17_sdlc-interactive-mode/case-matrix.md

@@ -0,0 +1,122 @@
+# Case matrix
+
+Every decision edge the orchestration declares, and the run that exercised it. Derived by reading the router and its three zone references end to end, not by recalling what was tested.
+
+The runs named here are this campaign's. The later batch, on the text as it stands, is in `w-batch.md`.
+
+Legend: `done` an observed run covered it · `flight` a run is covering it · `gap` nothing covers it yet · `n/a` unreachable in a sandbox.
+
+## Router, mode selection
+
+| # | Edge | State |
+| --- | --- | --- |
+| R1 | no mode word, so `auto` | done |
+| R2 | `auto` beside the source names the default | done |
+| R3 | `interactive` beside the source | done |
+| R4 | the word inside the source's own text selects nothing | done |
+| R4b | first word is literally the mode word, nothing beside it | done |
+| R4c | both words passed, case variants, a leading dash, trailing position | done |
+
+## Router, autonomous behaviour
+
+| # | Edge | State |
+| --- | --- | --- |
+| R5 | `auto` stops only for money, an irreversible action, or user authority | done |
+| R6 | a delegated step decides without asking | done |
+
+## Router, pauses
+
+| # | Edge | State |
+| --- | --- | --- |
+| R7 | pause on the contract | done |
+| R8 | pause on the plan | done |
+| R9 | pause on the outcome, before the request | done |
+| R10 | `interactive` dispatch limited to producers of those three, clarifying and formalizing included | done |
+| R11 | every other step dispatched in `auto` | done |
+| R12 | a spec is how Frame formalizes the contract, never a fourth artifact | done |
+| R13 | a dispatched step asks and waits as its own instructions say | done |
+| R14 | a step that ends without waiting, so the orchestrator waits on its result | done |
+| R15 | pause again on an artifact produced anew | done |
+
+## Router, refusals
+
+| # | Edge | State |
+| --- | --- | --- |
+| R16 | a refusal is a finding against the artifact | done |
+| R17a | a refused spec goes to Frame | done |
+| R17b | a refused contract goes to Frame | done |
+| R18 | a refused plan goes to Deliver | done |
+| R19a | a refused outcome goes to Deliver | done |
+| R19b | a refused outcome goes to Frame when it changes what is built | done |
+| R20 | nothing bounds the loop but the user | done |
+
+## Router, discipline
+
+| # | Edge | State |
+| --- | --- | --- |
+| R21 | read only the current zone reference | done |
+| R22 | verify a provider is installed before calling it | done |
+| R23 | spawn specialized agents for isolated work | done |
+| R24 | parallelize independent work | done |
+| R25 | repeat the responsible zone on an actionable gap | done |
+| R26 | the step-end marker only once the draft request exists | done |
+
+## Frame
+
+| # | Edge | State |
+| --- | --- | --- |
+| F1 | the source references a ticket, so resolve it | done |
+| F2 | no ticket, so the source as provided | done |
+| F3 | planning-ready, so straight to the contract | done |
+| F4 | intent can change what is built, so clarify | done |
+| F5 | only contract requirements missing, so formalize | done |
+| F6 | clarifying feeds formalizing | done |
+| F7 | formalizing yields the contract | done |
+| F8 | a resolved ticket is declared in the delivery folder | done |
+| F9 | no ticket, so nothing is declared | done |
+
+## Deliver
+
+| # | Edge | State |
+| --- | --- | --- |
+| D1 | the contract becomes a proportional plan | done |
+| D2 | the plan goes to one executor | done |
+| D3 | implementing feeds asserting | done |
+| D4 | architecture conformance whenever the project documents architecture | done |
+| D5 | no journey required, so commit | done |
+| D6 | a journey is required, so run it last | done |
+| D7 | the journey succeeds, so commit | done |
+| D8 | the journey fails, so back to the executor | done |
+| D9 | commit the validated work | done |
+| D10 | only a clean committed candidate reaches Check | done |
+| D11 | the assert repair loop iterates until it passes | done |
+| D12 | a blocking condition sets the plan blocked and stops | done |
+| D13 | any mismatch with the plan reports a replan | done |
+| D14 | the tree is never dirty at a phase boundary | done |
+
+## Check
+
+| # | Edge | State |
+| --- | --- | --- |
+| C1 | one fresh checker, independent from implementation | done |
+| C2 | the review clears, so challenge the outcome | done |
+| C3 | the review returns actionable findings | done |
+| C4 | the outcome is trustworthy, so open the draft request | done |
+| C5 | the challenge returns actionable findings | done |
+| C6 | product or contract findings become the next Frame source | done |
+| C7 | independent implementation findings go through Todo | done |
+| C8 | dependent repairs stay together in Deliver | done |
+| C9 | Todo feeds Deliver | done |
+| C10 | Check is re-entered after every new candidate | done |
+| C11 | the request opens only when nothing is actionable | done |
+
+## The six edges an earlier harness could not reach
+
+Each was unreachable because of a constraint the harness imposed, not because of anything the orchestration does. Three further sandboxes lift those constraints.
+
+| Edge | Constraint that hid it | How it is lifted |
+| --- | --- | --- |
+| `R23`, `C1` | subagents forbidden, so the orchestrator stayed observable and the checker was never independent | one sandbox requires spawning: delivery to one agent, review to a fresh one fed only the inputs the Check reference names |
+| `C4`, `C11`, `R26` | no remote and no forge, so the request never opened and the step-end marker never fired | one sandbox carries a real bare remote with `main` already pushed, and a `gh` that answers `pr create` while logging every call |
+| `R5` | no real cost and nothing irreversible | one sandbox declares a metered API with no free tier and a key it does not hold, and a module three external consumers depend on |
+| `R24` | read as a performance clause rather than a behaviour | the same sandbox asks for three helpers that share nothing, with fan-out permitted |