@sylad/cadence 1.35.0 → 1.37.0

package/docs/whats-new.md

@@ -4,6 +4,8 @@
 
 ## In two lines
 
+- **1.37.0**: one full test suite per lot, played by the gate (`suites` column); no correction pass without a finding; a richer implementation brief; `scripts/temps-d-un-lot.mjs` measures where a lot's time goes.
+- **1.36.0**: `cadence deliver` no longer waits for the CI of a sha whose commits only touch the plan, with timed steps and a `deliveries-steps.log` journal; `orchestrate --add` puts a lot in a live wave.
 - **1.35.0**: a test already red before a lot, or that only needs more time, no longer costs correction passes, including on a gate declared in parts; QA passes run in browsers of their own; design agents check contrast and AI tics.
 - **1.34.1**: republishes 1.34.0, whose npm publication failed after the tag; same features (edge-case probe, steadier `mise-en-service` tests).
 - **1.34.0**: an optional edge-case probe (`orchestrate.probe: true`) tries to break a lot's diff with tests at the edges before the code review; flaky tests of `mise-en-service` made deterministic.
@@ -63,6 +65,10 @@ Each is a paragraph in [docs/whats-new.md](whats-new.md) and a full section in [
 
 The long form of « In two lines » above (the README no longer carries a « What's new » section since L326: it links here). The full history, with the date of each version, is in [CHANGELOG.md](../CHANGELOG.md).
 
+**1.37.0**: the first release of the efficiency work, sized by a measure of 721 lots (L517, `docs/mesures/temps-d-un-lot.md`, script `node scripts/temps-d-un-lot.mjs`): a lot took 25 minutes and 265k tokens, tests were 62 % of the writing sessions' wall time and a correction pass cost about 12 minutes. The writing sessions of `cadence orchestrate` now play only the targeted tests of the code they touch; the full suite is played once by the program as the gate, `cadence verify --gate` takes its verdict back, and the final table and `--status` count the full suites of each lot in a `suites` column (L518, `docs/orchestrate.md`). A non-compliant review that lists no blocking or major finding no longer opens a correction pass: the lot is handed back with the announced totals as the cause; a test red in the suite and green alone is proposed as a lot to stabilise, and a green program gate always outweighs a session's claim of red tests (L522). The `implement` brief carries the code reviewer's grid, « edge-case tests first, seen failing, then code » and a re-reading of the diff before the last commit; the pre-check passes what it read (`precheckLu`) to the first implementation so it does not read the repository again (L523). The tests workflow tolerates the npm « previously published » refusal of its publish dry-run on a non-release commit, and nothing else (L515). `raf --version` and `raf -v` print the version, and `cadence orchestrate alpha:L1` launched from inside `alpha` says why the folder is not found (L376).
+
+**1.36.0**: `cadence deliver` stops waiting for a CI that proves nothing. When every commit since the previous delivery touches only the plan, it says `→ CI : non attendue (aucun fichier hors plan depuis <sha>)`, then runs the deploy and the checks; as soon as one commit touches anything else, or the proof is missing (no previous delivery, rewritten history, no plan, empty range), it waits as before (L516, `docs/deliver.md`). 42 % of the app deliveries measured on 2026-11-01 were such shas. Every step line of the output now starts with its UTC time and `✓ livré` ends with its duration, and each step played appends a JSON line to `deliveries-steps.log`, so a slow delivery can be read step by step. `cadence orchestrate --add <project:lot> [--wave <wave>]` adds a lot to a live wave instead of launching a second one: the lot is checked like a launched one, queued in the wave's `adds.log` and played as soon as a session slot is free; the refusal of a second wave in the same repository now names this command, with the lot and the wave (L421, `docs/orchestrate.md`). A session running in a sibling repository is no longer handed back for a commit on another repository's main branch once a lot was added to the wave.
+
 **1.35.0**: the wave's gate stops paying for reds that need no fix. With `orchestrate.testReplay`, a red that stays red alone in the lot is replayed alone at the start sha, and one already failing there is « déjà rouge »: no correction pass, no escalation; a test that expired in the whole suite and passes alone at 80 % or more of its delay is a « délai trop juste », a warning naming the test with its duration and its delay (L510, `docs/orchestrate.md`). On a gate played in several folders, `orchestrate.test` takes a list of parts `[{ dir, run, replay? }]` and each part plays, replays and attributes its own reds, so a composed gate gets the same two verdicts (L512, `docs/orchestrate.md`, « A gate declared in parts »; evatosorus `node --test` is not covered yet). `cadence corrections` now counts the passes launched on tests that ended without a code change (L510, `docs/corrections.md`). The gate can also run on another machine through `orchestrate.gate.host`, by ssh at the pushed sha, with a local fallback and a lost connection replayed locally, never counted red (L403, `docs/remote-gate.md`). The `qa-reviewer` opens a browser context and a profile of its own, so two QA passes started together no longer share a tab (L511, `docs/skills.md`). The `spec-writer` joins a `contraste.md` (WCAG 2.2 ratios, 4.5:1 at least) to each sheet, and the `ux-reviewer` gets a delivery grid and a static check of AI tics (L513, `docs/orchestrate.md`). Small fixes: `cadence release` prints its local tag before the gate and removes it when red (L508, `docs/releasing.md`), `raf ux` and `raf review` print the commit command for the regenerated plan (L509), and `cadence deliver` outside a wave commits the plan it wrote for the « article à rafraîchir » lot (L420, `docs/news.md`).
 
 **1.34.1**: 1.34.0 was tagged but its publication to npm failed (a CHANGELOG entry cited a lot with no commit in the tag); 1.34.1 publishes the same content, with that entry reworded. Install 1.34.1 to get the edge-case probe and the steadier tests of 1.34.0.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sylad/cadence",
-  "version": "1.35.0",
+  "version": "1.37.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",
@@ -20,6 +20,7 @@
     "NOTICE",
     "docs/raf.md",
     "docs/orchestrate.md",
+    "docs/mesures/brief-implementation-enrichi-avant-apres.md",
     "docs/deliver.md",
     "docs/remote-gate.md",
     "docs/spec.md",

package/templates/orchestrate/fix-docs.md

@@ -8,7 +8,7 @@ Documentation behind the lot:
 {{constats}}
 
 Read the diff of each commit above (`git show <sha>`), the project's CLAUDE.md, the README, the pages of `docs/`, the CHANGELOG and the news entries; update each document the change makes false or leaves out; where the README is a short home page, the detail goes in the pages of `docs/` and the README receives only a link. A document that the change really leaves true is left alone, but the gap stays open for the program until it is acknowledged: {{ack}} A session that neither writes the documentation nor acknowledges the gap hands the lot back to the lead: it never goes to review. Say why under "choix" as well.
-Rules: commit each document as soon as it is right, with explicit paths (never `git add -A` or `commit -a`), and a message that cites the lot (`docs({{lot}}): …`); run the project's documentation checks if it has any, and its full test suite and build if a test reads the documents, before reporting; do not push, deliver, run `raf done`, `raf ux` or `raf review`.
+Rules: commit each document as soon as it is right, with explicit paths (never `git add -A` or `commit -a`), and a message that cites the lot (`docs({{lot}}): …`); run the project's documentation checks if it has any, and the targeted tests that read the documents plus the build, before reporting (the full suite is the program's gate: do not replay it; with no gate below, play the full suite yourself, once); 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.
 {{elsewhere}}
 Do not stop to ask: an interpretation you settle yourself goes under "choix" with the alternative you did not take; "questions" stays empty. Making no documentation commit is a valid outcome only with the acknowledgement above.

package/templates/orchestrate/fix-minors.md

@@ -10,7 +10,7 @@ Minor findings:
 
 Fix each minor finding that is right, and nothing else. Rules: test first; commit each fix as soon as
 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,
+lot (`fix({{lot}}): …`); run the targeted tests of the code you touch (once, before committing) and the build, before reporting: the full suite is played once by the program as the gate given below, do not replay it (with no gate below, play the full suite yourself, once); 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

package/templates/orchestrate/fix.md

@@ -9,9 +9,10 @@ Commits of the lot so far:
 Findings to fix:
 {{constats}}
 
+Red tests named above (L522): before writing any code, replay each red test named alone, with the project's own single-test command. A test that is red alone is a defect: fix it. A test that is green when replayed alone is unstable under load, not a defect of the lot: do not change code for it, and list it under « choix » of your report as unstable, to be proposed to the lead for its own lot.
+
 Rules: test first; commit each fix as soon as 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
+`git add -A` or `commit -a`), and a message that cites the lot (`fix({{lot}}): …`); run the targeted tests of the code you touch (once, before committing) and the build, before reporting: the full suite is played once by the program as the gate given below, do not replay it (with no gate below, play the full suite yourself, once); do not push, deliver, run `raf done`, `raf ux` or
 `raf review`. Read the project's CLAUDE.md first.
 Sealed test of ANOTHER lot: if what your own sealed tests require contradicts a sealed acceptance test of another lot (an `acceptation-<lot>.json` that is not yours), it is a question to the lead naming both tests (file and `Rn — …` name of each): never modify, rewrite or reseal it and never pick a side. Stop there and put the question in your report. The program compares the fingerprints of the sealed tests of every other lot at the end of each session and hands your lot back, naming the first offending commit, before any 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.
