@sylad/cadence 1.0.0 → 1.2.0

package/templates/fiche-back.yaml

@@ -0,0 +1,75 @@
+# Gabarit de fiche back (lot sans écran, étape spec back d'orchestrate, L187). Copier dans docs/specs/<sujet>/fiche.yaml,
+# remplacer les valeurs, puis `cadence spec check docs/specs/<sujet>/fiche.yaml`.
+# Chaque clé et les invariants vérifiés sont décrits dans la section « spec » du README de cadence.
+# Un lot qui a aussi un écran (screen:) ajoute à ce fichier la partie écran du gabarit templates/fiche.yaml
+# (ecran, etats, champs, actions) : sujet.id et ecran.id sont alors le nom du dossier.
+sujet:
+  id: mon-sujet                # kebab-case ; nom du dossier docs/specs/<id>/
+  titre: Mon sujet
+  lot: L0                      # le lot d'implémentation
+  perimetre:                   # ce que le lot touche : au moins un module, un endpoint ou un job
+    modules: [backend/src/modules/mon-module]
+    endpoints: ["GET /api/elements"]
+    jobs: []
+    hors_perimetre: ["l'affichage dans le frontend (un lot d'écran à part)"]   # facultatif : ce que le lot ne fait pas
+
+cas:                           # C1, C2… dans l'ordre, sans trou
+  - id: C1
+    titre: Le client lit la liste alors que la source est en panne
+    acteur: un client de l'API
+    declencheur: GET /api/elements     # un appel de contrat, un job ou une commande
+    preconditions:
+      - la source externe ne répond pas
+    nominal:                   # les étapes du cas passant
+      - Le service interroge la source.
+      - L'appel échoue.
+      - Le service renvoie la dernière liste connue et écrit un warning.
+    alternatives:              # { si, alors, regles } : chaque alternative cite au moins une règle
+      - { si: la source répond, alors: la réponse est fraîche, regles: [R2] }
+    resultat: La dernière liste connue au lieu d'une erreur.
+  - id: C2
+    titre: Le planificateur rafraîchit la liste
+    acteur: le planificateur
+    declencheur: job elements-refresh
+    preconditions:
+      - une liste est en cache
+    nominal:
+      - Le job appelle la source.
+      - Le cache est réécrit.
+    alternatives: []
+    sans_alternative: le seul échec du job est celui de C1 (R1) ; il n'a pas d'autre branche   # obligatoire quand alternatives est vide
+    resultat: Le cache porte l'horodatage du dernier succès.
+
+regles:                        # R1, R2… dans l'ordre, sans trou
+  - id: R1
+    cas: [C1, C2]              # une règle back est rattachée à au moins un cas (une règle d'écran à un état : etat)
+    enonce: Quand la source échoue, l'API sert la dernière liste connue au lieu d'une erreur.
+    statut: sourcee            # sourcee : dit d'où elle vient (source) ; hypothese : dit ce qui changerait (si_faux)
+    source: "demande du lot : « servir le dernier cache connu au lieu d'une erreur »"   # une ligne du lot, un fichier:ligne, un contrat existant…
+    tests: ["R1 — source en panne : la dernière liste est servie"]   # chaque test nommé « Rn — … »
+  - id: R2
+    cas: [C1]
+    enonce: Une réponse fraîche ne porte pas le champ ageSecondes.
+    statut: hypothese
+    si_faux: Si le champ doit toujours être présent, seul son contenu change (aucune donnée en jeu).
+    tests: ["R2 — réponse fraîche : ageSecondes absent"]
+
+contrats:                      # A1, A2… dans l'ordre (dans une fiche mixte, communs avec les actions de l'écran)
+  - id: A1
+    appel: GET /api/elements   # VERBE /chemin, job <nom> ou commande <nom>
+    entree: aucune
+    sortie: "la liste, ou une liste vide (HTTP 200)"
+    erreurs:                   # { code, message } : code « HTTP <n> » ou « log <niveau> », message = le texte exact
+      - { code: log warn, message: "Serving cached list: source unavailable" }
+    regles: [R1, R2]
+  - id: A2
+    appel: job elements-refresh
+    entree: "cron 0 */15 * * * *"
+    sortie: "cache réécrit après un succès, inchangé après un échec"
+    erreurs: []
+    sans_erreur: le job ne répond à aucun appelant ; son échec est un warning déjà couvert par A1   # obligatoire quand erreurs est vide
+    regles: [R1]
+
+donnees:                       # D1… : les données touchées ([] si aucune)
+  - { id: D1, objet: "data/elements-cache.json ({ ts, data })", existant: true, modification: aucune, note: "relu en secours, format et écriture inchangés" }
+  # existant: true avec modification: ajout|changement exige  decision: <la réponse du lead à la question ciblée>

