@sylad/cadence 1.1.0 → 1.2.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.claude-plugin/marketplace.json +1 -1
- package/.claude-plugin/plugin.json +1 -1
- package/README.md +114 -21
- package/agents/acceptance-writer.md +3 -1
- package/agents/code-reviewer.md +6 -0
- package/agents/spec-writer.md +3 -1
- package/bin/cadence.js +4 -1
- package/dist/cli.js +145 -15
- package/dist/config.js +16 -4
- package/dist/lead.js +72 -19
- package/dist/orchestrate/accept.js +90 -4
- package/dist/orchestrate/aval.js +25 -6
- package/dist/orchestrate/briefs.js +3 -0
- package/dist/orchestrate/command.js +59 -26
- package/dist/orchestrate/continue.js +1 -1
- package/dist/orchestrate/cycle.js +260 -53
- package/dist/orchestrate/fiche.js +22 -0
- package/dist/orchestrate/launch.js +7 -7
- package/dist/orchestrate/spec.js +71 -14
- package/dist/orchestrate/state.js +2 -2
- package/dist/orchestrate/table.js +2 -0
- package/dist/plan.js +58 -1
- package/dist/spec.js +304 -77
- package/package.json +4 -3
- package/skills/lead/SKILL.md +33 -8
- package/templates/acceptation-runner.mjs +13 -5
- package/templates/fiche-back.yaml +75 -0
- package/templates/orchestrate/accept-back.md +16 -0
- package/templates/orchestrate/fiche.md +14 -0
- package/templates/orchestrate/spec-back.md +25 -0
|
@@ -0,0 +1,75 @@
|
|
|
1
|
+
# Gabarit de fiche back (lot sans écran, étape spec back d'orchestrate, L187). Copier dans docs/specs/<sujet>/fiche.yaml,
|
|
2
|
+
# remplacer les valeurs, puis `cadence spec check docs/specs/<sujet>/fiche.yaml`.
|
|
3
|
+
# Chaque clé et les invariants vérifiés sont décrits dans la section « spec » du README de cadence.
|
|
4
|
+
# Un lot qui a aussi un écran (screen:) ajoute à ce fichier la partie écran du gabarit templates/fiche.yaml
|
|
5
|
+
# (ecran, etats, champs, actions) : sujet.id et ecran.id sont alors le nom du dossier.
|
|
6
|
+
sujet:
|
|
7
|
+
id: mon-sujet # kebab-case ; nom du dossier docs/specs/<id>/
|
|
8
|
+
titre: Mon sujet
|
|
9
|
+
lot: L0 # le lot d'implémentation
|
|
10
|
+
perimetre: # ce que le lot touche : au moins un module, un endpoint ou un job
|
|
11
|
+
modules: [backend/src/modules/mon-module]
|
|
12
|
+
endpoints: ["GET /api/elements"]
|
|
13
|
+
jobs: []
|
|
14
|
+
hors_perimetre: ["l'affichage dans le frontend (un lot d'écran à part)"] # facultatif : ce que le lot ne fait pas
|
|
15
|
+
|
|
16
|
+
cas: # C1, C2… dans l'ordre, sans trou
|
|
17
|
+
- id: C1
|
|
18
|
+
titre: Le client lit la liste alors que la source est en panne
|
|
19
|
+
acteur: un client de l'API
|
|
20
|
+
declencheur: GET /api/elements # un appel de contrat, un job ou une commande
|
|
21
|
+
preconditions:
|
|
22
|
+
- la source externe ne répond pas
|
|
23
|
+
nominal: # les étapes du cas passant
|
|
24
|
+
- Le service interroge la source.
|
|
25
|
+
- L'appel échoue.
|
|
26
|
+
- Le service renvoie la dernière liste connue et écrit un warning.
|
|
27
|
+
alternatives: # { si, alors, regles } : chaque alternative cite au moins une règle
|
|
28
|
+
- { si: la source répond, alors: la réponse est fraîche, regles: [R2] }
|
|
29
|
+
resultat: La dernière liste connue au lieu d'une erreur.
|
|
30
|
+
- id: C2
|
|
31
|
+
titre: Le planificateur rafraîchit la liste
|
|
32
|
+
acteur: le planificateur
|
|
33
|
+
declencheur: job elements-refresh
|
|
34
|
+
preconditions:
|
|
35
|
+
- une liste est en cache
|
|
36
|
+
nominal:
|
|
37
|
+
- Le job appelle la source.
|
|
38
|
+
- Le cache est réécrit.
|
|
39
|
+
alternatives: []
|
|
40
|
+
sans_alternative: le seul échec du job est celui de C1 (R1) ; il n'a pas d'autre branche # obligatoire quand alternatives est vide
|
|
41
|
+
resultat: Le cache porte l'horodatage du dernier succès.
|
|
42
|
+
|
|
43
|
+
regles: # R1, R2… dans l'ordre, sans trou
|
|
44
|
+
- id: R1
|
|
45
|
+
cas: [C1, C2] # une règle back est rattachée à au moins un cas (une règle d'écran à un état : etat)
|
|
46
|
+
enonce: Quand la source échoue, l'API sert la dernière liste connue au lieu d'une erreur.
|
|
47
|
+
statut: sourcee # sourcee : dit d'où elle vient (source) ; hypothese : dit ce qui changerait (si_faux)
|
|
48
|
+
source: "demande du lot : « servir le dernier cache connu au lieu d'une erreur »" # une ligne du lot, un fichier:ligne, un contrat existant…
|
|
49
|
+
tests: ["R1 — source en panne : la dernière liste est servie"] # chaque test nommé « Rn — … »
|
|
50
|
+
- id: R2
|
|
51
|
+
cas: [C1]
|
|
52
|
+
enonce: Une réponse fraîche ne porte pas le champ ageSecondes.
|
|
53
|
+
statut: hypothese
|
|
54
|
+
si_faux: Si le champ doit toujours être présent, seul son contenu change (aucune donnée en jeu).
|
|
55
|
+
tests: ["R2 — réponse fraîche : ageSecondes absent"]
|
|
56
|
+
|
|
57
|
+
contrats: # A1, A2… dans l'ordre (dans une fiche mixte, communs avec les actions de l'écran)
|
|
58
|
+
- id: A1
|
|
59
|
+
appel: GET /api/elements # VERBE /chemin, job <nom> ou commande <nom>
|
|
60
|
+
entree: aucune
|
|
61
|
+
sortie: "la liste, ou une liste vide (HTTP 200)"
|
|
62
|
+
erreurs: # { code, message } : code « HTTP <n> » ou « log <niveau> », message = le texte exact
|
|
63
|
+
- { code: log warn, message: "Serving cached list: source unavailable" }
|
|
64
|
+
regles: [R1, R2]
|
|
65
|
+
- id: A2
|
|
66
|
+
appel: job elements-refresh
|
|
67
|
+
entree: "cron 0 */15 * * * *"
|
|
68
|
+
sortie: "cache réécrit après un succès, inchangé après un échec"
|
|
69
|
+
erreurs: []
|
|
70
|
+
sans_erreur: le job ne répond à aucun appelant ; son échec est un warning déjà couvert par A1 # obligatoire quand erreurs est vide
|
|
71
|
+
regles: [R1]
|
|
72
|
+
|
|
73
|
+
donnees: # D1… : les données touchées ([] si aucune)
|
|
74
|
+
- { id: D1, objet: "data/elements-cache.json ({ ts, data })", existant: true, modification: aucune, note: "relu en secours, format et écriture inchangés" }
|
|
75
|
+
# existant: true avec modification: ajout|changement exige decision: <la réponse du lead à la question ciblée>
|
|
@@ -0,0 +1,16 @@
|
|
|
1
|
+
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.
|
|
2
|
+
{{repos}}
|
|
3
|
+
{{accept}}
|
|
4
|
+
|
|
5
|
+
Rules:
|
|
6
|
+
- 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.
|
|
7
|
+
- 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.
|
|
8
|
+
- Do not touch the sheet, the plan or any application code. Do not push, deliver, run `raf done`, `raf ux` or `raf review`.
|
|
9
|
+
- 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.
|
|
10
|
+
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".
|
|
11
|
+
{{commits}}
|
|
12
|
+
{{reponse}}
|
|
13
|
+
Report: `commits`, `nonVerifie` (what you could not run or check), `choix`, `questions`, `resume`.
|
|
14
|
+
|
|
15
|
+
You are one short session of an orchestrated wave: do not launch subagents (the Agent tool is disabled).
|
|
16
|
+
Give your final report as the structured output, not as free text.
|
|
@@ -0,0 +1,14 @@
|
|
|
1
|
+
Sheet review of lot `{{lot}}` — "{{titre}}" — of the repository `{{chemin}}`, following your agent instructions (sheet mode).
|
|
2
|
+
Goal of the lot: {{objectif}}
|
|
3
|
+
{{repos}}
|
|
4
|
+
{{fiche}}
|
|
5
|
+
|
|
6
|
+
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.
|
|
7
|
+
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):
|
|
8
|
+
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.
|
|
9
|
+
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).
|
|
10
|
+
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`.
|
|
11
|
+
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).
|
|
12
|
+
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.
|
|
13
|
+
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.
|
|
14
|
+
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.
|
|
@@ -0,0 +1,25 @@
|
|
|
1
|
+
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.
|
|
2
|
+
Goal of the lot: {{objectif}}
|
|
3
|
+
{{repos}}
|
|
4
|
+
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.
|
|
5
|
+
{{spec}}
|
|
6
|
+
|
|
7
|
+
What you produce, in `<dir>/<sujet>/`:
|
|
8
|
+
- `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.
|
|
9
|
+
|
|
10
|
+
Sheet rules:
|
|
11
|
+
- 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`.
|
|
12
|
+
- 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.
|
|
13
|
+
- 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.
|
|
14
|
+
- Every datum the lot touches is in `donnees`; an existing datum whose model changes needs the lead's `decision`: that is a question (below).
|
|
15
|
+
- 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`.
|
|
16
|
+
- 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.
|
|
17
|
+
|
|
18
|
+
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`.
|
|
19
|
+
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".
|
|
20
|
+
{{commits}}
|
|
21
|
+
{{reponse}}
|
|
22
|
+
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`.
|
|
23
|
+
|
|
24
|
+
You are one short session of an orchestrated wave: do not launch subagents (the Agent tool is disabled).
|
|
25
|
+
Give your final report as the structured output, not as free text.
|