@sylad/cadence 1.29.0 → 1.30.0

package/.claude-plugin/marketplace.json

@@ -8,7 +8,7 @@
     {
       "name": "cadence",
       "description": "Session start and close rituals driven by a versioned plan (raf), and deliveries proven by their effect. Needs the cadence CLI (npm i -g @sylad/cadence).",
-      "version": "1.29.0",
+      "version": "1.30.0",
       "source": "./",
       "author": {
         "name": "Sylvain Ladoire"

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "cadence",
   "description": "A repo-native working method: session start and close rituals driven by a versioned plan (raf), deliveries proven by their effect, and three reviewer agents (UX, code, QA).",
-  "version": "1.29.0",
+  "version": "1.30.0",
   "author": { "name": "Sylvain Ladoire" },
   "homepage": "https://github.com/Sylad/cadence",
   "repository": "https://github.com/Sylad/cadence",

package/dist/cli.js

@@ -23,7 +23,7 @@ import { schedule } from './schedule.js';
 import { AGENTS_DIR, installAgents, installSkills, SKILLS_DIR } from './skills.js';
 import { configSet } from './config-set.js';
 import { movePriority } from './priority.js';
-import { findProjects, readDepth, leadTour, TITLE_MAX, truncate, readLeadUx, tourFreeLine, readLeadContextThreshold, tourLine, tourNoTestLines, tourWorktreeLines } from './lead.js';
+import { findProjects, readDepth, leadTour, TITLE_MAX, truncate, readLeadUx, tourFreeLine, readLeadContextThreshold, findLeadDir, tourLine, tourNoTestLines, tourWorktreeLines } from './lead.js';
 import { configuredCap, expiredHoldLines, slotsLine, orchestrate, realOrchestrateDeps } from './orchestrate/command.js';
 import { addHold, releaseHold } from './orchestrate/registry.js';
 import { activeLock, REPO_LOCK } from './orchestrate/lock.js';
@@ -1746,8 +1746,10 @@ function sessionContext(io, session) {
     if (!r.ok)
         throw new RafError(`session context : contexte illisible — ${r.reason} ; à traiter comme au seuil`);
     io.out(`ctx ${Math.round(r.ctx.percent)} % (${r.ctx.tokens}/${r.ctx.window})`);
-    const threshold = readLeadContextThreshold(io.cwd);
-    io.out(`seuil ${threshold} tokens : ${r.ctx.tokens >= threshold ? 'atteint' : 'sous le seuil'}`);
+    // Lancée d'un sous-projet, la commande lit le cadence.yaml du dossier du lead (L457) et nomme le dossier lu.
+    const leadDir = findLeadDir(io.cwd);
+    const threshold = readLeadContextThreshold(leadDir);
+    io.out(`seuil ${threshold} tokens : ${r.ctx.tokens >= threshold ? 'atteint' : 'sous le seuil'}${leadDir === io.cwd ? '' : ` (lu dans ${join(leadDir, 'cadence.yaml')})`}`);
     return 0;
 }
 function session([sub, ...args], ctx, values) {

package/dist/lead.js

@@ -1,5 +1,5 @@
 import { existsSync, readdirSync, readFileSync, statSync } from 'node:fs';
-import { basename, join, relative, sep } from 'node:path';
+import { basename, dirname, join, relative, sep } from 'node:path';
 import { audit, gateWaiting, nextUp, planCommits, workByLot } from './audit.js';
 import { PLAN_DEFAULT, PLAN_LEGACY, planLoader, readPlanConfig } from './config.js';
 import { diffDays } from './dates.js';
@@ -45,6 +45,24 @@ export function readLeadUx(parent) {
         throw new RafError(`${found.file} : lead.ux doit être « lead » ou « human »`);
     return ux;
 }
+/** Le dossier du lead pour `start` (L457) : `start` ou le premier parent dont le cadence.yaml porte la clé `lead:` ou `priority:` ; aucun ne la porte (ou un yaml illisible en chemin) = `start` lui-même. */
+export function findLeadDir(start) {
+    for (let dir = start;; dir = dirname(dir)) {
+        const file = join(dir, 'cadence.yaml');
+        if (existsSync(file)) {
+            try {
+                const raw = parse(readFileSync(file, 'utf8'));
+                if (raw && typeof raw === 'object' && ('lead' in raw || 'priority' in raw))
+                    return dir;
+            }
+            catch {
+                // un yaml illisible n'est pas celui d'un lead qu'on puisse lire : on continue de remonter
+            }
+        }
+        if (dirname(dir) === dir)
+            return start;
+    }
+}
 /** Seuil de contexte du lead quand `lead.contextThreshold` n'est pas posé (L437). */
 export const CONTEXT_THRESHOLD_DEFAULT = 150_000;
 /** Clé `lead.contextThreshold` du cadence.yaml du dossier (L437) : le nombre de tokens de contexte à partir duquel le lead ne lance plus de vague. En tokens et non en % : 60 % d'une fenêtre de 1M valait 600k. Un entier ≥ 1, sinon refus. */

package/dist/orchestrate/command.js

@@ -38,7 +38,7 @@ import { resolveLotRepos } from '../repos.js';
 import { excludeState, lotFinished, lotKey, lotRepoPaths, lotSlug, neighbourDirs, newLot, RunStore } from './state.js';
 import { linkNodeBin, nvmVersionsDir, resolveNode } from './node-env.js';
 import { quotaText, renderDetail, renderTable, resumeCommand } from './table.js';
-import { PACKAGE_ROOT, RESERVED_ENV, SnapshotRefusal, isSnapshotChild, resolveModulesDir, repairSnapshotModules, snapshotExists, waveReadsControl, waveReadsIntegrate, waveReadsLotBudget, waveReadsReplay, withoutLaunchVars, spawnReexec, takeSnapshot, toolDirOf } from './snapshot.js';
+import { PACKAGE_ROOT, RESERVED_ENV, SnapshotRefusal, isSnapshotChild, resolveModulesDir, repairSnapshotModules, snapshotExists, waveReadsAnswerQueue, waveReadsControl, waveReadsIntegrate, waveReadsLotBudget, waveReadsReplay, withoutLaunchVars, spawnReexec, takeSnapshot, toolDirOf } from './snapshot.js';
 const REPO_WAIT_MS = 3 * 60 * 60_000;
 const REPO_WAIT_POLL_MS = 5_000;
 export const DEFAULT_BUDGET = 2_000_000;
@@ -634,6 +634,8 @@ function freeLines(launch, drawn) {
 /** Efface l'écran et replace le curseur en haut : l'entrée d'un rendu de `--status --watch`. */
 const CLEAR_SCREEN = '\x1b[H\x1b[2J';
 const DEFAULT_WATCH_INTERVAL = 10;
+/** Attente (ms) entre deux lectures de la file de réponses d'une vague vivante (L407) quand aucune file de lots ne finit. */
+const ANSWER_POLL_MS = 2000;
 /** Ce que `--status` montre à un instant : les vagues vivantes, puis le tableau (absent si seules les vagues vivantes comptent). */
 function statusView(args, launch, cap, now) {
     const id = statusWave(args);
@@ -805,6 +807,8 @@ export async function orchestrate(argv, io, deps) {
         return resume(args, argv, io, deps, launch, today);
     if (args.drop.length || args.stopAfterCurrent)
         return control(args, io);
+    if (args.answers.length)
+        return answerOnly(args, io);
     if (args.lots.length === 0 && !args.continue)
         throw new RafError('usage : cadence orchestrate <projet>:<lot>… [--budget 2M] [--max-sessions 2] [--dry-run] [--continue [--until 18:00] [--priority a,b]] | --waits [--since AAAA-MM-JJ] | --status [vague] [--detail projet:lot | --watch [--interval 10]] | --resume [vague] [--answer projet:lot "réponse"] [--integrate projet:lot] [--replay projet:lot] | --drop projet:lot | --stop-after-current | --remove-worktree projet:lot [--abandon-commits]');
     const refusals = [];
@@ -1286,7 +1290,41 @@ async function execute(wave, lots, store, io, deps, today, cap, all = lots) {
                 if (held.includes(join(sharedStateDir(r), REPO_LOCK)) && all.filter((l) => lotRepoPaths(l).includes(r)).every(finished))
                     freeRepo(r);
             }
-        }, (lots) => lots.every((c) => c.tree));
+        }, (lots) => lots.every((c) => c.tree), {
+            pollMs: deps.slotPollMs ?? ANSWER_POLL_MS,
+            // L407 : les réponses déposées par `--answer` pendant la vague sont prises entre deux étapes ; un lot qui n'est plus en question ne rejoue rien.
+            take: (canRun) => {
+                const taken = [];
+                for (const e of store.answerQueue()) {
+                    const c = ctxs.find((x) => lotKey(x.lot.project, x.lot.lot) === e.lot);
+                    const why = !c ? 'lot inconnu' : c.lot.status !== 'question' ? `le lot n'attend plus de réponse (${c.lot.status})` : c.lot.pendingAnswer ? 'une réponse est déjà en cours de jeu' : null;
+                    if (why) {
+                        wctx.log(`${e.lot} : réponse écartée (${why})`);
+                        store.markAnswerTaken(e.id);
+                    }
+                    else if (c && canRun(c)) {
+                        c.lot.pendingAnswer = e.text;
+                        c.lot.answers.push(e.text);
+                        c.lot.questions = [];
+                        store.writeLot(c.lot);
+                        store.markAnswerTaken(e.id);
+                        wctx.log(`${e.lot} : réponse du lead prise, le lot repart`);
+                        // Le lot avait fini de jouer à sa question (`settled`) : il rejoue, il tient de nouveau un créneau — sans cela `lanes()` le sous-compte et le registre annonce un créneau libre de trop (L433).
+                        settled.delete(c);
+                        taken.push(c);
+                    }
+                }
+                if (taken.length) {
+                    try {
+                        updateWaveRepos(home, process.pid, repos.filter((x) => !freed.has(x)), lanes());
+                    }
+                    catch {
+                        // registre illisible : le décompte reste celui du dernier écrit
+                    }
+                }
+                return taken;
+            },
+        });
         handBackDroppedQuestions(ctxs); // un lot en question retiré pendant la vague : rendu avant de fixer le statut de la vague
     }
     finally {
@@ -1308,11 +1346,57 @@ async function execute(wave, lots, store, io, deps, today, cap, all = lots) {
         return 3;
     return all.every((l) => l.status === 'ready') ? 0 : 1;
 }
-/** `--drop` / `--stop-after-current` (L79) : une demande écrite dans le dossier d'état de la vague vivante ; c'est elle qui la lit avant sa prochaine session. */
-function control(args, io) {
-    const flags = '--drop / --stop-after-current';
-    if (args.lots.length || args.continue || args.dryRun || args.budget !== undefined || args.answers.length)
-        throw new RafError(`${flags} ne se combinent pas avec des lots à lancer, --continue, --dry-run, --budget ou --answer`);
+/**
+ * `--answer` sur une vague VIVANTE (L407) : la réponse est déposée dans la file de la vague (`answers.log`), qui la prend entre deux étapes et rejoue le lot dès qu'un créneau est libre.
+ * Sans cela le lead attendait la fin de la vague (15 min d'un lot bloqué le 28-10). Les lots visés sont contrôlés comme à la reprise : connus, en question.
+ */
+function answerLive(args, io, store) {
+    const lots = store.lots();
+    const refusals = [];
+    const keys = [];
+    for (const a of args.answers) {
+        const matches = lots.filter((l) => l.lot === a.lot && (a.project ? l.project === a.project : true));
+        const where = `${a.project ? `${a.project}:` : ''}${a.lot}`;
+        if (matches.length !== 1)
+            refusals.push(matches.length ? `--answer ${where} : plusieurs projets portent ce lot, précisez projet:lot` : `--answer ${where} : lot inconnu dans la vague ${store.id}`);
+        else if (matches[0].status !== 'question')
+            refusals.push(`--answer ${lotKey(matches[0].project, matches[0].lot)} : le lot n'attend pas de réponse (${matches[0].status})`);
+        else
+            keys.push({ key: lotKey(matches[0].project, matches[0].lot), text: a.text });
+    }
+    if (!waveReadsAnswerQueue(store.dir))
+        refusals.push(`la vague ${store.id} ne lit pas la file de réponses (lancée avec une version de cadence d'avant L407) : attendre sa fin, puis ${resumeCommand(store.id, '--answer', '<projet>:<lot>', '"…"')}`);
+    if (refusals.length) {
+        for (const r of refusals)
+            io.err(`orchestrate : ${r}`);
+        return 2;
+    }
+    for (const { key, text } of keys) {
+        const id = store.requestAnswer(key, text);
+        // La vague a pu finir entre le contrôle et le dépôt : sa file ne sera plus lue, la réponse est retirée et le lead reprend à la main.
+        if (!liveWaves(cadenceHome()).some((w) => w.wave === store.id)) {
+            store.markAnswerTaken(id);
+            io.err(`orchestrate : ${key} : la vague ${store.id} vient de finir, réponse non prise : ${resumeCommand(store.id, '--answer', key, '"…"')}`);
+            return 2;
+        }
+        store.journal(`demande : réponse du lead pour ${key}`);
+        io.out(`${key} : réponse déposée — la vague ${store.id} la prend entre deux étapes et rejoue le lot dès qu'un créneau est libre`);
+    }
+    return 0;
+}
+/** La vague vivante, pour `--answer` seul (sans --resume) : la même recherche que `--drop`. */
+function answerOnly(args, io) {
+    if (args.drop.length || args.stopAfterCurrent || args.budget !== undefined || args.dryRun || args.continue || args.lots.length)
+        throw new RafError("--answer ne se combine pas avec --drop, --stop-after-current, --budget, --dry-run, --continue ni des lots à lancer (sur une vague arrêtée : --resume --answer)");
+    const store = liveStore('--answer', args, io);
+    if (typeof store === 'number') {
+        io.err(`orchestrate : --answer : une vague arrêtée se reprend avec ${resumeCommand('<vague>', '--answer', '<projet>:<lot>', '"…"')}`);
+        return store;
+    }
+    return answerLive(args, io, store);
+}
+/** La vague vivante lancée depuis ce dossier que vise `--wave` (ou la seule) ; sinon le refus (code 2) déjà écrit. */
+function liveStore(flags, args, io) {
     const live = liveWaves(cadenceHome()).filter((w) => w.cwd === io.cwd && (args.wave === undefined || w.wave === args.wave));
     if (live.length === 0) {
         io.err(`orchestrate : ${flags} : aucune vague en cours${args.wave ? ` (${args.wave})` : ''} lancée depuis ce dossier`);
@@ -1327,6 +1411,16 @@ function control(args, io) {
         io.err(`orchestrate : ${flags} : dossier d'état de la vague ${live[0].wave} introuvable`);
         return 2;
     }
+    return store;
+}
+/** `--drop` / `--stop-after-current` (L79) : une demande écrite dans le dossier d'état de la vague vivante ; c'est elle qui la lit avant sa prochaine session. */
+function control(args, io) {
+    const flags = '--drop / --stop-after-current';
+    if (args.lots.length || args.continue || args.dryRun || args.budget !== undefined || args.answers.length)
+        throw new RafError(`${flags} ne se combinent pas avec des lots à lancer, --continue, --dry-run, --budget ou --answer`);
+    const store = liveStore(flags, args, io);
+    if (typeof store === 'number')
+        return store;
     const lots = store.lots();
     const refusals = [];
     const keys = [];
@@ -1427,6 +1521,9 @@ async function resume(args, argv, io, deps, launch, today) {
             io.err(`orchestrate : vague ${store.id} sans instantané (antérieure à L61) : reprise avec le dist/ et les gabarits courants`);
         }
     }
+    // L407 : la forme documentée sur une vague qui tourne encore dépose la réponse dans sa file au lieu de refuser ; avec une autre option de reprise, le refus ci-dessous reste.
+    if (args.answers.length && !args.lotBudgets.length && !args.drop.length && !args.integrate.length && args.budget === undefined && !args.continue && liveWaves(cadenceHome()).some((w) => w.wave === store.id && w.cwd === launch && w.pid !== process.pid))
+        return answerLive(args, io, store);
     const wave = store.readWave();
     const refusals = [];
     const info = deps.claudeInfo();

package/dist/orchestrate/cycle.js

@@ -1030,7 +1030,7 @@ async function session(c, kind, local = false) {
     save(c);
     return { step, report: res.structured, before, after, others };
 }
-/** Les dépôts tiers d'un lot (L456) : frères du dépôt du lot, hors voisins déclarés et dépôts des autres lots de la vague, ou d'une autre vague en cours du même dossier (leur branche principale bouge légitimement, R14). */
+/** Les dépôts tiers d'un lot (L456) : frères du dépôt du lot, hors voisins déclarés et dépôts des autres lots de la vague (leur branche principale bouge légitimement, R14). Une vague lancée après ce relevé, comme le lead ou une livraison, n'est pas dans la liste : seuls les commits qui citent un lot de cette vague sont constatés (L458) ; exclure les vagues vivantes déjà connues évite qu'un identifiant de lot commun (deux projets, chacun son L1) fasse passer leurs commits pour les nôtres. */
 function thirdRepos(c) {
     const mine = lotKey(c.lot.project, c.lot.lot);
     const others = [...c.wave.store.lots().filter((x) => lotKey(x.project, x.lot) !== mine), ...c.wave.store.liveWaveLots()].flatMap(lotRepoPaths);
@@ -1060,7 +1060,7 @@ function checkTiers(c, kind, step, before) {
             w.log(`${key} · dépôt tiers ${name} ignoré : aucune branche principale`);
         }
         else {
-            const moved = tierMoved(repo, b, a, relative(l.repo, c.loadPlan().path));
+            const moved = tierMoved(repo, b, a, w.store.lots().map((x) => x.lot));
             if (moved) {
                 step.status = 'failed';
                 step.cause = `commit sur la branche principale d'un autre dépôt (${name}, ${moved.branch})`;

package/dist/orchestrate/pool.js

@@ -25,14 +25,7 @@ export function groupLots(ctxs) {
     }
     return groups.map((g) => g.lots);
 }
-/**
- * Ordonnanceur : une file par dépôt, les lots d'un dépôt l'un après l'autre dans l'ordre donné, `slots` files au plus en parallèle. Deux lots qui partagent un dépôt
- * sont dans la même file : jamais deux sessions dans un même dépôt (le plafond global des sessions de toutes les vagues est tenu par command.ts).
- * `parallel(groupe)` (L279) : les lots de ce groupe sont chacun leur propre file — ils jouent ensemble, chacun dans son worktree, dans la limite de `slots` ;
- * un lot qui dépend d'un lot du groupe attend qu'il soit fini (ready après son intégration) avant de partir, et le lot en attente d'une place n'est pas commencé
- * (son worktree n'existe pas encore, R3). `onSettled` est appelé quand un lot a fini de jouer (L132 : command.ts libère alors les dépôts que plus aucun lot ne tient). Le budget, le quota et les incidents sont vérifiés par le cycle avant chaque session.
- */
-export async function runPool(ctxs, slots = SLOTS, known = [], onSettled = () => { }, parallel = () => false) {
+export async function runPool(ctxs, slots = SLOTS, known = [], onSettled = () => { }, parallel = () => false, answers) {
     const pending = groupLots(ctxs).flatMap((g) => (parallel(g) ? g.map((c) => [c]) : [g]));
     // Les lots pas encore finis de jouer (en file ou en cours) : un lot ne part pas tant que l'un d'eux est sa dépendance.
     const live = new Set(ctxs);
@@ -82,12 +75,28 @@ export async function runPool(ctxs, slots = SLOTS, known = [], onSettled = () =>
             const dep = ctxs.find((o) => o.lot.project === queue[0].lot.project && o.lot.lot === id);
             return !!dep && live.has(dep) && dep.lot.status !== 'ready';
         });
-    const running = new Set();
+    const running = new Map();
     const start = (queue) => {
         const p = runQueue(queue).finally(() => running.delete(p));
-        running.add(p);
+        running.set(p, queue);
+    };
+    // Sans worktree, un lot repris ne joue pas pendant qu'un autre lot du même dépôt joue, attend un créneau ou vient d'être accepté dans ce même tour (jamais deux sessions dans un dépôt).
+    const admitted = [];
+    const sameRepo = (a, b) => lotRepoPaths(a.lot).some((r) => lotRepoPaths(b.lot).includes(r));
+    const canRun = (c) => {
+        if (c.tree)
+            return true;
+        if ([...running.values(), ...pending].some((q) => q.some((o) => sameRepo(c, o))) || admitted.some((o) => sameRepo(c, o)))
+            return false;
+        admitted.push(c);
+        return true;
     };
     for (;;) {
+        admitted.length = 0;
+        for (const c of answers?.take(canRun) ?? []) {
+            live.add(c);
+            pending.push([c]);
+        }
         while (running.size < slots) {
             const next = pending.findIndex((q) => !blocked(q));
             if (next < 0)
@@ -101,6 +110,12 @@ export async function runPool(ctxs, slots = SLOTS, known = [], onSettled = () =>
             start(pending.shift());
             continue;
         }
-        await Promise.race(running);
+        if (!answers)
+            await Promise.race(running.keys());
+        else {
+            let timer;
+            await Promise.race([...running.keys(), new Promise((res) => (timer = setTimeout(res, answers.pollMs)))]);
+            clearTimeout(timer);
+        }
     }
 }

package/dist/orchestrate/snapshot.js

@@ -117,6 +117,19 @@ export function waveReadsControl(waveDir) {
         return false;
     }
 }
+/**
+ * La vague lit-elle la file de réponses `answers.log` (L407) ? Une vague lancée avant L407 ne la lirait jamais : la réponse y dormirait. Sans instantané : on suppose que oui.
+ */
+export function waveReadsAnswerQueue(waveDir) {
+    if (!snapshotExists(waveDir))
+        return true;
+    try {
+        return readFileSync(join(toolDirOf(waveDir), 'dist', 'orchestrate', 'state.js'), 'utf8').includes('answers.log');
+    }
+    catch {
+        return false;
+    }
+}
 /**
  * L'instantané de la vague connaît-il `--budget projet:lot=+N` (L223) ? Un instantané plus ancien relit l'argument avec son `parseBudget` et le refuse
  * comme budget invalide. Sans instantané : rien à relire, on suppose que oui.

package/dist/orchestrate/state.js

@@ -167,6 +167,42 @@ export class RunStore {
         const kept = readFileSync(f, 'utf8').split('\n').filter((l) => l.trim() !== '' && l.trim() !== 'stop-after-current');
         writeFileSync(f, kept.map((l) => `${l}\n`).join(''));
     }
+    /**
+     * File des réponses du lead à une vague vivante (L407) : `answers.log`, en ajout seul, une ligne JSON par réponse déposée (`{id, lot, text}`) ou par réponse prise (`{taken: id}`).
+     * La vague la relit entre deux étapes ; une réponse prise ou écartée n'y figure plus. Une ligne illisible est ignorée. Pas de `.json` : `lots()` le prendrait pour un lot.
+     */
+    answerQueue() {
+        const f = join(this.dir, 'answers.log');
+        if (!existsSync(f))
+            return [];
+        const entries = [];
+        const taken = new Set();
+        for (const line of readFileSync(f, 'utf8').split('\n')) {
+            try {
+                const o = JSON.parse(line);
+                if (typeof o.taken === 'number')
+                    taken.add(o.taken);
+                else if (typeof o.id === 'number' && typeof o.lot === 'string' && typeof o.text === 'string')
+                    entries.push({ id: o.id, lot: o.lot, text: o.text });
+            }
+            catch {
+                // ligne vide ou illisible : ignorée
+            }
+        }
+        return entries.filter((e) => !taken.has(e.id));
+    }
+    /** Dépose une réponse dans la file ; rend son numéro. */
+    requestAnswer(lot, text) {
+        const f = join(this.dir, 'answers.log');
+        const last = existsSync(f) ? [...readFileSync(f, 'utf8').matchAll(/^\{"id":(\d+),/gm)].map((m) => Number(m[1])) : [];
+        const id = Math.max(0, ...last) + 1;
+        appendFileSync(join(this.dir, 'answers.log'), `${JSON.stringify({ id, lot, text })}\n`);
+        return id;
+    }
+    /** La réponse `id` est prise (jouée, écartée ou retirée par son auteur) : elle ne sera plus relue. */
+    markAnswerTaken(id) {
+        appendFileSync(join(this.dir, 'answers.log'), `${JSON.stringify({ taken: id })}\n`);
+    }
     journal(line) {
         appendFileSync(join(this.dir, 'journal.log'), `${new Date().toISOString()} ${line}\n`);
     }

package/dist/orchestrate/tiers.js

@@ -87,20 +87,16 @@ export function takeTiers(repos, log) {
 }
 /** Plus de commits que cela dans le constat : le reste est compté. */
 const SHOWN = 5;
-/** Un commit du lead (R18) : le sujet commence par « plan: ». Il n'est toléré que s'il ne change que le fichier du plan. */
-const LEAD_SUBJECT = /^\S+ plan: /;
-/** Une ligne « sha sujet » est-elle un commit du lead : sujet « plan: » et le seul fichier changé est celui du plan ? */
-function isLeadCommit(repo, line, planFile) {
-    if (!LEAD_SUBJECT.test(line))
-        return false;
-    const files = (tryGit(repo, 'diff-tree', '--root', '--no-commit-id', '--name-only', '-r', line.split(' ')[0]) ?? '').split('\n').filter(Boolean);
-    return files.length > 0 && files.every((f) => f === planFile);
+/** Le sujet d'un commit cite-t-il l'un de ces lots ? Identifiant entier : « L1 » n'est ni dans « L10 » ni dans « L1.2 », mais l'est dans « feat(L1): » ou « demo:L1 ». */
+export function citesLot(subject, lots) {
+    return lots.some((id) => new RegExp(`(?<![\\w.-])${id.replace(/[.*+?^${}()|[\]\\]/g, '\\$&')}(?![\\w-]|\\.\\w)`).test(subject));
 }
 /**
  * Première branche principale dont le sha a bougé entre deux relevés, avec ce qu'il faut en dire : les commits ajoutés (sha court et sujet), ou la branche créée,
- * supprimée ou déplacée sans commit nouveau ; les commits du lead (R18 : « plan: » et rien d'autre que `planFile`) ne comptent pas. Une branche absente d'un seul côté a bougé (créée ou supprimée pendant la session). Null : rien n'a bougé.
+ * supprimée ou déplacée sans commit nouveau. Seuls comptent les commits dont le sujet cite un lot de la vague (`lots`, L458) : une livraison (bump de tag de deploy.sh), un commit du lead
+ * ou d'une autre vague ne citent aucun d'eux et passent. Une branche absente d'un seul côté a bougé (créée ou supprimée pendant la session). Null : rien n'a bougé.
  */
-export function tierMoved(repo, before, after, planFile) {
+export function tierMoved(repo, before, after, lots) {
     for (const branch of [...new Set([...Object.keys(before.mains), ...Object.keys(after.mains)])].sort()) {
         const b = before.mains[branch];
         const a = after.mains[branch];
@@ -111,9 +107,9 @@ export function tierMoved(repo, before, after, planFile) {
         // branche créée : seuls comptent les commits que aucune branche principale d'avant ne portait déjà
         const range = b ? [`${b}..${a}`] : [a, '--not', ...Object.values(before.mains)];
         const all = (tryGit(repo, 'log', '--abbrev=7', '--format=%h %s', ...range) ?? '').split('\n').filter(Boolean);
-        const lines = all.filter((l) => !isLeadCommit(repo, l, planFile));
+        const lines = all.filter((l) => citesLot(l.slice(l.indexOf(' ') + 1), lots));
         if (all.length && !lines.length)
-            continue; // que des commits du lead
+            continue; // aucun commit ne cite un lot de la vague
         if (!lines.length && !b)
             return { branch, detail: `branche créée (${a.slice(0, 7)})` };
         if (!lines.length)

package/docs/cadence-hud.md

@@ -93,7 +93,7 @@ Before the first reading the panel says `Lecture des plans…`; if `cadence lead
 
 **Last delivery of each project (L415).** Under the lots in progress, `Dernière livraison par projet (N)` shows one line per project that has delivered: `✔ finance  3f9a1c2 · il y a 2 j · verte · 2 lots clos non livrés : L12, L13`, or `✖ … · rouge` in red when the last delivery failed; `rien à livrer` when every closed lot was delivered, and nothing after `verte` when the plan is not known. It reads the journal `cadence deliver` writes (`.git/cadence/deliveries.log`, one `day sha` line per green delivery, and `deliveries-failed.log`) through the `LAST_DELIVERIES` script (python3, the folder and each direct sub-folder whose `.git` is a folder, like the failed-delivery script; run at each 5 s refresh **while the panel is open**): the last delivery is the red one when `deliveries-failed.log` was modified after `deliveries.log` (the files' modification date decides, as for the failed deliveries), the green one otherwise; a repository with no readable line is absent. The age counts days from the journal's day (the journal has no hour): `aujourd’hui`, `hier`, `il y a N j`. **Closed lots not delivered**: `cadence lead tour --json` gives each project row `closed`, the closed lots (`done`, archived ones included, lots with an `every:` left out) as `{ id, finished }`; a lot is delivered when a green delivery happened on the day it was closed or after (the rule of the delivery delay in `cadence perf`), so it is not delivered when closed **after the day of the last green delivery** — a red delivery delivers nothing, and a project that never delivered green counts all its closed lots. A project absent from the tour, in error, or read by a `cadence` too old to give `closed` shows no count (not « rien à livrer »: we do not know). Order: red first, then the most undelivered lots, then the name. Height (`deliveriesHeight`): the title and one line per project, within what the decisions and the lots in progress leave of the half of the body, `… +N projets` when they do not all fit, nothing under two lines; the tree keeps the rest. Calculation: `hooks/deliveries.ts` (`deliveriesOf`, `buildDeliveries`, `parseLastDeliveries`). Tested by `tests/deliveries.test.ts` (L415 R4 to R11), `tests/lots-pane.test.ts` (R12 to R14, panel mounted), `test/hud-livraisons-l415.test.ts` (R2, R3: the real script on real journals) and `test/lead-tour-lots.test.ts` (R1: the `closed` field).
 
-**What is waiting for a decision (L412).** Above the tree, a block `Ce qui attend une décision (N)` gathers what the person has to settle; it exists only when there is something to settle. It reads the band's waves (live ones, and the last finished one only when none is live), the finished waves of the folder that the collector returns apart in `ended` (whether a wave is live or not, without the band's 30-minute delay: **all** the finished waves of the last 7 days, with no cap on their number (a cost guard of 500 waves, far above the 162 waves per 7 days measured, is not a rule), newest first by the date of their `wave.json` — a question or a handed-back lot waits as long as the plan keeps the lot open and its wave is less than 7 days old (beyond that, the decision leaves the block even if the lot is still open in the plan), a newer wave finishing without that lot does not erase it; a live wave is not among them: its `wave.json`, always the most recent of the folder since orchestrate rewrites `consumed` in it, is skipped by the collector; the band and the tree keep reading `waves` only, their drawing does not change) and the failed deliveries; a lot counts once, in the first wave carrying it, live waves first then the finished ones newest first (taken over in a newer wave, that wave decides). Four kinds: `? project:lot  <questions>` (a lot in the `question` state; the short text is the first line of each question, joined by ` / `) with, below it in grey, the command that answers it (`cd <launch folder of the wave> && cadence orchestrate --resume --wave <wave> --answer project:lot "…"`, the one the end-of-wave table prints, preceded by a `cd` to the wave's `cwd`: orchestrate finds the wave only from there) — while the wave is live, no command but `réponse possible à la fin de la vague`, since orchestrate refuses to resume a wave that is still running; `↩ project:lot  <cause>` (a `handed-back` or `failed` lot: the first line of its outcome, the status in words when empty; a `suspended` lot waits for nothing from the person), in red; `◐ project:lot  verdict UX : <verdict>` (a `ready`, visible lot whose review returned a verdict) with `cd <repository of the lot> && raf ux <lot> "verdict"` below (the `repo` of the lot state: from the parent folder raf answers « pas de plan », from another project it would record the verdict on that project's lot of the same id) — the commands to copy start with `cd` and run as they are from any folder, a path with a space or a quote is quoted for sh; `✖ project  livraison : <short sha> · <reason> (<day>)` in red (7 characters: deliver writes the full 40-character sha in the log). The block never takes more than half of the body (3 lines at least): past that, the first decisions that fit, then `… +N décisions de plus`. Failed deliveries come from the `DELIVERIES` script (collect.ts, python3), run at every 5 s refresh **while the panel is open**: for the folder and each direct sub-folder whose `.git` is a directory, the last line of `.git/cadence/deliveries-failed.log`, unless `deliveries.log` was modified after it (a green delivery clears the failure; file modification times decide, the day on the line cannot order two writes of the same day). The plan decides: the panel's board (read from `cadence lead tour --json`) drops any decision whose lot is no longer open in a project the tour read, so a UX verdict recorded then `raf done`, or a handed-back lot taken over and closed, disappears at the next plan read; a project missing from the board, in error or without lots keeps its decisions. The command to copy is wrapped over several lines at the panel's width, never cut, every line but the last ending with the shell continuation ` \` (`\` glued to the piece when a word longer than the line is cut): pasted as they are into a shell, the lines run one command, the whole one (without it, a first line `cadence orchestrate --resume --wave <wave>` ran alone, without its `--answer`); the wrapped lines count in the block's ceiling. Details in the plugin's README.
+**What is waiting for a decision (L412).** Above the tree, a block `Ce qui attend une décision (N)` gathers what the person has to settle; it exists only when there is something to settle. It reads the band's waves (live ones, and the last finished one only when none is live), the finished waves of the folder that the collector returns apart in `ended` (whether a wave is live or not, without the band's 30-minute delay: **all** the finished waves of the last 7 days, with no cap on their number (a cost guard of 500 waves, far above the 162 waves per 7 days measured, is not a rule), newest first by the date of their `wave.json` — a question or a handed-back lot waits as long as the plan keeps the lot open and its wave is less than 7 days old (beyond that, the decision leaves the block even if the lot is still open in the plan), a newer wave finishing without that lot does not erase it; a live wave is not among them: its `wave.json`, always the most recent of the folder since orchestrate rewrites `consumed` in it, is skipped by the collector; the band and the tree keep reading `waves` only, their drawing does not change) and the failed deliveries; a lot counts once, in the first wave carrying it, live waves first then the finished ones newest first (taken over in a newer wave, that wave decides). Four kinds: `? project:lot  <questions>` (a lot in the `question` state; the short text is the first line of each question, joined by ` / `) with, below it in grey, the command that answers it (`cd <launch folder of the wave> && cadence orchestrate --resume --wave <wave> --answer project:lot "…"`, the one the end-of-wave table prints, preceded by a `cd` to the wave's `cwd`: orchestrate finds the wave only from there) — the same command while the wave is live (L407: orchestrate then drops the answer in the wave's queue, which the live wave reads between two steps, instead of refusing « la vague tourne encore »); `↩ project:lot  <cause>` (a `handed-back` or `failed` lot: the first line of its outcome, the status in words when empty; a `suspended` lot waits for nothing from the person), in red; `◐ project:lot  verdict UX : <verdict>` (a `ready`, visible lot whose review returned a verdict) with `cd <repository of the lot> && raf ux <lot> "verdict"` below (the `repo` of the lot state: from the parent folder raf answers « pas de plan », from another project it would record the verdict on that project's lot of the same id) — the commands to copy start with `cd` and run as they are from any folder, a path with a space or a quote is quoted for sh; `✖ project  livraison : <short sha> · <reason> (<day>)` in red (7 characters: deliver writes the full 40-character sha in the log). The block never takes more than half of the body (3 lines at least): past that, the first decisions that fit, then `… +N décisions de plus`. Failed deliveries come from the `DELIVERIES` script (collect.ts, python3), run at every 5 s refresh **while the panel is open**: for the folder and each direct sub-folder whose `.git` is a directory, the last line of `.git/cadence/deliveries-failed.log`, unless `deliveries.log` was modified after it (a green delivery clears the failure; file modification times decide, the day on the line cannot order two writes of the same day). The plan decides: the panel's board (read from `cadence lead tour --json`) drops any decision whose lot is no longer open in a project the tour read, so a UX verdict recorded then `raf done`, or a handed-back lot taken over and closed, disappears at the next plan read; a project missing from the board, in error or without lots keeps its decisions. The command to copy is wrapped over several lines at the panel's width, never cut, every line but the last ending with the shell continuation ` \` (`\` glued to the piece when a word longer than the line is cut): pasted as they are into a shell, the lines run one command, the whole one (without it, a first line `cadence orchestrate --resume --wave <wave>` ran alone, without its `--answer`); the wrapped lines count in the block's ceiling. Details in the plugin's README.
 
 The data is the `lots` field of `cadence lead tour --json` ([lead tour](lead.md#lead-tour)), read together with the band's `progress` (same call, same folder). While the panel is open, the modification date of each plan (`.cadence/raf.yaml` and `cadence.yaml` of the folder and of its direct sub-folders) is read every 5 s, one `stat` each: a changed plan, like a wave transition, triggers a new reading before the minute is over. Cost of the `lots` field (R18, measured on 2026-10-28 with `cadence lead tour --json` on the parent folder of ten projects, three passes each): before L401 (cadence 1.19.1, no `lots`) 8.0 / 9.1 / 7.3 s and 86 KB of output; after (the L401 code) 7.5 / 7.0 / 8.4 s and 188 KB (192,503 bytes). The output more than doubles in size but the duration stays in the same order, under the 20 s refresh delay of the band, so the rule holds.
 

package/docs/lead.md

@@ -55,7 +55,9 @@ picture, not its source.
    question from a session comes back to the human at once; the answer goes in with
    `cadence orchestrate --resume --wave <wave> --answer <project>:<lot> "…"` (the wave is named: the
    command is printed under each question of the table, ready to run; without a wave, `--resume` is refused as
-   soon as the folder keeps several unfinished waves). The lead never answers in the
+   soon as the folder keeps several unfinished waves). While the wave is still running the same command (or
+   `cadence orchestrate --answer <project>:<lot> "…"`) queues the answer and the live wave replays the lot at
+   once, whatever the other lots do (L407). The lead never answers in the
    human's place. `--drop` and `--stop-after-current` steer a wave that is running.
 4. **Review.** The final table of the wave lists the lots ready, handed back, and the line
    « livrable jusqu'à <sha> » for a ready lot stacked under a handed-back one. Minor findings come back in

package/docs/orchestrate.md

@@ -35,6 +35,7 @@ cadence orchestrate --resume … --dry-run                         # refused: a
 # a resume running on the wave's snapshot receives `--resume <wave>` in place of `--wave <wave>`, so an older snapshot cannot pick another wave; a wave whose id looks like a lot (`suite2`) cannot be named that way, so it is resumed with the current `dist/` and templates
 cadence orchestrate --drop ccc:L29 [--wave <wave>]   # from another terminal: take a lot out of the running wave
 cadence orchestrate --stop-after-current [--wave <wave>]   # from another terminal: let the running sessions finish, start nothing else
+cadence orchestrate --answer ol-companion:L22 "reply" [--wave <wave>]   # from another terminal: answer a lot of the running wave that is waiting for it (below)
 ```
 
 **Claude Code must be installed and logged in** (L378). Before starting a lot, `cadence orchestrate` runs `claude auth status` (no model, no cost); when it says `loggedIn: false` the command is refused (exit 2) before anything is written: no `raf start`, no plan commit, the lot stays `todo`. The message says what to do: « claude n'est pas connecté : lancer `claude` puis /login (état : `claude auth status`) ». `--dry-run` starts no session, so it is not refused: it prints the same message after its first line, as a `⚠`. `claude auth status` is read once per launch, so with `--continue` the rounds of a wave do not run it again for every candidate lot. An unreadable answer (a `claude` without `auth status`) is not a refusal.
@@ -60,6 +61,8 @@ this way is left out of the resume checks (repository lock, `.nvmrc` Node, dirty
 refuse the resume, and a refusal writes nothing to `control.log`.
 `--resume --wave <wave> --stop-after-current` is refused (exit 2): resuming contradicts stopping.
 
+**Answering on a live wave (L407).** `--answer <project:lot> "…"` (from the folder that launched the wave, `--wave` when several are live) no longer waits for the wave to end: on 28-10 a lot waited about 15 minutes for its answer because another lot of the wave was still running, and `--resume` refuses a wave that is running. The answer is appended to the wave's queue (`answers.log` in `.cadence/runs/<wave>/`, one JSON line per answer and per answer taken), the command prints `<lot> : réponse déposée` and returns at once. The live wave reads the queue every 2 seconds and each time a lot finishes, applies the answer to the lot (the same state as `--resume --answer`: the answer joins the brief of its next session) and replays it as one more line of the pool, as soon as a session slot is free; a lot with no worktree never plays together with another lot of its repository. The documented form `--resume --wave <wave> --answer …` does the same when that wave is still running (it used to be refused with `tourne encore`); combined with another resume option (`--budget`, `--drop`, `--integrate`, `--continue`) it is still refused. Refused (exit 2) before anything is written: a lot that is unknown, that several projects carry, or that is not waiting for an answer (`question`); no live wave in that folder (the message gives the `--resume --wave <wave> --answer` form for a stopped wave); a wave started before L407, whose snapshot does not read the queue. `--answer` alone does not combine with `--drop`, `--stop-after-current`, `--budget`, `--dry-run`, `--continue` or lots to launch. An answer whose lot is no longer waiting when the wave reads it (dropped, or already answered by an earlier line) is discarded and the journal says so (`réponse écartée`), it is never played twice; if the wave finishes between the check and the write, the answer is withdrawn and the command says to use `--resume`. Not covered: a lot that depends (`after`) on the answered lot and was left waiting in the pool is not started by this wave when the answer makes the lot ready; `--resume` plays it.
+
 **`--goal "…"` and `goal:` — the objective of the briefs when the title is stale (L258)**: the first line of the `{{objectif}}` of every
 brief of a lot (and the title quoted in their first sentence) is the lot's title; when a change of scope made it stale, the lead no longer
 has to delegate by hand. Three ways to give the goal, in this order of precedence (`--goal`, then the plan's key, then the title):
@@ -999,10 +1002,13 @@ main branch of any other repository**, whether the lot's text cites it or not: o
 `wip/<project>-<lot>` in that repository, commit on it, never push, and say it under « choix ».
 
 **What the program checks.** Before and after each writing session it reads, with no network (one `git for-each-ref` per repository, no `ls-remote`, no `fetch`),
-the sha of the main branches of the other repositories. The main branches of a repository are, among its local branches, the one `origin/HEAD` names, `main` and
+the sha of the main branches of the other repositories (the commits it reports are filtered, see below). The main branches of a repository are, among its local branches, the one `origin/HEAD` names, `main` and
 `master`; one that moves is enough. When one moved, the lot is handed back to the lead (`handed-back`, the step `failed`) before the checks and the next lot, with
 a finding: `incident : commit sur la branche principale d'un autre dépôt (<repository>, <branch>) pendant <project>:<lot> (<step>) : <short sha> <subject> ; la voie
-est la branche wip/<project>-<lot>`. The repository is marked dirty for the wave. A branch created or deleted during the session counts as a moved sha. The comparison
+est la branche wip/<project>-<lot>`. **Only a commit whose subject cites a lot of the wave is reported** (`feat(L1): chart cluster-sante`; the whole identifier counts, `L10` and `L1.2` do not cite `L1`; the
+body of the message is not read). Every other commit on that main branch passes: a delivery (the tag bump of a `deploy.sh` in a GitOps repository), a commit of the lead
+(`plan: …`), a commit of another wave, whenever it was launched, a commit that cites no lot. The rule needs no registry of the waves, so it holds
+for a wave started after the session began. The repository is marked dirty for the wave. A branch created or deleted during the session counts as a moved sha. The comparison
 is on the branch, not on `HEAD`: a commit made then left with `HEAD` elsewhere is found too. The program **does not undo the commit** (no reset, no revert, no move of
 the branch): it states and hands back, the lead decides. The check also runs when the session ends in failure, at the time limit or at the quota, not only on a
 successful one: otherwise the next attempt would take the moved sha as its reference and the commit would never be named.
@@ -1014,10 +1020,12 @@ That makes every sibling repository, cited by the lot or not.
 
 - the lot's own repository, and the neighbours declared by `repos:`: they keep their behaviour (the session commits on their current branch, a moved `HEAD` is put back
   with a warning, `raf commits` and the review read them as before);
-- the repositories of the **other lots of the same wave**, and their neighbours, and those of the lots of another wave **running at the same time** from the same launch folder
-  (its state says `running` and its process lives): their main branch moves legitimately through their own sessions and their integration;
-- the commits of the **lead** on a main branch: a commit whose subject starts with `plan: ` and that changes only the plan file (same relative path as the lot's) is left
-  out of the finding; any other commit is found, including a `plan: ` commit that touches another file (a GitOps delivery that changes a `values.yaml` is found);
+- the repositories of the **other lots of the same wave**, and their neighbours: their main branch moves legitimately through their own sessions and their integration, and
+  those commits cite the lots of the wave; likewise those of the lots of a wave **running at the same time** that the registry shows when the session starts (two projects
+  can both have a `L1`: the citation alone would take the other wave's commits for the lot's own). A wave launched later is not in that list: its commits pass because
+  they cite no lot of this wave;
+- the commits that **cite no lot of the wave** (see above): deliveries, the lead's `plan: ` commits, another wave's commits. A branch deleted, created or moved with no new
+  commit is still reported;
 - a repository two levels below the folder (`folder/group/repository`), a child that is not a git repository, and a **linked worktree** (a child whose `.git` is a file);
 - a symbolic link to a repository already counted (each repository is counted once, under its real path), and the folder itself when it is a git repository;
 - a repository whose references cannot be read, or that has no main branch before and after the session: it is skipped with a line of the wave's log

package/docs/session.md

@@ -24,7 +24,10 @@ cadence session context            # `ctx 42 % (84000/200000)`: the context of Y
                                    # `seuil 150000 tokens : sous le seuil` or `… : atteint` (tokens ≥ threshold)
 ```
 
-`lead.contextThreshold` is read in the `cadence.yaml` of the folder where `session context` runs (the lead's folder): an integer ≥ 1,
+`lead.contextThreshold` is read in the `cadence.yaml` of the lead's folder: the folder where `session context` runs, or else the first
+parent whose `cadence.yaml` carries a `lead:` or `priority:` key (run from a sub-project it no longer falls back on the default). When it
+is read in a parent, the verdict line names the file: `seuil 500000 tokens : sous le seuil (lu dans /…/cadence.yaml)`. With no such
+parent, the current folder and the default apply. The value is an integer ≥ 1,
 in tokens, because a percentage moves with the window (60 % is 120k on 200k, 600k on 1M). A zero, a negative, a decimal or
 a non-number is refused with the key's name (exit 2, read as at the threshold). It is not scaled to the window: on a window
 smaller than the threshold the verdict never reads `atteint`, so set a lower one there.

package/docs/whats-new.md

@@ -4,6 +4,7 @@
 
 ## In two lines
 
+- **1.30.0**: a question can be answered while its wave still runs; the sibling-repository check of 1.29.0 only flags commits that cite a lot of the wave; `session context` reads the lead's threshold from the lead's folder.
 - **1.29.0**: a wave session can no longer commit on the main branch of another repository than its lot's (the lot is handed back with the finding); `verify --gate` no longer links data folders into its throwaway copy.
 - **1.28.0**: projects are reordered from the lots panel or `cadence lead priority`; the lead's context threshold is in tokens; reviewers answer the lead in a few lines; the gate replays under plan commits when tests read the plan.
 - **1.27.0**: `cadence corrections --classify` names the sub-cause of each code-bug pass and the dominant link of the chain, `cadence perf` shows it; the mockup review checks hierarchy, tokens, texts and extra accessibility.
@@ -56,6 +57,8 @@ Each is a paragraph in [docs/whats-new.md](whats-new.md) and a full section in [
 
 The long form of « In two lines » above (the README no longer carries a « What's new » section since L326: it links here). The full history, with the date of each version, is in [CHANGELOG.md](../CHANGELOG.md).
 
+**1.30.0**: `cadence orchestrate --answer <project>:<lot> "…"` (or `--resume --wave <wave> --answer`) is accepted while the wave is still running (L407, `docs/orchestrate.md`): the answer goes into a queue the live wave reads, the lot takes a slot again under the wave's cap, plays in its own worktree when the mode is on, and never runs beside another session of the same repository; the registry counts it at once, so « créneaux libres » stays right. Before, the lead had to wait for the end of the wave. The check of 1.29.0 against commits on the main branch of a sibling repository (L456) now flags only the commits that cite a lot of the wave (L458): a delivery's tag bump in a GitOps repository, the lead's plan commits and the lots of another live wave launched later no longer hand a lot back — three false positives on 30-10. `cadence session context` reads `lead.contextThreshold` from the lead's folder, the first parent holding `lead:` or `priority:`, instead of the current folder (L457).
+
 **1.29.0**: two incidents of 30-10 turned into mechanisms. A writing session of a wave no longer commits on the main branch of a repository its lot does not declare (L456, `docs/orchestrate.md`): the brief forbids it and names the way, a branch `wip/<project>-<lot>`, and at the end of each session the program compares the main branches of the sibling repositories of the folder; a commit found there hands the lot back with the repository, the branch and the shas, and never moves or reverts anything — the lead moves the commits. Commits of the lead (subject `plan:`, plan file only) and commits of lots of another live wave of the folder are tolerated; repositories declared by the lot (`repos:`) keep their behaviour. The case was a session that committed a chart on the production branch of a GitOps repository. `cadence verify --gate` no longer links the ignored folders of the main tree that are not dependencies (`data/`, `data-local/`, `.env`) into its throwaway copy (L455, `docs/deliver.md`): a test comparing paths by `realpath` went red in the copy and green in the main tree at the same sha, and stopped a delivery.
 
 **1.28.0**: the lead spends less of its context, and the projects are ordered where they are read. `cadence lead priority <project> --before|--after <project>` rewrites the `priority:` list of the folder's `cadence.yaml`, comments kept, and the lots panel does the same by drag and drop or Alt+↑/↓ in a region « ordre des projets » above the tree (L449, `docs/lead.md`, `docs/cadence-hud.md`); a move it cannot write back faithfully (a name that prefixes another) is refused with its reason. The lead's context threshold is a number of tokens, `lead.contextThreshold` (150000 by default), read by `cadence session context` (L437). `ux-reviewer`, `doc-keeper` and the reviewers answer the lead in a few lines and keep the full report in the file named by `Report file:` (L452), and `raf` cuts the titles it echoes to 60 characters (L453). `orchestrate.gate.readsPlan` lets a project whose tests read the plan say so: `cadence verify --gate` then replays the suite under plan-only commits instead of taking over the wave's verdict (L450). A lot made `visible` by its own session during a wave now goes through the UX step instead of coming out ready without it (L454).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sylad/cadence",
-  "version": "1.29.0",
+  "version": "1.30.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",