@sylad/cadence 0.20.0 → 0.22.0

package/dist/plan.js

@@ -97,6 +97,10 @@ export class Plan {
             lots.flow = false; // « lots: [] » écrit par init : passer en style bloc
         return new Plan(path, doc, !/^lots:[^\n]*\n(?:#[^\n]*\n)*- /m.test(text), settings);
     }
+    /** Le plan tel qu'il est maintenant sur le disque (un script a pu l'écrire depuis la lecture), mêmes réglages. */
+    reloaded() {
+        return Plan.load(this.path, this.settings);
+    }
     save() {
         this.writable();
         writeFileSync(this.path, this.doc.toString({ lineWidth: 0, indentSeq: this.indentSeq }));
@@ -317,6 +321,13 @@ export class Plan {
         this.doc.get('lots').add(node);
         return id;
     }
+    /** Déclare les dépôts voisins d'un lot (clé `repos:`) : un chemin seul, ou `{ path, cite }` quand le voisin est partagé. */
+    setRepos(lotId, repos) {
+        this.writable();
+        const node = this.doc.createNode(repos.map((r) => (r.cite === undefined ? r.path : { path: r.path, cite: r.cite })));
+        node.flow = true;
+        this.lotNode(lotId).set('repos', node);
+    }
     addTask(lotId, title) {
         this.writable();
         const lot = this.lotNode(lotId);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sylad/cadence",
-  "version": "0.20.0",
+  "version": "0.22.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

@@ -18,9 +18,9 @@ commands (its CLAUDE.md names them), never with `raf start|done|note|ux|review`.
   (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. Count the free slots from what `--status` shows per wave, not from the live sessions (a
-  wave's steps take a slot and give it back between two steps): 2 − Σ min(cap, number of repositories
-  of the wave that still have lots). Never raise `--max-sessions` above two to speed a wave up.
+  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.
 - **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** —
@@ -97,6 +97,37 @@ questions back (`--resume --answer <project>:<lot> "…"`), look at the UX revie
 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).
 
+### 2c. Chaining without the human
+
+Once the human has given the **first choice and the order** (the lots, and the priority: `--priority` or the
+`priority:` list of the parent folder's `cadence.yaml`), the lead does not come back to ask « next? ». For each lot a
+wave hands back **ready**, it chains, in this order, one project at a time: re-verify it yourself (section 3, point 2),
+`raf done` (a read-only plan: the project's own command; a `visible` lot first waits for the human's UX verdict, `raf ux`, and is neither closed nor delivered without it — the chain goes on with the other lots), push, deliver (section 4), the `qa-reviewer` check that
+section asks for; then it starts the next wave, in the declared priority — `cadence orchestrate --continue --priority …` draws the next ready lot
+of the plan itself (section 2b), and the limits of section « Limits that always apply » still hold. A lot that was not
+handed back ready (refused, review not compliant after the correction passes, red delivery, blocking QA finding) is
+not chained over: it is reported, and the chain goes on with the lots that do not depend on it.
+
+**The threshold.** Before every new wave, read the context of the lead session with `cadence session context`: the
+`cadence-hud` mod publishes the context of each session, one file per session named after its id, and the command reads the
+one named by `$CLAUDE_CODE_SESSION_ID` (Claude Code sets it in the environment of your Bash, so it is your own session,
+whatever the folder; `--session <id>` overrides it). Without the variable it falls back to the folder only if a single
+session publishes for it; two sessions in one folder make it exit 2 ("pass --session"), never guess the latest. It prints
+`ctx 42 % (84000/200000)`, the figure the `ctx` segment of the band shows, which the band publishes to
+a file because it is only a rendering the model cannot see. If the command fails (exit code 2: the band is not loaded in
+this session, several sessions share the folder without the variable, or the figure is older than two minutes), treat it as
+**at the threshold**: you cannot prove you are under it, and without the band loaded the lead does not chain.
+From **60 %** upward, start nothing: at the threshold the lead runs `session-close` in each project touched, writes its
+memory (filtered, as `session-close` says), and records three lines for next time with `cadence session next` — the wave
+that was about to start comes first among them. Under it, chain. The lead says in one sentence which side of the threshold
+it is on each time it chains or stops; it never waits for the figure to move (never a polling loop).
+
+**What stays with the human**: the first choice and the order; the questions a session raised (the lead brings them
+back at once and does not answer in the human's place); the UX reservations (`raf ux` is recorded on the human's
+verdict, a UX reviewer's captures are looked at by the human). While a question or a UX reservation is pending on a
+lot, the chain goes on with the other lots and does not wait for it. A delivery that needs the human's confirmation
+(their standing instructions, section 4) is a stop of the chain, not a bypass.
+
 ## 3. Check
 
 0. After an orchestrated wave the review is already done, by a fresh session: read the table, then go to

package/templates/orchestrate/review-small.md

@@ -5,6 +5,7 @@ cite the lot (`raf commits {{lot}}`, or `git log`), run the checks, report real
 {{repos}}
 {{ux}}
 {{checks}}
+{{docs}}
 {{choix}}
 A proposed sub-task describes an observable bug (a wrong output, a crash, a measured regression); any other minor finding stays a note of this lot, not a sub-task.
 You are read-only: do not modify, commit, push or run `raf review|ux|done`. Do not launch subagents.

package/templates/orchestrate/review.md

@@ -3,6 +3,7 @@ You are given the repository path and the lot id only: read the diff yourself fr
 cite the lot (`raf commits {{lot}}`, or `git log`), run the checks, report real defects only.
 {{repos}}
 {{checks}}
+{{docs}}
 {{choix}}
 A proposed sub-task describes an observable bug (a wrong output, a crash, a measured regression); any other minor finding stays a note of this lot, not a sub-task.
 You are read-only: do not modify, commit, push or run `raf review|ux|done`. Do not launch subagents.