@sylad/cadence 1.2.0 → 1.4.0

package/dist/orchestrate/waits.js

@@ -0,0 +1,120 @@
+import { existsSync, readdirSync, readFileSync } from 'node:fs';
+import { join } from 'node:path';
+import { isDay, toDay } from '../dates.js';
+import { RunStore } from './state.js';
+/** « 4 min 27 s », « 45 s », « 1 h 02 min 03 s » (la forme de `duration` et des lignes du journal) en millisecondes ; null si illisible. */
+export function parseWaitMs(text) {
+    const m = /^(?:(\d+) h )?(?:(\d+) min )?(\d+) s$/.exec(text.trim());
+    if (!m)
+        return null;
+    return ((Number(m[1] ?? 0) * 60 + Number(m[2] ?? 0)) * 60 + Number(m[3])) * 1000;
+}
+/**
+ * Les attentes d'un créneau d'un journal : comptées à l'obtention (« obtenu après … »), au jour de cette ligne ; `unfinished` = attentes commencées sans créneau obtenu.
+ * Chaque attente est appariée à son lot (« <projet>:<lot> · … ») : deux lots d'une même vague (un par dépôt, runPool) attendent en même temps. Une ligne sans lot (journal d'avant) est celle de la vague entière.
+ */
+export function parseWaits(journal) {
+    const waits = [];
+    let unfinished = 0;
+    const state = new Map(); // « depuis » de la dernière ligne d'attente : une ligne dont il ne progresse pas (recule, ou « depuis 0 s » de nouveau) est celle d'une nouvelle attente
+    for (const line of journal.split('\n')) {
+        const m = /^(\S+) (?:(\S+) · )?(?:en attente d'un créneau de session depuis (.+?) \(|créneau de session obtenu après (.+?) d'attente)/.exec(line);
+        if (!m)
+            continue;
+        const key = m[2] ?? '';
+        let s = state.get(key);
+        if (!s)
+            state.set(key, (s = { open: false, since: 0 }));
+        if (m[4] === undefined) {
+            const ms = parseWaitMs(m[3]) ?? 0;
+            if (s.open && ms <= s.since)
+                unfinished++;
+            s.open = true;
+            s.since = ms;
+            continue;
+        }
+        const ms = parseWaitMs(m[4]);
+        const at = new Date(m[1]);
+        if (ms !== null && !Number.isNaN(at.getTime()))
+            waits.push({ day: toDay(at), ms });
+        s.open = false;
+    }
+    for (const s of state.values())
+        if (s.open)
+            unfinished++;
+    return { waits, unfinished };
+}
+/** Les arrêts par le quota d'un journal (« … → suspended — quota atteint », cycle.ts), au jour de la ligne : le statut final de wave.json ne les garde pas, `--resume` le remet à `running` puis `done`. */
+export function parseQuotaStops(journal) {
+    const days = [];
+    for (const line of journal.split('\n')) {
+        const m = /^(\S+) \S+ → suspended — quota atteint$/.exec(line);
+        const at = m ? new Date(m[1]) : null;
+        if (at && !Number.isNaN(at.getTime()))
+            days.push(toDay(at));
+    }
+    return days;
+}
+/** Attente de créneau par vague et par jour, lue dans les `journal.log` et `wave.json` de `.cadence/runs/<vague>/` du dossier de lancement ; `since` écarte les vagues d'avant ce jour (début de l'identifiant). */
+export function readWaits(launchDir, since) {
+    const base = RunStore.runsDir(launchDir);
+    const ids = existsSync(base) ? readdirSync(base).filter((n) => existsSync(join(base, n, 'wave.json'))).sort() : [];
+    const waves = [];
+    const days = new Map();
+    const dayOf = (day) => {
+        let d = days.get(day);
+        if (!d)
+            days.set(day, (d = { day, totalMs: 0, count: 0, waves: 0, quotaHits: 0, consumed: 0 }));
+        return d;
+    };
+    for (const id of ids) {
+        const idDay = id.slice(0, 10);
+        if (!isDay(idDay) || (since && idDay < since))
+            continue; // un dossier qui n'est pas une vague datée (essai à la main) n'a pas de jour
+        let meta = {};
+        try {
+            meta = JSON.parse(readFileSync(join(base, id, 'wave.json'), 'utf8'));
+        }
+        catch {
+            // wave.json illisible : la vague compte sans jetons
+        }
+        const journalFile = join(base, id, 'journal.log');
+        const journal = existsSync(journalFile) ? readFileSync(journalFile, 'utf8') : '';
+        const { waits, unfinished } = parseWaits(journal);
+        waves.push({ id, totalMs: waits.reduce((s, w) => s + w.ms, 0), count: waits.length, maxMs: Math.max(0, ...waits.map((w) => w.ms)), unfinished, status: meta.status ?? '?', consumed: meta.consumed ?? 0 });
+        const d = dayOf(idDay);
+        d.waves++;
+        d.consumed += meta.consumed ?? 0;
+        for (const day of parseQuotaStops(journal))
+            dayOf(day).quotaHits++;
+        for (const w of waits) {
+            const dw = dayOf(w.day);
+            dw.totalMs += w.ms;
+            dw.count++;
+        }
+    }
+    return { waves, days: [...days.values()].sort((a, b) => a.day.localeCompare(b.day)) };
+}
+function duration(ms) {
+    const s = Math.round(ms / 1000);
+    if (s < 60)
+        return `${s} s`;
+    const min = Math.floor(s / 60);
+    return min < 60 ? `${min} min ${String(s % 60).padStart(2, '0')} s` : `${Math.floor(min / 60)} h ${String(min % 60).padStart(2, '0')} min ${String(s % 60).padStart(2, '0')} s`;
+}
+/** Deux tableaux : par jour, puis par vague (celles qui ont attendu). */
+export function renderWaits(r) {
+    if (r.waves.length === 0)
+        return ['aucune vague dans ce dossier'];
+    const lines = ['attente de créneau de session, par jour', '  jour         attente cumulée   attentes  vagues  quota atteint  jetons'];
+    for (const d of r.days)
+        lines.push(`  ${d.day}   ${duration(d.totalMs).padEnd(16)}  ${String(d.count).padStart(8)}  ${String(d.waves).padStart(6)}  ${String(d.quotaHits).padStart(13)}  ${d.consumed}`);
+    const total = r.days.reduce((s, d) => s + d.totalMs, 0);
+    lines.push(`  total        ${duration(total)}`, '', 'par vague (celles qui ont attendu)');
+    const waited = r.waves.filter((w) => w.count > 0 || w.unfinished > 0).sort((a, b) => b.totalMs - a.totalMs);
+    if (waited.length === 0)
+        lines.push('  aucune');
+    for (const w of waited)
+        lines.push(`  ${w.id}   ${duration(w.totalMs).padEnd(16)}  ${w.count} attente(s), la plus longue ${duration(w.maxMs)}${w.unfinished ? `, ${w.unfinished} sans créneau obtenu` : ''}  [${w.status}]`);
+    return lines;
+}

