@mjasnikovs/pi-task 0.38.29 → 0.38.30

package/dist/task/test-assembly.d.ts

@@ -1,27 +1,20 @@
 /**
  * test-assembly — deterministic detection of TEST-REBUILT PRODUCTION WIRING, feeding
- * the verify gate's prompt (run-8 F4; third recurrence of the test-the-copy class,
- * runs 3, 4, 8).
+ * the verify gate's prompt. A recurring shape, not a one-off.
  *
  * The failure class: a test file re-constructs wiring that ALSO exists in production
  * — it builds its own app assembly / its own entry point out of the same leaf modules
  * the production entry composes, then tests THAT private copy. The copy can be wired
- * differently from production and stay green while the shipped wiring is broken. Run-8
- * fixture: `test/photos.test.ts` imports the real `authRoutes` + `photosRoutes` leaves,
- * mounts them into its OWN app at a DIFFERENT prefix than the production entry, and
- * runs 102/102 green — while the shipped upload path is dead because production mounts
- * the same leaf at the wrong prefix. The verify child, judging "do the tests pass",
- * saw green and counted the photos area verified. The seam the test was supposed to
- * cover is exactly the seam it re-implemented away.
+ * differently from production and stay green while the shipped wiring is broken: the
+ * test mounts the same leaf at one prefix, production mounts it at another, and the
+ * seam the test was supposed to cover is the seam it re-implemented away.
  *
  * This is the VERIFY-SIDE complement of the generation-side wiring probe
- * (wiring-claims.ts, item #5) and shares the load-bearing lesson of
- * substitution-probe / skip-escape / wiring-claims: a deterministic finding that NAMES
- * the suspect file is the reliable lever; a bare prompt rule is weak. rule 3b already
- * tells the child to spot-check that self-authored tests exercise the real artifact,
- * but F4 slips through because these tests DO import the real leaf modules — they just
- * bypass the real ASSEMBLY, which rule 3b's "did it import and call the module" check
- * does not catch. This probe supplies the missing concrete fact.
+ * (wiring-claims.ts). Rule 3b already tells the child to spot-check that
+ * self-authored tests exercise the real artifact, but this shape slips past it:
+ * these tests DO import the real leaf modules — they just bypass the real ASSEMBLY,
+ * which "did it import and call the module" does not catch. This probe supplies the
+ * missing concrete fact.
  *
  * THE SIGNAL is pure import-graph SHAPE, zero stack/framework assumptions (no "app",
  * no "route", no "mount", no language runtime): a test file T is flagged when there is
@@ -34,10 +27,10 @@
  * shared-utility imports out: a test importing an api client + a schema module that
  * every page also imports is NOT re-assembly (those utilities have many production
  * importers); a test importing two route modules that only the server entry composes
- * IS re-assembly. Measured on the run-8 fixture tree: flags exactly the four backend
- * tests that rebuild the server entry's route composition (including the real
- * photos seam bug) and leaves clean the single-leaf direct test, the utility-sharing
- * page test, and the source-grepping test — 0 false positives.
+ * IS re-assembly. What that leaves clean, by construction: a test importing ONE
+ * leaf, a test importing utilities several production files also import, a test that
+ * imports the assembly itself, and a source-grepping test whose "imports" are quoted
+ * strings inside assertions.
  *
  * Findings are ADVISORY (probe+rule): they mandate the child to exercise the REAL
  * shipped assembly directly before counting the area verified; they never auto-FAIL.

package/dist/task/test-assembly.js

@@ -1,27 +1,20 @@
 /**
  * test-assembly — deterministic detection of TEST-REBUILT PRODUCTION WIRING, feeding
- * the verify gate's prompt (run-8 F4; third recurrence of the test-the-copy class,
- * runs 3, 4, 8).
+ * the verify gate's prompt. A recurring shape, not a one-off.
  *
  * The failure class: a test file re-constructs wiring that ALSO exists in production
  * — it builds its own app assembly / its own entry point out of the same leaf modules
  * the production entry composes, then tests THAT private copy. The copy can be wired
- * differently from production and stay green while the shipped wiring is broken. Run-8
- * fixture: `test/photos.test.ts` imports the real `authRoutes` + `photosRoutes` leaves,
- * mounts them into its OWN app at a DIFFERENT prefix than the production entry, and
- * runs 102/102 green — while the shipped upload path is dead because production mounts
- * the same leaf at the wrong prefix. The verify child, judging "do the tests pass",
- * saw green and counted the photos area verified. The seam the test was supposed to
- * cover is exactly the seam it re-implemented away.
+ * differently from production and stay green while the shipped wiring is broken: the
+ * test mounts the same leaf at one prefix, production mounts it at another, and the
+ * seam the test was supposed to cover is the seam it re-implemented away.
  *
  * This is the VERIFY-SIDE complement of the generation-side wiring probe
- * (wiring-claims.ts, item #5) and shares the load-bearing lesson of
- * substitution-probe / skip-escape / wiring-claims: a deterministic finding that NAMES
- * the suspect file is the reliable lever; a bare prompt rule is weak. rule 3b already
- * tells the child to spot-check that self-authored tests exercise the real artifact,
- * but F4 slips through because these tests DO import the real leaf modules — they just
- * bypass the real ASSEMBLY, which rule 3b's "did it import and call the module" check
- * does not catch. This probe supplies the missing concrete fact.
+ * (wiring-claims.ts). Rule 3b already tells the child to spot-check that
+ * self-authored tests exercise the real artifact, but this shape slips past it:
+ * these tests DO import the real leaf modules — they just bypass the real ASSEMBLY,
+ * which "did it import and call the module" does not catch. This probe supplies the
+ * missing concrete fact.
  *
  * THE SIGNAL is pure import-graph SHAPE, zero stack/framework assumptions (no "app",
  * no "route", no "mount", no language runtime): a test file T is flagged when there is
@@ -34,10 +27,10 @@
  * shared-utility imports out: a test importing an api client + a schema module that
  * every page also imports is NOT re-assembly (those utilities have many production
  * importers); a test importing two route modules that only the server entry composes
- * IS re-assembly. Measured on the run-8 fixture tree: flags exactly the four backend
- * tests that rebuild the server entry's route composition (including the real
- * photos seam bug) and leaves clean the single-leaf direct test, the utility-sharing
- * page test, and the source-grepping test — 0 false positives.
+ * IS re-assembly. What that leaves clean, by construction: a test importing ONE
+ * leaf, a test importing utilities several production files also import, a test that
+ * imports the assembly itself, and a source-grepping test whose "imports" are quoted
+ * strings inside assertions.
  *
  * Findings are ADVISORY (probe+rule): they mandate the child to exercise the REAL
  * shipped assembly directly before counting the area verified; they never auto-FAIL.

package/dist/task/timings.d.ts

@@ -2,9 +2,11 @@
  * Phase timing data — captures how long each pipeline phase took so we can
  * spot regressions and target future speed improvements.
  *
- * Top-level entries are the five phases (refine, research, grill, compose,
- * critique). Each phase may attach optional sub-step children (e.g. research
- * → workers + verify-tooling, grill → gen + auto-answers + user input).
+ * Top-level entries are the five phases of PHASE_ORDER (refine, research, grill,
+ * compose, critique). Each phase may attach optional sub-step children, recorded
+ * through `deps.recordSubStep`: research reports `workers` and `verify-tooling`,
+ * grill `gen` and `auto-answer`, critique `triage` and `rewrite`, and every phase
+ * child reports its own `<name> wait` / `<name> work` split.
  *
  * `formatTimings` produces the human-readable block we write to the
  * `## phase timings` section of the TASK_NNNN.md file.

package/dist/task/timings.js

@@ -2,9 +2,11 @@
  * Phase timing data — captures how long each pipeline phase took so we can
  * spot regressions and target future speed improvements.
  *
- * Top-level entries are the five phases (refine, research, grill, compose,
- * critique). Each phase may attach optional sub-step children (e.g. research
- * → workers + verify-tooling, grill → gen + auto-answers + user input).
+ * Top-level entries are the five phases of PHASE_ORDER (refine, research, grill,
+ * compose, critique). Each phase may attach optional sub-step children, recorded
+ * through `deps.recordSubStep`: research reports `workers` and `verify-tooling`,
+ * grill `gen` and `auto-answer`, critique `triage` and `rewrite`, and every phase
+ * child reports its own `<name> wait` / `<name> work` split.
  *
  * `formatTimings` produces the human-readable block we write to the
  * `## phase timings` section of the TASK_NNNN.md file.

package/dist/task/title-label.d.ts

@@ -2,8 +2,8 @@
  * Display-label compression.
  *
  * A refined GOAL paragraph becomes the stored `title`, which the pipeline reads
- * in full — but it can run to 1000+ characters, which makes the widget head and
- * `/task list` unreadable. `compressTitle` spawns a tool-less local-model child
+ * in full — but a paragraph-long title makes the widget head and `/task list`
+ * unreadable. `compressTitle` spawns a tool-less local-model child
  * to distill that title into a short, identifying label that we store ALONGSIDE
  * (never replacing) the full title, purely for display. Every failure mode —
  * model error, empty output, leaked tool call, abort, an over-long answer —
@@ -13,8 +13,13 @@
 import type { PhaseDeps } from './child-runner.js';
 /**
  * Reduce a raw model completion to a single clean label line: first non-empty
- * line, stripped of surrounding quotes/backticks and a leading "label:" echo,
- * whitespace collapsed. Returns '' when nothing usable remains.
+ * line, a leading "label:" echo removed, then quotes/backticks stripped from the
+ * ends, then whitespace collapsed. Returns '' when nothing usable remains.
+ *
+ * The quote strip runs BEFORE the collapse, so it anchors on the raw line: a quote
+ * sitting next to leading or trailing whitespace survives (`"X"  ` → `X"`). That
+ * only ever leaves one stray character in the label, and the label is display-only
+ * — `title` is what the pipeline reads.
  */
 export declare function sanitizeLabel(raw: string): string;
 /**

package/dist/task/title-label.js

@@ -2,8 +2,8 @@
  * Display-label compression.
  *
  * A refined GOAL paragraph becomes the stored `title`, which the pipeline reads
- * in full — but it can run to 1000+ characters, which makes the widget head and
- * `/task list` unreadable. `compressTitle` spawns a tool-less local-model child
+ * in full — but a paragraph-long title makes the widget head and `/task list`
+ * unreadable. `compressTitle` spawns a tool-less local-model child
  * to distill that title into a short, identifying label that we store ALONGSIDE
  * (never replacing) the full title, purely for display. Every failure mode —
  * model error, empty output, leaked tool call, abort, an over-long answer —
@@ -15,8 +15,13 @@ import { LABEL_MAX, truncateLabel } from './parsers.js';
 import { COMPRESS_LABEL_PROMPT } from './prompts.js';
 /**
  * Reduce a raw model completion to a single clean label line: first non-empty
- * line, stripped of surrounding quotes/backticks and a leading "label:" echo,
- * whitespace collapsed. Returns '' when nothing usable remains.
+ * line, a leading "label:" echo removed, then quotes/backticks stripped from the
+ * ends, then whitespace collapsed. Returns '' when nothing usable remains.
+ *
+ * The quote strip runs BEFORE the collapse, so it anchors on the raw line: a quote
+ * sitting next to leading or trailing whitespace survives (`"X"  ` → `X"`). That
+ * only ever leaves one stray character in the label, and the label is display-only
+ * — `title` is what the pipeline reads.
  */
 export function sanitizeLabel(raw) {
     const firstLine = raw.split('\n').find(l => l.trim().length > 0) ?? '';

package/dist/task/type-only-answer.d.ts

@@ -1,62 +1,54 @@
 /**
- * Deterministic detector for the F-2 shape: a pi-worker-docs answer that RESTATES a type
- * signature or declaration for a USAGE question, without ever saying what the API DOES.
+ * Deterministic detector for a pi-worker-docs answer that RESTATES a type signature
+ * or declaration for a USAGE question, without ever saying what the API DOES.
  *
- * THE FATAL CASE, from mx5 run 15 (research-cache.json, verbatim):
+ * The shape, in one example. Asked "hc factory function signature base url parameter
+ * types", a docs child answers that `hc` "accepts a generic type `T` extending
+ * `Hono`… and takes two parameters: `baseUrl` of type `Prefix`". Every clause is
+ * type-level: it names the parameter's TYPE, and `Prefix` is itself an opaque type
+ * variable, while saying nothing about what `baseUrl` MEANS — is it an origin, or a
+ * mount prefix? Escalation to search/fetch never fires, because the answer looks
+ * complete: it named the very parameter that was asked about. The caller then fills
+ * the semantic gap from memory, and a wrong guess about that one word can kill every
+ * request the client makes.
  *
- *   query : "hc factory function signature base url parameter types exported from hono/client"
- *   answer: "The `hc` factory function exported from `hono/client` accepts a generic type
- *            `T` extending `Hono`, an optional string prefix type `Prefix` (defaulting to
- *            `string`), and takes two parameters: `baseUrl` of type `Prefix` and an optional
- *            `options` of type `ClientRequestOptions`. It returns a
- *            `UnionToIntersection<Client<T, Prefix>>`."
+ * The lever: when a docs answer for a usage question is ONLY a signature restatement
+ * with no behavioural statement, treat it as UNANSWERED so the caller escalates
+ * (follow the `@see` pointer, fetch the spec-cited URL) instead of accepting a type
+ * as the answer.
  *
- * Every clause is type-level. "`baseUrl` of type `Prefix`" names the parameter's TYPE — and
- * `Prefix` is itself an opaque type variable — while saying nothing about what `baseUrl`
- * MEANS (is it an origin, or a mount prefix?). Escalation to search/fetch never fired
- * because the answer looked complete: it named the very parameter asked about. worker:context
- * then filled the semantic gap from memory and shipped `hc<AppType>('/api')`, so every request
- * went to `/api/api/...` ⇒ 404 ⇒ the product's entire API surface was dead (F-2 → F-1).
- *
- * The lever (PROMPT 2 DO item 1): when a docs answer for a usage question is ONLY a
- * signature/declaration restatement with no behavioural statement, treat it as UNANSWERED so
- * the caller escalates (follow the `@see` pointer / fetch the spec-cited URL) instead of
- * accepting a type as the answer.
- *
- * ── PRECISION/RECALL TRADEOFF (chosen deliberately; documented per the task) ────────────────
- * A FALSE POSITIVE here (flagging a real answer as type-only) forces a needless escalation:
- * wall-clock cost against PROMPT 2 invariant 1, which caps added child spawns. A false
- * NEGATIVE (missing a type-only answer) merely leaves the pre-existing bug unfixed for that
- * one borderline case. So this detector is tuned for HIGH PRECISION on real answers, accepting
- * low recall — "better to miss a borderline type-only answer than to flag a real one." Three
- * independent gates must ALL hold before an answer is called type-only; any one failing clears
- * it. Calibrated against the run-15 corpus: of the 149 valid (non-"unclear") pi-worker-docs
- * answers, this rule flags EXACTLY ONE — the recorded `hc` case — and clears the other 148,
- * including every legitimate signature answer to an explicit "give me the type/signature"
- * question (bun.password.hash, toBuffer, BuildOutput, …). See type-only-answer.test.ts.
+ * ── PRECISION OVER RECALL, deliberately ─────────────────────────────────────────
+ * A FALSE POSITIVE (flagging a real answer as type-only) forces a needless
+ * escalation and costs a child spawn. A false NEGATIVE merely leaves one borderline
+ * answer un-escalated. So three independent gates must ALL hold before an answer is
+ * called type-only, and any one failing clears it. That is what keeps a legitimate
+ * signature answer to an explicit "give me the type" question out.
  *
  * THE THREE GATES (all required):
- *   1. USAGE QUESTION. The question must seek usage/semantics — "how", "use", "work", "chain",
- *      "example", "call", "rpc", "mean", or it names a usage concept whose meaning is being
- *      sought ("base url"). A question that asks only for a TYPE / SIGNATURE / DEFINITION /
- *      FIELDS is legitimately answered by a signature, so it is NOT gated in. (The recorded hc
- *      query is signature-shaped but names "base url", the concept whose meaning was needed.)
- *   2. NO BEHAVIOURAL CONTENT IN PROSE. The answer must contain no statement of what the API
- *      DOES: no usage verb ("use/call/pass/import"), no runtime-effect verb ("executes/
- *      prepends/enables/wraps"), no concrete usage example, no semantic meaning ("means/
- *      represents/so pass"), no concrete default VALUE or value RANGE ("default of 80", "from
- *      1 to 100"). Any one clears. This scan runs over `proseOf(answer)`, NOT the raw answer:
- *      a verb that is really a method name inside a declaration ("methods route(url, handler)
- *      and use(...handlers)") is an identifier, not behaviour, and must not clear the answer.
- *   3. SIGNATURE RESTATEMENT. The answer must actually be a declaration/signature restatement —
- *      "of type", "takes N parameters", "accepts", "returns a…", "extends", "interface",
- *      "declare const/function". Without this it is not type-only, it is just terse prose.
+ *   1. USAGE QUESTION. The question must seek usage/semantics — "how", "use",
+ *      "work", "chain", "example", "call", "rpc", "mean" — or name a usage concept
+ *      whose meaning is being sought ("base url"). A question asking only for a
+ *      TYPE / SIGNATURE / DEFINITION is legitimately answered by a signature, so it
+ *      is NOT gated in. (The `hc` query above is signature-shaped but names "base
+ *      url", the concept whose meaning was needed.)
+ *   2. NO BEHAVIOURAL CONTENT IN PROSE. The answer must contain no statement of what
+ *      the API DOES: no usage verb ("use/call/pass/import"), no runtime-effect verb
+ *      ("executes/prepends/enables/wraps"), no concrete example, no semantic meaning
+ *      ("means/represents/so pass"), no concrete default VALUE or range ("default of
+ *      80", "from 1 to 100"). Any one clears. This scan runs over `proseOf(answer)`,
+ *      NOT the raw answer: a verb that is really a method name inside a declaration
+ *      ("methods route(url, handler) and use(...handlers)") is an identifier, not
+ *      behaviour, and must not clear the answer.
+ *   3. SIGNATURE RESTATEMENT. The answer must actually be a declaration restatement —
+ *      "of type", "takes N parameters", "accepts", "returns a…", "extends",
+ *      "interface", "declare const/function". Without this it is not type-only, it
+ *      is just terse prose.
  *
- * An explicit "unclear from this package/page" is NOT type-only — it is the HONEST non-answer,
- * already handled by the escalation path (PROMPT 2 DO item 2 escalates BOTH). It is cleared
- * here with a distinct reason so the caller can route it through the existing unclear channel.
+ * An explicit "unclear from this package/page" is NOT type-only — it is the HONEST
+ * non-answer, and it is cleared here with a distinct reason so the caller routes it
+ * through the existing unclear channel instead.
  *
- * Pure and side-effect free; unit-tested in type-only-answer.test.ts against real run-15 text.
+ * Pure and side-effect free; unit-tested in type-only-answer.test.ts against real text.
  */
 /** The verdict, with a human-readable reason for logging and for the escalation channel. */
 export interface TypeOnlyVerdict {
@@ -73,7 +65,7 @@ export interface TypeOnlyVerdict {
  * declaration. Without this, a bare type-only answer like
  *   "It has methods route(url, handler) and use(...handlers)."
  * is wrongly cleared, because `use(...handlers)` matches /\buse\b/ and `handler` matches
- * /handle/ — the F-3(a) router-fixture shape. So before scanning for behaviour we remove:
+ * /handle/. So before scanning for behaviour we remove:
  *   - `name(args)` call fragments, whose args are identifiers, not prose (this is what
  *     carries the method-name verbs);
  *   - `declare const|function|module|class|namespace …` declaration lines.

package/dist/task/type-only-answer.js

@@ -1,62 +1,54 @@
 /**
- * Deterministic detector for the F-2 shape: a pi-worker-docs answer that RESTATES a type
- * signature or declaration for a USAGE question, without ever saying what the API DOES.
+ * Deterministic detector for a pi-worker-docs answer that RESTATES a type signature
+ * or declaration for a USAGE question, without ever saying what the API DOES.
  *
- * THE FATAL CASE, from mx5 run 15 (research-cache.json, verbatim):
+ * The shape, in one example. Asked "hc factory function signature base url parameter
+ * types", a docs child answers that `hc` "accepts a generic type `T` extending
+ * `Hono`… and takes two parameters: `baseUrl` of type `Prefix`". Every clause is
+ * type-level: it names the parameter's TYPE, and `Prefix` is itself an opaque type
+ * variable, while saying nothing about what `baseUrl` MEANS — is it an origin, or a
+ * mount prefix? Escalation to search/fetch never fires, because the answer looks
+ * complete: it named the very parameter that was asked about. The caller then fills
+ * the semantic gap from memory, and a wrong guess about that one word can kill every
+ * request the client makes.
  *
- *   query : "hc factory function signature base url parameter types exported from hono/client"
- *   answer: "The `hc` factory function exported from `hono/client` accepts a generic type
- *            `T` extending `Hono`, an optional string prefix type `Prefix` (defaulting to
- *            `string`), and takes two parameters: `baseUrl` of type `Prefix` and an optional
- *            `options` of type `ClientRequestOptions`. It returns a
- *            `UnionToIntersection<Client<T, Prefix>>`."
+ * The lever: when a docs answer for a usage question is ONLY a signature restatement
+ * with no behavioural statement, treat it as UNANSWERED so the caller escalates
+ * (follow the `@see` pointer, fetch the spec-cited URL) instead of accepting a type
+ * as the answer.
  *
- * Every clause is type-level. "`baseUrl` of type `Prefix`" names the parameter's TYPE — and
- * `Prefix` is itself an opaque type variable — while saying nothing about what `baseUrl`
- * MEANS (is it an origin, or a mount prefix?). Escalation to search/fetch never fired
- * because the answer looked complete: it named the very parameter asked about. worker:context
- * then filled the semantic gap from memory and shipped `hc<AppType>('/api')`, so every request
- * went to `/api/api/...` ⇒ 404 ⇒ the product's entire API surface was dead (F-2 → F-1).
- *
- * The lever (PROMPT 2 DO item 1): when a docs answer for a usage question is ONLY a
- * signature/declaration restatement with no behavioural statement, treat it as UNANSWERED so
- * the caller escalates (follow the `@see` pointer / fetch the spec-cited URL) instead of
- * accepting a type as the answer.
- *
- * ── PRECISION/RECALL TRADEOFF (chosen deliberately; documented per the task) ────────────────
- * A FALSE POSITIVE here (flagging a real answer as type-only) forces a needless escalation:
- * wall-clock cost against PROMPT 2 invariant 1, which caps added child spawns. A false
- * NEGATIVE (missing a type-only answer) merely leaves the pre-existing bug unfixed for that
- * one borderline case. So this detector is tuned for HIGH PRECISION on real answers, accepting
- * low recall — "better to miss a borderline type-only answer than to flag a real one." Three
- * independent gates must ALL hold before an answer is called type-only; any one failing clears
- * it. Calibrated against the run-15 corpus: of the 149 valid (non-"unclear") pi-worker-docs
- * answers, this rule flags EXACTLY ONE — the recorded `hc` case — and clears the other 148,
- * including every legitimate signature answer to an explicit "give me the type/signature"
- * question (bun.password.hash, toBuffer, BuildOutput, …). See type-only-answer.test.ts.
+ * ── PRECISION OVER RECALL, deliberately ─────────────────────────────────────────
+ * A FALSE POSITIVE (flagging a real answer as type-only) forces a needless
+ * escalation and costs a child spawn. A false NEGATIVE merely leaves one borderline
+ * answer un-escalated. So three independent gates must ALL hold before an answer is
+ * called type-only, and any one failing clears it. That is what keeps a legitimate
+ * signature answer to an explicit "give me the type" question out.
  *
  * THE THREE GATES (all required):
- *   1. USAGE QUESTION. The question must seek usage/semantics — "how", "use", "work", "chain",
- *      "example", "call", "rpc", "mean", or it names a usage concept whose meaning is being
- *      sought ("base url"). A question that asks only for a TYPE / SIGNATURE / DEFINITION /
- *      FIELDS is legitimately answered by a signature, so it is NOT gated in. (The recorded hc
- *      query is signature-shaped but names "base url", the concept whose meaning was needed.)
- *   2. NO BEHAVIOURAL CONTENT IN PROSE. The answer must contain no statement of what the API
- *      DOES: no usage verb ("use/call/pass/import"), no runtime-effect verb ("executes/
- *      prepends/enables/wraps"), no concrete usage example, no semantic meaning ("means/
- *      represents/so pass"), no concrete default VALUE or value RANGE ("default of 80", "from
- *      1 to 100"). Any one clears. This scan runs over `proseOf(answer)`, NOT the raw answer:
- *      a verb that is really a method name inside a declaration ("methods route(url, handler)
- *      and use(...handlers)") is an identifier, not behaviour, and must not clear the answer.
- *   3. SIGNATURE RESTATEMENT. The answer must actually be a declaration/signature restatement —
- *      "of type", "takes N parameters", "accepts", "returns a…", "extends", "interface",
- *      "declare const/function". Without this it is not type-only, it is just terse prose.
+ *   1. USAGE QUESTION. The question must seek usage/semantics — "how", "use",
+ *      "work", "chain", "example", "call", "rpc", "mean" — or name a usage concept
+ *      whose meaning is being sought ("base url"). A question asking only for a
+ *      TYPE / SIGNATURE / DEFINITION is legitimately answered by a signature, so it
+ *      is NOT gated in. (The `hc` query above is signature-shaped but names "base
+ *      url", the concept whose meaning was needed.)
+ *   2. NO BEHAVIOURAL CONTENT IN PROSE. The answer must contain no statement of what
+ *      the API DOES: no usage verb ("use/call/pass/import"), no runtime-effect verb
+ *      ("executes/prepends/enables/wraps"), no concrete example, no semantic meaning
+ *      ("means/represents/so pass"), no concrete default VALUE or range ("default of
+ *      80", "from 1 to 100"). Any one clears. This scan runs over `proseOf(answer)`,
+ *      NOT the raw answer: a verb that is really a method name inside a declaration
+ *      ("methods route(url, handler) and use(...handlers)") is an identifier, not
+ *      behaviour, and must not clear the answer.
+ *   3. SIGNATURE RESTATEMENT. The answer must actually be a declaration restatement —
+ *      "of type", "takes N parameters", "accepts", "returns a…", "extends",
+ *      "interface", "declare const/function". Without this it is not type-only, it
+ *      is just terse prose.
  *
- * An explicit "unclear from this package/page" is NOT type-only — it is the HONEST non-answer,
- * already handled by the escalation path (PROMPT 2 DO item 2 escalates BOTH). It is cleared
- * here with a distinct reason so the caller can route it through the existing unclear channel.
+ * An explicit "unclear from this package/page" is NOT type-only — it is the HONEST
+ * non-answer, and it is cleared here with a distinct reason so the caller routes it
+ * through the existing unclear channel instead.
  *
- * Pure and side-effect free; unit-tested in type-only-answer.test.ts against real run-15 text.
+ * Pure and side-effect free; unit-tested in type-only-answer.test.ts against real text.
  */
 import { isAbstention } from '../workers/abstention.js';
 /**
@@ -181,7 +173,7 @@ function firstMatch(text, patterns) {
  * declaration. Without this, a bare type-only answer like
  *   "It has methods route(url, handler) and use(...handlers)."
  * is wrongly cleared, because `use(...handlers)` matches /\buse\b/ and `handler` matches
- * /handle/ — the F-3(a) router-fixture shape. So before scanning for behaviour we remove:
+ * /handle/. So before scanning for behaviour we remove:
  *   - `name(args)` call fragments, whose args are identifiers, not prose (this is what
  *     carries the method-name verbs);
  *   - `declare const|function|module|class|namespace …` declaration lines.

package/dist/task/unfailable-command.d.ts

@@ -1,40 +1,34 @@
 /**
  * unfailable-command — is this shell command's exit status DESTROYED by its own
- * construction? (nexttask 19C)
+ * construction?
  *
  * WHY THIS EXISTS. `recheckAcceptDebts` may auto-close an accepted debt on exactly
  * one piece of evidence: the debt named a VERIFY command, that command was re-run,
- * and it exited ZERO (accept-debt.ts — "the debt named a command, the command was
- * run, and it passed"). `isStorableCommand` used to filter only on length and
- * control characters, so nothing asked whether a ZERO exit could ever mean
- * anything. Sixteen stored-eligible VERIFY lines in the corpus on this box cannot
- * exit non-zero no matter what the tree contains:
+ * and it exited ZERO (accept-debt.ts). Filtering the stored command on length and
+ * control characters alone never asks whether a ZERO exit could mean anything. Three
+ * shapes make it meaningless:
  *
- *     C  `test -f "$SO_LIB" && echo "PASS: …" || echo "FAIL: …"`     15  ← both
- *        branches that can be LAST are echoes, so the status is echo's: 0.
- *     A  `bun -e "console.assert(…)"`                                 1  ← measured
- *        in both runtimes: `console.assert(1===2,'X')` prints and exits 0.
- *     B  `npx tsc --noEmit 2>&1 | tail -5; test $? -eq 0 && …`        1  ← `$?` is
- *        tail's status, not tsc's.
- *
- * IAR1 (CMake / C++ / OBS plugin — no database, no frontend, no HTTP server)
- * carries 11 of the 16; one of its tasks is SEVEN consecutive `test -f … && echo
- * "PASS" || echo "FAIL"` lines standing in for a build verification.
+ *     C  `test -f "$SO_LIB" && echo "PASS: …" || echo "FAIL: …"`  ← both branches
+ *        that can run LAST are echoes, so the status is echo's: 0.
+ *     A  `bun -e "console.assert(…)"`  ← `console.assert` prints and continues; the
+ *        process still exits 0, in bun and in node alike.
+ *     B  `npx tsc --noEmit 2>&1 | tail -5; test $? -eq 0 && …`  ← `$?` is tail's
+ *        status, not tsc's.
  *
  * THE VERDICT IS A REFUSAL, NOT A CLAIM. An unfailable command is not stored, so
  * the debt stays OPEN and surfaced — the strictly smaller claim. Nothing here can
  * close a debt, fail a gate, or edit a spec.
  *
  * DECIDED ON SHELL SHAPE, NEVER ON THE VERB. `grep -q …` and `ctest …` set a real
- * status and are untouched; `test -f X || { echo …; exit 1; }` exits non-zero and
- * is untouched. Naming verbs is the mistake nexttask 3 already paid for
- * (command-shrink's guard compared NAMES) and 16B re-bought.
+ * status and are untouched; `test -f X || { echo …; exit 1; }` exits non-zero and is
+ * untouched. A rule keyed on command NAMES would have to know every checker that
+ * exists, and would still miss the shape — the same mistake command-shrink's guard
+ * made by comparing names.
  *
- * OUT OF SCOPE BY DESIGN: bare `|| true`. skip-escape.ts:11-19 records the FP
- * measurement — of 45 `||` uses in the historical VERIFY blocks exactly one was a
- * real skip-escape; a blanket `|| true` rule is ~90% false positives (teardown,
- * setup, negative tests). `rm -rf build || true` classifies CAN-FAIL here and must
- * keep doing so.
+ * OUT OF SCOPE BY DESIGN: bare `|| true`. As skip-escape.ts explains, most `||`
+ * uses are teardown, setup or a negative test rather than an escape, so a blanket
+ * rule would be almost all false positives. `rm -rf build || true` classifies
+ * CAN-FAIL here and must keep doing so.
  *
  * THREE OUTCOMES, and `unknown` is a first-class answer: a shape this cannot
  * decide is never guessed at, it is left alone (which is today's behaviour).

package/dist/task/unfailable-command.js

@@ -1,40 +1,34 @@
 /**
  * unfailable-command — is this shell command's exit status DESTROYED by its own
- * construction? (nexttask 19C)
+ * construction?
  *
  * WHY THIS EXISTS. `recheckAcceptDebts` may auto-close an accepted debt on exactly
  * one piece of evidence: the debt named a VERIFY command, that command was re-run,
- * and it exited ZERO (accept-debt.ts — "the debt named a command, the command was
- * run, and it passed"). `isStorableCommand` used to filter only on length and
- * control characters, so nothing asked whether a ZERO exit could ever mean
- * anything. Sixteen stored-eligible VERIFY lines in the corpus on this box cannot
- * exit non-zero no matter what the tree contains:
+ * and it exited ZERO (accept-debt.ts). Filtering the stored command on length and
+ * control characters alone never asks whether a ZERO exit could mean anything. Three
+ * shapes make it meaningless:
  *
- *     C  `test -f "$SO_LIB" && echo "PASS: …" || echo "FAIL: …"`     15  ← both
- *        branches that can be LAST are echoes, so the status is echo's: 0.
- *     A  `bun -e "console.assert(…)"`                                 1  ← measured
- *        in both runtimes: `console.assert(1===2,'X')` prints and exits 0.
- *     B  `npx tsc --noEmit 2>&1 | tail -5; test $? -eq 0 && …`        1  ← `$?` is
- *        tail's status, not tsc's.
- *
- * IAR1 (CMake / C++ / OBS plugin — no database, no frontend, no HTTP server)
- * carries 11 of the 16; one of its tasks is SEVEN consecutive `test -f … && echo
- * "PASS" || echo "FAIL"` lines standing in for a build verification.
+ *     C  `test -f "$SO_LIB" && echo "PASS: …" || echo "FAIL: …"`  ← both branches
+ *        that can run LAST are echoes, so the status is echo's: 0.
+ *     A  `bun -e "console.assert(…)"`  ← `console.assert` prints and continues; the
+ *        process still exits 0, in bun and in node alike.
+ *     B  `npx tsc --noEmit 2>&1 | tail -5; test $? -eq 0 && …`  ← `$?` is tail's
+ *        status, not tsc's.
  *
  * THE VERDICT IS A REFUSAL, NOT A CLAIM. An unfailable command is not stored, so
  * the debt stays OPEN and surfaced — the strictly smaller claim. Nothing here can
  * close a debt, fail a gate, or edit a spec.
  *
  * DECIDED ON SHELL SHAPE, NEVER ON THE VERB. `grep -q …` and `ctest …` set a real
- * status and are untouched; `test -f X || { echo …; exit 1; }` exits non-zero and
- * is untouched. Naming verbs is the mistake nexttask 3 already paid for
- * (command-shrink's guard compared NAMES) and 16B re-bought.
+ * status and are untouched; `test -f X || { echo …; exit 1; }` exits non-zero and is
+ * untouched. A rule keyed on command NAMES would have to know every checker that
+ * exists, and would still miss the shape — the same mistake command-shrink's guard
+ * made by comparing names.
  *
- * OUT OF SCOPE BY DESIGN: bare `|| true`. skip-escape.ts:11-19 records the FP
- * measurement — of 45 `||` uses in the historical VERIFY blocks exactly one was a
- * real skip-escape; a blanket `|| true` rule is ~90% false positives (teardown,
- * setup, negative tests). `rm -rf build || true` classifies CAN-FAIL here and must
- * keep doing so.
+ * OUT OF SCOPE BY DESIGN: bare `|| true`. As skip-escape.ts explains, most `||`
+ * uses are teardown, setup or a negative test rather than an escape, so a blanket
+ * rule would be almost all false positives. `rm -rf build || true` classifies
+ * CAN-FAIL here and must keep doing so.
  *
  * THREE OUTCOMES, and `unknown` is a first-class answer: a shape this cannot
  * decide is never guessed at, it is left alone (which is today's behaviour).
@@ -125,8 +119,8 @@ function hasPipeline(seg) {
  * EVERY remaining operator: `&&` skips what follows when the status is non-zero,
  * `||` skips it when the status is zero. A chain that mixes the two after `c_i`
  * therefore always runs on past it. For `A && B || C`: A is never terminal (the
- * `||` picks C up after A fails), B is terminal when it succeeds, C is terminal —
- * so the status is always an echo's, which is the run-21 shape.
+ * `||` picks C up after A fails), B is terminal when it succeeds, and C is
+ * terminal — so if B and C are both echoes the status is always an echo's.
  */
 function terminalIndices(ops, n) {
     const out = [];
@@ -167,7 +161,7 @@ function isPureEcho(cmd) {
     return !splitTopLevel(cmd, ['>>', '>']).ops.length;
 }
 /**
- * RULE A — a `console.assert` check. Measured, not assumed, in both runtimes:
+ * RULE A — a `console.assert` check. Run it yourself in either runtime:
  *
  *     $ bun  -e "console.assert(1===2,'X'); console.log('end')"; echo $?   → 0
  *     $ node -e "console.assert(1===2,'X'); console.log('end')"; echo $?   → 0