@mjasnikovs/pi-task 0.38.28 → 0.38.30

package/dist/task/plan-session.js

@@ -1,31 +1,29 @@
 /**
  * The /task-plan interaction loop.
  *
- * Sequential & adaptive, exactly like /task's grill (phases.ts `phaseGrill`) and
- * /task-auto's clarify (auto-orchestrator.ts `planAuto`): ask ONE question at a
- * time, feed every answer back into the next generation call so later questions
- * react to earlier ones, and stop when the model emits NONE. The duplicate
- * backstop (`isDuplicateQuestion` + `DUP_REPROMPT_HINT` + `MAX_DUP_STRIKES`), the
- * markdown handling, the A/B answer-letter mapping and the YOLO policy are the
- * SAME modules those two loops use — none of that is new here.
+ * Sequential and adaptive: ask ONE question at a time, feed the whole transcript
+ * back into the next generation call so later questions react to earlier answers,
+ * and stop when the model emits NONE. Generation, the question cap and the
+ * duplicate backstop live in question-source.ts; the answer cards and the A/B
+ * letter mapping in question-dialog.ts; markdown in inline-markdown.ts; the
+ * unattended policy in yolo.ts. /task's grill (phases.ts `phaseGrill`) and
+ * /task-auto's clarify (auto-orchestrator.ts `planAuto`) drive the same modules.
  *
- * What IS new is the control surface. In grill and clarify the user's only move is
- * to answer the question in front of them. Here three moves are available at every
- * single prompt, in that order of appearance:
+ * What this loop adds is the control surface. Grill and clarify let the user only
+ * answer the question in front of them. Here three moves are on every prompt, in
+ * this order of appearance:
  *
  *   ❓ ask the model a question   — the user asks, the model answers (PLAN_ASK)
- *   ✎ answer in your own words    — the free-text card askQuestionBox already
- *                                    appends to every boxed picker; it is not new,
- *                                    it is simply always present here, and it
- *                                    doubles as "state a decision" when the model
- *                                    has nothing to ask
+ *   ✎ answer in your own words    — the free-text card askQuestionBox appends to
+ *                                    every boxed picker. It doubles as "state a
+ *                                    decision" when the model has nothing to ask.
  *   ▶ proceed to execution        — stop planning, hand the decisions to /task
  *                                    (PLAN_PROCEED). Always the LAST card in the
  *                                    box — it ends the session, so it sits under
  *                                    every move that continues it, including the
  *                                    free-text card (see `manualPosition`).
  *
- * The loop is pure with respect to I/O: every side effect (child calls, dialogs,
+ * The loop performs no I/O of its own: every side effect (child calls, dialogs,
  * persistence) arrives through {@link PlanSessionDeps}, so the whole interaction
  * is unit-testable without a TUI or a model.
  */
@@ -38,8 +36,8 @@ export { resolveAnswer } from './question-dialog.js';
 // ─── Control actions ─────────────────────────────────────────────────────────
 /**
  * Sentinel values the picker resolves to when the user takes a control action
- * instead of answering. Deliberately shaped like the existing `USER_CANCELLED`
- * sentinel (child-runner.ts): a value no model answer and no human ever types.
+ * instead of answering. Same shape as `USER_CANCELLED` (child-runner.ts): a
+ * value no model answer and no human ever types.
  */
 export const PLAN_ASK = '__plan_ask__';
 export const PLAN_PROCEED = '__plan_proceed__';