package/dist/plan.js

@@ -437,15 +437,15 @@ export class Plan {
         const keys = node.items.map((p) => String(p.key?.value ?? p.key));
         node.items.splice(keys.indexOf('visible') + 1, 0, this.doc.createPair('screen', screen));
     }
-    /** Pose (true) ou retire (false) le `spec:` d'un lot existant ; `screen:` l'implique, donc on ne retire pas la spec d'un lot à écran. Renvoie false quand `screen:` rendait la pose sans objet. */
+    /** Pose (true) ou retire (false) le `spec:` d'un lot existant ; `screen: page` l'implique, donc on ne retire pas la spec d'un lot à page (`component` et `journey` suivent le chemin ordinaire depuis L209 : leur `spec: true` est la spec back). Renvoie false quand `screen: page` rendait la pose sans objet. */
     setSpec(ref, on) {
         this.writable();
         if (ref.includes('/'))
             throw new RafError(`la spec se pose sur un lot, pas une sous-tâche : ${ref}`);
         const node = this.lotNode(ref);
-        if (this.lot(ref).screen) {
+        if (this.lot(ref).screen === 'page') {
             if (!on)
-                throw new RafError(`${ref} a screen: — retirer d'abord screen: (raf screen ${ref} none), l'écran implique la spec`);
+                throw new RafError(`${ref} a screen: page — retirer d'abord screen: (raf screen ${ref} none), l'écran implique la spec`);
             return false;
         }
         if (!on) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sylad/cadence",
-  "version": "1.2.0",
+  "version": "1.4.0",
   "description": "A small, repo-native working method: a versioned plan linked to your commits, a changelog with screenshots, session rituals and deliveries proven by their effect.",
   "license": "MIT",
   "author": "Sylvain Ladoire",

package/skills/lead/SKILL.md

@@ -14,13 +14,16 @@ commands (its CLAUDE.md names them), never with `raf start|done|note|ux|review`.
 
 ## Limits that always apply
 
-- **At most two subagents running at once.** Queue the rest. The sessions of an orchestrated wave
-  (section 2b) count toward this limit: orchestrate sessions plus subagents never exceed two. A wave
-  already caps itself (`--max-sessions`, 2 by default, shared by every wave); before starting a
-  subagent, check `cadence orchestrate --status`, and while a wave runs, start none beyond the free
-  slots. Read the free slots, do not compute them: `cadence orchestrate --status` and `cadence lead tour` print
-  `créneaux libres : N sur 2` (the registry subtracts, for each live wave, min(cap, repositories it still holds)
-  from the two slots; no line from `lead tour` means no live wave, so both are free). Never raise `--max-sessions` above two to speed a wave up.
+- **At most as many subagents running at once as the session cap, 2 unless the human set another.** Queue
+  the rest. The cap is the human's setting (`CADENCE_MAX_SESSIONS`, or `--max-sessions` on a wave; 2 by
+  default, shared by every wave). The sessions of an orchestrated wave (section 2b) count toward this limit:
+  orchestrate sessions plus subagents never exceed the cap. A wave already caps itself; before starting a
+  subagent, check `cadence orchestrate --status`, and while a wave runs, start none beyond the free slots. Read the cap and the
+  free slots, do not compute them: `cadence orchestrate --status` and `cadence lead tour` print
+  `créneaux libres : N sur M` (M is the configured cap; the registry subtracts, for each live wave, min(cap,
+  repositories it still holds) from the M slots; no line from `lead tour` means no live wave, so all M are free).
+  Never raise `--max-sessions` or `CADENCE_MAX_SESSIONS` yourself to speed a wave up: raising the cap is a decision of
+  the human (a trial at 3 was decided on 2026-10-12); if the slots are the bottleneck, say so and let them decide.
 - **Never two subagents in the same repository at the same time**, and the lead does not commit in a
   repository where a subagent is working.
 - **Deliveries and `raf ux` / `raf review` verdicts are done by the lead, one project at a time** —
@@ -92,7 +95,7 @@ and the project declares how to see its app (`orchestrate.ux` in `cadence.yaml`)
 (Opus, the `code-reviewer` agent; Sonnet, with no pass on the minor findings, for a lot whose estimate is
 ≤ 0.25 d — `orchestrate.review` in `cadence.yaml`; a blocker or major finding still brings a correction and an
 Opus review), a correction in a new session if the review is not compliant (two
-passes at most) — and records `raf review` itself when the code review is compliant. A lot with `spec: true` (no screen) goes `spec → fiche → accept` before the code: the `code-reviewer` reviews its back-end sheet, and the hypotheses of the final sheet come back in the table as « hypothèse de la fiche » lines, which the lead relays to the human. The state is in
+passes at most, a third when the review converges: blocking + major findings down from one review to the next and only one left) — and records `raf review` itself when the code review is compliant. A lot with `spec: true` (no screen) goes `spec → fiche → accept` before the code: the `code-reviewer` reviews its back-end sheet, and the hypotheses of the final sheet come back in the table as « hypothèse de la fiche » lines, which the lead relays to the human. The state is in
 `.cadence/runs/<wave>/`, not in this conversation. `@haiku` only when the human writes it, for a
 mechanical lot. Exit code: 0 all ready · 1 some lots handed back · 2 refused before acting · 3 wave
 suspended (budget or usage limit; `--resume --budget …` continues).
