@sylad/cadence 0.6.0 → 0.8.0

package/dist/verify.js

@@ -0,0 +1,114 @@
+import { spawn } from 'node:child_process';
+import { constants } from 'node:os';
+import { onTermination } from './proc.js';
+import { describeCheck, realDeps, retryCheck, TIMED_OUT } from './deliver.js';
+function killGroup(pgid, sig) {
+    try {
+        process.kill(-pgid, sig);
+    }
+    catch {
+        // groupe déjà vide
+    }
+}
+/**
+ * Une commande de vérification, en groupe de processus détaché (nouvelle session, sans tty) : au délai,
+ * TOUT le groupe est tué (aucun enfant orphelin) ; un signal reçu par cadence lui est relayé. Asynchrone :
+ * les vérifications tournent en parallèle. Réservé aux vérifications (verify, session start) — jamais
+ * aux commandes de deliver, qui gardent le groupe de premier plan et le tty.
+ */
+function execGroup(root, cmd, env, timeoutMs, quiet) {
+    return new Promise((resolve) => {
+        const child = spawn('sh', ['-c', cmd], {
+            cwd: root,
+            env: { ...process.env, ...env },
+            stdio: quiet ? 'ignore' : ['ignore', 'inherit', 'inherit'],
+            detached: true,
+        });
+        const pgid = child.pid;
+        if (pgid === undefined) {
+            child.once('error', () => resolve(127));
+            return;
+        }
+        // Ctrl-C, SIGTERM ou raccrochage reçu par cadence : relayé au groupe avant de sortir.
+        const forget = onTermination((sig) => killGroup(pgid, sig));
+        let timedOut = false;
+        const timer = setTimeout(() => {
+            timedOut = true;
+            killGroup(pgid, 'SIGKILL');
+        }, timeoutMs);
+        child.once('exit', (code, signal) => {
+            clearTimeout(timer);
+            forget();
+            if (timedOut)
+                killGroup(pgid, 'SIGKILL'); // sh mort avant ses enfants : le groupe est vidé quand même
+            resolve(timedOut ? TIMED_OUT : signal ? 128 + (constants.signals[signal] ?? 0) : (code ?? 1));
+        });
+    });
+}
+/** Dépendances réelles des vérifications. `quiet` : sortie des commandes non relayée (rapport de session start). */
+export function realCheckDeps(root, opts = {}) {
+    const { fetch, sleep, now } = realDeps(root);
+    return { fetch, sleep, now, exec: (cmd, env, timeoutMs) => execGroup(root, cmd, env, timeoutMs, !!opts.quiet) };
+}
+/**
+ * Rejoue des vérifications d'effet, TOUTES EN PARALLÈLE : chaque essai reçoit le budget entier
+ * (`attemptMs`, tuée au-delà : « délai dépassé »), une vérification lente ne prend rien aux autres.
+ * UNE passe par défaut ; avec `retryMs`, chacune est réessayée de son côté (toutes les POLL_VERIFY)
+ * jusqu'à ce délai. Durée totale bornée par retryMs + attemptMs. Résultats dans l'ordre des vérifications.
+ * Le code d'une vérification est celui de deliver (tryCheck/retryCheck) : aucune règle n'est dupliquée.
+ */
+export async function replayChecks(checks, deps, sha, env, opts) {
+    const until = deps.now() + opts.retryMs;
+    return Promise.all(checks.map(async (c) => ({ label: describeCheck(c, sha), reason: await retryCheck(c, deps, sha, env, until, () => opts.attemptMs) })));
+}
+export const resultLine = (r) => (r.reason === null ? `✓ ${r.label}` : `✗ ${r.label} — ${r.reason}`);
+export function summaryLine(results) {
+    const red = results.filter((r) => r.reason !== null).length;
+    const n = results.length;
+    return red === 0
+        ? `verify : ${n}/${n} vérifications vertes`
+        : `verify : ${red} effet${red > 1 ? 's' : ''} rouge${red > 1 ? 's' : ''} sur ${n} vérification${n > 1 ? 's' : ''}`;
+}
+/** Variables passées aux commandes de vérification, comme à celles de deliver. */
+export function verifyEnv(sha) {
+    return { CADENCE_SHA: sha, CADENCE_SHORT: sha.slice(0, 7), CADENCE_BRANCH: '' };
+}
+/** Délai de chaque essai d'une vérification de `cadence verify`. */
+export const VERIFY_ATTEMPT_MS = 120_000;
+/** `cadence verify` : 0 tout vert, 1 un effet rouge, 2 rien à vérifier. */
+export async function verifyCommand(ctx, deps) {
+    const { config, out } = ctx;
+    if (config.verify.length === 0) {
+        out(config.script !== undefined
+            ? 'verify : aucune vérification déclarée — ce projet livre par son script (deliver.script) et ses contrôles sont les siens ; ' +
+                'déclarer deliver.verify dans cadence.yaml pour les rejouer hors livraison'
+            : 'verify : aucune vérification déclarée (deliver.verify)');
+        return 2;
+    }
+    const results = await replayChecks(config.verify, deps, ctx.sha, verifyEnv(ctx.sha), { retryMs: ctx.retry * 1000, attemptMs: VERIFY_ATTEMPT_MS });
+    for (const r of results)
+        out(resultLine(r));
+    out(summaryLine(results));
+    return results.some((r) => r.reason !== null) ? 1 : 0;
+}
+/**
+ * Délai de chaque vérification de « session start », lancées en parallèle : c'est aussi, à la mise à mort
+ * près, la durée totale — la reprise ne doit pas attendre un réseau absent.
+ */
+export const MORNING_BUDGET_MS = 10_000;
+/**
+ * Lignes « Effets en production » du rapport de reprise : un seul essai par vérification, borné. Rien à dire
+ * (liste vide) pour un projet sans verify ; ne lève jamais — c'est un fait de plus, pas une condition.
+ */
+export async function effectLines(config, sha, deps) {
+    if (config.verify.length === 0)
+        return [];
+    try {
+        const results = await replayChecks(config.verify, deps, sha, verifyEnv(sha), { retryMs: 0, attemptMs: MORNING_BUDGET_MS });
+        const shown = results.filter((r) => r.reason !== null);
+        return shown.length === 0 ? [`✓ ${summaryLine(results)}`] : [...shown.map(resultLine), summaryLine(results)];
+    }
+    catch (e) {
+        return [`✗ verify : ${e.message}`];
+    }
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sylad/cadence",
-  "version": "0.6.0",
+  "version": "0.8.0",
   "description": "A small, repo-native working method: a versioned plan linked to your commits, a changelog with screenshots, session rituals and deliveries proven by their effect.",
   "license": "MIT",
   "author": "Sylvain Ladoire",
@@ -9,8 +9,18 @@
     "raf": "bin/raf.js",
     "cadence": "bin/cadence.js"
   },
