@sylad/cadence 1.8.0 → 1.10.0

package/skills/deliver/SKILL.md

@@ -27,6 +27,11 @@ deliver:
   script: ./scripts/ship.sh "$CADENCE_SHORT"
 ```
 
+A script that deploys a commit other than `$CADENCE_SHA` (it committed a Nouveautés timestamp itself)
+writes that sha into the file named by `$CADENCE_DEPLOYED_FILE`: cadence logs it as delivered and never guesses
+(a content that is not a hexadecimal commit sha — `HEAD` or a branch name included — fails the delivery; empty during a wave, the log keeps `$CADENCE_SHA` and a warning
+says the head moved).
+
 Its arguments go after `--`: `cadence deliver -- api frontend` (`--sha <rev>` to deliver a pushed
 commit other than HEAD). Ask the human (or the project's own
 delivery skill) which arguments this delivery needs; never guess them.
@@ -36,7 +41,7 @@ delivery skill) which arguments this delivery needs; never guess them.
 Every `cadence` / `raf` command works on the git repository of the current directory. When the
 session runs from a parent folder that holds several projects (not itself a repository), run each
 command inside the project concerned: `cd <project> && cadence …`. The projects are the sub-folders
-that contain `docs/plan/raf.yaml`, or a `cadence.yaml` with a `plan:` key.
+that contain `.cadence/raf.yaml` or `docs/plan/raf.yaml`, or a `cadence.yaml` with a `plan:` key.
 
 Deliver one project at a time: the one the human names, or ask.
 

package/skills/lead/SKILL.md

@@ -7,7 +7,7 @@ description: Lead several cadence projects from a parent folder without loading
 
 The lead session stays small: it reads summaries, decides with the human, delegates, checks and
 delivers. Project files are changed by subagents, each with its own context; the facts of the tour come from `cadence lead tour`, a program. The projects
-are the sub-folders of the current directory that contain `docs/plan/raf.yaml`, or a `cadence.yaml`
+are the sub-folders of the current directory that contain `.cadence/raf.yaml` or `docs/plan/raf.yaml`, or a `cadence.yaml`
 with a `plan:` key. A project whose `cadence.yaml` maps the fields of a plan kept by its own tool is
 **read-only** for `raf`: it takes part in the tour, and its plan is changed with the project's own
 commands (its CLAUDE.md names them), never with `raf start|done|note|ux|review`.
@@ -21,7 +21,16 @@ commands (its CLAUDE.md names them), never with `raf start|done|note|ux|review`.
   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).
+  repositories it still holds) and one slot per lead session (below) from the M slots; no line from `lead tour` means no live wave and no lead session, so all M are free).
+  **A session you start by hand counts too** (a fix subagent, a review, a QA pass launched outside a wave): the registry does not
+  see it, so declare it. Right before starting it, `cadence lead hold <label> [--ttl minutes]` (60 minutes by default,
+  the label names the session: `correctif-L12`); as soon as it comes back, `cadence lead release <label>`. While it is held, both
+  commands print `sessions du lead : N (labels)` and subtract it from `créneaux libres`; the `--ttl` is the maximum duration you
+  declare for the session (size it to the slot you have, not to the optimistic case). When it runs out the hold stops counting, but
+  nothing stops the session: `lead tour` and `orchestrate --status` print `⚠ session du lead échue : <label> (…)` until you
+  release it, and the band shows the same ⚠ row. **At each ⚠, decide at once**: either it is still worth the slot, so renew it
+  with `cadence lead hold <label> --ttl <minutes>` and say why in one sentence, or stop it (`TaskStop` or the agent's end) and
+  `cadence lead release <label>`. A fix that ran 5 h on a 3 h slot (23-10) is the case this catches. Holding does not block anything and never raises the cap.
   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
@@ -34,8 +43,8 @@ commands (its CLAUDE.md names them), never with `raf start|done|note|ux|review`.
 ## 1. Tour of the projects
 
 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
-(`silencieux Nj` when idle for more than three days), drift, notes from the last close, the next ready lot,
+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,
 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.
@@ -59,7 +68,7 @@ one fresh short session per step; the wave runs from a frozen copy of the cadenc
 `cd <project> && raf start <lot>`, then starts from the brief written by `cadence orchestrate --dry-run
 <project>:<lot>`: it is already rendered (`{{chemin}}`, `{{lot}}`, `{{titre}}`, `{{objectif}}` and `{{news}}`,
 the News instruction of a `visible` lot, are filled in; it names no wave Playwright directory — a hand delegation has none — so the screenshot goes under the OS temp directory, then into `docs/nouveautes/captures/`). The lead only adjusts the goal to what done looks
-like (the human's words) and keeps the rest verbatim.
+like (the human's words) and keeps the rest verbatim. **A stale title is no reason to delegate by hand**: the lot's scope changed since the plan was written, so give the new goal to the program — `--goal "…"` on the launch (one lot per launch), or a `goal:` key on the lots in the plan (every launch, several lots at once): `goal:` in a native plan, and in a plan kept by another tool (read-only, e.g. maritime's `docs/plan/taches.yaml`) the key of theirs that holds it, mapped with `plan.fields: { goal: <their key> }` in `cadence.yaml` (an unmapped key other than `goal` is ignored without a message). It replaces the title as the objective of every brief and shows in the wave table.
 
 A lot that adds or changes a screen is `visible`: after the implementation, have the
 `ux-reviewer` agent review it (give it the URL or the way to run the app) and bring its verdict and
@@ -74,6 +83,8 @@ silent wait, no polling loop — `cadence orchestrate --status` shows where the
 cadence orchestrate <project>:<lot> <project>:<lot>@haiku … --wave <id> [--budget 2M]
 ```
 