@@ -100,7 +103,7 @@ suspended (budget or usage limit; `--resume --budget …` continues).
 What the orchestrator does **not** do, and stays with the lead: choose the lots (with the human), bring the
 questions back (`--resume --answer <project>:<lot> "…"`), look at the UX reviewer's captures and record
 `raf ux` (the orchestrator reports its verdict, it never records it; who decides it is the `lead.ux` setting, section 2c), re-verify (section 3, point 2),
-`raf done`, push and deliver. **A locked acceptance test that contradicts the sheet** (the lot is handed back with `verrou des tests d'acceptation`, or the session's question says its own test is wrong, e.g. a regex that rejects a sentence the sheet allows) has a path, and it is the lead's, never a session's: correct the test in the working tree, **the sheet unchanged**, then `cadence spec reseal <lot> <test> --reason "why it contradicts the sheet"` (outside any wave): the program redoes the fingerprint of that one test, writes the reason in `acceptation.json` (`resceaux`) and as a note of the lot, commits both, and the lock keeps everything else. It refuses a lot that is not in progress, a changed sheet and any other listed test touched, and during a wave of that repository. It is atomic (a refused commit restores `acceptation.json` and the test), with a plan kept read-only by another tool it leaves the plan untouched and says a note is to be added by hand, with an untracked plan or one outside the repository it writes the note but does not commit it (`plan à commiter`: do not add it again), and if the commit of the note is refused the reseal stays done and the error says to commit the plan by hand. Do it **between two sessions**, never inside one: a resealed commit that belongs to a session of the wave is not adopted (still a lock violation), and sessions are forbidden the command. Then continue the lot: `--resume --answer` when it waits on a `question`; a new wave `cadence orchestrate <project>:<lot>` when it was handed back (`--resume` skips finished lots). Minor findings and proposed sub-tasks come back in the table: adding them to
+`raf done`, push and deliver. **A locked acceptance test that contradicts the sheet** (the lot is handed back with `verrou des tests d'acceptation`, or the session's question says its own test is wrong, e.g. a regex that rejects a sentence the sheet allows) has a path, and it is the lead's, never a session's: correct the test in the working tree (the sheet is left as it is; if it was amended, **commit it first, citing the lot**: an amended sheet whose every commit cites the lot is accepted, L217, never put it back to the red state), then `cadence spec reseal <lot> <test> --reason "why it contradicts the sheet"` (outside any wave): the program redoes the fingerprint of that one test, writes the reason in `acceptation.json` (`resceaux`) and as a note of the lot, commits both, and the lock keeps everything else. For a **delivered** lot (`vert: true`) whose contract does not change but whose test is unstable, add `--porteur <the lot in progress that carries the fix>`: the commit and the note cite that lot, `vert` stays true (L212). It refuses a lot that is neither in progress nor delivered, a sheet with uncommitted changes or touched by a commit that does not cite the lot, and any other listed test touched, and during a wave of that repository. It is atomic (a refused commit restores `acceptation.json` and the test), with a plan kept read-only by another tool it leaves the plan untouched and says a note is to be added by hand, with an untracked plan or one outside the repository it writes the note but does not commit it (`plan à commiter`: do not add it again), and if the commit of the note is refused the reseal stays done and the error says to commit the plan by hand. Do it **between two sessions**, never inside one: a resealed commit that belongs to a session of the wave is not adopted (still a lock violation), and sessions are forbidden the command. Then continue the lot: `--resume --answer` when it waits on a `question`; a new wave `cadence orchestrate <project>:<lot>` when it was handed back (`--resume` skips finished lots). Minor findings and proposed sub-tasks come back in the table: adding them to
 the plan is the lead's decision. A minor finding becomes a lot of its own only if it describes an observable bug (a wrong output, a crash, a measured regression); otherwise it stays a note of the originating lot, so that a review never feeds the next one. If an orchestrated wave is running in a repository, do not commit there
 and do not deliver it (`cadence deliver` refuses).
 

package/templates/acceptation-runner.mjs

@@ -6,8 +6,11 @@
 //   vitest.acceptation.config.ts   (commande dédiée, orchestrate.accept)
 //                             test: { include: acceptationOnly() }   (une LISTE de lanceurs : chacun ne voit que les fichiers sous sa racine, cf. acceptationOnly)
 //
+//   playwright.config.ts      testMatch: acceptationE2e()   (suite e2e, lancée APRÈS le build : une acceptation `"e2e": true`, navigateur et dist requis)
+//
 // Un acceptation.json à `vert: false` (tests rouges du lot, pas encore implémenté) exclut ses fichiers du lanceur du projet et de la CI ;
 // le cycle pose `vert: true` quand la commande dédiée passe, et les fichiers rejoignent alors le lanceur ordinaire.
+// Exception (L203) : une acceptation `"e2e": true` ne le rejoint JAMAIS (sans dist ni Chromium elle le rendrait rouge) : elle reste exclue, verte ou non, et va dans la suite e2e.
 import { existsSync, readdirSync, readFileSync } from 'node:fs';
 import { join, posix } from 'node:path';
 
@@ -22,8 +25,7 @@ const read = (file) => {
 
 const escape = (s) => s.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
 
-/** Fichiers des acceptation-<lot>.json (ou acceptation.json) à `vert: false` sous `<root>/<dir>/*` (un fichier par lot : plusieurs par écran), relatifs à `root` ; `format: 'regex'` pour testPathIgnorePatterns. */
-export function acceptationIgnored(root = process.cwd(), dir = 'docs/specs', format = 'glob') {
+function collect(root, dir, format, keep) {
   const base = join(root, dir);
   if (!existsSync(base)) return [];
   const out = [];
@@ -37,13 +39,23 @@ export function acceptationIgnored(root = process.cwd(), dir = 'docs/specs', for
     }
     for (const file of files) {
       const doc = read(join(folder, file));
-      if (!doc || doc.vert === true) continue;
+      if (!doc || !keep(doc)) continue;
       for (const f of doc.fichiers) if (typeof f === 'string') out.push(format === 'regex' ? `${escape(f)}$` : f);
     }
   }
   return out;
 }
 
+/** Fichiers des acceptation-<lot>.json (ou acceptation.json) à `vert: false`, ou à `e2e: true` (verts ou non), sous `<root>/<dir>/*` (un fichier par lot : plusieurs par écran), relatifs à `root` ; `format: 'regex'` pour testPathIgnorePatterns. */
+export function acceptationIgnored(root = process.cwd(), dir = 'docs/specs', format = 'glob') {
+  return collect(root, dir, format, (doc) => doc.vert !== true || doc.e2e === true);
+}
+
+/** Fichiers des acceptations `e2e: true` (vertes ou rouges) sous `<root>/<dir>/*`, relatifs à `root` : le `testMatch` de la suite e2e, lancée après le build. */
+export function acceptationE2e(root = process.cwd(), dir = 'docs/specs', format = 'glob') {
+  return collect(root, dir, format, (doc) => doc.e2e === true);
+}
+
 /**
  * Fichiers de l'acceptation.json donné (par défaut celui de `CADENCE_ACCEPTATION`, posé par le cycle) : l'`include` de la config dédiée.
  * Avec une liste de lanceurs (`orchestrate.accept` en liste), chaque lanceur ne prend que les fichiers sous SA racine, le dossier de son

package/templates/orchestrate/accept-back.md

@@ -7,6 +7,7 @@ Rules:
 - Every test must FAIL for now, because the feature is missing (not because of a typo or a broken setup): the program runs the dedicated command and refuses tests that pass.
 - Do not touch the sheet, the plan or any application code. Do not push, deliver, run `raf done`, `raf ux` or `raf review`.
 - Commit with explicit paths (never `git add -A` or `commit -a`), ONE commit citing the lot (`test({{lot}}): acceptation R1–Rn (rouge)`) with the test files, the acceptation file and the runner configuration, and leave the working tree clean. The program seals the acceptation file afterwards (it adds the fingerprint of each test file): never write `empreintes` or `vert: true` yourself.
+Never run `git checkout` or `git switch` to another commit or branch in this repository: the orchestrator watches it and a moved HEAD breaks the other sessions of the wave. To look at another sha, use a throwaway `git worktree add --detach <tmp> <sha>`, removed afterwards.
 Decide minor interpretation questions yourself and list each one under "choix" with the alternative you did not take. Leave "questions" empty rather than writing a placeholder such as "no question".
 {{commits}}
 {{reponse}}

package/templates/orchestrate/accept.md

@@ -7,6 +7,7 @@ Rules:
 - Every test must FAIL for now, because the feature is missing (not because of a typo or a broken setup): the program runs the dedicated command and refuses tests that pass.
 - Do not touch the sheet, the mockup, the plan or any application code. Do not push, deliver, run `raf done`, `raf ux` or `raf review`.
 - Commit with explicit paths (never `git add -A` or `commit -a`), ONE commit citing the lot (`test({{lot}}): acceptation R1–Rn (rouge)`) with the test files, the acceptation file and the runner configuration, and leave the working tree clean. The program seals the acceptation file afterwards (it adds the fingerprint of each test file): never write `empreintes` or `vert: true` yourself.
+Never run `git checkout` or `git switch` to another commit or branch in this repository: the orchestrator watches it and a moved HEAD breaks the other sessions of the wave. To look at another sha, use a throwaway `git worktree add --detach <tmp> <sha>`, removed afterwards.
 Decide minor interpretation questions yourself and list each one under "choix" with the alternative you did not take. Leave "questions" empty rather than writing a placeholder such as "no question".
 {{commits}}
 {{reponse}}

package/templates/orchestrate/fix-minors.md

@@ -12,6 +12,7 @@ Fix each minor finding that is right, and nothing else. Rules: test first; commi
 its tests pass, with explicit paths (never `git add -A` or `commit -a`), and a message that cites the
 lot (`fix({{lot}}): …`); run the project's full test suite and build before reporting; do not push,
 deliver, run `raf done`, `raf ux` or `raf review`. Read the project's CLAUDE.md first.
+Never run `git checkout` or `git switch` to another commit or branch in this repository: the orchestrator watches it and a moved HEAD breaks the other sessions of the wave. To look at another sha, use a throwaway `git worktree add --detach <tmp> <sha>`, removed afterwards.
 Do not stop to ask. A finding that is wrong, or not worth its change, is not fixed: list it under
 "choix" in your report with the reason — the reviewer re-reads it and the lead sees it. Leave
 "questions" empty. Making no commit at all is a valid outcome when every finding is rejected.

package/templates/orchestrate/fix.md

@@ -12,6 +12,7 @@ Rules: test first; commit each fix as soon as its tests pass, with explicit path
 `git add -A` or `commit -a`), and a message that cites the lot (`fix({{lot}}): …`); run the project's
 full test suite and build before reporting; do not push, deliver, run `raf done`, `raf ux` or
 `raf review`. Read the project's CLAUDE.md first.
+Never run `git checkout` or `git switch` to another commit or branch in this repository: the orchestrator watches it and a moved HEAD breaks the other sessions of the wave. To look at another sha, use a throwaway `git worktree add --detach <tmp> <sha>`, removed afterwards.
 If a finding is wrong, say so under "choix" with the reason. Ask (under "questions") only when a fix needs a decision that passes the rule below.
 A question is legitimate only if it names what it would change: the scope of the lot, the architecture, or a costly rollback (data, production, public API);
 otherwise it is a choice: decide, write the alternative you did not take, go on. Minor choices to settle yourself:
@@ -19,6 +20,7 @@ a spacing, colour or label value when a measurement or a rule justifies it; the
 a News entry: only if a finding asks for it; a written rule of the project's CLAUDE.md (apply it); who launches the review or UX pass (never the session: the program and the lead do).
 "not my job to touch the plan" is not a question: say it in the report.
 Never stop to ask about how to organise your own work (split or squash a commit, order of the sub-parts, whether to continue, "I have no question"): decide, list it under "choix", go on. Leave "questions" empty rather than writing a placeholder such as "no question".
+Tests already red before the lot: if the suite is red, check whether the same tests are red at the sha the lot started from (the parent of the oldest work commit that cites {{lot}}, plan-only commits left out, or the `HEAD` before this session if the lot has none: a throwaway `git worktree add --detach <tmp> <sha>`, removed afterwards). Failures already there are not a defect of this lot: do not try to fix them and do not report your tests as red for them; list their names under "echecsDeBase" in your report (one test per entry, as the runner prints it), list under "nouveauxEchecs" the tests that are red now and were NOT red at that sha (an empty list when there are none: with `vert: false`, a non-empty "echecsDeBase" and an empty "nouveauxEchecs" the lot goes to review without a correction pass; any entry in "nouveauxEchecs" with `vert: false` triggers one), and say under "nonVerifie" if you could not check. The program replays the suite itself and compares to the same baseline.
 A finding you contest (it describes a state older than the code, or you think it wrong) is not a question and not a reason to stop: do not ask the lead to arbitrate. Write it under "choix" with the evidence (the command, the line, the commit), fix what is right, go on; the next fresh review re-reads it.
 You are one short session of an orchestrated wave: do not launch subagents (the Agent tool is disabled).
 Give your final report as the structured output (commits, tests, build, what you could not verify, choices, questions).

package/templates/orchestrate/implement.md

@@ -7,6 +7,7 @@ Rules: test first; commit each sub-part as soon as its tests pass, with explicit
 `git add -A` or `commit -a`), and a message that cites the lot (`feat({{lot}}): …`); run the project's
 full test suite and build before reporting; do not push, deliver, run `raf done`, `raf ux` or
 `raf review`.
+Never run `git checkout` or `git switch` to another commit or branch in this repository: the orchestrator watches it and a moved HEAD breaks the other sessions of the wave. To look at another sha, use a throwaway `git worktree add --detach <tmp> <sha>`, removed afterwards.
 Documentation: the project's README (and its usage documentation) describes the behaviour you deliver, updated in the same commits, like the CHANGELOG — a README that does not follow your change is a major finding of the review.
 Decide minor interpretation questions yourself (the wording of a message, a name, a default, the
 reading of an ambiguous line of the lot) and list each one under "choix" in your report, with the
@@ -19,6 +20,7 @@ a written rule of the project's CLAUDE.md (apply it); who launches the review or
 Never stop to ask about how to organise your own work (split or squash a commit, order of the sub-parts, whether to continue, "I have no question"): decide, list it under "choix", go on. Leave "questions" empty rather than writing a placeholder such as "no question".
 If the lot's commits already cover its open sub-tasks, do not ask whether to continue: make no commit and say so
 in your report (the review that follows re-reads those commits). If they do not cover them all, implement the rest.
+Tests already red before the lot: if the suite is red, check whether the same tests are red at the sha the lot started from (the parent of the oldest work commit that cites {{lot}}, plan-only commits left out, or the `HEAD` before this session if the lot has none: a throwaway `git worktree add --detach <tmp> <sha>`, removed afterwards). Failures already there are not a defect of this lot: do not try to fix them and do not report your tests as red for them; list their names under "echecsDeBase" in your report (one test per entry, as the runner prints it), list under "nouveauxEchecs" the tests that are red now and were NOT red at that sha (an empty list when there are none: with `vert: false`, a non-empty "echecsDeBase" and an empty "nouveauxEchecs" the lot goes to review without a correction pass; any entry in "nouveauxEchecs" with `vert: false` triggers one), and say under "nonVerifie" if you could not check. The program replays the suite itself and compares to the same baseline.
 Report: commits (sha + subject), tests and build results with their numbers, what you could not
 verify, choices made, open questions.
 

package/templates/orchestrate/spec-back.md

@@ -16,6 +16,7 @@ Sheet rules:
 - If, after reading the lot and the code, you find that the lot changes NO behaviour (nothing a user, an API client or another service can observe: a lint, a rename, a move, a doc, a CI or cache setting without observable effect), write one line with the reason in `sousSeuil`, create no sheet, and finish: the lot then follows the usual path.
 
 Commit the sheet with explicit paths (never `git add -A` or `commit -a`), a message that cites the lot (`spec({{lot}}): …`), and leave the working tree clean. Do not implement the behaviour, do not write application code or tests, do not push, deliver, run `raf done`, `raf ux` or `raf review`.
+Never run `git checkout` or `git switch` to another commit or branch in this repository: the orchestrator watches it and a moved HEAD breaks the other sessions of the wave. To look at another sha, use a throwaway `git worktree add --detach <tmp> <sha>`, removed afterwards.
 Decide minor interpretation questions yourself and list each one under "choix" with the alternative you did not take. Leave "questions" empty rather than writing a placeholder such as "no question".
 {{commits}}
 {{reponse}}

package/templates/orchestrate/spec.md

@@ -14,9 +14,10 @@ Sheet rules:
 - Check every date in the sample data of the mockup before keeping it: compute its weekday (a command such as `date -d 2026-09-03 +%A`, or a script), never write it from memory — a « Wed 03/09 » that is a Thursday sends the mockup back for nothing. The same goes for any figure that must add up (a score and its result, a total and its parts).
 - Expose the messages exactly as the screen shows them; the message of a rule is visible in the state its `etat` names.
 - A rule you invent is not a free choice: **a hypothesis whose `si_faux` involves an expensive-to-undo choice is a question, not a hypothesis.** The four expensive categories: a data model or storage (key, migration, user data created once shipped); a public or shared API contract, or an already published route / URL; a destructive or irreversible action (deletion, sending, payment); a rule that contradicts an existing sourced rule. In those cases do not write the hypothesis: stop and put the question under "questions" (the lead answers and the step is resumed). Everything else (wording, order of the fields, error state, spacing) is a written hypothesis, cheap to correct later.
-- If, after reading the lot and the code, you find that the lot changes NO screen (no new page, component or modified journey), write one line with the reason in `sousSeuil`, create no mockup and no sheet, and finish: the lot then follows the usual path.
+- If, after reading the lot and the code, you find that the lot changes NO screen (no new page), write one line with the reason in `sousSeuil`, create no mockup and no sheet, and finish: the lot then follows the usual path.
 
 Commit the spec with explicit paths (never `git add -A` or `commit -a`), a message that cites the lot (`spec({{lot}}): …`), the sheet, the mockup and the captures together, and leave the working tree clean. Do not implement the screen, do not write application code or tests, do not push, deliver, run `raf done`, `raf ux` or `raf review`.
+Never run `git checkout` or `git switch` to another commit or branch in this repository: the orchestrator watches it and a moved HEAD breaks the other sessions of the wave. To look at another sha, use a throwaway `git worktree add --detach <tmp> <sha>`, removed afterwards.
 Decide minor interpretation questions yourself and list each one under "choix" with the alternative you did not take. Leave "questions" empty rather than writing a placeholder such as "no question".
 {{commits}}
 {{reponse}}