-  "files": ["bin", "dist", "skills", "agents", ".claude-plugin", "README.md", "LICENSE"],
-  "engines": { "node": ">=20" },
+  "files": [
+    "bin",
+    "dist",
+    "skills",
+    "agents",
+    ".claude-plugin",
+    "README.md",
+    "LICENSE"
+  ],
+  "engines": {
+    "node": ">=20"
+  },
   "scripts": {
     "build": "tsc -p tsconfig.build.json",
     "test": "vitest run",

package/skills/deliver/SKILL.md

@@ -51,7 +51,9 @@ Deliver one project at a time: the one the human names, or ask.
 4. On failure: read which step failed and why. Fix the cause, commit, push, deliver again. Never rerun
    blindly, never skip a check to make it pass.
 5. On success: `raf done <id>` (or the project's own tool when its plan is read-only) for the lots it lists **whose effect you have seen**; if one of them is
-   `visible`, `cadence news build` and deliver the news too.
+   `visible`, `cadence news build` and deliver the news too. With a read-only plan the list holds only
+   the lots that were in progress when the delivery started; the project's own tool has the last word
+   on what it marked delivered.
 6. After a green delivery that changes what a page shows or what it is served (screen, API, data
    source, configuration of either) — in practice every delivery except docs-, plan- or tests-only
    ones — have the `qa-reviewer` agent walk the delivered app in a real browser, whether the lot

package/skills/session-close/SKILL.md

@@ -24,6 +24,9 @@ With no project named, run `cadence session close` in each project touched durin
      otherwise `raf note <id> "where it stands, what blocks"`;
    - a commit without a lot that belongs to one → `raf note <id> "commits: <sha> …"`; nothing if it
      is genuinely outside the plan (docs, chores);
+   - a plan commit reported because it also touches a file generated from the plan (a published
+     plan) → propose to declare that file under `plan.files` in `cadence.yaml`; the files of a commit
+     decide whether it is plan upkeep, never its subject;
    - a finished lot marked `visible` without a news entry → `cadence news new <id>`, written for the
      user, with a screenshot;
    - a lot that `raf done` refuses, or that the check reports as finished, for lack of a review —
@@ -43,6 +46,8 @@ With no project named, run `cadence session close` in each project touched durin
 5. **Clean state**: everything committed and pushed, no delivery running. If the command still exits 1,
    say what remains and do NOT say the session is closed.
 6. **Three lines for next time**: `cadence session next "…" "…" "…"` — the next `session-start` shows them.
+   The lines replace the previous notes. Without a line the command refuses and keeps them; erase
+   them on purpose with `cadence session next --clear`, only when nothing is left to say.
 
 ## Do not
 

package/skills/session-start/SKILL.md

@@ -30,6 +30,9 @@ three most useful items across projects and wait. With a project named, work in
    - **Done since**: 3 to 6 lines, grouped by lot, not by commit. Mention commits without a lot.
    - **Drift**: each `✗` line from the check, with the one command that fixes it.
    - **Delivery in progress** or a stale lock: no new delivery until it is resolved.
+   - **Effects in production** ("Effets en production"): a red `✗` line is the first thing to say —
+     a delivered feature that no longer works outranks any new lot; re-run `cadence verify` to confirm
+     (a network blip also shows as red).
    - **Notes from the last close**, if any.
    - **Project facts** ("Faits propres au projet"), when the project plugs its own morning script in
      (`session.start` in `cadence.yaml`): summarise what bears on today's choice — deadlines, the