+For a single lot whose title is stale, add `--goal "<what done looks like>"` (refused with two lots, `--continue` or `--resume`); for several lots, a `goal:` key per lot in the plan (mapped by `plan.fields.goal` on a plan kept by another tool).
+
 **Make the wave visible to the human.** Name the background task after what it runs — « vague `<id>` :
 `<project>:<lot>`, … » (its `description`), so the task list says which projects and lots, not just « a task
 is running » — and pass `--wave <id>` (e.g. `2026-10-08-1030`) so its state folder is known in advance. Right after
@@ -85,7 +96,7 @@ tail -n +1 -F .cadence/runs/<id>/journal.log     # from the folder the wave was
 ```
 
 Each line it prints reaches this conversation as it happens: relay it to the human in one short sentence, and
-bring a question back at once (`--resume --answer`). That follow-up replaces any waiting loop: still no polling,
+bring a question back at once (`--resume --wave <wave> --answer`, the command printed under the question). That follow-up replaces any waiting loop: still no polling,
 no `sleep`. The human can also watch from a terminal with `cadence orchestrate --status --watch` (table refreshed
 every 10 s, `--interval <s>` to change it; it stops by itself when no wave is running).
 
@@ -93,8 +104,14 @@ every 10 s, `--interval <s>` to change it; it stops by itself when no wave is ru
 another command: `cadence orchestrate --drop <project>:<lot>` takes a lot out of the wave — a lot not started never starts, a lot
 with a session running lets that session finish, then it is handed back to the lead (its commits stay); a lot that depended on it is
 handed back too. `cadence orchestrate --stop-after-current` lets the sessions running finish and starts nothing else: the wave
-ends `interrupted`, and `--resume` takes it up again. To take a lot out of a wave that is already stopped, use
-`--resume --drop <project>:<lot>` (the lot is handed back instead of being replayed). Neither kills a session.
+ends `interrupted`, and `--resume --wave <wave>` takes it up again (the command printed names the wave). To take a lot out of a wave that is already stopped, use
+`--resume --wave <wave> --drop <project>:<lot>` (the lot is handed back instead of being replayed). Neither kills a session.
+
+**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), 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.
 
 `cadence orchestrate --dry-run …` first when a precondition is in doubt. The program, not the lead, runs
 for each lot a fresh short session per step — implementation (Sonnet), code review
@@ -107,9 +124,9 @@ mechanical lot. Exit code: 0 all ready · 1 some lots handed back · 2 refused b
 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
+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. 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. 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
 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).
 
@@ -166,6 +183,7 @@ is always recorded by the lead's own `raf ux`, never by a subagent.
 
 0. After an orchestrated wave the review is already done, by a fresh session: read the table, then go to
    point 2. For a lot delegated by hand:
+0b. For a lot delegated by hand, `raf check` or the `dérive` column reporting `documentation en retard` is handled **before** the review: hand the lot to the `doc-keeper` agent (a fresh subagent; the absolute path of the project and the lot id; it updates the documents, or only lists them if you say read-only). Read the `docs.articles` key of the project's `cadence.yaml` yourself and put its entries (`repo`, `file`, and the absolute path of that repository, `repo` being relative to the project) in the brief, with read access to that repository for the subagent: the agent examines a document outside the repository only if the brief names it, and with no entry (the key is absent by default) you name none. A proposed lot it returns for a document outside the repository (`docs.articles`) is yours to decide: it never writes to that plan.
 1. The `code-reviewer` agent, as a fresh subagent (most capable model), reviews the lot. Give it
    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,

package/skills/session-close/SKILL.md

@@ -10,7 +10,7 @@ description: Close a work session on a repository that uses cadence — plan hyg
 Every `cadence` / `raf` command works on the git repository of the current directory. When the
 session runs from a parent folder that holds several projects (not itself a repository), run
 `cadence session close --all` there (`--depth 2` for projects one folder deeper): one "## project"
-section per sub-folder that contains `docs/plan/raf.yaml`, or a `cadence.yaml` with a `plan:` key.
+section per sub-folder that contains `.cadence/raf.yaml` or `docs/plan/raf.yaml`, or a `cadence.yaml` with a `plan:` key.
 Other commands (`raf …`, `cadence deliver`) still run inside the project concerned: `cd <project> && cadence …`.
 
 With no project named, run `cadence session close --all` from the parent folder, or `cadence session close` in each project touched during the session

package/skills/session-start/SKILL.md

@@ -5,7 +5,7 @@ description: Start a work session on a repository that uses cadence — gather t
 
 # Session start — resume without reciting
 
-The repository already carries the state: the plan (`docs/plan/raf.yaml`, or the file named by `plan:` in `cadence.yaml`), the history, the notes left at
+The repository already carries the state: the plan (`.cadence/raf.yaml`, or the legacy `docs/plan/raf.yaml`, or the file named by `plan:` in `cadence.yaml`), the history, the notes left at
 the last close. The only thing missing is the human's priority for today. This skill gathers the facts,
 proposes, and stops.
 
@@ -14,7 +14,7 @@ proposes, and stops.
 Every `cadence` / `raf` command works on the git repository of the current directory. When the
 session runs from a parent folder that holds several projects (not itself a repository), run
 `cadence session start --all` there (`--depth 2` for projects one folder deeper): one "## project"
-section per sub-folder that contains `docs/plan/raf.yaml`, or a `cadence.yaml` with a `plan:` key.
+section per sub-folder that contains `.cadence/raf.yaml` or `docs/plan/raf.yaml`, or a `cadence.yaml` with a `plan:` key.
 Other commands (`raf …`, `cadence deliver`) still run inside the project concerned: `cd <project> && cadence …`.
 
 With no project named, run `cadence session start --all` from the parent folder (or `cadence session start` in **each** project that has a plan) and report

package/templates/inventaire.json

@@ -0,0 +1,96 @@
+{
+  "version": 1,
+  "genre": "inventaire",
+  "document": { "slug": "exemple", "sha256": "0000000000000000000000000000000000000000000000000000000000000000" },
+  "pages": 5,
+  "roles": {
+    "titre": "titre d'un document, d'une page ou d'une section",
+    "titre-panneau": "titre d'un panneau ou d'une fenêtre d'interface",
+    "paragraphe": "phrase ou bloc de texte courant",
+    "legende": "texte qui désigne une figure, un tableau ou une échelle de couleurs (« Figure 1 — … »)",
+    "etiquette-figure": "mot ou valeur écrit dans une figure (flèche, axe, courbe, seuil)",
+    "exigence": "énoncé d'une exigence dans une liste d'exigences",
+    "ligne": "ligne d'un relevé ou d'un formulaire, sans autre fonction",
+    "message_erreur": "message qui signale une erreur ou un refus à l'utilisateur",
+    "unite": "unité accolée à une valeur (kt, hPa, m)",
+    "info_bulle": "texte court qui apparaît au survol ou au focus d'un élément",
+    "bouton": "contrôle sur lequel on agit (composant), ou son libellé (texte)",
+    "champ": "zone où l'on saisit une valeur (composant), ou son libellé (texte)",
+    "case_a_cocher": "contrôle à deux états, coché ou non, indépendant des autres",
+    "selecteur": "contrôle qui fait choisir une valeur dans une liste fermée (liste déroulante, boutons radio)",
+    "onglet": "entrée d'une barre qui bascule entre des vues de même niveau",
+    "menu": "liste d'actions ou de destinations qui s'ouvre depuis un contrôle",
+    "liste": "suite d'éléments de même nature affichés les uns sous les autres",
+    "panneau": "zone d'interface qui regroupe des contrôles (composant)",
+    "carte": "zone d'affichage cartographique ou graphique (composant)",
+    "icone": "pictogramme sans texte qui représente une action ou un objet",
+    "badge": "pastille ou marque qui qualifie un élément (statut, compteur)"
+  },
+  "elements": [
+    {
+      "type": "ecran", "id": "exemple#ecran-1", "confiance": "mesure",
+      "source": { "page": 1, "zone": { "x": 0, "y": 0, "l": 1700, "h": 2200 } },
+      "largeur_reference": 1440,
+      "zones": [{ "nom": "entete", "x": 0, "y": 0, "l": 1440, "h": 96, "pct": { "x": 0, "y": 0, "l": 100, "h": 8 } }]
+    },
+    {
+      "type": "composant", "id": "exemple#composant-1", "confiance": "mesure",
+      "source": { "page": 1, "zone": { "x": 120, "y": 600, "l": 240, "h": 64 } },
+      "role": "bouton", "position": { "x": 120, "y": 600 }, "taille": { "l": 240, "h": 64 }, "contenu": "Valider", "ecran": "exemple#ecran-1"
+    },
+    {
+      "type": "etat", "id": "exemple#etat-1", "confiance": "lu",
+      "source": { "page": 2, "zone": { "x": 120, "y": 600, "l": 240, "h": 64 } },
+      "citations": [{ "page": 2, "ligne": 14, "extrait": "le bouton est grisé tant que le formulaire est vide" }],
+      "nom": "vide", "cible": "exemple#composant-1"
+    },
+    {
+      "type": "texte", "id": "exemple#texte-1", "confiance": "lu",
+      "source": { "page": 1, "zone": { "x": 140, "y": 612, "l": 120, "h": 28 } },
+      "libelle": "Valider", "role": "bouton"
+    },
+    {
+      "type": "jeton", "id": "exemple#jeton-1", "confiance": "mesure",
+      "source": { "page": 1, "zone": { "x": 120, "y": 600, "l": 240, "h": 64 } },
+      "categorie": "couleur", "valeur": "#c81e28", "point": { "x": 130, "y": 610 },
+      "contraste": { "texte": "#ffffff", "fond": "#c81e28", "ratio": 5.9 }
+    },
+    {
+      "type": "table", "id": "exemple#table-1", "confiance": "lu",
+      "source": { "page": 3, "zone": { "x": 100, "y": 400, "l": 1500, "h": 300 } },
+      "colonnes": ["Code", "Sens", "Unité"],
+      "lignes": [["T", "température", "K"], ["P", "pression", "Pa"]]
+    },
+    {
+      "type": "gabarit", "id": "exemple#gabarit-1", "confiance": "lu",
+      "source": { "page": 4, "zone": { "x": 100, "y": 300, "l": 1500, "h": 500 } },
+      "nom": "message d'observation",
+      "champs": [
+        { "nom": "date", "obligatoire": true, "format": "AAAAMMJJ" },
+        { "nom": "vent", "obligatoire": false, "format": "entier", "min": 0, "max": 360 }
+      ]
+    },
+    {
+      "type": "schema", "id": "exemple#schema-1", "confiance": "lu",
+      "source": { "page": 5, "zone": { "x": 100, "y": 300, "l": 1500, "h": 900 } },
+      "noeuds": [{ "id": "capteur", "libelle": "Capteur" }, { "id": "serveur", "libelle": "Serveur" }],
+      "flux": [{ "de": "capteur", "vers": "serveur", "libelle": "envoie la mesure", "direction": "de_vers" }]
+    },
+    {
+      "type": "lien", "id": "exemple#lien-1", "confiance": "lu",
+      "source": { "page": 5, "zone": { "x": 100, "y": 300, "l": 1500, "h": 900 } },
+      "figure": "Figure 1 — chaîne de mesure", "passage": { "page": 5, "ligne": 3, "extrait": "comme le montre la figure ci-dessous" }, "constat": "confirme"
+    },
+    {
+      "type": "statut", "id": "exemple#statut-1", "confiance": "lu",
+      "source": { "page": 1, "zone": { "x": 1400, "y": 20, "l": 200, "h": 40 } },
+      "libelle": "Proposal", "couvre": ["exemple#ecran-1", "exemple#composant-1"]
+    },
+    {
+      "type": "silence", "id": "exemple#silence-1", "confiance": "incertain",
+      "source": { "page": 2 },
+      "cause": "le document ne montre aucun écran d'erreur",
+      "question": "Que voit l'utilisateur quand le serveur ne répond pas ?"
+    }
+  ]
+}

package/templates/orchestrate/accept-back.md

@@ -16,3 +16,4 @@ Report: `commits`, `nonVerifie` (what you could not run or check), `choix`, `que
 
 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, not as free text.
