@mjasnikovs/pi-task 0.38.28 → 0.38.30

package/dist/task/render-check.js

@@ -1,14 +1,12 @@
 /**
  * render-check — one headless-browser page load against the booted app's live
- * listener, judging whether the client actually RENDERED anything (mx5 runs 8 and
- * 11).
+ * listener, judging whether the client actually RENDERED anything.
  *
- * The failure class: every "renders without runtime errors" check in the pipeline
- * was curl — and curl cannot execute JavaScript. Run 8 shipped an app whose ESM
- * bundle was loaded in a classic script tag: HTTP 200 on every route, permanently
- * BLANK page, all gates green. Run 11 shipped a router with no <Switch> (the 404
- * fallback rendered on every page) — invisible to every gate for the same reason.
- * The gate's boot check proves a LISTENER exists (run 10); this proves the
+ * The failure class: every other "renders without runtime errors" check in the
+ * pipeline is curl-shaped (boot-probe.ts says so at its own call site), and curl
+ * cannot execute JavaScript. An app whose client bundle throws on load answers
+ * HTTP 200 on every route and shows a permanently BLANK page, with every such
+ * check green. The gate's boot check proves a LISTENER exists; this proves the
  * listener serves a page whose client code MOUNTS something.
  *
  * Mechanism, deterministic and dependency-free: discover a Chrome-family binary
@@ -16,9 +14,9 @@
  * only found), load the page once with `--headless --dump-dom` (which executes the
  * page's JS under a virtual-time budget), and judge the RENDERED body: it must
  * contain visible text or concrete visual/interactive elements. A blank mount
- * point after JS ran is the run-8 class — FAIL with the body's shape. What it
- * deliberately does NOT judge: correctness of what rendered (run 11's 404-below-
- * login needs app knowledge no generic gate has).
+ * point after JS ran is the class — FAIL with the body's shape. What it
+ * deliberately does NOT judge: whether what rendered is CORRECT. That needs app
+ * knowledge no generic gate has.
  *
  * Env-gap contract as everywhere: no browser found, a browser that cannot launch,
  * or a dump that produced nothing → SKIP with a note (the caller surfaces it as
@@ -46,12 +44,10 @@ function onPath(bin) {
 }
 /**
  * The newest Playwright-cache Chromium, if any — the HEADLESS SHELL preferred over
- * the full build. Found, never installed: the cache exists on any box that ever ran
- * Playwright browsers (the mx5-class projects install it as their own test
- * dependency). The headless shell is purpose-built for `--dump-dom` and returns
- * promptly on a network URL where the full system chromium can stall under a
- * virtual-time budget (validated live on this box: shell exits 0 in ~1s, full
- * chromium times out at 30s on the same http:// URL).
+ * the full build. Found, never installed: the cache exists on any box that ever
+ * ran Playwright browsers, which many projects install as a test dependency. The
+ * headless shell is preferred because it is purpose-built for exactly this — one
+ * `--dump-dom` and exit — with no browser UI to bring up.
  */
 export function playwrightCachedChromium() {
     const cache = process.env.PLAYWRIGHT_BROWSERS_PATH
@@ -146,17 +142,17 @@ export function judgeRenderedDom(html) {
 const RENDER_TIMEOUT_MS = 30_000;
 const VIRTUAL_TIME_BUDGET_MS = 8_000;
 /**
- * A Chrome console line on stderr:
+ * A Chrome console line on stderr, as chrome-headless-shell writes it:
  *
- *     [11506:11506:0814/090315.702981:INFO:CONSOLE:322] "Uncaught ReferenceError:
- *         process is not defined", source: http://localhost:8791/main.js (322)
+ *     [0830/084427.287122:INFO:CONSOLE:1] "Uncaught ReferenceError: process is
+ *         not defined", source: http://127.0.0.1:8791/boom.html (1)
  *
- * Only the severity and the message survive. The bracketed pid/tid/timestamp
- * prefix is DROPPED on purpose: it changes every run, and the failure detail is
- * the string `normalizeFailureDetail` compares across autofix attempts. A volatile
- * prefix in there would make two runs of the SAME defect look different, which is
- * a change to the non-progress classifier's behaviour — and 19B may not change any
- * verdict, only explain one.
+ * Only the severity and the message survive. The bracketed timestamp prefix — some
+ * builds prepend a pid/tid pair too, which is why the prefix is matched loosely —
+ * is DROPPED on purpose: it changes every run, and the failure detail is the string
+ * `normalizeFailureDetail` (final-gate-progress.ts) compares across autofix
+ * attempts. A volatile prefix in there would make two runs of the SAME defect look
+ * different, silently changing the non-progress classifier's behaviour.
  */
 const CONSOLE_LINE_RE = /^\[[^\]]*:(INFO|WARNING|ERROR|VERBOSE\d*):CONSOLE:\d*\]\s*(.*)$/;
 /** At most this many console lines ride along; the whole block is clamped again. */
@@ -164,17 +160,10 @@ const MAX_CONSOLE_LINES = 12;
 /**
  * The page's console output, as captured while the DOM was being rendered.
  *
- * MEASURED on this box (2026-08-14) against the shipped mx5 run-21 bundle, both
- * binaries the probe can discover:
- *
- *     /usr/bin/chromium              --dump-dom alone → 0 bytes of stderr
- *                                    + --enable-logging=stderr --v=0 → 2 CONSOLE
- *                                      lines, one of them the cause
- *     playwright chrome-headless-shell
- *                                    → the 2 CONSOLE lines either way
- *
- * and in ALL FOUR arms stdout was byte-identical at 318 bytes, so the DOM the
- * judge reads is untouched by the flags.
+ * `--enable-logging=stderr --v=0` is what routes the page's console to stderr.
+ * The DOM the judge reads is untouched by those flags: with and without them,
+ * `--dump-dom` writes byte-identical stdout on both binaries this probe can
+ * discover.
  */
 export function parseConsoleLines(stderr) {
     const out = [];
@@ -196,11 +185,9 @@ export function parseConsoleLines(stderr) {
 /**
  * Append the console output to a FAIL detail — and to nothing else.
  *
- * WHY (nexttask 19B; the class 18A opened for repo-health). Run 21's fix child was
- * told "the body is EMPTY" and nothing more. It spent 45 minutes on tests, bundler
- * config and static serving, read the offending line twice, and moved on. The
- * probe was holding the answer the whole time: `Uncaught ReferenceError: process
- * is not defined`, at main.js:322.
+ * Without it the fix child is told "the body is EMPTY" and nothing more, while the
+ * probe was holding the cause the whole time: the page's own
+ * `Uncaught ReferenceError`, with the source file and line Chrome already printed.
  *
  * Strictly additive by construction: it takes an existing FAIL detail and returns
  * it with text appended. It cannot turn a PASS into a FAIL, cannot reach
@@ -232,9 +219,9 @@ export function runRenderCheck(url, browser) {
         '--no-sandbox',
         '--disable-dev-shm-usage',
         `--virtual-time-budget=${VIRTUAL_TIME_BUDGET_MS}`,
-        // Route the page's console to stderr (nexttask 19B). stdout — the DOM
-        // the judge reads — is byte-identical with and without these; measured
-        // on both discoverable binaries, see withConsoleEvidence.
+        // Route the page's console to stderr. stdout — the DOM the judge
+        // reads — is byte-identical with and without these; see
+        // parseConsoleLines.
         '--enable-logging=stderr',
         '--v=0',
         '--dump-dom',
@@ -255,7 +242,7 @@ export function runRenderCheck(url, browser) {
     }
     const judged = judgeRenderedDom(dom);
     // The verdict is the judge's, unchanged. Only a FAIL grows: it carries the
-    // console output the probe already had at the moment it judged (19B).
+    // console output the probe already had at the moment it judged.
     return judged.ok ?
         { outcome: 'pass', detail: judged.detail }
         : { outcome: 'fail', detail: withConsoleEvidence(judged.detail, r.stderr ?? '') };

package/dist/task/repo-health-check.d.ts

@@ -9,11 +9,10 @@ export interface HealthOutcome {
     ecosystem: string | null;
     /**
      * First lines of the failing command's combined stderr+stdout — captured so a
-     * FAIL is explainable from artifacts alone. Run-8 F8: five enforce passes were
-     * discarded on "`bun run lint` exited 2" and the cause was unreproducible
-     * post-run because only the exit code was recorded (exit 2 is the linter's
-     * CRASH class; findings exit 1 — the captured output is what tells them apart).
-     * Empty string on pass / skip.
+     * FAIL is explainable from artifacts alone. The exit code alone does not say
+     * what happened: eslint exits 1 for findings and 2 when it could not run at
+     * all (a missing config, say), so "`bun run lint` exited 2" is unreproducible
+     * after the fact unless the output was kept. Empty string on pass / skip.
      */
     output: string;
 }
@@ -41,17 +40,14 @@ export type HealthProgress = (command: string) => void;
  *    treated as an environment gap, not a fault.
  *  - A command that ran and exited non-zero → the first such failure is returned.
  *
- * This module owns DISCOVERY and its own output policy; running a command and
- * deciding what its ending MEANS is `command-run.ts`'s. It used to own those too —
- * `HealthRun`, `classifyHealthRun` and `spawnHealthCommand` were a second statement
- * of the gap ladder, with no injectable runner, so every classification case in the
- * suite spawned a real shell. `command-run.ts`'s own header notes that this module
- * "had solved exactly this shape years earlier" and the gate never adopted it; this
- * is the adoption, in the other direction.
+ * This module owns DISCOVERY and its own output policy. Running a command and
+ * deciding what its ending MEANS is `command-run.ts`'s — one statement of the
+ * env-gap ladder, with an injectable runner, so a classification case needs no
+ * real shell.
  *
  * `captureHealthOutput` stays this module's own: 40 lines of a linter's report is a
- * real difference from `outputTail`'s 400 characters, and that is a parameter, not a
- * thing to unify.
+ * real difference from `outputTail`'s 400-character default, and that is a
+ * parameter, not a thing to unify.
  *
  * `onCommand` lets the caller name the running command in a live status line — the
  * gate runs this immediately after the implementation turn ends, when the impl

package/dist/task/repo-health-check.js

@@ -1,27 +1,24 @@
 /**
  * repo-health-check — the deterministic, whole-repo half of the verify gate.
  *
- * The failure this closes (proven on the mx5 run): the verify gate ran only the
- * task's OWN composed VERIFY block, and that block is authored per-task by the local
- * model — so it is inconsistent. Some tasks lint the whole repo, some (TASK_0021)
- * ship a VERIFY of `tsc --noEmit` ONLY, with no lint at all. A/B on the live model,
- * 5 runs/arm on the real dirty tree: the tsc-only task false-PASSed 5/5 while
- * `bun run lint` reported 11 errors. The model gate is only ever as good as the
+ * The failure this closes: the task's own composed VERIFY block is authored
+ * per-task by a model, so what it covers varies. One task lints the whole repo;
+ * the next ships a VERIFY of `tsc --noEmit` and no lint at all, and a lint-only
+ * regression then passes its gate. The model gate is only ever as good as the
  * VERIFY block it happened to be handed.
  *
  * This check does NOT depend on that block. It discovers the project's OWN
  * whole-repo static-analysis command (the one a fresh checkout / CI would run) and
  * lets its REAL exit code decide — no model, so there is no per-file narrowing and
- * no "those errors aren't in my files" gray area. A non-zero exit is a FAIL that the
- * caller turns into the existing verify-FAIL outcome (→ the AUTOFIX / ACCEPT /
- * dismiss picker; the user decides).
+ * no "those errors aren't in my files" gray area. A non-zero exit becomes the
+ * verify gate's `repo-health` FAIL (verify-work.ts), which reaches the
+ * AUTOFIX / ACCEPT picker in verify-resolution.ts.
  *
  * Scope is deliberately STATIC ANALYSIS ONLY (lint / typecheck / clippy / vet), never
  * `test`, `build`, `run`, or anything that boots a server or needs a database. Those
  * depend on external services the verify prompt already carves out as an environment
- * gap — running them here would re-introduce the false-FAIL that once wrongly blamed
- * code for a missing DB. Static analysis is hermetic: it needs no network, no service,
- * no fixtures, and it is exactly the class of the reported defect.
+ * gap, so running them here would blame code for a missing database. Static analysis
+ * is hermetic: it needs no network, no service and no fixtures.
  *
  * Absence is a PASS, two ways: (1) no recognised manifest at all (a pure-docs or
  * config-only repo has nothing that can regress); (2) a manifest with no static-check
@@ -78,7 +75,7 @@ export function discoverHealthCommands(cwd) {
     if (existsSync(path.join(cwd, 'package.json'))) {
         const s = packageScripts(cwd);
         const cmds = [];
-        // Only static-analysis scripts. `lint` commonly chains tsc (as in mx5's
+        // Only static-analysis scripts. `lint` commonly chains tsc (as in this
         // `prettier && eslint && tsc`), so a single `bun run lint` covers both.
         for (const name of ['lint', 'typecheck']) {
             if (s[name])
@@ -118,17 +115,14 @@ function noCommandOutcome(ecosystem) {
  *    treated as an environment gap, not a fault.
  *  - A command that ran and exited non-zero → the first such failure is returned.
  *
- * This module owns DISCOVERY and its own output policy; running a command and
- * deciding what its ending MEANS is `command-run.ts`'s. It used to own those too —
- * `HealthRun`, `classifyHealthRun` and `spawnHealthCommand` were a second statement
- * of the gap ladder, with no injectable runner, so every classification case in the
- * suite spawned a real shell. `command-run.ts`'s own header notes that this module
- * "had solved exactly this shape years earlier" and the gate never adopted it; this
- * is the adoption, in the other direction.
+ * This module owns DISCOVERY and its own output policy. Running a command and
+ * deciding what its ending MEANS is `command-run.ts`'s — one statement of the
+ * env-gap ladder, with an injectable runner, so a classification case needs no
+ * real shell.
  *
  * `captureHealthOutput` stays this module's own: 40 lines of a linter's report is a
- * real difference from `outputTail`'s 400 characters, and that is a parameter, not a
- * thing to unify.
+ * real difference from `outputTail`'s 400-character default, and that is a
+ * parameter, not a thing to unify.
  *
  * `onCommand` lets the caller name the running command in a live status line — the
  * gate runs this immediately after the implementation turn ends, when the impl
@@ -141,7 +135,7 @@ export async function runRepoHealthCheck(cwd, opts = {}) {
     const run = opts.run ?? spawnCommand;
     for (const [bin, args] of cmds) {
         opts.onCommand?.(`${bin} ${args.join(' ')}`);
-        // Runner resolution (mx5 run 16): a PATH-stripped environment must not
+        // Runner resolution: a PATH-stripped environment must not
         // silently skip the statics when the runner sits at a known install
         // location; the resolved dir also rides on PATH for the script chain.
         const runner = resolveRunner(bin);

package/dist/task/requirements.d.ts

@@ -13,16 +13,12 @@ export declare function parseRequirementLines(text: string): RequirementEntry[];
  *  passages from doc-order truncation. */
 export declare function keepGroundedRequirements(entries: RequirementEntry[], sourceDoc: string): RequirementEntry[];
 /**
- * Bound the list WITHOUT doc-order truncation. Two measured failure shapes drive
- * the rule:
- *  - an eager model extracts 40+ items top-down (every §1 decision row), so a
- *    plain first-N cap systematically drops the TAIL sections — exactly where
- *    mx5 keeps its testing obligations;
- *  - "given order" as the tie-break re-creates the same tail bias one level up
- *    (mx5 run 16, measured live: the model emitted 185 requirements, 178
- *    grounded — INCLUDING §9's "serves `/api` + static `dist/`", the clause
- *    whose loss shipped a permanently blank app — and the cap's doc-order fill
- *    cut all 138 past the cap, every one from the design's tail).
+ * Bound the list WITHOUT doc-order truncation. An extractor that works top-down
+ * yields more entries than the cap from the doc's early sections alone, so a
+ * plain first-N cap drops the TAIL sections wholesale — and a spec keeps its
+ * testing and deployment obligations at the end. "Given order" as the tie-break
+ * re-creates the same bias one level up.
+ *
  * Rule (deterministic priority, not a knob): entries quoting an obligation-
  * marked passage survive first; the remaining budget is filled ROUND-ROBIN
  * across the source doc's sections (each section's entries in doc order), so
@@ -32,9 +28,9 @@ export declare function keepGroundedRequirements(entries: RequirementEntry[], so
  * cannot be located) the fill degrades to the old given-order behavior.
  */
 export declare function capRequirements(entries: RequirementEntry[], passages: string[], sourceDoc?: string, 
-/** A/B seam: `false` reproduces the pre-budget rule, so an offline harness can
- *  score the shipped rule against the one it replaced without transcribing
- *  sectionFairFill and letting the copy drift. Production never passes it. */
+/** `false` skips the low-value deprioritisation, so a caller can compare the
+ *  two fills without transcribing sectionFairFill. Production never passes it
+ *  — auto-orchestrator.ts calls this with three arguments. */
 deprioritiseLowValue?: boolean): RequirementEntry[];
 /**
  * Quotes that pass the grounding guard (verbatim substring of the doc) but state
@@ -46,11 +42,11 @@ export declare function isLowValueQuote(quote: string): boolean;
 /**
  * DETERMINISTIC RECALL FLOOR (same medicine as the launch-contract checklist):
  * paragraphs carrying an obligation marker (word-bounded "required"/"must").
- * Extraction recall over a 20KB doc is the weak model's, and it is variance-
- * prone — measured live, 1 of 5 runs kept 16 quotes with ZERO §10 items. The
- * host enumerates the marked passages; the prompt lists their head lines as a
- * checklist, and uncoveredPassages() below turns "a marked passage produced no
- * quote" into hard evidence for one forced re-extraction.
+ * Extraction recall over a long doc is the model's, and it varies run to run, so
+ * an entire section can come back with no quotes at all. The host enumerates the
+ * marked passages; the prompt lists their head lines as a checklist, and
+ * uncoveredPassages() below turns "a marked passage produced no quote" into hard
+ * evidence for one forced re-extraction.
  */
 export declare function enumerateObligationPassages(doc: string): string[];
 /** Marked passages none of the kept quotes came from — the hard evidence that
@@ -106,22 +102,23 @@ export declare function readRequirements(cwd: string): Promise<string>;
  *   • `unresolved`   — grounded requirements still unmapped after the retry rounds.
  *   • `judgeFlagged` — free-text areas the holistic coverage judge flagged as
  *     uncovered that requirement-extraction never captured as a tracked entry, so
- *     the grounded channels above are structurally blind to them (mx5 2026-07-16:
- *     §10's test-infra setup was seen ONLY by the judge and, having no carrier,
- *     was warned-about then dropped). These are plain strings, not quotes of the
- *     source; marked distinctly so a task can tell an inferred area from a verbatim
- *     obligation.
+ *     the grounded channels above are structurally blind to them: without this
+ *     channel such an area is warned about once and then dropped. These are plain
+ *     strings, not quotes of the source; marked distinctly so a task can tell an
+ *     inferred area from a verbatim obligation.
  *   • `danglingArtifacts` — runtime files the spec references but nothing
- *     produces (mx5 run 13: the served `index.html` no task, tree entry, or
- *     build output ever created), still unclaimed by any title at coverage
+ *     produces (an `index.html` the server serves that no task, tree entry or
+ *     build output ever creates), still unclaimed by any title at coverage
  *     exhaustion. Deterministically extracted (artifact-closure.ts), so like
  *     judge areas they are host-authored strings, not source quotes.
  */
 export declare function appendCarriedRequirements(cwd: string, crossCutting: RequirementEntry[], unresolved?: RequirementEntry[], judgeFlagged?: string[], danglingArtifacts?: string[]): Promise<void>;
 /**
  * The read-only block refine/compose receive when carried requirements exist.
- * Verbatim content travels with every task (the directive pattern that works),
- * and the VERIFY mandate is explicit — goal C rides here.
+ * Verbatim content travels with every task — the REFINE_PRESERVE_DIRECTIVE
+ * pattern in phases.ts, content rather than a pointer — and the VERIFY mandate is
+ * spelled out, so a mandated verification methodology reaches every applicable
+ * task's runnable checks.
  */
 export declare function buildRequirementsBlock(requirements: string): string;
 export interface OwnedRequirement {
@@ -133,7 +130,7 @@ export interface OwnedRequirement {
      *  plan time, and spliced repair tasks shift them). */
     title: string;
     /**
-     * DETACHED (nexttask 2, owned-freeze-reassign.ts): the files this obligation
+     * DETACHED: the files this obligation
      * names that its assigned task FROZE, making it unsatisfiable there. While
      * set, the entry is owned by nobody — `ownedForTitle` skips it — and `title`
      * records only where it came from. The next task whose refined prompt shows
@@ -162,50 +159,20 @@ export declare function ownedForTitle(owned: OwnedRequirement[], title: string):
  *  task's obligations and must survive into the spec. */
 export declare function buildOwnedRequirementsBlock(owned: OwnedRequirement[]): string;
 /**
- * BRACES for the owned channel (the PROMPT-1 pattern): deterministically append
- * each owned obligation the composed spec does not already carry as a
- * CONSTRAINTS bullet. Measured need (scripts/live-owned-requirement-compose-ab
- * .ts, 8 reps/arm on two real run-16 losses): with the belt block alone compose
- * folded the clause into CONSTRAINTS/ACCEPTANCE in only 2/8 reps per fixture
- * (baseline 0/8) — an instruction the model mostly ignores, the PROMPT-4 shape.
- * A host-side append cannot be ignored. "Already carries" = the normalised
- * quote appears anywhere in the spec — belt-obeying reps aren't double-stated.
- * No CONSTRAINTS section (shape-invalid spec) → returned unchanged; this runs
- * only on specs the shape gate already accepted.
- *
- * NOT EXTENDED TO CONSUMER TASKS — REFUTED AT STEP 0, 2026-07-27. The proposal
- * was to classify owned requirements INVARIANT (prohibition-shaped) vs
- * DELIVERABLE and propagate the INVARIANTs from here to every task whose spec
- * names the same symbol/file, because mx5 run 17 gave all three Hono-RPC
- * obligations to TASK_0021 (which complied perfectly) while the four CONSUMER
- * tasks that never saw them — 0027/0031/0033/0034 — hand-wrote casts and shipped
- * 7 dead client call sites. It was not built, for two measured reasons
- * (scripts/owned-consumer-generality-step0.ts, re-runnable):
- *
- *  1. IT DOES NOT GENERALIZE. The task's own kill condition was <20% of a second
- *     stack's OWNED requirements being prohibition-shaped. IAR1, 8 live
- *     regenerations of the real plan-time pipeline over its real 10-task list:
- *     2/42 pooled = 4.8% (narrow four-phrase reading 1/42 = 2.4%). mx5 itself is
- *     7/33 = 21.2% only under the BROAD rule above; under "never/don't/must
- *     not/do not" it is 2/33 = 6.1%. The structural reason is in accountCoverage
- *     right here: a prohibition the map leaves NONE is already carried
- *     cross-cutting to every task, so in the five reps that logged the split 18
- *     of IAR1's 19 prohibition-shaped requirements were never owner-only in the
- *     first place. mx5's 7 leaked because the model mapped them to a TASK.
- *  2. THE TARGETING RULE MISSES ITS OWN MOTIVATING CASE. Symbol/file relevance
- *     would not have reached the four violators for the clause they actually
- *     broke ("If a call isn't fully typed end-to-end via `hc`, fix the route
- *     chaining/export, don't paper over it…"): its only extractable symbol is
- *     `chaining/export`, which no consumer spec contains — 0 consumers. Its
- *     siblings would have reached all four, attaching to 13/41 tasks each; across
- *     mx5's 33 owned requirements the mean attach rate is 21% of all tasks and
- *     5/33 would attach to more than half of them (the task's own I1 trigger).
+ * The host-side belt for the owned channel: deterministically append each owned
+ * obligation the composed spec does not already carry as a CONSTRAINTS bullet.
+ * The injected block alone is an instruction compose can ignore; an append
+ * cannot be. "Already carries" = the normalised quote appears anywhere in the
+ * spec, so a spec that DID fold the clause in is not double-stated. No
+ * CONSTRAINTS section → returned unchanged; this runs only on specs the shape
+ * gate already accepted.
  *
- * Do not re-open on mx5 evidence alone. A future attempt needs a second stack
- * where prohibition-shaped requirements actually land OWNED, and a targeting rule
- * that survives a clause whose symbols are prose.
+ * Scoped to the OWNING task only. A prohibition the coverage map leaves unowned is
+ * already carried cross-cutting to every task by `accountCoverage` above, so the
+ * owned channel is not the place to reach a requirement's other readers.
  */
 export declare function appendOwnedConstraints(spec: string, owned: OwnedRequirement[]): string;
-/** The decompose-prompt ledger block (goal E's belt): the grounded requirement
- *  list rides into decompose so structure-mirroring can't discharge it. */
+/** The decompose-prompt ledger block: the grounded requirement list rides into
+ *  decompose so a title list that mirrors the spec's own headings cannot
+ *  discharge it. */
 export declare function buildRequirementsLedger(requirements: RequirementEntry[]): string;