@sylad/cadence 1.24.0 → 1.26.0

package/skills/lead/SKILL.md

@@ -35,8 +35,16 @@ commands (its CLAUDE.md names them), never with `raf start|done|note|ux|review`.
   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** —
-  never by a subagent, never two deliveries in parallel.
+- **Deliveries and `raf ux` / `raf review` verdicts are done by the lead, one project at a time, or by the `livreur` agent it
+  launches** (L439): the delivery and, with `lead.ux: lead`, `raf ux` may be done by the `livreur`; `raf review` stays with the
+  lead. Launch one `livreur` at a time: never two deliveries in parallel, and each `livreur` counts in the cap of subagents. Only another
+  `livreur` or another subagent blocks a new one; the sessions of a running wave do not (a ready lot is delivered while the wave runs,
+  section 2b). Never launch a `livreur` while the wave integrates a lot (`cadence lead tour` shows it): `raf done` would write the plan
+  of the main tree, which that integration refuses as modified. Brief: the absolute project folder, the lot, the sha to deliver
+  (« livrable jusqu'à »), the value of `lead.ux`, the base URL of the delivered app (the `deliver` configuration of `cadence.yaml`),
+  and for a visible lot with `lead.ux: lead` the `ux-reviewer`'s report and the folder of its captures. It hands back one line
+  (`L84 livré 3d6edf4, QA à lancer <url>`) or one `Question : …`; the lead itself launches the `qa-reviewer` with the URL of the line
+  (section 4), then the `livreur` of the next ready lot.
 - A subagent cannot ask the human anything. When it hits an ambiguity it stops and reports; the lead
   brings the question to the human.
 
@@ -179,7 +187,7 @@ reviewer's last line brought up to date. It does so only when the reviewer has n
 what the lot promised. At the **slightest doubt** — a reservation of the reviewer it cannot settle, a capture it cannot read,
 a layout or wording choice that is a matter of taste, a state the captures do not show — it records nothing, brings the
 captures and the question to the human, and the chain goes on with the other lots as for any UX reservation. The verdict
-is always recorded by the lead's own `raf ux`, never by a subagent.
+is recorded by the lead's own `raf ux` or, for a lot it hands over, by the `livreur` on the same criterion (it opens the captures itself and records nothing at the slightest doubt).
 
 ## 3. Check
 
@@ -190,6 +198,11 @@ is always recorded by the lead's own `raf ux`, never by a subagent.
    the absolute path of the project and the lot id, **not** the author's report: it reads the diff
    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.
+   Add a line `Report file: <absolute path>` in a temporary folder outside the repository (one file per
+   lot and pass): the agent writes its full report there and answers you in 5 lines (verdict, blocking
+   findings, follow-ups, the path). Read the file only when you need it: to act on a blocking finding,
+   to hand a finding to a fix, or to bring the verdict line up to date for `raf review`. A short reply with `Blocking: 0`
+   needs no read.
 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. 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
@@ -212,7 +225,7 @@ is always recorded by the lead's own `raf ux`, never by a subagent.
 
 ## 4. Delivery
 
-One project at a time, by the lead: push, then the `deliver` skill (`cadence deliver --dry-run`, then
+One project at a time, by the lead or, for a ready lot it hands over, by the `livreur` agent (« Limits that always apply »): push, then the `deliver` skill (`cadence deliver --dry-run`, then
 `cadence deliver`). Follow the human's standing instructions about confirmation before production.
 
 **The sha pushed needs a green verdict of the gate (L426).** Where the project declares a gate (`orchestrate.test` or
@@ -220,9 +233,11 @@ One project at a time, by the lead: push, then the `deliver` skill (`cadence del
 refuses with exit 3 a push of a branch whose local sha has no green verdict of `cadence verify --gate`, naming the sha and
 the command to run. The verdict of the re-check (section 3, point 2) belongs to the lot's sha, and the head of `main` is
 almost never that sha: `raf done` does not commit, so the plan commit that follows it (« plan: Lx terminé »), a release
-commit or the plan commit of the next lot sits above. Such a plan commit has no verdict, and `verify --gate --sha <head>`
-cannot reuse the wave's record (made at the lot's sha, `checks.head`): it replays the whole gate, ~5 minutes. Count that
-replay in: after the plan commit, `cadence verify --gate --sha HEAD`, then push `main`. Delivering while the wave runs
+commit or the plan commit of the next lot sits above. A commit that changes only the plan file (L432) takes the verdict of
+its parent, stacked ones included: the hook lets it through, no replay. A commit that also touches another file (a release
+commit, a plan commit with code) has no verdict, and `verify --gate --sha <head>` cannot reuse the wave's record (made at the
+lot's sha, `checks.head`): it replays the whole gate, ~5 minutes. Count that replay in: after such a commit,
+`cadence verify --gate --sha HEAD`, then push `main`. Delivering while the wave runs
 (section 2b) pushes the lot's sha alone (`git push origin <sha>:main`): its verdict is the one the re-check recorded, and the
 plan commit is pushed later, after its own replay. `CADENCE_PUSH_UNGATED=1 git push …` lets a push through with no verdict
 and says so on stderr: it is for the push the human explicitly asks ungated (a plan-only or docs-only commit above a verified
@@ -248,6 +263,10 @@ without an expectations file gets a draft back: show it to the human, who correc
 whether it is committed. It is not a gate: `raf done` does not wait for it, and a finding becomes a
 new lot, not a reopened one.
 
+Give the `qa-reviewer` the same line `Report file: <absolute path>` (outside the repository): it answers in 5 lines
+(verdict, blocking findings, follow-ups, the path) and keeps the full report, with its measurements, in that file; read the
+file only to show the human a blocking finding or to commit the draft of an expectations file.
+
 ## 5. Close
 
 At the end, the `session-close` routine in each project touched, and `cadence session next` lines in