@sylad/cadence 0.11.0 → 0.13.0

package/templates/orchestrate/implement.md

@@ -5,14 +5,16 @@ Rules: test first; commit each sub-part as soon as its tests pass, with explicit
 `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
 `raf 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.
 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.
 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), AND the plan, its notes and the project's CLAUDE.md do not settle it;
 otherwise it is a choice: decide, write the alternative you did not take, go on. Minor choices to settle yourself:
 a spacing, colour or label value when a measurement or a rule justifies it; the URL of a link (the most general official page if a precise one is not certain);
-a News entry for a visible lot (yes, always); a written rule of the project's CLAUDE.md (apply it); who launches the review or UX pass (never the session: the program and the lead do).
+a written rule of the project's CLAUDE.md (apply it); who launches the review or UX pass (never the session: the program and the lead do).
 "not my job to touch the plan" is not a question: say it in the report.
+Never stop to ask about how to organise your own work (split or squash a commit, order of the sub-parts, whether to continue, "I have no question"): decide, list it under "choix", go on. Leave "questions" empty rather than writing a placeholder such as "no question".
 If the lot's commits already cover its open sub-tasks, do not ask whether to continue: make no commit and say so
 in your report (the review that follows re-reads those commits). If they do not cover them all, implement the rest.
 Report: commits (sha + subject), tests and build results with their numbers, what you could not
@@ -21,5 +23,7 @@ verify, choices made, open questions.
 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. If the plan is kept by the project's own tool
 (read-only for `raf`), use that tool's commands named in the project's CLAUDE.md, never `raf start|done|note`.
+{{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.

package/templates/orchestrate/precheck.md

@@ -0,0 +1,10 @@
+Pre-check for lot `{{lot}}` — "{{titre}}" — of the repository `{{chemin}}`, as the read-only pre-check reader.
+Question: is the deliverable of this lot ALREADY in the repository (done by another lot, or by a correction)?
+Goal of the lot: {{objectif}}
+Read the lot, its notes and sub-tasks in the plan (`docs/plan/raf.yaml`, or the file named by `plan:` in `cadence.yaml`),
+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).

package/templates/orchestrate/review-recheck.md

@@ -4,7 +4,9 @@ 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.
+{{checks}}
 {{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.
 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

package/templates/orchestrate/review-small.md

@@ -3,9 +3,12 @@ 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.
 {{ux}}
+{{checks}}
 {{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.
 Give your report as the structured output: counts of blocking / major / minor findings (usability
 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.

package/templates/orchestrate/review.md

@@ -1,7 +1,9 @@
 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.
+{{checks}}
 {{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.
 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

package/templates/orchestrate/ux.md

@@ -2,9 +2,11 @@ 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}}
+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;
 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.