@pmelab/gtd 38.2.0 → 40.0.0

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "gtd",
-  "version": "38.2.0",
+  "version": "40.0.0",
   "description": "Drive the gtd loop inside Claude Code: agent turns run as subagents, gtd decides every beat",
   "author": {
     "name": "Philipp Melab"

package/README.md

@@ -213,9 +213,10 @@ Label: Checking the baseline
 ```
 
 A green suite leaves the tree clean, so the process moves on to triage. A red
-suite instead writes `.gtd/FEEDBACK.md`, and the process goes to
-`start-gate.blocked` — same two commands, different outcome, decided entirely by
-what the beat left in the tree.
+suite instead writes `.gtd/FEEDBACK.md`; the process runs it once more at
+`start-gate.recheck`, and only a second red goes to `start-gate.blocked` — same
+two commands, different outcome, decided entirely by what the beat left in the
+tree.
 
 Land the green one, and the beat after it belongs to an agent.
 
@@ -418,10 +419,9 @@ phone UI does not show them).
 
 ### The workflow it ships with
 
-One built-in workflow drives all of that. From where you sit, it has three
+One built-in workflow drives all of that. From where you sit, it has four
 moments — everything between them runs without you, with the judged exceptions
-noted in step 3 below — plus a fourth, review, only on `refactor-first` or when
-you open the `review` door.
+noted in steps 3 and 4 below.
 
 1. **You sketch.** Change anything, or write the idea into `.gtd/TODO.md`. Rough
    is fine; it is treated as a sketch, not as work.
@@ -448,14 +448,12 @@ you open the `review` door.
    against the full suite (`testCommand`) and fixed until it passes — so keep
    that suite fast; gtd has no lighter one. Scenario wording is not frozen: a
    review's `## Scenarios` chunk marks any assertion an existing scenario lost
-   as `Weakened:` — **risk: `feature` has no review, so a build turn that
-   weakens a scenario reaches `idle` unflagged unless you open the `review`
-   door.** After the build the quality lap runs, and the process ends: the
-   feature workflow has no human review of the finished change. Two points along
-   the process (one with flag mode off) are judged rather than always asking you
-   outright — each stops and hands you a verdict to make (`gtd judge answer`, or
-   land with a clean tree to accept the conservative default, which never skips
-   work; `gtd judge run --provider fixed --answers <path>` — or the
+   as `Weakened:`, so you sign the scenarios off at step 4. After the build the
+   quality lap runs. Three points along the process (two with flag mode off) are
+   judged rather than always asking you outright — each stops and hands you a
+   verdict to make (`gtd judge answer`, or land with a clean tree to accept the
+   conservative default, which never skips work;
+   `gtd judge run --provider fixed --answers <path>` — or the
    `GTD_JUDGE_ANSWERS` env var, inline JSON — answers one from a file, piped
    between `gtd judge --json` and `gtd judge answer`;
    `gtd judge run --provider jev` asks TypeSafe's Jev instead, with the key in
@@ -473,6 +471,8 @@ you open the `review` door.
      or get rejected and retried?
    - Every red round after the first: was the failure identical, new, or
      progress?
+   - After you review: is each of your notes an edit, a question, a nit or
+     praise?
 
    gtd itself never calls a judge: `gtd loop`, the Claude Code mod and the
    reference driver answer these through `gtd judge run` (auto selection: jev
@@ -484,22 +484,20 @@ you open the `review` door.
    and skip a gate unattended.**
 
    Once the change is built, the whole change goes through a qualitative review
-   lap: six lenses, one turn each, in order — `correctness`, `owasp-security`,
-   `ponytail-review`, `test-audit`, `conventions`, `spec-challenge`.
-   `correctness`, `owasp-security` and `spec-challenge` run on the planner model
-   (`smart`), the other three on the coder model (`base`); a `qualityReviews`
-   entry `<lens>=<model>` picks a lens's own. Each traces the change from its
-   own angle and records every finding, blocking or not; one fix turn then fixes
-   ALL of them once, with no re-review after the fix. A clean turn means
-   approval only when that lens found nothing at all. This lap is where code
-   quality is looked at, and every round pays for it. It is the last look the
-   feature workflow takes: the process ends at `idle` once it is clean (and the
-   suite green), with no review rest — **risk: nothing re-reads the code the
-   single fix turn writes; only the suite gates it.** Findings the fix cap
-   leaves in `.gtd/QUALITY.md` rest at `build.quality-unresolved` until you
-   delete or empty the file; the suite then runs on any hand edits. **Nobody
-   signs the finished change off unless you open the `review` door** (below).
-   The `fix` door repairs a red baseline through this same lap.
+   lap before you see anything: six lenses, one turn each, in order —
+   `correctness`, `owasp-security`, `ponytail-review`, `test-audit`,
+   `conventions`, `spec-challenge`. `correctness`, `owasp-security` and
+   `spec-challenge` run on the planner model (`smart`), the other three on the
+   coder model (`base`); a `qualityReviews` entry `<lens>=<model>` picks a
+   lens's own. Each traces the change from its own angle and records every
+   finding, blocking or not; one fix turn then fixes ALL of them once, with no
+   re-review after the fix. A clean turn means approval only when that lens
+   found nothing at all. This lap is where code quality is looked at, and every
+   round pays for it. It never replaces step 4 — your review stays the final
+   gate, and nothing here skips it. Findings the fix cap leaves in
+   `.gtd/QUALITY.md` rest at `build.quality-unresolved` until you delete or
+   empty the file; the suite then runs on any hand edits before the review. The
+   `fix` door (below) repairs a red baseline through this same lap.
 
    A red suite that keeps failing past a few fix attempts escalates instead of
    retrying forever: an agent turn reads the failing output and writes
@@ -508,30 +506,35 @@ you open the `review` door.
    as-is, handing that document to the next fix turn as its instruction. Two
    such rounds with no fix is the terminal stop: the last analysis stays on disk
    instead of a third being written, and editing it is what gets the next
-   attempt anywhere new.
-
-4. **You review — the refactor, or on request.** The feature workflow asks for
-   one review only on `refactor-first`: of the refactor slice, before the
-   feature is built (see [the naive pass](#the-naive-pass)). For the finished
-   change run `gtd door review <commitish>` (`/gtd review [base]`); that review
-   hands notes to `fix` instead of re-planning (below). Either way you get a
-   review document listing what changed and what to look at. Before you see it,
+   attempt anywhere new. Before any escalation or red-baseline stop the suite
+   runs once more; a pass there continues without you and is recorded as
+   `Gtd-Mark: flaky=<check>` (see
+   [Re-check before a person](docs/configuration.md#re-check-before-a-person)).
+
+4. **You review.** After the last slice's quality lap you get a review document
+   over the whole change, listing what changed and what to look at (on
+   `refactor-first` the refactor slice gets one of its own first, before the
+   feature is built; see [the naive pass](#the-naive-pass)). Before you see it,
    an automatic risk-fix pass (`build.review.fix.risks.fixing`) runs. Any risk
    the reviewer names (a note opening with `Risk:`) is fixed first, the suite
    kept green, and the review rewritten — once per review round, so a risk the
    rewrite still names reaches you unfixed; risk: a fix lands with no check that
-   the risk was real. Tick the boxes to approve, or write what is wrong. At the
-   refactor review, approving moves on to the feature; feedback is judged note
-   by note (a third judged point), each as `edit`, `question`, `nit` or
-   `praise`. An `edit` re-derives the refactor (in a custom workflow built on
-   `buildTail`, it sends the process back to step 2 for re-derived
-   requirements). A `question` is answered inline under your note and the
-   process stops at the review again — no new plan. A `nit` is fixed in one
-   batch, the suite must go green (a red one gets fix turns first), then a fresh
-   review of the change stops at the review again. `praise` is dropped; a round
-   of only praise signs off. When a round mixes them, questions are answered and
-   nits fixed first, then the edits are planned — risk: the planning lap may
-   redo nit fixes it touches.
+   the risk was real. Tick the boxes to approve, or write what is wrong.
+   Approving ends the process (at the refactor review, it moves on to the
+   feature); feedback is judged note by note, each as `edit`, `question`, `nit`
+   or `praise`. An `edit` sends the process back to step 2 for re-derived
+   requirements — the built criteria keep their IDs (reworded in place when
+   their behaviour changes) and new behaviour gets new ones — then the
+   implementation is amended to meet them, with no new naive pass or seam judge,
+   every criterion's coverage is judged again, the quality lap runs, and you
+   review again. At the refactor review an `edit` re-derives the refactor
+   instead. A `question` is answered inline under your note and the process
+   stops at the review again — no new plan. A `nit` is fixed in one batch, the
+   suite must go green (a red one gets fix turns first), then a fresh review of
+   the change stops at the review again. `praise` is dropped; a round of only
+   praise signs off. When a round mixes them, questions are answered and nits
+   fixed first, then the edits are planned — risk: the planning lap may redo nit
+   fixes it touches.
 
    Each `edit` note also gets a severity tier from four judge questions
    (security, reversibility, blast radius, new concept). `critical` and `should`
@@ -551,7 +554,7 @@ you open the `review` door.
 You never talk to it. Every exchange is a file in `.gtd/` that you edit in your
 own editor, and every answer you give is a commit. Your test suite is the gate
 throughout: a red baseline stops the process before it starts, and a red build
-is fixed before the process ends.
+is fixed before review.
 
 Prefer a phone or another device over your editor? `gtd ui` opens the file whose
 turn it is as a small web app, over Tailscale — including a step that names no
@@ -631,14 +634,15 @@ criterion ID the naive pass's tests named, and the suite must be green with
 them. A wrong approach is retried twice, then rests for you to steer or overrule
 it. `gtd slices` lists the `refactor` and `feature` slices. A refactor that
 already carried the whole feature leaves the rebuild only the carried-over
-tests, and the feature's quality lap covers the whole change. Once the
+tests, and the feature's quality lap and review cover the whole change. Once the
 implementation is green, a judge checks every criterion ID has a covering test:
 an uncovered one goes back to the agent (twice, then to you) instead of ending
 the feature, and each covered ID is recorded as a `Gtd-Mark: covers=<id>`
 trailer. See
 [Acceptance-criteria coverage](docs/configuration.md#acceptance-criteria-coverage).
-Feedback at the refactor review re-runs the refactor, never design; a
-refactor-review change the refactor cannot build is refused, and the only way
+Feedback at the feature review re-runs design and the implementation, never the
+naive pass; feedback at the refactor review re-runs the refactor, never design;
+a refactor-review change the refactor cannot build is refused, and the only way
 out is `gtd abandon`. A process from 27.5.0 or later whose judge ruled
 `refactor-first` must `gtd abandon` too. Each slice's quality lap reviews only
 that slice. Details in
@@ -648,10 +652,11 @@ that slice. Details in
 criteria than the cap is built in slices: after design an agent groups related
 criteria (same flow or subsystem) into `.gtd/SLICES.md`, as few slices as the
 cap allows, and each slice — naive pass, refactor and rebuild when judged so,
-health loop, quality lap — runs in order from where the previous one landed.
-`gtd slices` lists them as `feature-1`, `feature-2`, … (`refactor-<n>` ahead of
-a refactored one). A change within the cap is one `feature` slice, as before.
-See [Coarse slices](docs/configuration.md#coarse-slices).
+health loop, quality lap — runs in order from where the previous one landed; the
+review follows the last one and covers the whole change. `gtd slices` lists them
+as `feature-1`, `feature-2`, … (`refactor-<n>` ahead of a refactored one). A
+change within the cap is one `feature` slice, as before. See
+[Coarse slices](docs/configuration.md#coarse-slices).
 
 **Flag mode (`flagMode`, on by default).** On, the naive pass's judge runs as
 above and a rebuilt implementation is asked for a new release flag (none at a
@@ -745,6 +750,9 @@ it never replays and a config changed since is no refusal:
 - **findings** — the net count of `## ` findings each quality-lap lens added to
   `.gtd/QUALITY.md`, keyed by the lap's lens path (`build.quality.correctness`,
   `refactor.build.quality.correctness`, …)
+- **flaky** — red checks that passed on their re-check (`Gtd-Mark: flaky=…`),
+  keyed by the re-check's full step name (`start-gate.recheck`,
+  `build.health.recheck`, …)
 
 `--json` prints `{ processes, total }`; `--json=total.refactorFirstRate` prints
 one value. Model, phase and lens keys may hold dots a path cannot reach: select

package/dist/chunks/{reserved-C3PgP7XB.mjs → reserved-Qt5FM6Ia.mjs}

@@ -1,4 +1,4 @@
-import { accessFor, agent, answered, changesSince, check, codeThreads, defineWorkflow, displayPath, env, head, human, judge, numeric, quote, read, refuse, scope, skillsFor, start, vars } from "../flows.mjs";
+import { accessFor, agent, answered, changesSince, check, codeThreads, defineWorkflow, displayPath, env, head, human, judge, mark, numeric, quote, read, refuse, scope, skillsFor, start, vars } from "../flows.mjs";
 import { escalation as escalation$1, gate as gate$1, healthy as healthy$1, lensScopes, lensesOf, removedAssertions } from "../workflow-kit.mjs";
 import { c as String$, g as standardSchemaV1, h as optionalWith, l as Struct, n as Boolean$, s as Number$ } from "./Schema-C6fLlQzx.mjs";
 //#region src/workflows/shared/registry.ts
@@ -421,14 +421,14 @@ What each change does next (then run \`gtd land\`):
 - **Continue** — having undone the sketch by hand, check the test baseline is green and start triage (**start-gate.check**).
 `;
 const qualityUnresolvedMessage = () => `The quality lap's fix turns hit their cap and \`.gtd/QUALITY.md\` still
-holds findings. Nothing reviews the change after this, so the process
-will not end with them open.
+holds findings. Nothing after this fixes them, so the process will not
+go on with them open.
 
 Fix what matters by hand, then delete or empty \`.gtd/QUALITY.md\` —
 dropping a finding is your call to make.
 
 What each change does next (then run \`gtd land\`):
-- **Delete or empty \`.gtd/QUALITY.md\`** — the suite runs on your edits, then the process ends (**idle**).
+- **Delete or empty \`.gtd/QUALITY.md\`** — the suite runs on your edits, then the next slice is built, or after the last one you review the change (**build.review.reviewing**).
 - **Anything else** — rests here again.
 `;
 const startGateBlockedMessage = () => `The test baseline is red — gtd will not start new work on a broken suite.
@@ -466,8 +466,10 @@ reword a criterion in place, append a new one with the next unused
 number, delete a dropped one — never renumber, never reuse an ID. When
 the file holds no list (a review loop-back rewrites it), recover the
 last settled one from history (\`git log -p -- .gtd/REQUIREMENTS.md\`)
-and carry its IDs over. Landing is refused while a criterion has no ID or
-two share one.
+and carry its IDs over: after a review a built criterion keeps its ID,
+reworded in place when the review changes its behaviour, and new
+behaviour gets a new ID. Landing is refused while a criterion has no ID
+or two share one.
 `;
 const riskTierBlock = `
 ## Risk tier and production signals
@@ -1580,6 +1582,19 @@ const baseline = (name, label = "Checking the baseline") => check(name, env.test
 	report: FEEDBACK,
 	label
 });
+/**
+* Re-run a red check as step `name` before a person sees it. Green records
+* `Gtd-Mark: flaky=<red>` on the re-check's landing and resolves `true`.
+*/
+const recheck = async (name, red, options = {}) => {
+	const green = await check(name, env.testCommand ?? "", {
+		...options,
+		report: FEEDBACK,
+		label: "Re-running checks"
+	});
+	if (green) mark("flaky", red);
+	return green;
+};
 const escalationSteps = (rules) => ({
 	limit: 2,
 	describe: () => describeEscalation(rules),
@@ -1630,15 +1645,17 @@ const sameFailure = async (previous, current) => {
 	});
 	return comparable && truncated.length === 0 && answered(answers.verdict, "identical", numeric(vars.judgeIdenticalMinP, Infinity));
 };
+const healthSweep = (options) => [ESCALATION, ...options.sweepOnGreen ?? []];
 const runSuite = (options) => check("health.check", env.testCommand ?? "", {
 	report: FEEDBACK,
 	label: "Running checks",
-	sweepOnGreen: [ESCALATION, ...options.sweepOnGreen ?? []]
+	sweepOnGreen: healthSweep(options)
 });
 /**
 * Loop until the suite is green: check, and on red run `fix` — escalating
 * first once `FIX_CAP` fixes are spent, or a judge calls the failure
-* identical to the previous round's.
+* identical to the previous round's. An escalation re-runs the suite once
+* first; a green re-run ends the loop.
 */
 const healthy = (fix, options = {}) => healthy$1(guarded(fix, options.guard), {
 	check: () => runSuite(options),
@@ -1647,14 +1664,16 @@ const healthy = (fix, options = {}) => healthy$1(guarded(fix, options.guard), {
 	fixesSoFar: options.fixesSoFar ?? 0,
 	sameFailure,
 	escalations: options.escalations ?? { rounds: 0 },
+	recheck: () => recheck("health.recheck", "health.check", { sweepOnGreen: healthSweep(options) }),
 	escalation: guardedSteps(options.guard, options.describeGuard, options.guardRests, options.rules)
 });
 /**
-* Hold the process at `<name>.blocked` until the suite is green. `guard` runs
+* Hold the process at `<name>.blocked` until the suite is green, re-running a
+* red check once as `<name>.recheck` before resting. `guard` runs
 * after each `blocked` landing only — never after a check, whose refusal would
 * re-run the same script forever.
 */
-const gate = (name, message, guard) => gate$1(name, () => baseline("check"), guarded(() => human("blocked", {
+const gate = (name, message, guard) => gate$1(name, async () => await baseline("check") || recheck("recheck", `${name}.check`), guarded(() => human("blocked", {
 	message,
 	label: "Baseline is red",
 	file: FEEDBACK

package/dist/chunks/{tail-Bkxki2nK.mjs → tail-tAHx_AHe.mjs}

@@ -1,6 +1,6 @@
 import { read, refuse, removeScript, run, scope, showScript, vars } from "../flows.mjs";
 import { fixFindings, lensEntriesOf, lensOf, qualityLap as qualityLap$1, reviewToHandOff } from "../workflow-kit.mjs";
-import { C as fixCheck, D as reviewMissing, O as reviewQuality, T as fixRisks, Y as handOffAwaitReviewMessage, d as guarded, f as healthy, h as QUALITY, k as reviewing, l as escalation, w as fixQuality, x as awaitReview, y as REVIEW } from "./reserved-C3PgP7XB.mjs";
+import { C as fixCheck, D as reviewMissing, O as reviewQuality, T as fixRisks, Y as handOffAwaitReviewMessage, d as guarded, f as healthy, h as QUALITY, k as reviewing, l as escalation, w as fixQuality, x as awaitReview, y as REVIEW } from "./reserved-Qt5FM6Ia.mjs";
 //#region src/workflows/shared/tail.ts
 /** The reviewer's own `.gtd/REVIEW.md`, kept beside the human's notes so `fix` can tell them apart. */
 const REVIEW_ORIG = ".gtd/REVIEW.orig.md";

package/dist/gtd.bundle.mjs

@@ -41406,7 +41406,8 @@ const emptyTally = () => ({
 		naive: 0,
 		rebuild: 0
 	},
-	byLens: record()
+	byLens: record(),
+	flaky: record()
 });
 const sum = (record) => Object.values(record).reduce((a, b) => a + b, 0);
 const finish = (t) => ({
@@ -41426,6 +41427,10 @@ const finish = (t) => ({
 	findings: {
 		total: sum(t.byLens),
 		byLens: t.byLens
+	},
+	flaky: {
+		total: sum(t.flaky),
+		byStep: t.flaky
 	}
 });
 const tallyCost = (t, open, costs, phase) => {
@@ -41482,6 +41487,7 @@ const processMetrics = (commits) => {
 		if (subject.actor === "agent" && CONTINUE.test(at)) add(t.continuations, at.replace(CONTINUE, "$1"), 1);
 		const lens = LENS.exec(at)?.[1];
 		if (lens !== void 0 && commit.findings > 0) add(t.byLens, lens, commit.findings);
+		if (message.marks.some((m) => m.name === "flaky")) add(t.flaky, at, 1);
 		tallyDecision(t, open, at, subject.to);
 	}
 	return finish(t);
@@ -41496,6 +41502,7 @@ const totalMetrics = (all) => {
 		t.doubleWork.naive += m.cost.doubleWork.naive;
 		t.doubleWork.rebuild += m.cost.doubleWork.rebuild;
 		for (const [k, v] of Object.entries(m.findings.byLens)) add(t.byLens, k, v);
+		for (const [k, v] of Object.entries(m.flaky.byStep)) add(t.flaky, k, v);
 	}
 	return {
 		processes: all.length,
@@ -41533,7 +41540,8 @@ const line = (label, m) => {
 		`${label}: ${slices.decided} slices, ${slices.rebuilt} rebuilt (refactor-first ${percent}), ${slices.refactored} refactored`,
 		`${continued} continuations${continued > 0 ? ` (${listed(m.continuations)})` : ""}`,
 		`cost ${cost.total} (${listed(cost.byPhase)}; by model ${listed(cost.byModel) || "-"}), double work ${cost.doubleWork.total}`,
-		`${m.findings.total} findings${m.findings.total > 0 ? ` (${listed(m.findings.byLens)})` : ""}`
+		`${m.findings.total} findings${m.findings.total > 0 ? ` (${listed(m.findings.byLens)})` : ""}`,
+		`${m.flaky.total} flaky${m.flaky.total > 0 ? ` (${listed(m.flaky.byStep)})` : ""}`
 	].join("; ");
 };
 const runHistoryMetricsCommand = (refs, json, out) => gen(function* () {
@@ -42943,9 +42951,10 @@ const COMMAND_ROWS = [
 			"Report how the kept processes went: slices whose naive pass",
 			"landed or was rebuilt (the refactor-first rate), continuations",
 			"per phase, Gtd-Cost by model and phase with the double work of",
-			"a rebuild, and quality-lap findings per lens — per process and",
-			"in total. Each <ref> is read as by history show, but a branch",
-			"name means every process kept from it; none means every ref.",
+			"a rebuild, quality-lap findings per lens, and red checks that",
+			"passed on their re-check — per process and in total. Each <ref>",
+			"is read as by history show, but a branch name means every",
+			"process kept from it; none means every ref.",
 			"Reads commit subjects and trailers, never replays, so a",
 			"changed config is no refusal. --json prints { processes, total",
 			"} as one document; writes nothing"

package/dist/testkit.mjs

@@ -10327,7 +10327,8 @@ const emptyTally = () => ({
 		naive: 0,
 		rebuild: 0
 	},
-	byLens: record()
+	byLens: record(),
+	flaky: record()
 });
 const sum = (record) => Object.values(record).reduce((a, b) => a + b, 0);
 const finish = (t) => ({
@@ -10347,6 +10348,10 @@ const finish = (t) => ({
 	findings: {
 		total: sum(t.byLens),
 		byLens: t.byLens
+	},
+	flaky: {
+		total: sum(t.flaky),
+		byStep: t.flaky
 	}
 });
 const tallyCost = (t, open, costs, phase) => {
@@ -10403,6 +10408,7 @@ const processMetrics = (commits) => {
 		if (subject.actor === "agent" && CONTINUE.test(at)) add(t.continuations, at.replace(CONTINUE, "$1"), 1);
 		const lens = LENS.exec(at)?.[1];
 		if (lens !== void 0 && commit.findings > 0) add(t.byLens, lens, commit.findings);
+		if (message.marks.some((m) => m.name === "flaky")) add(t.flaky, at, 1);
 		tallyDecision(t, open, at, subject.to);
 	}
 	return finish(t);
@@ -10417,6 +10423,7 @@ const totalMetrics = (all) => {
 		t.doubleWork.naive += m.cost.doubleWork.naive;
 		t.doubleWork.rebuild += m.cost.doubleWork.rebuild;
 		for (const [k, v] of Object.entries(m.findings.byLens)) add(t.byLens, k, v);
+		for (const [k, v] of Object.entries(m.flaky.byStep)) add(t.flaky, k, v);
 	}
 	return {
 		processes: all.length,
@@ -10454,7 +10461,8 @@ const line = (label, m) => {
 		`${label}: ${slices.decided} slices, ${slices.rebuilt} rebuilt (refactor-first ${percent}), ${slices.refactored} refactored`,
 		`${continued} continuations${continued > 0 ? ` (${listed(m.continuations)})` : ""}`,
 		`cost ${cost.total} (${listed(cost.byPhase)}; by model ${listed(cost.byModel) || "-"}), double work ${cost.doubleWork.total}`,
-		`${m.findings.total} findings${m.findings.total > 0 ? ` (${listed(m.findings.byLens)})` : ""}`
+		`${m.findings.total} findings${m.findings.total > 0 ? ` (${listed(m.findings.byLens)})` : ""}`,
+		`${m.flaky.total} flaky${m.flaky.total > 0 ? ` (${listed(m.flaky.byStep)})` : ""}`
 	].join("; ");
 };
 const runHistoryMetricsCommand = (refs, json, out) => gen(function* () {
@@ -11855,9 +11863,10 @@ const COMMAND_ROWS = [
 			"Report how the kept processes went: slices whose naive pass",
 			"landed or was rebuilt (the refactor-first rate), continuations",
 			"per phase, Gtd-Cost by model and phase with the double work of",
-			"a rebuild, and quality-lap findings per lens — per process and",
-			"in total. Each <ref> is read as by history show, but a branch",
-			"name means every process kept from it; none means every ref.",
+			"a rebuild, quality-lap findings per lens, and red checks that",
+			"passed on their re-check — per process and in total. Each <ref>",
+			"is read as by history show, but a branch name means every",
+			"process kept from it; none means every ref.",
 			"Reads commit subjects and trailers, never replays, so a",
 			"changed config is no refusal. --json prints { processes, total",
 			"} as one document; writes nothing"

package/dist/workflow-kit.mjs

@@ -17,10 +17,15 @@ const untilSettled = async (check, pending) => {
 };
 const STAMP = /\n<!-- gtd check [0-9a-f]+ -->\n?$/;
 const stripStamp = (text) => text.replace(STAMP, "\n");
+/** `true` when the re-check passed, else the red re-check's report — the one the escalation describes. */
+const recheckReport = async (health) => {
+	if (health.recheck === void 0) return void 0;
+	return await health.recheck() || stripStamp(read(health.report) ?? "");
+};
 /**
 * Loop until the suite is green: check, and on red run `fix` — escalating
 * first once `fixCap` fixes are spent, or `sameFailure` calls the failure
-* identical to the previous round's.
+* identical to the previous round's, unless `recheck` passes.
 */
 const healthy = async (fix, health) => {
 	let fixes = health.fixesSoFar ?? 0;
@@ -34,6 +39,12 @@ const healthy = async (fix, health) => {
 		const stuck = previous !== void 0 && await health.sameFailure(previous, current);
 		previous = current;
 		if (stuck || fixes >= health.fixCap) {
+			const rechecked = await recheckReport(health);
+			if (rechecked === true) {
+				health.escalations.rounds = 0;
+				return;
+			}
+			previous = rechecked ?? previous;
 			await escalation(health.escalations, health.escalation);
 			fixes = 0;
 		}

package/dist/workflows/cleanup.mjs

@@ -1,6 +1,6 @@
 import { agent, changes, glob, read, refuse, scope, start, vars } from "../flows.mjs";
-import { Dt as registryEntry, Ot as requireFlag, S as coder, St as envDefaults, Tt as flagReferences, i as skills, n as summary, o as flagShipped, r as access, t as steering, xt as defaults } from "../chunks/reserved-C3PgP7XB.mjs";
-import { a as refusePendingHandOff, r as handOffTail } from "../chunks/tail-Bkxki2nK.mjs";
+import { Dt as registryEntry, Ot as requireFlag, S as coder, St as envDefaults, Tt as flagReferences, i as skills, n as summary, o as flagShipped, r as access, t as steering, xt as defaults } from "../chunks/reserved-Qt5FM6Ia.mjs";
+import { a as refusePendingHandOff, r as handOffTail } from "../chunks/tail-tAHx_AHe.mjs";
 //#region src/workflows/cleanup/cleanup.ts
 const removingPrompt = (name, registry) => `Clean up the release flag "${name}", which is default-on: delete its entry in ${registry}, and remove every \`GTD_FLAG_${name.toUpperCase()}\` check from the shipped sources. Keep the flag-on path; delete code only the off path reached, including tests that pin the off path.`;
 const cleanupFlow = async () => {