+{{tmp}}

package/templates/orchestrate/accept.md

@@ -16,3 +16,4 @@ Report: `commits`, `nonVerifie` (what you could not run or check), `choix`, `que
 
 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, not as free text.
+{{tmp}}

package/templates/orchestrate/fiche.md

@@ -12,3 +12,4 @@ Read the project's CLAUDE.md first, then the sheet, then the code and the tests
 Rank the findings blocking / major / minor, never on taste: a blocking or major finding sends the sheet back to the spec writer (one more pass only), a minor one becomes a note of the lot.
 You are read-only: do not modify, commit, push or run `raf review|ux|done`. Do not launch subagents. Leave `sousTaches` empty: a sheet has no bug to sub-task.
 Give your report as the structured output: counts of blocking / major / minor findings, each finding (severity, file, line, text), what you could not verify, and a one-line verdict.
+{{tmp}}

package/templates/orchestrate/fix-docs.md

@@ -0,0 +1,18 @@
+Work in `{{chemin}}` on lot `{{lot}}` — "{{titre}}" — of its plan, as the librarian (doc-keeper agent).
+The program computed that the commits of the lot touch code without touching the documentation that describes it (cadence.yaml docs.sync). Update the documentation, and nothing else: no code, no test.
+{{repos}}
+Commits of the lot so far:
+{{commits}}
+
+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`.
+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.
+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).
+{{reponse}}
+{{tmp}}

