@sylad/cadence 1.13.0 → 1.14.1

package/docs/spec.md

@@ -28,6 +28,8 @@
 
 `cadence spec reseal <lot> <test> --reason texte` is the lead's way to correct one sealed acceptance test of the lot in progress that contradicts its sheet (unchanged, or amended by commits of the lot, L217; of a delivered lot, also by commits of another delivered lot, L229) (of a delivered lot: add `--porteur <lot in progress>`); refused while a wave of the repository is running, or a wave that is not `done` keeps open (question waiting, suspended, queued) any lot of this repository still `doing` in its plan, the resealed lot or another (L238: one error, also when a live wave holds the lock, names each wave (live ones to wait for), its launch folder and, for each stopped wave, the single `cd <folder> && cadence orchestrate --resume --wave <wave> --drop <project>:<lot> --drop …` that closes all its open lots of the repository, the queued ones that are not `doing` in the plan included (L239); a lot `done` or absent in the plan never refuses), see [The accept step](orchestrate.md#the-accept-step-red-acceptance-tests-and-their-lock).
 
+`cadence spec green <lot>` (L366, GitHub issue #18) is the lead's way to put back to green a lot driven and closed by hand (`raf done`) whose `acceptation-<lot>.json` stayed at `vert: false`: closed like that, its tests keep the lock total and every later wave of the repository is handed back with `verrou des tests d'acceptation … premier commit fautif` on lots that never touched them, and `spec reseal` does not cover it (it takes a lot `doing`, or a delivered lot at `vert: true` with `--porteur`). The program runs the lot's acceptance command (`orchestrate.accept`, same rules as the cycle) and, green, sets `vert: true`, reseals the listed tests refined since the red commit (one `resceaux` entry each) and commits the file alone, citing the lot (`chore(<lot>): acceptation verte, vert: true posé par cadence spec green`, or the project's `plan.commit` template when it has one; the subject stays short and fixed, the tests resealed are listed in the commit body, one `- <path>` line each, so a `header-max-length` hook accepts it); red, the tail of the output goes to stderr, exit 1, nothing changed; already green, nothing to do. Refused for a `todo` lot, from a session (`CADENCE_ORCHESTRATED`), during a wave of the repository and while an unfinished wave keeps a lot of the repository open (the same refusals as `spec reseal`, worded for `spec green`); a listed test changed but not committed is refused before anything runs. `raf done` refuses such a lot without `--force`, and `cadence orchestrate --dry-run` prints `acceptation rouge d'un lot clos` once per repository, see [A closed lot left at vert: false](orchestrate.md#the-accept-step-red-acceptance-tests-and-their-lock).
+
 `cadence spec qa <fiche.yaml>` derives from a valid sheet the section of `docs/qa/expectations.md` for its screen and prints it on the standard output
 (it never writes the file: you paste the section, and the lead commits it like the rest of the plan files). A sheet with violations prints them on the
 error output, nothing on the standard one, and exits 1. The derivation is built so that the planned empty and error states are never reported as defects:

package/docs/stabilite.md

@@ -31,5 +31,7 @@ From 1.0.0 cadence follows [semantic versioning](https://semver.org): what is li
 - The wording of the briefs and of the instructions inside the skills and the agents.
 - The **format of the sheets** (`fiche.yaml`: the screen sheet `templates/fiche.yaml`, the back-end sheet `templates/fiche-back.yaml`, the mixed sheet) and so the invariants `cadence spec check` enforces: experimental while the next bricks of the spec step (S3–S6) still reshape it, a sheet that passes today may be refused by a later release. The `spec` commands and their exit codes are guaranteed, the keys they read are not yet.
 
+**Node**: `engines.node` is `>=22.18` (the first Node that runs `.ts` files without a tool, which the test suite relies on). The minimum Node version follows the maintained LTS lines: when a Node line leaves maintenance, cadence raises its minimum in a **minor** release, announced under *Changed* in the [CHANGELOG](../CHANGELOG.md) with an explicit warning. Node 20, out of maintenance since April 2026, is no longer supported.
+
 There is no schema version and no migration: a file written by an earlier release keeps working, and a key a
 release adds is optional.

package/docs/whats-new.md

@@ -4,6 +4,8 @@
 
 ## In two lines
 
+- **1.14.1**: publishes 1.14.0 (tagged, never published): Node 22.18 or later is required; `plan.commit`, `plan.onWrite`, `orchestrate.testReplay`, `spec green`, `ref coverage` and `verify --gate --sha`.
+- **1.14.0**: Node 22.18 or later is now required (Node 20 dropped). `plan.commit`, `plan.onWrite` and `orchestrate.testReplay` fit a wave to your hooks, files and load; `spec green`, `ref coverage` and `verify --gate --sha` are new.
 - **1.13.0**: `cadence release` prepares the version commit; `cadence config set --all` sets one key in every project; waves share the machine between sessions, reserve a budget for the escalation and tolerate the lead's delivery push.
 - **1.12.1**: the escalation line of the final table follows the lot's state (a lot withdrawn or failed during its escalation no longer reads « en cours »), and a test that raced on the GitHub runner is deterministic.
 - **1.12.0**: `orchestrate.escalation: { model: fable }` plays one correction and one fresh review on that model before a wave hands a lot back; absent, nothing changes.
@@ -33,6 +35,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.14.1**: 1.14.0 was tagged but never published (a test of the Node minimum read only `[Unreleased]`, which the version commit empties, a fault of the test and not of the tool, L368); 1.14.1 publishes it as it stands, so everything listed under 1.14.0 below arrives with it, Node 22.18 or later first.
+
+**1.14.0**: **Node 22.18 or later is now required (Node 20 dropped)** (L365, `docs/stabilite.md`, `docs/releasing.md`): `engines.node` goes from `>=20` to `>=22.18`, the first release that runs `.ts` files without a tool, which the test suite depends on, and Node 20 is out of maintenance; it ships in a minor version because the minimum Node version now follows the maintained LTS lines. Upgrade Node before installing it. A wave fits the project it runs in. `plan.commit` in `cadence.yaml` (L343) is a template (`{lot}`, `{action}`, `{vague}`) for the subject of every plan commit, so a `commit-msg` hook that enforces Conventional Commits no longer fails a lot before any session, and `--dry-run` plays each subject through the repository's real hook. `plan.onWrite: { command, files }` (L346) regenerates the files derived from the plan after every write and commits them with it; a failing command refuses the write. Models are free (L345): `@<model>` of a lot and `orchestrate.review.light` / `full` take any name `claude --model` accepts. The gate runs under the project's Node, the `.nvmrc` first (L351). Fewer lots lost for nothing. `orchestrate.testReplay` (L354, `docs/orchestrate.md`) replays a red test of the gate alone before it counts, so a test that fails only under load is reported as unstable instead of triggering correction passes; a lot whose gate is green is no longer corrected (L361); the integration rebases again, up to twice, when the branch moved meanwhile (L364), and files the entries under the right `[Unreleased]` (L362). For the lead. `cadence spec green <lot>` and a refusal of `raf done` on a lot whose acceptance is still red (L366) stop a lot closed by hand from locking the tests of every later wave. `cadence ref coverage <inventaire.json>` and the `reference-planner` agent (L367) list the elements of a reference document that no lot covers. `cadence verify --gate --sha <sha>` (L348) replays the gate at a commit in a throwaway worktree. `lead tour` and `session` flag a close note that quotes a lot already done (L347). `cadence release` now prints the whole plugin update (L359), the test suite no longer depends on `TMPDIR` (L360), and the measured walk of a new user (L357) is in `docs/mesures/`.
+
 **1.13.0**: a lead of several projects loses less time on what is not the lot's fault. `cadence release patch|minor|major` (L341, `docs/releasing.md`) prepares the version commit (versions, CHANGELOG, checks of `docs/whats-new.md`) and prints the publication steps in order, without publishing anything. `cadence config set <key> <value> --all` (L342, `docs/lead.md`) sets one key in the `cadence.yaml` of every project of the folder, comments and order kept, with a config lot and a commit per project. In a wave, every session and the test gate get their share of the machine (`CADENCE_TEST_WORKERS`, cores ÷ session cap, L350), so suites no longer time out under the load of their neighbours; the lot's budget keeps a share for the escalation when `orchestrate.escalation` is declared (L349), so the escalation can actually play; the lead's own push of a ready lot during a wave no longer stops a running lot (L352, guards tested by L353); the `implement` brief asks for a real walkthrough of what was delivered and lists the human's decisions found in the notes of the lot and its parent (L344). Two tests of cadence that turned red only inside a wave are deterministic again (L355, L356).
 
 **1.12.1**: fixes after 1.12.0. The « escalade » line of the final table follows the lot's state (L338): a lot handed back or failed during its escalation before the model's verdict (`--resume --drop`, step exception, incident of the repository) reads « engagée, lot rendu avant le verdict du modèle » instead of « en cours », and only an escalated session that returned nothing (model unavailable to the account, cut, timeout) counts as `échec` in the table and in `cadence perf`, whose `--json` key list in `docs/perf.md` now names `escalations` and `quality`. Two tests of the worktree integration that raced on the order in which two lots take the integration lock — one of them failed the first publication run of 1.11.0 — now force that order (L339).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sylad/cadence",
-  "version": "1.13.0",
+  "version": "1.14.1",
   "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",
@@ -49,7 +49,7 @@
     "LICENSE"
   ],
   "engines": {
-    "node": ">=20"
+    "node": ">=22.18"
   },
   "scripts": {
     "build": "tsc -p tsconfig.build.json --noEmit",
@@ -64,7 +64,7 @@
     "yaml": "^2.5.0"
   },
   "devDependencies": {
-    "@types/node": "^20.14.0",
+    "@types/node": "^22.0.0",
     "typescript": "^5.5.0",
     "vitest": "^2.0.0"
   },

package/skills/lead/SKILL.md

@@ -44,7 +44,7 @@ commands (its CLAUDE.md names them), never with `raf start|done|note|ux|review`.
 
 Run `cadence lead tour` from the parent folder (one command, no subagent, no model: it reads the same
 facts as `cadence session start` for every project). It prints one line per project — lots in progress with their commit count
-(`0 commit` included; `silencieux Nj` when idle for more than three days), drift, notes from the last close, the next ready lot,
+(`0 commit` included; `silencieux Nj` when idle for more than three days), drift, notes from the last close (a `⚠ note périmée : L217 done le 24-10` beside a note means it quotes a lot already finished: relay it as stale, never ask for that lot), the next ready lot,
 repository state — and exits 0 even when a project is in error (its line says so). `--json` gives the same
 content. Read the lines yourself; open a project's own `cadence session start` only for the one you need to
 look at closer.
@@ -109,7 +109,7 @@ ends `interrupted`, and `--resume --wave <wave>` takes it up again (the command
 
 **One worktree per lot** (`orchestrate.worktrees`, L279) is on by default in cadence's own `cadence.yaml` since 2026-10-25 (L320) and off in a project that does not set the key (the key is the whole switch: no environment variable). Two independent lots of one repository then play at once, each in its own worktree, and the program integrates them. Its options belong to that mode: `--resume --wave <wave> --integrate <project:lot>` replays a lot handed back at the integration step (the wave's output names that exact command), `--replay <project:lot>` also after a refused plan write, `--remove-worktree <project:lot> [--abandon-commits]` removes a kept worktree and branch, and `cadence orchestrate --status` and `cadence lead tour` list the worktrees kept by waves (nothing to list in the default mode).
 
-**Delivering while the wave runs.** A lot that turns **ready** in the journal is not left waiting: once the lead has re-verified it (section 3, point 2) and recorded its verdict (`raf done`), it delivers that lot at once, without waiting for the end of the wave. The re-check runs at that sha in a throwaway `git worktree add --detach <tmp> <sha>` (removed afterwards), never in the shared tree, which holds the lots still running. Take the sha to deliver from `git log`: the last commit of the ready lot such that no commit of a lot that is not ready (running, queued, in question, handed back) sits beneath it — the same « livrable jusqu'à » the final table prints. Push that sha alone (`git push origin <sha>:main`, never HEAD, which holds the code of lots still running; the wave tolerates exactly this push — the journal says « push du lead (livraison de <lot>) toléré » — because the sha is an ancestor of HEAD holding no commit of a lot of the wave that is not ready (a commit that cites no lot passes), whereas any other push still stops the wave as an incident), then `cadence deliver --dry-run --sha <sha>` and `cadence deliver --sha <sha>`: `deliver` accepts a `--sha` during a wave of the same repository when none of its commits belongs to a lot that is not ready, and refuses otherwise, naming the lots. Without `--sha` it stays refused until every lot of the repository is ready or handed back. The wave's sessions keep committing in the working tree: `--sha` never reads it. What the log keeps is `<sha>`, unless the delivery script declares another deployed commit in `CADENCE_DEPLOYED_FILE`; if HEAD moved during the delivery without that declaration, `deliver` warns (« la tête a avancé pendant la livraison ») and the log keeps `<sha>`: it is not a failure. This is the measured gain: a ready lot used to wait for the slowest lot of its wave (1,554 lot-minutes between « ready » and the end of the wave over 28 waves).
+**Delivering while the wave runs.** A lot that turns **ready** in the journal is not left waiting: once the lead has re-verified it (section 3, point 2) and recorded its verdict (`raf done`), it delivers that lot at once, without waiting for the end of the wave. The re-check runs at that sha with `cadence verify --gate --sha <sha>` (a throwaway worktree whose untracked dependencies are linked from the main tree, removed afterwards), never in the shared tree, which holds the lots still running. Take the sha to deliver from `git log`: the last commit of the ready lot such that no commit of a lot that is not ready (running, queued, in question, handed back) sits beneath it — the same « livrable jusqu'à » the final table prints. Push that sha alone (`git push origin <sha>:main`, never HEAD, which holds the code of lots still running; the wave tolerates exactly this push — the journal says « push du lead (livraison de <lot>) toléré » — because the sha is an ancestor of HEAD holding no commit of a lot of the wave that is not ready (a commit that cites no lot passes), whereas any other push still stops the wave as an incident), then `cadence deliver --dry-run --sha <sha>` and `cadence deliver --sha <sha>`: `deliver` accepts a `--sha` during a wave of the same repository when none of its commits belongs to a lot that is not ready, and refuses otherwise, naming the lots. Without `--sha` it stays refused until every lot of the repository is ready or handed back. The wave's sessions keep committing in the working tree: `--sha` never reads it. What the log keeps is `<sha>`, unless the delivery script declares another deployed commit in `CADENCE_DEPLOYED_FILE`; if HEAD moved during the delivery without that declaration, `deliver` warns (« la tête a avancé pendant la livraison ») and the log keeps `<sha>`: it is not a failure. This is the measured gain: a ready lot used to wait for the slowest lot of its wave (1,554 lot-minutes between « ready » and the end of the wave over 28 waves).
 
 **Free resources.** While a wave is live or a session is held with `cadence lead hold`, `cadence lead tour` and `cadence orchestrate --continue` print, after the free slots line, `prêts, ressources libres : <project>:<lot> <title> (<resources>) · …`: the ready lots whose shared resources (`uses:`) nothing holds. Read it again each time an agent comes back (a session ended, a lot handed back or ready) and each time a lot is blocked (a question, a refusal, a resource taken), **before waiting** for the next transition: a lot listed there can start now, so start it (with the free slots line saying a slot is free) instead of waiting behind the blocked one. The line is a display: nothing is locked, and it never raises the cap — no `créneaux libres`, no new session. No line means no ready lot is free: wait.
 
@@ -126,7 +126,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 --wave <wave> --answer <project>:<lot> "…"`, naming the wave: a bare `--resume` is refused when several waves are unfinished), 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 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. It is also refused while a wave that is not `done` (stopped on a question or the quota, or still alive) keeps open any lot of that repository still `doing` in its plan, **the resealed lot, the porteur or any other lot of the repository** (the lock hands back all of them, L238; a lot `done` or absent in the plan, an old abandoned wave, a lot of another repository with the same id never block): the error is a single message, also when a live wave holds the repository lock: it lists every wave (the live ones and the stopped ones) with its launch folder and its lots and gives, for each stopped wave, ONE command to run as it stands, `cd <launch folder> && cadence orchestrate --resume --wave <wave> --drop <project>:<lot> --drop <project>:<lot>` (a `--drop` per open lot of the repository, queued ones not yet `doing` in the plan included, since `--resume` replays the whole wave; or `--resume --wave <wave> --answer …` to let it go on); a wave still alive is waited for. Close them **first**, reseal afterwards. 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: 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. It is also refused while a wave that is not `done` (stopped on a question or the quota, or still alive) keeps open any lot of that repository still `doing` in its plan, **the resealed lot, the porteur or any other lot of the repository** (the lock hands back all of them, L238; a lot `done` or absent in the plan, an old abandoned wave, a lot of another repository with the same id never block): the error is a single message, also when a live wave holds the repository lock: it lists every wave (the live ones and the stopped ones) with its launch folder and its lots and gives, for each stopped wave, ONE command to run as it stands, `cd <launch folder> && cadence orchestrate --resume --wave <wave> --drop <project>:<lot> --drop <project>:<lot>` (a `--drop` per open lot of the repository, queued ones not yet `doing` in the plan included, since `--resume` replays the whole wave; or `--resume --wave <wave> --answer …` to let it go on); a wave still alive is waited for. Close them **first**, reseal afterwards. 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: a new wave `cadence orchestrate <project>:<lot>` when it was handed back (`--resume` skips finished lots). **A lot closed by hand and left at `vert: false`: `cadence spec green <lot>` (L366).** `spec reseal` does not cover it (it takes a lot `doing`, or a delivered lot at `vert: true` with `--porteur`): a lot closed with `raf done` while its `acceptation-<lot>.json` stayed at `vert: false` keeps the lock total on its tests, and every later wave of the repository is handed back with `verrou des tests d'acceptation … premier commit fautif` on lots that never touched them (issue #18). The way out is `cadence spec green <lot>`, outside any wave: the program runs the lot's acceptance command (`orchestrate.accept`), and, green, sets `vert: true`, reseals the listed tests refined since the red commit and commits the file alone, citing the lot; red, nothing changes (exit 1). `raf done` now refuses such a lot without `--force`, and `cadence orchestrate --dry-run` prints `acceptation rouge d'un lot clos` for each one before the wave starts; a lot handed back for a test of a **closed** lot it never touched is this case, not a test to reseal. 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).
 