package/templates/fiche.yaml

@@ -0,0 +1,41 @@
+# Gabarit de fiche d'écran (étape spec d'orchestrate, L170). Copier dans docs/specs/<écran>/fiche.yaml,
+# remplacer les valeurs, puis `cadence spec check docs/specs/<écran>/fiche.yaml`.
+# Chaque clé et les invariants vérifiés sont décrits dans la section « spec » du README de cadence.
+ecran:
+  id: mon-ecran                # kebab-case ; nom du dossier docs/specs/<id>/
+  titre: Mon écran
+  route: /mon-ecran            # commence par /
+  lot: L0                      # le lot d'implémentation
+  largeurs: [1440, 390]        # largeurs de rendu : toujours ces deux-là
+  maquette: docs/specs/mon-ecran/maquette.html
+etats: [vide, chargement, erreur, charge]   # au moins vide, chargement, erreur
+
+champs:                        # id unique en kebab-case : c'est aussi le data-testid de la maquette
+  - { id: titre-page, libelle: Titre de la page, type: texte, source: statique, obligatoire: true }
+  - { id: liste-elements, libelle: Liste des éléments, type: liste, source: "GET /api/elements → items", obligatoire: true }
+  - { id: message-vide, libelle: Message d'état vide, type: texte, source: statique, obligatoire: true }
+  - { id: message-erreur, libelle: Message d'erreur de chargement, type: texte, source: statique, obligatoire: false }
+  - { id: bouton-reessayer, libelle: Réessayer, type: bouton, source: "action A2", obligatoire: false }
+
+regles:                        # R1, R2… dans l'ordre, sans trou
+  - id: R1
+    etat: vide                 # l'un des etats : l'état où la règle s'applique et où son message est visible
+    enonce: Sans élément, l'écran affiche le message d'état vide à la place de la liste.
+    message: "Aucun élément pour le moment."   # texte exact à l'écran, ou ~ (null) s'il n'y en a pas
+    champs: [message-vide]     # les champs que la règle fait apparaître
+    masque: [liste-elements]   # (vide seulement) les champs que la règle fait disparaître ; ids de la fiche
+    statut: sourcee            # sourcee : dit d'où elle vient (source) ; hypothese : dit ce qui changerait (si_faux)
+    source: "demande du lot : « un état vide qui dit quoi faire »"
+    tests: ["R1 — état vide : le message s'affiche, pas de liste"]   # chaque test nommé « Rn — … »
+  - id: R2
+    etat: erreur
+    enonce: Si l'appel échoue, l'écran affiche l'erreur et un bouton « Réessayer » qui rappelle l'API.
+    message: "Impossible de charger les éléments."
+    champs: [message-erreur, bouton-reessayer]
+    statut: hypothese
+    si_faux: Si le message doit changer, seul ce bloc change (aucune donnée en jeu).
+    tests: ["R2 — erreur : message et bouton Réessayer", "R2 — Réessayer relance l'appel"]
+
+actions:                       # A1, A2… dans l'ordre
+  - { id: A1, declencheur: ~, appel: "GET /api/elements", regles: [R1, R2] }   # ~ : le chargement de l'écran
+  - { id: A2, declencheur: bouton-reessayer, appel: "GET /api/elements", regles: [R2] }

package/templates/orchestrate/accept-back.md

@@ -0,0 +1,16 @@
+Acceptance tests of the behaviour of lot `{{lot}}` in `{{chemin}}`, as the acceptance writer: you write the tests BEFORE any code, from the sheet only, so that the implementer has an independent oracle. You are not the implementer: you do not write, read-to-copy or guess the implementation.
+{{repos}}
+{{accept}}
+
+Rules:
+- One or more cases per rule of the sheet, named exactly as the sheet plans it (`regles[].tests`, e.g. `R5 — une entrée de 14 jours est refusée : null`); the tests call the contracts of `contrats[]` as close as possible (the controller or the service for an HTTP call, the method of the job for a `job`), and simulate the external sources from `entree`. What cannot be automated is out of scope.
+- Every test must FAIL for now, because the feature is missing (not because of a typo or a broken setup): the program runs the dedicated command and refuses tests that pass.
+- Do not touch the sheet, the plan or any application code. Do not push, deliver, run `raf done`, `raf ux` or `raf review`.
+- Commit with explicit paths (never `git add -A` or `commit -a`), ONE commit citing the lot (`test({{lot}}): acceptation R1–Rn (rouge)`) with the test files, the acceptation file and the runner configuration, and leave the working tree clean. The program seals the acceptation file afterwards (it adds the fingerprint of each test file): never write `empreintes` or `vert: true` yourself.
+Decide minor interpretation questions yourself and list each one under "choix" with the alternative you did not take. Leave "questions" empty rather than writing a placeholder such as "no question".
+{{commits}}
+{{reponse}}
+Report: `commits`, `nonVerifie` (what you could not run or check), `choix`, `questions`, `resume`.
+
+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.

package/templates/orchestrate/accept.md

@@ -0,0 +1,16 @@
+Acceptance tests of the screen of lot `{{lot}}` in `{{chemin}}`, as the acceptance writer: you write the tests BEFORE any code, from the sheet and the mockup only, so that the implementer has an independent oracle. You are not the implementer: you do not write, read-to-copy or guess the implementation.
+{{repos}}
+{{accept}}
+
+Rules:
+- One or more cases per rule of the sheet, named exactly as the sheet plans it (`regles[].tests`, e.g. `R3 — erreur : message et bouton Réessayer`); selectors are the `data-testid` of the fields (= field ids of the sheet); API calls are simulated from `actions[]`. What cannot be automated (rendering, ergonomics, readability) is out of scope.
+- Every test must FAIL for now, because the feature is missing (not because of a typo or a broken setup): the program runs the dedicated command and refuses tests that pass.
+- Do not touch the sheet, the mockup, the plan or any application code. Do not push, deliver, run `raf done`, `raf ux` or `raf review`.
+- Commit with explicit paths (never `git add -A` or `commit -a`), ONE commit citing the lot (`test({{lot}}): acceptation R1–Rn (rouge)`) with the test files, the acceptation file and the runner configuration, and leave the working tree clean. The program seals the acceptation file afterwards (it adds the fingerprint of each test file): never write `empreintes` or `vert: true` yourself.
+Decide minor interpretation questions yourself and list each one under "choix" with the alternative you did not take. Leave "questions" empty rather than writing a placeholder such as "no question".
+{{commits}}
+{{reponse}}
+Report: `commits`, `nonVerifie` (what you could not run or check), `choix`, `questions`, `resume`.
+
+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.

package/templates/orchestrate/fiche.md

@@ -0,0 +1,14 @@
+Sheet review of lot `{{lot}}` — "{{titre}}" — of the repository `{{chemin}}`, following your agent instructions (sheet mode).
+Goal of the lot: {{objectif}}
+{{repos}}
+{{fiche}}
+
+You review the sheet BEFORE any code is written: the later steps (acceptance tests, implementation, code review) take it as their reference. This is NOT the review of the code of the lot, and not the `raf review` verdict.
+Read the project's CLAUDE.md first, then the sheet, then the code and the tests of the modules of `sujet.perimetre`, and every source the sheet cites. Check, with a measurement for each finding (the file:line you opened, the command you ran):
+1. Sourced or hypothesis. Each `sourcee` rule cites a source that exists: open the file:line or the note and read what it says. Each `hypothese` carries a `si_faux` and does not hide one of the four expensive categories (data model or storage; public or shared API contract or published route; destructive or irreversible action; contradiction with a sourced rule) — such a hypothesis is a *major* finding.
+2. No contradiction. With a rule already coded (search the modules of the perimeter, open the existing tests that assert the opposite) and with an existing API contract (field, error code, route).
+3. Errors and limits. For each contract: the empty, absent, expired, oversized and duplicate inputs and each failure of an external source have a rule, or a motivated `sans_alternative` / `sans_erreur`.
+4. One test per rule. Each rule has at least one planned test whose name says what is checked and could fail (the program already checks that a test is planned).
+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.

package/templates/orchestrate/fix-minors.md

@@ -1,6 +1,7 @@
 Work in `{{chemin}}` on lot `{{lot}}` — "{{titre}}" — of its plan.
 A fresh review found only minor findings: the lot is compliant, and this is the one pass that treats them.
 {{repos}}
+{{fiche}}
 Commits of the lot so far:
 {{commits}}
 

package/templates/orchestrate/fix.md

@@ -1,6 +1,7 @@
 Work in `{{chemin}}` on lot `{{lot}}` — "{{titre}}" — of its plan. A fresh review of the commits
 of this lot found the defects below; fix them, and nothing else.
 {{repos}}
+{{fiche}}
 Commits of the lot so far:
 {{commits}}
 

package/templates/orchestrate/implement.md

@@ -2,6 +2,7 @@ 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).
 Goal: {{objectif}}
 {{repos}}
+{{fiche}}
 Rules: test first; commit each sub-part as soon as its tests pass, with explicit paths (never
 `git add -A` or `commit -a`), and a message that cites the lot (`feat({{lot}}): …`); run the project's
 full test suite and build before reporting; do not push, deliver, run `raf done`, `raf ux` or

package/templates/orchestrate/maquette.md

@@ -0,0 +1,12 @@
+UX review of the mockup of the screen of lot `{{lot}}` — "{{titre}}" — in `{{chemin}}`, following your agent instructions (mockup mode).
+Goal of the lot: {{objectif}}
+{{repos}}
+{{maquette}}
+
+You review the mockup BEFORE any code is written: the later steps (acceptance tests, implementation) will take the sheet and the mockup as their reference. Read the project's CLAUDE.md and its charter (existing CSS and variables, neighbouring components) first: the product's identity is a constraint.
+Besides the usability and accessibility checks of your instructions, check the consistency between the mockup and the sheet: every field of `champs` is in the mockup with its `data-testid`, every rule message (`regles[].message`) is visible, word for word, in the state named by the `etat` of the rule, every state of `etats` has its section `#etat-<état>`, the `masque` of an empty-state rule really hides the fields it names.
+Check the sample data of the mockup: recompute the weekday of every date shown (do not trust the one written). A wrong sample datum (weekday, date, figure that does not add up) is a minor finding, not a major one: it changes no rule, no field and no state of the sheet, and is fixed in a line.
+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.

package/templates/orchestrate/review-small.md

@@ -3,6 +3,7 @@ This lot is small: one single pass covers the code review AND the usability revi
 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.
 {{repos}}
+{{fiche}}
 {{ux}}
 {{checks}}
 {{docs}}

package/templates/orchestrate/review.md

@@ -2,6 +2,7 @@ Review lot `{{lot}}` — "{{titre}}" — of the repository `{{chemin}}`, followi
 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.
 {{repos}}
+{{fiche}}
 {{checks}}
 {{docs}}
 {{choix}}

package/templates/orchestrate/spec-back.md

@@ -0,0 +1,25 @@
+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.
+{{spec}}
+
+What you produce, in `<dir>/<sujet>/`:
+- `fiche.yaml`, in the format of the template below (`sujet`, `cas`, `regles`, `contrats`, `donnees`). Check it with `cadence spec check <fiche>` until it is valid.
+
+Sheet rules:
+- Every use case (`cas`) names its trigger (a contract call, a job, a command), its preconditions, its nominal steps, and its alternatives and error cases, each pointing to the rules that govern it — or says `alternatives: []` with its reason in `sans_alternative`.
+- Every rule is `sourcee` (it says where it comes from: a line of the lot, a note, a rule already coded as **file:line** — the review opens it —, an existing API contract, an existing test, a requirement of a reference document) or `hypothese` (you chose it for lack of a source; `si_faux` says what would change if it were wrong). Never present a guess as sourced. Every rule is attached to at least one case and has at least one planned test, named `Rn — …`, whose name says what is checked and could fail.
+- Every contract (`contrats`) gives the call (`VERBE /chemin`, `job <nom>` or `commande <nom>`), the input, the output and the errors with the exact code (`HTTP <n>` or `log <level>`) and the exact message; for each, think of the empty, absent, expired, oversized and duplicate inputs and of every failure of an external source, and give each a rule — or say `sans_erreur` with the reason.
+- Every datum the lot touches is in `donnees`; an existing datum whose model changes needs the lead's `decision`: that is a question (below).
+- A rule you invent is not a free choice: **a hypothesis whose `si_faux` involves an expensive-to-undo choice is a question, not a hypothesis.** The four expensive categories: a data model or storage (key, column, table, file or cache format, migration); a public or shared API contract, or an already published route or job name (renaming, removing or changing the type or the meaning of a field, an error code, a route); a destructive or irreversible action (deletion, purge, sending a mail or a notification, payment, one-way migration); a rule that contradicts an existing sourced rule or a rule already coded. In those cases do not write the hypothesis: stop and put the question under "questions" (the lead answers and the step is resumed). Everything else (wording, order, a default) is a written hypothesis, cheap to correct later. **An optional field added to an existing response is not a break** when the sheet proves the old response is unchanged (a rule says so): write it as a hypothesis with its `si_faux`.
+- If, after reading the lot and the code, you find that the lot changes NO behaviour (nothing a user, an API client or another service can observe: a lint, a rename, a move, a doc, a CI or cache setting without observable effect), write one line with the reason in `sousSeuil`, create no sheet, and finish: the lot then follows the usual path.
+
+Commit the sheet with explicit paths (never `git add -A` or `commit -a`), a message that cites the lot (`spec({{lot}}): …`), and leave the working tree clean. Do not implement the behaviour, do not write application code or tests, do not push, deliver, run `raf done`, `raf ux` or `raf review`.
+Decide minor interpretation questions yourself and list each one under "choix" with the alternative you did not take. Leave "questions" empty rather than writing a placeholder such as "no question".
+{{commits}}
+{{reponse}}
+Report: `fiche` (path of the sheet relative to the repository, e.g. `docs/specs/<sujet>/fiche.yaml`, or empty under the threshold), `sousSeuil` (the reason, or empty), `commits`, `nonVerifie` (what you could not check), `choix`, `questions`, `resume`.
+
+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.

package/templates/orchestrate/spec.md

@@ -0,0 +1,28 @@
+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.
+{{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).
+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:
+- Every rule is `sourcee` (it says where it comes from: a line of the lot, a note, `expectations.md`, a rule already coded, an API contract) or `hypothese` (you chose it for lack of a source; `si_faux` says what would change if it were wrong). Never present a guess as sourced.
+- Check every date in the sample data of the mockup before keeping it: compute its weekday (a command such as `date -d 2026-09-03 +%A`, or a script), never write it from memory — a « Wed 03/09 » that is a Thursday sends the mockup back for nothing. The same goes for any figure that must add up (a score and its result, a total and its parts).
+- Expose the messages exactly as the screen shows them; the message of a rule is visible in the state its `etat` names.
+- A rule you invent is not a free choice: **a hypothesis whose `si_faux` involves an expensive-to-undo choice is a question, not a hypothesis.** The four expensive categories: a data model or storage (key, migration, user data created once shipped); a public or shared API contract, or an already published route / URL; a destructive or irreversible action (deletion, sending, payment); a rule that contradicts an existing sourced rule. In those cases do not write the hypothesis: stop and put the question under "questions" (the lead answers and the step is resumed). Everything else (wording, order of the fields, error state, spacing) is a written hypothesis, cheap to correct later.
+- If, after reading the lot and the code, you find that the lot changes NO screen (no new page, component or modified journey), write one line with the reason in `sousSeuil`, create no mockup and no sheet, and finish: the lot then follows the usual path.
+
+Commit the spec with explicit paths (never `git add -A` or `commit -a`), a message that cites the lot (`spec({{lot}}): …`), the sheet, the mockup and the captures together, and leave the working tree clean. Do not implement the screen, do not write application code or tests, do not push, deliver, run `raf done`, `raf ux` or `raf review`.
+Decide minor interpretation questions yourself and list each one under "choix" with the alternative you did not take. Leave "questions" empty rather than writing a placeholder such as "no question".
+{{commits}}
+{{reponse}}
+Report: `fiche` (path of the sheet relative to the repository, e.g. `docs/specs/<screen>/fiche.yaml`, or empty under the threshold), `sousSeuil` (the reason, or empty), `commits`, `nonVerifie` (what you could not render or check), `choix`, `questions`, `resume`.
+
+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).
+{{captures}}

package/templates/orchestrate/ux.md

@@ -2,6 +2,7 @@ Review the usability and accessibility of lot `{{lot}}` — "{{titre}}" — of t
 following your agent instructions. Read the diff yourself from the commits that cite the lot
 (`raf commits {{lot}}`, or `git log`).
 {{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.
 You are read-only: do not modify, commit, push or run `raf review|ux|done`. Do not launch subagents.
 Ground every finding in a named rule (Nielsen heuristic, WCAG 2.2 AA criterion) or a measurement;