package/templates/orchestrate/fix-minors.md

@@ -25,4 +25,5 @@ You are one short session of an orchestrated wave: do not launch subagents (the
 Give your final report as the structured output (commits, tests, build, what you could not verify, choices).
 {{reponse}}
 {{captures}}
-Browser (Playwright): if a Playwright MCP server is available in this session (only in an orchestrated wave: a brief delegated by hand has none), the orchestrator launched it with its own output directory, in the orchestrator's run directory outside the repository: give screenshots, snapshots and traces a relative file name only (e.g. `page-home.png`), they land there. Never an absolute path, never the `--output-dir` option (the server's launch argument, which a session cannot set). If no such server is available, do not install or start one; if you use the Playwright CLI, write its outputs under the OS temp directory (or the temporary folder the project's CLAUDE.md names), never inside the repository, which must stay clean.
+Browser (Playwright): if a Playwright MCP server is available in this session (only in an orchestrated wave: a brief delegated by hand has none), the orchestrator launched it with its own output directory, in the orchestrator's run directory outside the repository. {{shots}} If no such server is available, do not install or start one; if you use the Playwright CLI, write its outputs under the OS temp directory (or the temporary folder the project's CLAUDE.md names), never inside the repository, which must stay clean.
+{{tmp}}

package/templates/orchestrate/fix.md