@@ -191,7 +191,9 @@ is always recorded by the lead's own `raf ux`, never by a subagent.
    itself from the commits that cite the lot, runs the checks, and returns real defects only,
    ranked, with what it could not verify and a one-line verdict.
 2. **The lead re-verifies itself**: `git log` shows the commits, the test suite and build pass when
-   run by the lead, `raf check` is clean. A subagent is green on what it *could* test; say plainly
+   run by the lead, `raf check` is clean. During a wave, or in any tree that is not the lead's own, replay the gate at the lot's last sha with
+   `cadence verify --gate --sha <sha> [--project <dir>]` (exit 0 green, 1 red with the failing tests, 2 nothing to replay): a bare
+   `git worktree add` has no `node_modules` or `.venv` and reddens suites that only miss their dependencies. A subagent is green on what it *could* test; say plainly
    what nobody could verify.
 3. Fix or re-delegate what the review found; then record the verdict, `raf review <lot> "…"` with
    the code reviewer's last line brought up to date (and `raf ux <lot> "…"` for a visible lot, with

package/skills/orchestrate/SKILL.md

@@ -18,7 +18,7 @@ cadence orchestrate finance-tracker:L41 cadence:L18@haiku --budget 1.5M
 ```
 
 - One positional argument per lot: `<project>:<lot>`, then `@<model>` to give that lot a model (`@haiku`, `@sonnet`,
-  `@opus`). The project is what comes before the **first `:`**, the model what comes after the **last `@`**.
+  `@opus`, or any model name the account has, such as `@fable`, passed as it stands to `claude --model`; `--dry-run` warns for a name outside the three aliases). The project is what comes before the **first `:`**, the model what comes after the **last `@`**.
 - **A lot id may contain « / »** (sub-tasks of a plan kept read-only by another tool, `Q4/accueil-4-ux12`): write it as is, never escape
   it, never replace it, never split it. Quote the whole argument only if the shell needs it.
 - There is no `--lot` and no `--model`: the lot and its model are always in the same argument, `<project>:<lot>@<model>`.

package/skills/session-close/SKILL.md

@@ -68,6 +68,8 @@ With no project named, run `cadence session close --all` from the parent folder,
 6. **Clean state**: everything committed and pushed, no delivery running. If the command still exits 1,
    say what remains and do NOT say the session is closed.
 7. **Three lines for next time**: `cadence session next "…" "…" "…"` — the next `session-start` shows them. The command prints the lines as recorded: report them from that output, do not run `session start` again.
+   If the report has a "Notes de la dernière clôture à réécrire" section, those notes quote a lot already
+   finished (`⚠ note périmée`): propose their rewrite in the lines below, never carry them over as they are.
    The lines replace the previous notes. Without a line the command refuses and keeps them; erase
    them on purpose with `cadence session next --clear`, only when nothing is left to say.
 

package/skills/session-start/SKILL.md

@@ -34,7 +34,8 @@ three most useful items across projects and wait. With a project named, work in
    - **Effects in production** ("Effets en production"): a red `✗` line is the first thing to say —
      a delivered feature that no longer works outranks any new lot; re-run `cadence verify` to confirm
      (a network blip also shows as red).
-   - **Notes from the last close**, if any.
+   - **Notes from the last close**, if any. A note followed by `⚠ note périmée : L217 done le 24-10`
+     quotes a lot already finished: say it is stale, do not propose that lot.
    - **Project facts** ("Faits propres au projet"), when the project plugs its own morning script in
      (`session.start` in `cadence.yaml`): summarise what bears on today's choice — deadlines, the
      project's own planning, documentation drift — and leave the rest.