@@ -23,7 +24,7 @@ Self-check before handing back (the recurring findings of the reviews), covering
 - no false comment: a comment, a docstring or a message never describes a behaviour the code no longer has or does not have.
 A point you cannot hold is written under "choix" or "nonVerifie" of your report, not left unsaid.
 
-Auto-verification once the tests are green, before the review: when the full test suite and the build pass, re-read the complete diff of your fix commits (`git diff <HEAD before your first fix>..HEAD`, run in each repository where you committed a fix: the project and any neighbouring repository above) against the grid of the code-reviewer agent: code bug; architecture drift; docs/architecture.md (or the project's architecture documentation) up to date; edge cases; one test per changed behaviour. What you find in your own fix, fix it at once (a `fix({{lot}}): …` commit) and rerun the suite and the build; touch nothing else. Then write in "resume" a paragraph that starts with « auto-vérification »: what you re-read, what you found and fixed, what you could not hold. It is one reading of the diff, not a second review: no subagent, no new exploration, no re-reading of files the diff does not touch.
+Auto-verification once the tests are green, before the review: when the targeted tests and the build pass, re-read the complete diff of your fix commits (`git diff <HEAD before your first fix>..HEAD`, run in each repository where you committed a fix: the project and any neighbouring repository above) against the grid of the code-reviewer agent: code bug; architecture drift; docs/architecture.md (or the project's architecture documentation) up to date; edge cases; one test per changed behaviour. What you find in your own fix, fix it at once (a `fix({{lot}}): …` commit) and rerun the targeted tests and the build; touch nothing else. Then write in "resume" a paragraph that starts with « auto-vérification »: what you re-read, what you found and fixed, what you could not hold. It is one reading of the diff, not a second review: no subagent, no new exploration, no re-reading of files the diff does not touch.
 
 If a finding is wrong, say so under "choix" with the reason. If you make no commit at all, "choix" MUST say why: a session with no commit and no reason is handed back to the lead without a new review (the review would reread the same commits). 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);
@@ -32,7 +33,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.
+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, unless the program's gate is green (L522): then the claim is not believed and nothing is opened), 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

@@ -5,8 +5,7 @@ Goal: {{objectif}}
 {{fiche}}
 {{decisions}}
 Rules: test first; commit each sub-part as soon as its tests pass, with explicit paths (never
-`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
+`git add -A` or `commit -a`), and a message that cites the lot (`feat({{lot}}): …`); run the targeted tests of the code you touch (once, before committing) and the build, before reporting: the full suite is played once by the program as the gate given below, do not replay it (with no gate below, play the full suite yourself, once); do not push, deliver, run `raf done`, `raf ux` or
 `raf review`.
 Sealed test of ANOTHER lot: if what your own sealed tests require contradicts a sealed acceptance test of another lot (an `acceptation-<lot>.json` that is not yours), it is a question to the lead naming both tests (file and `Rn — …` name of each): never modify, rewrite or reseal it and never pick a side. Stop there and put the question in your report. The program compares the fingerprints of the sealed tests of every other lot at the end of each session and hands your lot back, naming the first offending commit, before any 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.
@@ -24,9 +23,11 @@ Limits and rules, before the walkthrough (a code bug found by the review is the
 - edge cases [L447] (the first sub-cause of the code bugs: 96 of the 136 `bug-code` passes of the 24–30-10 window, 71 %): write the list BEFORE the first line of code, and before reporting play each listed input once on the real path (a real file or a real call, never only your fixture) and compare what comes out with what the rule says. For every function, parser, pattern, threshold or command you add or change, list the inputs at its edge — empty, absent, twice, wrong order, wrong type, refused, the real shape of the data (not the one of your fixture), the other callers of what you changed — and give each one a test that fails without your code, before handing back, except a case the fiche does not cover: with a fiche, you do not code a rule it does not state, so that case is written under "nonVerifie" or "choix", neither coded nor tested; a case you listed and did not test goes under "nonVerifie";
 - claims: each figure, « all », « never » or « always » that your README, docs, comments or tests state is checked against the code or by running it, not from memory.
 
+Grid of the code-reviewer (L523), the one the review applies to your diff: code bug (wrong result, unhandled error, input trusted raw); architecture drift (a responsibility in the wrong module, a duplicated block, a layer skipped); a test missing or that cannot fail; dead code; an error swallowed; documentation that does not follow the change; a written convention of the project not followed. Edge cases first: for each edge case of the goal (the « edge cases » point above: empty, absent, twice, wrong order, wrong type, refused, the real shape of the data, the other callers of what you change), write its test BEFORE the first line of code and see it fail for the right reason, then code; a case the lot does not cover is neither coded nor tested, it goes under "nonVerifie" or "choix". Before your last commit, re-read your diff against this grid and fix what it shows; a point you do not hold goes under "choix" or "nonVerifie" of the report (no new field).
+
 Real walkthrough once the tests are green, before the auto-verification below: play what you delivered as a user would, not by re-reading the diff. A command: run it in a throwaway repository (`git init` in a fresh folder of the session's temporary folder, never inside the repository), following step by step the documentation the lot wrote (README, `docs/`), every command exactly as written there; a command the documentation cannot run, or whose documented path is impossible from the state the previous steps leave, is broken. A screen: open it in each of its states, failure included, the failure shown where the action takes place (in view from the control the user just used, not above or below the fold), and take a capture of each. What breaks, fix in this same session (test first, a `fix({{lot}}): …` commit) and play it again. Then write in "resume" a paragraph that starts with « parcours réel »: what you played, what broke and was fixed, what you could not play (also under "nonVerifie"); a lot with nothing to play (no command, no screen) says so in that paragraph.
 
-Auto-verification once the tests are green, before the review: when the full test suite and the build pass, re-read the complete diff of the lot, commit by commit (the commits `raf commits {{lot}}` lists, each with `git show <sha>`; never a `git diff` range, which would take in the commits of other lots) against the grid of the code-reviewer agent: code bug (wrong result, unhandled error, input trusted); architecture drift (a responsibility put in the wrong module, a duplicated block, a layer skipped); docs/architecture.md (or the project's architecture documentation) up to date; edge cases (the list of the edge-cases point above, each with its test); one test per changed behaviour. What you find, fix it at once (test first, a `fix({{lot}}): …` commit) and rerun the suite and the build. Then write in "resume" a paragraph that starts with « auto-vérification »: what you re-read, what you found and fixed, what you could not hold. It is one reading of the diff, not a second review: no subagent, no new exploration, no re-reading of files the diff does not touch.
+Auto-verification once the tests are green, before the review: when the targeted tests and the build pass, re-read the complete diff of the lot, commit by commit (the commits `raf commits {{lot}}` lists, each with `git show <sha>`; never a `git diff` range, which would take in the commits of other lots) against the grid of the code-reviewer agent (the paragraph « Grid of the code-reviewer (L523) » above): code bug (wrong result, unhandled error, input trusted); architecture drift (a responsibility put in the wrong module, a duplicated block, a layer skipped); docs/architecture.md (or the project's architecture documentation) up to date; edge cases (the list of the edge-cases point above, each with its test); one test per changed behaviour. What you find, fix it at once (test first, a `fix({{lot}}): …` commit) and rerun the targeted tests and the build. Then write in "resume" a paragraph that starts with « auto-vérification »: what you re-read, what you found and fixed, what you could not hold. It is one reading of the diff, not a second review: no subagent, no new exploration, no re-reading of files the diff does not touch.
 
 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
@@ -39,7 +40,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.
+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, unless the program's gate is green (L522): then the claim is not believed and nothing is opened), 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/precheck.md

@@ -9,4 +9,5 @@ Answer `oui` only when every part of the lot is present, with a proof for each (
 some parts are present (say which); `non` otherwise. When in doubt, answer `non`: an implementation session follows.
 You are read-only: do not modify, commit, push or run `raf start|done|note|review|ux`. Do not launch subagents.
 Give your report as the structured output: `dejaPresent` (oui | partiel | non), `preuves` (the proofs), `resume` (one sentence).
+Also give, in the optional `lu` field, what you read to look: the files the lot concerns (`path:line`), the neighbouring code to imitate and the existing tests you opened, one line each (a few lines, not a copy of the code). The implementation session starts from it instead of searching again; leave `lu` out when you read nothing of use.
 {{tmp}}