@@ -18,10 +18,12 @@ Self-check before handing back (the recurring findings of the reviews), covering
 - documentation: the README and the architecture documentation describe the behaviour, updated in the same commits as the behaviour (and the CHANGELOG);
 - tests: one test per rule of the fiche, named « Rn — … »; with no fiche, one test per business rule of the lot, named after it;
 - no dead code, and no test that cannot fail: a test whose assertion is always true, or that does not exercise the rule it names;
-- screens: for a modified screen, the capture due of each state, at 1440 and 390 px, with a relative file name; a lot with no modified screen owes none, and says so;
+- screens: for a modified screen, the capture due of each state, at 1440 and 390 px, with a file name (where it goes is the Playwright paragraph's rule); a lot with no modified screen owes none, and says so;
 - 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.
+
 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:
@@ -35,4 +37,5 @@ You are one short session of an orchestrated wave: do not launch subagents (the
 Give your final report as the structured output (commits, tests, build, what you could not verify, choices, questions).
 {{reponse}}
 {{captures}}
-Browser (Playwright): if a Playwright MCP server is available in this session (only in an orchestrated wave: a brief delegated by hand has none), the orchestrator launched it with its own output directory, in the orchestrator's run directory outside the repository: give screenshots, snapshots and traces a relative file name only (e.g. `page-home.png`), they land there. Never an absolute path, never the `--output-dir` option (the server's launch argument, which a session cannot set). If no such server is available, do not install or start one; if you use the Playwright CLI, write its outputs under the OS temp directory (or the temporary folder the project's CLAUDE.md names), never inside the repository, which must stay clean.
+Browser (Playwright): if a Playwright MCP server is available in this session (only in an orchestrated wave: a brief delegated by hand has none), the orchestrator launched it with its own output directory, in the orchestrator's run directory outside the repository. {{shots}} If no such server is available, do not install or start one; if you use the Playwright CLI, write its outputs under the OS temp directory (or the temporary folder the project's CLAUDE.md names), never inside the repository, which must stay clean.
+{{tmp}}

package/templates/orchestrate/implement.md

@@ -1,5 +1,5 @@
 Work in `{{chemin}}` on lot `{{lot}}` — "{{titre}}" — of its plan
-(`docs/plan/raf.yaml`, or the file named by `plan:` in `cadence.yaml`; read the lot, its notes and sub-tasks, and the project's CLAUDE.md first).
+(`.cadence/raf.yaml`, the legacy `docs/plan/raf.yaml`, or the file named by `plan:` in `cadence.yaml`; read the lot, its notes and sub-tasks, and the project's CLAUDE.md first).
 Goal: {{objectif}}
 {{repos}}
 {{fiche}}
@@ -9,15 +9,17 @@ full test suite and build before reporting; do not push, deliver, run `raf done`
 `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.
-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.
+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. Where the project's README is a short home page, the detail of a change goes in the pages of `docs/` and the README receives only a link to that page.
 Self-check before handing back (the recurring findings of the reviews). Go through this list point by point on your own commits before you report, and fix what is missing:
 - documentation: the README and the architecture documentation describe the behaviour, updated in the same commits as the behaviour (and the CHANGELOG);
 - tests: one test per rule of the fiche, named « Rn — … »; with no fiche, one test per business rule of the lot, named after it;
 - no dead code, and no test that cannot fail: a test whose assertion is always true, or that does not exercise the rule it names;
-- screens: for a modified screen, the capture due of each state, at 1440 and 390 px, with a relative file name; a lot with no modified screen owes none, and says so;
+- screens: for a modified screen, the capture due of each state, at 1440 and 390 px, with a file name (where it goes is the Playwright paragraph's rule); a lot with no modified screen owes none, and says so;
 - 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 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 (empty, absent, twice, wrong order, refused); 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.
+
 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
 alternative you did not take — the reviewer re-reads them. Stop and ask (under "questions") only on a real blocker.
@@ -39,4 +41,5 @@ Give your final report as the structured output, not as free text. If the plan i
 {{news}}
 {{commits}}
 {{reponse}}
-Browser (Playwright): if a Playwright MCP server is available in this session (only in an orchestrated wave: a brief delegated by hand has none), the orchestrator launched it with its own output directory, in the orchestrator's run directory outside the repository: give screenshots, snapshots and traces a relative file name only (e.g. `page-home.png`), they land there. Never an absolute path, never the `--output-dir` option (the server's launch argument, which a session cannot set). If no such server is available, do not install or start one; if you use the Playwright CLI, write its outputs under the OS temp directory (or the temporary folder the project's CLAUDE.md names), never inside the repository, which must stay clean.
+Browser (Playwright): if a Playwright MCP server is available in this session (only in an orchestrated wave: a brief delegated by hand has none), the orchestrator launched it with its own output directory, in the orchestrator's run directory outside the repository. {{shots}} If no such server is available, do not install or start one; if you use the Playwright CLI, write its outputs under the OS temp directory (or the temporary folder the project's CLAUDE.md names), never inside the repository, which must stay clean.
+{{tmp}}

package/templates/orchestrate/maquette.md

@@ -11,4 +11,5 @@ Check the sample data of the mockup: recompute the weekday of every date shown (
 Ground every finding in a named rule (Nielsen heuristic, WCAG 2.2 AA criterion) or a measurement, or in a mismatch between the mockup and the sheet. Rank them blocking / major / minor: a blocking or major finding sends the mockup back to the spec writer, a minor one becomes a note of the lot.
 You are read-only: do not modify, commit, push or run `raf review|ux|done`; this review is NOT the `raf ux` verdict (the conformity pass after the code keeps that role). Do not launch subagents. Leave `sousTaches` empty: a mockup has no bug to sub-task.
 Give your report as the structured output: counts of blocking / major / minor findings, each finding (severity, file, line, text), what you could not verify, and a one-line verdict.
-Playwright (browser MCP): this session's Playwright server was launched by the orchestrator with its own output directory, which lies in the orchestrator's run directory, outside the repository. Every screenshot, snapshot and trace you take lands there, so give each one a relative file name only (e.g. `maquette-erreur-390-revue.png`), never an absolute path, never the `--output-dir` option, and never write browser outputs anywhere else; the repository must stay clean.
+Playwright (browser MCP): this session's Playwright server was launched by the orchestrator with its own output directory, which lies in the orchestrator's run directory, outside the repository. {{shots}} Never write browser outputs anywhere else; the repository must stay clean.
+{{tmp}}

package/templates/orchestrate/precheck.md

@@ -2,10 +2,11 @@ Pre-check for lot `{{lot}}` — "{{titre}}" — of the repository `{{chemin}}`,
 Question: is the deliverable of this lot ALREADY in the repository (done by another lot, or by a correction)?
 Goal of the lot: {{objectif}}
 {{repos}}
-Read the lot, its notes and sub-tasks in the plan (`docs/plan/raf.yaml`, or the file named by `plan:` in `cadence.yaml`),
+{{lecture}}
 then look for the deliverable in the code and tests (`git log`, `grep`, reading the files the lot names). Do not
 implement anything and do not run the full test suite: this is a quick look.
 Answer `oui` only when every part of the lot is present, with a proof for each (file:line or commit sha); `partiel` when
 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).
+{{tmp}}

package/templates/orchestrate/review-recheck.md

@@ -4,6 +4,7 @@ treated them. Check that the minor findings fixed are fixed, that the fixes brok
 rest of the lot is still sound: read the diff yourself from the commits that cite the lot
 (`raf commits {{lot}}`, or `git log`), run the checks, report real defects only. A new minor finding
 is reported, not a reason to ask for another pass. This is a code review only.
+Goal of the lot (it takes precedence over the title in the plan): {{objectif}}
 {{repos}}
 {{checks}}
 {{choix}}
@@ -12,3 +13,4 @@ You are read-only: do not modify, commit, push or run `raf review|ux|done`. Do n
 Give your report as the structured output: counts of blocking / major / minor findings, each finding
 (severity, file, line, text), proposed sub-tasks, what you could not verify, and the one-line verdict
 for `raf review {{lot}}`.
+{{tmp}}

package/templates/orchestrate/review-small.md

@@ -2,7 +2,9 @@ Review lot `{{lot}}` — "{{titre}}" — of the repository `{{chemin}}`, followi
 This lot is small: one single pass covers the code review AND the usability review.
 You are given the repository path and the lot id only: read the diff yourself from the commits that
 cite the lot (`raf commits {{lot}}`, or `git log`), run the checks, report real defects only.
+Goal of the lot (it takes precedence over the title in the plan): {{objectif}}
 {{repos}}
+{{integration}}
 {{fiche}}
 {{ux}}
 {{checks}}
@@ -15,4 +17,6 @@ Give your report as the structured output: counts of blocking / major / minor fi
 findings included, each tied to a named rule — Nielsen heuristic or WCAG 2.2 AA criterion — or a
 measurement), each finding (severity, file, line, text), proposed sub-tasks, what you could not
 verify, and the one-line verdict for `raf review {{lot}}`.
-Browser (Playwright): if a Playwright MCP server is available in this session (only in an orchestrated wave: a brief delegated by hand has none), the orchestrator launched it with its own output directory, in the orchestrator's run directory outside the repository: give screenshots, snapshots and traces a relative file name only (e.g. `page-home.png`), they land there. Never an absolute path, never the `--output-dir` option (the server's launch argument, which a session cannot set). If no such server is available, do not install or start one; if you use the Playwright CLI, write its outputs under the OS temp directory (or the temporary folder the project's CLAUDE.md names), never inside the repository, which must stay clean.
+Browser (Playwright): if a Playwright MCP server is available in this session (only in an orchestrated wave: a brief delegated by hand has none), the orchestrator launched it with its own output directory, in the orchestrator's run directory outside the repository. {{shots}} If no such server is available, do not install or start one; if you use the Playwright CLI, write its outputs under the OS temp directory (or the temporary folder the project's CLAUDE.md names), never inside the repository, which must stay clean.
+In an orchestrated wave a capture reaches the run directory, outside the repository, only through the absolute path above: never at the repository root (romans-1440px.png, expenses-390px.png), never through a script or a shell command that writes into the repository.
+{{tmp}}

package/templates/orchestrate/review.md

@@ -1,6 +1,7 @@
 Review lot `{{lot}}` — "{{titre}}" — of the repository `{{chemin}}`, following your agent instructions.
 You are given the repository path and the lot id only: read the diff yourself from the commits that
 cite the lot (`raf commits {{lot}}`, or `git log`), run the checks, report real defects only.
+Goal of the lot (it takes precedence over the title in the plan): {{objectif}}
 {{repos}}
 {{fiche}}
 {{checks}}
@@ -12,3 +13,4 @@ You are read-only: do not modify, commit, push or run `raf review|ux|done`. Do n
 Give your report as the structured output: counts of blocking / major / minor findings, each finding
 (severity, file, line, text), proposed sub-tasks, what you could not verify, and the one-line verdict
 for `raf review {{lot}}`.
+{{tmp}}

package/templates/orchestrate/spec-back.md

@@ -1,7 +1,7 @@
 Spec of the behaviour of lot `{{lot}}` — "{{titre}}" — in `{{chemin}}`, as the spec writer: you write a machine-readable sheet (use cases, rules, contracts, data) BEFORE any code, so that the later steps (review of the sheet, acceptance tests, implementation) share one reference. There is no screen part: only the sheet.
 Goal of the lot: {{objectif}}
 {{repos}}
-Read the lot, its notes and sub-tasks in the plan (`docs/plan/raf.yaml`, or the file named by `plan:` in `cadence.yaml`), the project's CLAUDE.md, and the code and tests of the modules the lot touches (the services, controllers or jobs, their tests, the API contracts and error messages already present): the rules already coded are sources, and a new rule must not contradict them.
+Read the lot, its notes and sub-tasks in the plan (`.cadence/raf.yaml`, the legacy `docs/plan/raf.yaml`, or the file named by `plan:` in `cadence.yaml`), the project's CLAUDE.md, and the code and tests of the modules the lot touches (the services, controllers or jobs, their tests, the API contracts and error messages already present): the rules already coded are sources, and a new rule must not contradict them.
 {{spec}}
 
 What you produce, in `<dir>/<sujet>/`:
@@ -24,3 +24,4 @@ Report: `fiche` (path of the sheet relative to the repository, e.g. `docs/specs/
 
 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, not as free text.
+{{tmp}}

package/templates/orchestrate/spec.md

@@ -1,12 +1,12 @@
 Spec of the screen of lot `{{lot}}` — "{{titre}}" — in `{{chemin}}`, as the spec writer: you write a static mockup and a machine-readable sheet BEFORE any code, so that the later steps (UX review of the mockup, acceptance tests, implementation) share one reference.
 Goal of the lot: {{objectif}}
 {{repos}}
-Read the lot, its notes and sub-tasks in the plan (`docs/plan/raf.yaml`, or the file named by `plan:` in `cadence.yaml`), the project's CLAUDE.md, its charter (existing CSS and variables, neighbouring components, `docs/qa/expectations.md`) and the routes and API contracts already present.
+Read the lot, its notes and sub-tasks in the plan (`.cadence/raf.yaml`, the legacy `docs/plan/raf.yaml`, or the file named by `plan:` in `cadence.yaml`), the project's CLAUDE.md, its charter (existing CSS and variables, neighbouring components, `docs/qa/expectations.md`) and the routes and API contracts already present.
 {{spec}}
 
 What you produce, in `<dir>/<écran>/`:
 1. `maquette.html`: static HTML + CSS, to the project's charter (reuse its variables, fonts and components; invent no style when an equivalent exists), no business JavaScript. Every state is an addressable section: `<section id="etat-vide">`, `etat-chargement`, `etat-erreur`, and `etat-charge` when the screen has data. Every field of the sheet carries `data-testid="<id of the field>"`.
-2. The captures described above, one per state and per width, copied from the Playwright output directory of this wave into the folder (a Playwright capture lands outside the repository: give it a relative file name only, then copy it).
+2. The captures described above, one per state and per width, copied from the Playwright output directory of this wave into the folder (give a capture the absolute path of that directory, as the Playwright paragraph says, then copy it).
 3. `fiche.yaml`, in the format of the template below. Check it with `cadence spec check <fiche>` until it is valid, and derive the QA expectations with `cadence spec qa <fiche>` only if the lot asks for it.
 
 Sheet rules:
@@ -25,5 +25,6 @@ Report: `fiche` (path of the sheet relative to the repository, e.g. `docs/specs/
 
 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, not as free text.
-Browser (Playwright): the orchestrator launched the Playwright MCP server with its own output directory, in the orchestrator's run directory outside the repository: give screenshots, snapshots and traces a relative file name only (e.g. `maquette-vide-1440.png`), they land there. Never an absolute path, never the `--output-dir` option (the server's launch argument, which a session cannot set).
+Browser (Playwright): the orchestrator launched the Playwright MCP server with its own output directory, in the orchestrator's run directory outside the repository. {{shots}}
 {{captures}}
+{{tmp}}

package/templates/orchestrate/ux.md

@@ -1,6 +1,7 @@
 Review the usability and accessibility of lot `{{lot}}` — "{{titre}}" — of the repository `{{chemin}}`,
 following your agent instructions. Read the diff yourself from the commits that cite the lot
 (`raf commits {{lot}}`, or `git log`).
+Goal of the lot (it takes precedence over the title in the plan): {{objectif}}
 {{ux}}
 {{fiche}}
 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.
@@ -10,4 +11,5 @@ describe a mockup before proposing any redesign, never code it.
 Give your report as the structured output: counts of blocking / major / minor findings, each finding
 (severity, file, line, text), proposed sub-tasks, what you could not verify, and the one-line verdict
 for `raf ux {{lot}}`.
-Playwright (browser MCP): this session's Playwright server was launched by the orchestrator with its own output directory, which lies in the orchestrator's run directory, outside the repository. Every screenshot, snapshot and trace you take lands there, so give each one a relative file name only (e.g. `page-home.png`, `home-390px.png`): the lead will look at them in that directory. Never an absolute path (such as one under `/tmp`), never the `--output-dir` option (it is the server's launch argument, which a session cannot set), and never write browser outputs anywhere else; the repository must stay clean.
+Playwright (browser MCP): this session's Playwright server was launched by the orchestrator with its own output directory, which lies in the orchestrator's run directory, outside the repository. {{shots}} Never write browser outputs anywhere else; the repository must stay clean.
+{{tmp}}