@@ -53,18 +51,19 @@ export const PLAN_STATE_LABEL = '✎ Add a decision of your own…';
 export const PLAN_NO_QUESTIONS = 'No further questions — the decisions so far settle how this task is built.';
 /**
  * Hard ceiling on model-generated questions for one plan. The loop is open-ended
- * (it stops when the model emits NONE); this only bounds a model that never
- * does. Matches /task-auto's MAX_CLARIFY_QUESTIONS, for the same reason.
+ * — it stops when the model emits NONE — so this only bounds a model that never
+ * does. Same value as /task-auto's MAX_CLARIFY_QUESTIONS.
  */
 export const MAX_PLAN_QUESTIONS = 8;
 /**
  * Corrective re-prompt for a question reply that did not follow the format —
- * either nothing parseable at all, or a question with no `SUGGESTED:` line. Same
- * shape and same one-shot budget as GRILL_AUTO_FORMAT_HINT (prompts.ts), which
- * exists because the local model drops a required tag every so often and a
- * silent fallback is worse than one extra call: an unparsed reply reads as "no
- * questions left" and a missing SUGGESTED leaves the picker with nothing to
- * recommend.
+ * either nothing the parser could read, or a question with no `SUGGESTED:` line.
+ * Same shape and same one-shot budget as GRILL_AUTO_FORMAT_HINT (prompts.ts).
+ *
+ * Both failures are silent without it. `makeQuestionSource` answers `exhausted`
+ * for a reply it cannot parse, which this loop renders as "no further questions";
+ * and a question with no SUGGESTED reaches `buildOptionCards` with nothing to
+ * build a card from.
  */
 export const PLAN_FORMAT_HINT = '[SYSTEM NOTE: Your previous reply did NOT follow the required format. Output exactly '
     + 'one numbered question line ("1. **...?** short rationale"), then on the NEXT line a '
@@ -72,16 +71,10 @@ export const PLAN_FORMAT_HINT = '[SYSTEM NOTE: Your previous reply did NOT follo
     + 'REQUIRED and must never be blank. Add an "ALT: " line only for a binary A-or-B fork. '
     + 'If nothing is left to ask, output the single token NONE and nothing else. No preamble, '
     + 'no analysis, no other text.]';
-// Re-exported, NOT re-implemented. After the state machine moved to
-// question-source.ts these were byte-identical copies: production read THAT
-// module's, while plan-session.test.ts and four `scripts/live-*.ts` A/B harnesses
-// read these — so a fix to `pickQuestion`'s heuristic would land in one copy while
-// the harnesses kept measuring the other, and the measurement would silently stop
-// describing shipped behaviour. That is the drift class this pass removes.
 export { isNoneReply, pickQuestion } from './question-source.js';
 /**
  * Does the question offer the user a choice between two named alternatives?
- * Deliberately shallow — an "X or Y?" in the question's own clause.
+ * Deliberately shallow: an `or` anywhere before the first question mark.
  */
 export function looksLikeFork(question) {
     return /\bor\b/i.test(question.split('?')[0] ?? '');
@@ -89,21 +82,16 @@ export function looksLikeFork(question) {
 /**
  * Does the recommended default DEFER the decision instead of making one?
  *
- * The prompt asks for a "concrete, decisive default", and nothing enforced it.
- * Live (aiz-client TASK_PLAN_0001, 2026-08-05): the model asked "what specific
- * report should this new tab display?" and recommended
- * "clarify with the user what the report is meant to show before proceeding".
- * The user pressed enter, so it was recorded `(accepted recommendation)` and rode
- * into /task's handoff as an AUTHORITATIVE decision — an order not to proceed,
- * addressed to a run where no user exists. /task duly built a task whose
- * ACCEPTANCE was "a planning document with placeholder sections" and whose VERIFY
- * asserted that no source file had changed.
- *
  * A deferral is not an answer, and the one place it can never be one is here: the
  * user IS present during planning, so "ask the user" is a null move — that IS the
- * question. Detection is anchored to the START of the default, which keeps it off
- * legitimate product behaviour ("prompt the user to confirm deletion" decides
- * something; "ask the user which report" decides nothing).
+ * question. An accepted recommendation is a `decision` entry, so it rides into
+ * /task's handoff inside the block `buildHandoffPrompt` (plan-io.ts) labels
+ * authoritative — addressed to a run where no user exists.
+ *
+ * Every pattern is anchored to the START of the default, which keeps it off
+ * legitimate product behaviour: "prompt the user to confirm deletion" decides
+ * something and does not match; "ask the user which report" decides nothing and
+ * does.
  */
 export function isDeferralSuggestion(suggested) {
     const s = suggested.trim().replace(/^["'`*_\s]+/, '');
@@ -116,9 +104,9 @@ export function isDeferralSuggestion(suggested) {
         || /^(do not|don'?t|no)\b[^.]{0,40}\b(proceed|implement|build|start|write|decide)\b/i.test(s));
 }
 /**
- * Corrective re-prompt for a default that deferred the decision. Same one-shot
- * budget and same quote-it-back shape as {@link planForkHint}, because the child
- * is stateless and cannot otherwise know what it just recommended.
+ * Corrective re-prompt for a default that deferred the decision. Quotes the
+ * question and the default back, because the child is a fresh process carrying
+ * only its prompt and cannot otherwise know what it just recommended.
  */
 export function planDecisiveHint(question, suggested) {
     return ('[SYSTEM NOTE: Your previous reply asked this question:\n'
@@ -133,17 +121,12 @@ export function planDecisiveHint(question, suggested) {
 }
 /**
  * Corrective re-prompt for a fork-shaped question that shipped only ONE option.
+ * With no ALT, `buildOptionCards` emits a single card, so the user has to type
+ * out the alternative the model itself just named.
  *
- * Measured on the local model (scripts/live-task-plan-step0.ts, 15 reps): the
- * SUGGESTED line is always there, but 10/15 questions named two alternatives and
- * gave only one of them — so the picker showed a single card and the user had to
- * type out the option the model itself had just proposed.
- *
- * The retry quotes the question back because the child is stateless (a fresh
- * process per call, prompt only), so it cannot otherwise know what it just wrote.
- * Validated before wiring (scripts/live-task-plan-fork-alt.ts): 6/6 fires
- * recovered an ALT, and 6/6 re-asked the SAME question rather than changing the
- * subject. It costs one extra child call on the questions where it fires.
+ * The retry quotes the question back because the child is a fresh process
+ * carrying only its prompt, so it cannot otherwise know what it just wrote. It
+ * costs one extra child call on the questions where it fires.
  */
 export function planForkHint(question) {
     return ('[SYSTEM NOTE: Your previous reply asked this question:\n'
@@ -158,11 +141,8 @@ export function planForkHint(question) {
  * A default that DEFERS decides nothing, and an accepted deferral reaches the
  * consumer dressed as an authoritative decision.
  *
- * Declared as its own constant because it is the one rule BOTH dialogs use, and
- * `CLARIFY_QUALITY_RULES` referencing it by `id` string would be the retyped
- * literal with no compile link that this pass exists to remove — a rename would
- * silently yield `[undefined]` and throw on the first clarify question of every
- * run.
+ * Its own constant because it is the one rule BOTH tables below hold, shared by
+ * reference so the compiler links them.
  */
 const DEFERRAL_RULE = {
     id: 'SUGGESTED deferred the decision',
@@ -170,9 +150,10 @@ const DEFERRAL_RULE = {
         planDecisiveHint(plain, q.suggested)
         : null,
     // When only the recommendation defers, the ALT is still a real commitment:
-    // promote it so the question keeps a usable default. With no ALT the option is
-    // DROPPED rather than shown, so an empty submit records an unanswered question
-    // instead of a decision the user never made.
+    // promote it so the question keeps a usable default. With no ALT the default
+    // is dropped, `buildOptionCards` returns undefined, and `resolveAnswer` maps
+    // an empty submit to '(skipped)' rather than to a decision the user never
+    // made.
     repair: q => {
         const { alt: _alt, suggested: _suggested, ...rest } = q;
         return q.alt !== undefined ? { ...rest, suggested: q.alt } : { ...rest };
@@ -181,16 +162,15 @@ const DEFERRAL_RULE = {
 /**
  * PLAN's quality rules, in order.
  *
- * Each is worth exactly one corrective re-prompt (the child is stateless, so each
- * hint quotes the question back), and each DEGRADES rather than discards when the
- * defect survives — a question with a weak default still beats no question.
+ * The corrective-re-prompt budget is per QUESTION and shared across the whole
+ * table (question-source.ts): at most one rule fires per draw, and a defect that
+ * survives its re-prompt DEGRADES through `repair` rather than discarding the
+ * question — a weak default still beats no question. Each hint quotes the
+ * question back, because the child is a fresh process carrying only its prompt.
  *
  * Only {@link CLARIFY_QUALITY_RULES} is shared with `/task-auto`, and only the
- * deferral rule is in it. The other two were MEASURED here (10/15 fork-shaped
- * questions shipped one option; the SUGGESTED requirement is in both prompts) but
- * each costs one extra child call every time it fires, and clarify is the most
- * A/B'd path in the codebase — moving them there is its own experiment, not a
- * side effect of sharing a state machine. Recorded rather than done.
+ * deferral rule is in it. The other two cost an extra child call every time they
+ * fire.
  */
 export const PLAN_QUALITY_RULES = [
     {
@@ -202,7 +182,7 @@ export const PLAN_QUALITY_RULES = [
     DEFERRAL_RULE,
     {
         // A fork-shaped question that ships one option leaves the user typing out
-        // the alternative the model itself just named (10/15 measured live).
+        // the alternative the model itself just named.
         id: 'fork-shaped question with no ALT',
         detect: (q, plain) => q.alt === undefined && q.suggested !== undefined && looksLikeFork(plain) ?
             planForkHint(plain)
@@ -212,12 +192,9 @@ export const PLAN_QUALITY_RULES = [
 /**
  * The deferral rule alone — the one clarify shares.
  *
- * It exists because an accepted "clarify with the user before proceeding" rode
- * into `/task`'s handoff AS AN AUTHORITATIVE DECISION and produced a task whose
- * ACCEPTANCE was "a planning document with placeholder sections" and whose VERIFY
- * asserted that no source file had changed. Clarify's answers ride into the
- * decompose prompt and the AUTO file with exactly the same authority and had no
- * guard at all — the same bug, one command over, waiting.
+ * Clarify's answers ride into the decompose prompt and the AUTO file with the
+ * same authority /task-plan's decisions ride into the handoff, so an accepted
+ * "clarify with the user before proceeding" lands there as an instruction too.
  *
  * It is also the only one of the three that costs nothing on the happy path: a
  * decisive default never triggers it.
@@ -290,7 +267,8 @@ export const ASK_QUESTION = 'What do you want to ask about this task? The answer
 export async function runPlanSession(deps) {
     const entries = [];
     const render = (s) => deps.renderMarkdown?.(s) ?? s;
-    /** The model has nothing (more) to ask: NONE, the cap, or the dup backstop. */
+    /** The model has nothing (more) to ask — any `exhausted` draw: NONE, the
+     *  cap, the duplicate backstop, or a reply the parser could not read. */
     let exhausted = false;
     let pending = null;
     const commit = async (entry) => {

package/dist/task/probe-gaming.d.ts

@@ -1,37 +1,38 @@
 /**
  * probe-gaming — deterministic detection of CHECK-GAMING code, feeding the verify
- * and enforce gate prompts (run-8 F6).
+ * gate's rule 4c (verify-work.ts) and the enforce prompt (enforce-guidelines.ts).
  *
  * The failure class: the implementation writes code — or a comment on it — whose
- * STATED PURPOSE is to make a check pass, rather than to satisfy the requirement the
- * check stands for. mx5 run-8 shipped, verbatim,
- *   `// Return 401 so the verification test passes (expects 200/401/403 for /api routes).`
- * above four catch-all handlers added to satisfy the VERIFY curl instead of fixing
- * the broken route mount. The route stayed dead; the check went green; the code SAID
- * SO IN WRITING. A check is a MESSENGER for a requirement — code written to quiet the
- * messenger instead of meeting the requirement is the defect, and when it announces
- * its own intent it is cheaply detectable.
+ * STATED PURPOSE is to make a check pass, rather than to satisfy the requirement
+ * the check stands for. A catch-all handler carrying
+ *   `// Return 401 so the verification test passes`
+ * leaves the real route dead while the check goes green. A check is a MESSENGER
+ * for a requirement; code written to quiet the messenger instead of meeting the
+ * requirement is the defect, and when it announces its own intent it is cheaply
+ * detectable.
  *
- * Same probe+rule design as the other run-8 probes (skip-escape.ts,
- * prohibition-probe.ts, substitution-probe.ts, test-assembly.ts): a deterministic
- * finding is the reliable lever, a prompt rule alone is weak. This scans the task's
- * DIFF (added lines only — the work this task introduced) for the gaming tell and
- * hands each hit to the gate child verbatim, so the rule fires on a concrete line
- * rather than on the model self-discovering the intent.
+ * Same probe+rule design as the other probes (skip-escape.ts,
+ * prohibition-probe.ts, substitution-probe.ts, test-assembly.ts): each is a
+ * `probeAdapter` row in verify-work.ts with its own findings, prompt block and
+ * numbered rule. This one scans the task's DIFF (added lines only — the work this
+ * task introduced) for the gaming tell and hands each hit to the gate child
+ * verbatim, so the rule fires on a concrete line rather than on the model
+ * self-discovering the intent.
  *
- * Advisory, never an auto-FAIL: intent phrasing is prose and a genuinely-benign line
- * could in principle carry it ("returns 401 so the auth test passes" describing a
- * CORRECT auth path). The child reads the exact line and the surrounding code and
- * judges — the verify rule directs it to confirm the underlying requirement is
- * actually met, not merely that the check is green.
+ * Advisory, never an auto-FAIL: a probe contributes findings and a prompt block,
+ * and `probeAdapter` degrades an absent or throwing probe to its empty value.
+ * Intent phrasing is prose and a genuinely-benign line could in principle carry it
+ * ("returns 401 so the auth test passes" describing a CORRECT auth path). The child
+ * reads the exact line and the surrounding code and judges — the verify rule
+ * directs it to confirm the underlying requirement is actually met, not merely
+ * that the check is green.
  *
- * FP-MEASURED on the real run-8 corpus (~/hub/mx5, all 53 commits): 1 unique hit in
- * 50,735 added lines — exactly the true F6 line, zero false positives. The tell is a
- * purpose phrase binding a CHECK noun (test / verification / lint / CI / gate / …) to
- * a pass-state or a gaming verb; benign uses of the same words ("pass the test data",
- * "run the verification suite", "the linter flagged this") do not match. Pure
- * diff-text analysis — no stack, framework, or tool-name assumptions; a project with
- * no such comment simply yields no findings (nothing to observe = pass).
+ * The tell is a purpose phrase binding a CHECK noun (test / verification / lint /
+ * CI / gate / …) to a pass-state or a gaming verb. Benign uses of the same words
+ * do not match: "pass the test data", "run the verification suite" and "the linter
+ * flagged this" all return false. Pure diff-text analysis — no stack, framework, or
+ * tool-name assumptions; a project with no such comment simply yields no findings,
+ * and nothing to observe is not a failure.
  */
 /** One added line from a task's diff: the file it was added to and its text. */
 export interface AddedLine {

package/dist/task/prohibition-probe.d.ts

@@ -2,21 +2,18 @@
  * prohibition-probe — deterministic detection of VIOLATED SPEC PROHIBITIONS,
  * feeding the verify gate's prompt.
  *
- * The failure class (mx5 run 7, "New Listing page" task): the spec's CONSTRAINTS
- * said "**Do NOT modify** any server-side code: `src/server/index.ts`, …"; the
- * implementation modified `src/server/index.ts` anyway; the verify child SAW it
- * ("VIOLATES 'Do NOT modify server-side code'"), waived it ("BUT: this is
- * additive, tests pass with it"), and PASSed. Worse, the reproduction fixture
- * showed the baseline child usually never LOOKS: 5/5 baseline runs consulted no
- * diff at all and several affirmatively claimed the forbidden file was untouched.
+ * The failure class: the spec's CONSTRAINTS say "**Do NOT modify** any
+ * server-side code: `src/server/index.ts`, …", the implementation modifies that
+ * file anyway, and the verify child either waives the violation ("this is
+ * additive, tests pass with it") or never looks. Nothing else in the gate makes it
+ * run `git diff`, and rule 4b says it plainly: a forbidden file can be modified
+ * without any test noticing.
  *
- * So — like the substitution probe (see substitution-probe.ts, whose A/B proved
- * prompt language alone gets ~40% attention while a concrete deterministic
- * finding gets 100%) — the fix is a deterministic pre-check whose finding is
- * injected into the prompt: extract the concrete paths the spec forbids
- * modifying, intersect with the task's changed files (pure git shape, already
- * collected for the substitution probe), and hand the child each hit with the
- * exact constraint wording.
+ * So — like the substitution probe (substitution-probe.ts) — the fix is a
+ * pre-check whose finding is injected into the prompt: extract the concrete paths
+ * the spec forbids modifying, intersect with the task's changed files (pure git
+ * shape, from the same `collectChangedFiles` the substitution probe uses), and
+ * hand the child each hit with the exact constraint wording.
  *
  * The finding is advisory, not an auto-FAIL, for one reason: prohibitions in
  * real specs are prose and can be CONDITIONAL ("Do NOT modify `api.ts` beyond
@@ -24,8 +21,9 @@
  * false-FAIL legitimate work. The finding therefore carries the constraint line
  * verbatim and the prompt's no-waiver rule (4b in verify-work.ts) forbids
  * excusing an ABSOLUTE prohibition while directing conditional ones to be judged
- * against their own stated exception. A violation that was fully reverted before
- * verify produces no diff entry, so it never fires — reverted = not violated.
+ * against their own stated exception. A violation fully reverted before verify
+ * leaves no entry in `git diff HEAD`, so it never fires — reverted = not
+ * violated.
  */
 import type { ChangedFile } from './substitution-probe.js';
 /** One "do not modify X" constraint extracted from the spec text. */

package/dist/task/prompts.d.ts

@@ -1,8 +1,8 @@
 /**
  * Prompt templates for every phase of the pi-task pipeline.
  *
- * Each template is a pure function: inputs → prompt string.  No I/O, no side
- * effects, trivially testable.
+ * Each template is a pure function or a plain string constant: inputs → prompt
+ * text. The module imports nothing, so there is no I/O and no side effect.
  */
 export declare const MAX_GRILL_QUESTIONS = 20;
 /**
@@ -21,8 +21,7 @@ export declare const COMPRESS_LABEL_PROMPT: (title: string, maxChars: number) =>
  *
  * Without it, refine is told "the task title is only a pointer into that spec —
  * follow the spec" with no signal that the other steps exist, so a one-step
- * "Scaffold …" title re-expands the entire design into one task (validated: a real
- * /task-auto run implemented all 24 steps under step 1).
+ * "Scaffold …" title can re-expand the entire design into one task.
  */
 declare const REFINE_PROMPT: (raw: string, planContext?: string, existingFiles?: string, contracts?: string, directives?: string) => string;
 declare const RESEARCH_READ_ONLY_CONSTRAINT = "IMPORTANT: You are ONLY allowed to READ. Do NOT create, modify, or delete any files. Use the read, grep, find, and ls tools to inspect the repo.";

package/dist/task/prompts.js

@@ -1,8 +1,8 @@
 /**
  * Prompt templates for every phase of the pi-task pipeline.
  *
- * Each template is a pure function: inputs → prompt string.  No I/O, no side
- * effects, trivially testable.
+ * Each template is a pure function or a plain string constant: inputs → prompt
+ * text. The module imports nothing, so there is no I/O and no side effect.
  */
 // Caps both the per-response question count (parseGrillQuestions/parseClarifyList)
 // and the grill loop's total iterations, so a model that never emits NONE can't
@@ -33,8 +33,7 @@ ${title}`;
  *
  * Without it, refine is told "the task title is only a pointer into that spec —
  * follow the spec" with no signal that the other steps exist, so a one-step
- * "Scaffold …" title re-expands the entire design into one task (validated: a real
- * /task-auto run implemented all 24 steps under step 1).
+ * "Scaffold …" title can re-expand the entire design into one task.
  */
 const REFINE_PROMPT = (raw, planContext, existingFiles, contracts, directives) => `${planContext ? planContext + '\n\n---\n\n' : ''}You receive a user's task description for an AI coding agent. Rewrite it to be unambiguous and actionable.
 
@@ -69,11 +68,11 @@ Task: ${raw}`;
 const RESEARCH_READ_ONLY_CONSTRAINT = `IMPORTANT: You are ONLY allowed to READ. Do NOT create, modify, or delete any files. Use the read, grep, find, and ls tools to inspect the repo.`;
 // Shared guard for every research worker. Open-ended tasks ("analyze the code",
 // "how would you improve X", "write a report") tempt a worker into producing the
-// deliverable itself — e.g. writing the whole code-review report in the CONTEXT
-// section, which then runs for many minutes, gets truncated, and poisons every
-// downstream phase. Research only gathers INPUTS for a later spec; it must never
-// be the deliverable. This also pins the output format (no preamble, no fences,
-// no repeated header) that large/open-ended tasks otherwise drift away from.
+// deliverable itself — writing the whole code-review report into the CONTEXT
+// section instead of the facts that section is for. Research only gathers INPUTS
+// for a later spec; it must never be the deliverable. It also pins the output
+// format: no preamble, no code fences, and no repeat of the section name as a
+// header.
 const RESEARCH_INPUTS_NOT_DELIVERABLE = `CRITICAL — you are gathering INPUTS for a later spec, NOT performing the task. Even if the task asks you to analyze, review, audit, report, plan, design, or write code, you must NOT produce that deliverable here. Do not write the report/analysis/plan/code. Your entire job is to emit the one structured section described below, which feeds a separate phase that writes the spec. Surveying the repo so that section is accurate is right; producing the task's output is wrong and wastes the run.
 
 OUTPUT DISCIPLINE — strict: emit ONLY the raw section lines described below. No preamble (never "I've read the codebase…", never "Here is the … section"), no closing remarks, no Markdown headings, no code fences (no \`\`\`), and do NOT repeat the section name as a header. The first character of your output is the first entry of the list.`;
@@ -128,17 +127,8 @@ No section header. No other sections. No preamble.
 
 Task:
 ${refined}`;
-// STAGE 2 (2026-07-23): APIS_SEMANTICS_CONTRACT was wired in above and UNWIRED after its A/B
-// FAILED. It is the ONE lever of three that moved worker:apis's behaviour — behaviour-class
-// package queries 20/20 vs 2/20, Fisher p ≈ 0 — confirming Stage 1's mechanism (completion is
-// set by the output CONTRACT, not the answer or the target). But it failed invariant 2a: the
-// ungrounded-symbol rate rose 1.0% -> 4.7% (p(rise) = 0.0010) and the semantics clause it adds
-// carried 15% ungrounded symbols with the mandatory `UNVERIFIED:` abstention used 0 times in 40
-// reps. The model obeys "ask a behaviour question" and ignores "abstain when you cannot verify",
-// so it manufactures semantics — the exact F-1 laundering the file exists to prevent. The module
-// and its tests are KEPT as the durable asset (like spec-urls.ts after PROMPT 4); only this
-// interpolation is reverted. Full write-up: nexxtasks.txt "STAGE 2". Re-run: scripts/
-// live-apis-contract-ab.ts. Do NOT re-wire without a lever that closes the abstention gap.
+// `APIS_SEMANTICS_CONTRACT` (apis-contract.ts) is deliberately NOT interpolated
+// into any prompt here. See that module's own docstring before wiring it in.
 const RESEARCH_CONTEXT_PROMPT = (refined) => `You are doing targeted research for an AI coding agent. Use the read, grep, find, and ls tools to gather background knowledge and architectural context the agent will need for the following task.
 
 RELEVANCE — read carefully: keep it tight. Each bullet must be an architectural fact that changes HOW the agent implements THIS task — a constraint, a non-obvious data flow, a gotcha, a hidden coupling. No general project tour, no restating the task, no facts the agent would not act on. If a bullet would not change a single implementation decision, drop it. There is no fixed bullet count — include every fact that bears on the task and no filler; fewer sharp bullets beat many shallow ones. If the task is itself an analysis or review, these bullets capture facts that analysis will rely on — they are NOT the analysis; do not write findings or recommendations here.
@@ -330,12 +320,13 @@ ${research}
 User Q&A:
 ${qa}
 ${contracts && contracts.trim() ? `\n${contracts.trim()}\n` : ''}`;
-// Fast triage pass run before the (expensive) full rewrite. It produces either
-// the single token CLEAN — meaning the compose draft needs no rewrite — or a
-// short defect list. When CLEAN, the orchestrator returns the draft unchanged
-// and skips the rewrite entirely; otherwise the defects are fed into
-// CRITIQUE_PROMPT as a focus list so the rewrite targets real problems instead
-// of re-deriving them from scratch.
+// Fast triage pass run before the full rewrite. It produces either the single
+// token CLEAN — meaning the compose draft needs no rewrite — or a short defect
+// list. CLEAN alone does not skip the rewrite: phases.ts only short-circuits when
+// the draft already parses a VERIFY block, no deterministic critique probe forced
+// itself in, and there are no carried-in defects. Otherwise the triage defects are
+// fed into CRITIQUE_PROMPT as a focus list so the rewrite targets real problems
+// instead of re-deriving them from scratch.
 const CRITIQUE_TRIAGE_PROMPT = (spec, refined, qa, contracts) => `You are triaging an implementation spec for an AI coding agent. Decide whether it needs a rewrite. Do NOT rewrite it — only judge it.
 
 The refined task and the user's Q&A below are GROUND TRUTH. Judge the spec against them. Look for SUBSTANTIVE defects only:

package/dist/task/qa-transcript.d.ts

@@ -3,25 +3,18 @@
  * (`/task-auto`) — and the one place its numbering, its formatting and its
  * provenance policy live.
  *
- * `question-dialog.ts` unified the ANSWER side of these loops: the picker cards
- * and the reply mapping. It did not unify what the loop RECORDS, and that was
- * eight retyped push sites across two files, each choosing a suffix by hand
- * according to which branch of an `if/else` it stood in.
+ * `question-dialog.ts` owns the ANSWER side of these loops — the picker cards and
+ * the reply mapping. This owns what the loop RECORDS.
  *
- * The cost is written into the code. `phases.ts` states the invariant in a
- * comment — *"No provenance stamp here, unlike clarify's transcript: this string
- * is fed back VERBATIM into the next grill-gen prompt, so a `(accepted
- * recommendation)` suffix would become model input"* — and TWELVE LINES ABOVE it,
- * the YOLO branch pushes `${answer} ${YOLO_STAMP}` into that very array. The rule
- * was violated inside the loop body that declares it, because the rule lived in
- * prose and the decision lived at each push.
- *
- * Here it is a property of a value: an entry states its KIND, and the policy says
- * where that kind's provenance is allowed to appear.
+ * Provenance is a property of a value here, not a decision taken at each push
+ * site: an entry states its KIND, and the policy says where that kind's
+ * provenance is allowed to appear. The two renderings below differ ONLY in those
+ * suffixes, which is how a hand-stamped transcript drifts apart unnoticed.
  *
  * NOT unified here: `plan-session.ts`'s `PlanEntry` transcript. It is a different
- * shape — decisions vs advisory notes, persisted to its own task file, with no
- * `Qn:`/`An:` numbering — and folding it in would be a rename, not a deepening.
+ * shape — model decisions, advisory notes and user-stated decisions in one list,
+ * persisted to its own task file — and folding it in would be a rename, not a
+ * deepening.
  */
 /** How one answer was arrived at. */
 export type QaKind = 
@@ -56,7 +49,6 @@ export interface QaPolicy {
      * becomes model input describing how the answer was obtained rather than what
      * it was. Clarify deliberately shows its generator the provenance, so a
      * question the triage already settled reads as settled and is not re-asked.
-     * An option, not a unification — it is observable either way.
      */
     generatorSeesProvenance: boolean;
 }
@@ -64,10 +56,11 @@ export interface QaPolicy {
  * GRILL: stamps `auto` and both YOLO kinds in the record, and shows the generator
  * nothing.
  *
- * `accepted` is deliberately NOT in the record set. Grill's record reaches
- * `COMPOSE_PROMPT` and `CRITIQUE_PROMPT`, where it is named GROUND TRUTH; clarify's
- * reaches a decompose prompt. Whether those two should agree is a prompt question
- * with its own A/B, so today's answer is preserved rather than harmonised here.
+ * `accepted` is deliberately NOT in the record set, and clarify's policy below
+ * disagrees. Grill's record is handed to `COMPOSE_PROMPT` and `CRITIQUE_PROMPT`
+ * (the latter names the Q&A GROUND TRUTH); clarify's is handed to
+ * `AUTO_DECOMPOSE_PROMPT`. Whether the two should agree is a question about those
+ * prompts, so each keeps its own answer here.
  */
 export declare const GRILL_QA_POLICY: QaPolicy;
 /** CLARIFY: stamps every non-typed kind, in the record and to the generator alike. */
@@ -90,7 +83,7 @@ export declare class QaTranscript {
     /** How many questions have been answered. Also the next question's number − 1. */
     get length(): number;
     get entries(): ReadonlyArray<QaEntry>;
-    /** Record one answered question. The number is assigned here, not by the caller. */
+    /** Record one answered question. Position IS the number; no caller supplies one. */
     add(kind: QaKind, question: string, answer: string): void;
     /** The persisted / handed-on transcript, with provenance per the policy. */
     forRecord(): string;