@mjasnikovs/pi-task 0.38.29 → 0.38.30

package/dist/task/owned-freeze-conflict.js

@@ -1,79 +1,43 @@
 /**
- * owned-freeze-conflict — the FIFTH unsatisfiable-pair family (nexttask 7):
- * an AUTHORITATIVE owned requirement whose file falls inside a CATEGORY freeze
- * written by the same spec.
+ * owned-freeze-conflict — an unsatisfiable spec pair: an AUTHORITATIVE owned
+ * requirement whose file falls inside a CATEGORY freeze written by the same spec.
  *
- * WHY frozen-conflict.ts does not see it (mx5 run 18, TASK_0023). The owned
- * channel worked: `.pi-tasks/requirements-owned.md` carried the design clause
- * "**Server:** `bun run --watch src/server/index.ts` — serves `/api` + static
- * `dist/`." and the composed spec carried it verbatim under CONSTRAINTS, marked
- * AUTHORITATIVE. The same CONSTRAINTS block then said "Do not modify
- * `docker-compose.dev.yml`, …, or any source files outside of `package.json`",
- * and the spec's ACCEPTANCE/VERIFY converted the behavioural half of the clause
- * ("serves `/api` + static `dist/`") into a string-match on `package.json`. The
- * only file that could implement it — `src/server/index.ts` — was frozen. The
- * requirement was structurally unsatisfiable inside its owning task, VERIFY
- * PASSed honestly, and the app shipped with no static route.
+ * THE SHAPE. A spec carries a design clause verbatim under CONSTRAINTS, marked
+ * AUTHORITATIVE, whose behavioural half can only be satisfied inside one file —
+ * and the same spec freezes a category of files that covers that file. The task's
+ * own VERIFY can then only assert strings in the files it is allowed to touch, so
+ * it PASSes honestly while the requirement is never met.
  *
- * The existing detector misses this shape twice over (both visible in its own
- * header): its freeze side needs a NAMED path (`pathNamedIn`), and run 18's
- * freeze names a CATEGORY ("any source files outside of `package.json`"); its
- * statement side must match one of four measured phrasing families, and a plain
- * behavioural claim matches none of them.
+ * WHY frozen-conflict.ts does not see it. Its freeze side needs a NAMED path
+ * (`pathNamedIn`), and a category freeze names a CLASS instead. Its statement side
+ * must match one of a fixed set of registration phrasings, and a plain behavioural
+ * claim matches none of them.
  *
  * HIGH-PRECISION BY CONSTRUCTION — the statement side needs no NLP:
  *   - owned requirement lines are MACHINE-MARKED. `appendOwnedConstraints`
- *     stamps every one it appends with "owned requirement from the source
- *     design (AUTHORITATIVE; …)"; when compose folded the quote in by itself
- *     the marker is absent, so the caller may also pass the run's ledger
- *     entries and the quote is matched verbatim against the spec text.
+ *     (requirements.ts) stamps every bullet it appends with "— owned requirement
+ *     from the source design (AUTHORITATIVE; satisfy it in this task, do not
+ *     narrow it)". When compose folded the quote in by itself the marker is
+ *     absent, so the caller may also pass the run's ledger entries and the quote
+ *     is matched verbatim against the spec text.
  *   - the requirement names its path literally, so the intersection is lexical.
- *   - category freezes are a small closed lexical set ("any source files
- *     outside of X", "any files other than X", "only X may be modified",
- *     "no files outside X").
+ *   - category freezes are a small closed lexical set ("any source files outside
+ *     of X", "any files other than X", "only X may be modified", "no files
+ *     outside X").
  *
- * ── STATUS, 2026-08-05: WIRED — but as a DETACH, not as a rewrite. ──────────
- *
- * `owned-freeze-reassign.ts` consumes this detector at the last spec-producing
- * step (`phases.ts`, right after `appendOwnedConstraints`) and resolves a finding
+ * WHERE IT RUNS, AND WHY IT CANNOT RUN EARLIER. `owned-freeze-reassign.ts`
+ * consumes this detector inside `critiquePhase`, immediately after
+ * `appendOwnedConstraints` — the last spec-producing step. It resolves a finding
  * by BOOKKEEPING: the requirement leaves the task that cannot satisfy it and is
  * claimed later by the task whose refined prompt says it writes the frozen file.
- * The quote is never edited, so the deletion failure below cannot recur. A/B-1
- * (scripts/owned-freeze-reassign-ab.ts) PASSes on the corpus with five
- * invariants. The rewrite lever recorded below stays REFUTED and unwired.
- *
- * ── The critique-REWRITE seam FAILED its A/B, 2026-08-04. ────────────────────
- *
- * The detector is precise — 1 finding over 58 real composed specs, and it is the
- * true positive (scripts/owned-freeze-conflict-fp-suite.ts, PASS; STEP 0 in
- * scripts/owned-vs-freeze-baserate.ts). What failed is the LEVER built on it,
- * for two independent reasons, both measured:
+ * The quote itself is never edited.
  *
- *  1. THE SEAM IS BLIND IN PRODUCTION. `appendOwnedConstraints` — the BRACES that
- *     stamp the machine-marked owned bullet this detector keys on — runs AFTER
- *     `critiqueWithFallback`, inside the `critique` step (phases.ts). When
- *     critique runs, the stamped line does not exist yet; compose's own folding
- *     is a PARAPHRASE ("The server watch command must match the contract exactly:
- *     `…` — serves `/api` + static `dist/`"), so neither the stamp nor the
- *     verbatim quote is there to match. Live: 0/40 compose drafts carried a
- *     detectable pair while 11/40 carried the clause semantically. A critique-
- *     time probe cannot see the shape it was designed for.
- *  2. THE REWRITE RESOLVES IT BY DELETING THE REQUIREMENT. Forced through the
- *     controlled critique seam on run 18's real TASK_0023 draft (n=20/arm):
- *     pair-present 8/20 → 0/20, but the resolution was scoped ownership in only
- *     9/20 — the other 11/20 removed the AUTHORITATIVE clause outright and
- *     rationalised it ("this references an existing file; no edits are required
- *     or permitted"), with 0 of the 11 reassigning it to the task that owns the
- *     file. VERIFY behaviour-observation was 6/20 in BOTH arms: the delivered
- *     spec still verifies the requirement by grepping `package.json`.
+ * A critique-time probe cannot work, because `critiquePhase` calls
+ * `critiqueWithFallback` BEFORE `appendOwnedConstraints`: when critique runs, the
+ * stamped line does not exist yet, and compose's own folding is a paraphrase, so
+ * neither the stamp nor a verbatim quote is there to match.
  *
- * Removal of the pair is not satisfaction of the requirement — the same lesson
- * as the run-16 lever's delivery metric, one level down. Anything built here
- * next has to act AFTER the braces, where the pair actually exists, and cannot
- * be a model rewrite: the braces are the last spec-producing step.
- *
- * It is a pure text function so the base rate, the FP suite and the live A/B all
- * measure the same object.
+ * It is a pure text function, so a test measures the same object production does.
  */
 import { PROHIBITION_RE } from './prohibition-probe.js';
 import { pathNamedIn } from './frozen-path-guard.js';
@@ -87,14 +51,14 @@ const OWNED_MARKER_RE = /owned\s+requirement\s+from\s+the\s+source\s+design/i;
  * Modification verbs, shared by the active and passive freeze families. Scoped
  * to modification exactly as `PROHIBITION_RE` is: a "do not CREATE any files
  * other than X" line is a creation ban and freezes no existing file, so it must
- * never be read as a category freeze (mx5 run 18 TASK_0009 ships that line).
+ * never be read as a category freeze.
  */
 const MOD_VERB = 'modif|touch|edit|chang|alter|rewrit|overwrit';
 /**
  * A category noun phrase with an exception: "any source files outside of X",
- * "any existing file other than X", "no files except X". `\w+` slots absorb the
- * qualifiers seen in the corpora (source/existing/other), bounded so the phrase
- * cannot span a whole paragraph.
+ * "any existing file other than X", "no files except X". The `\w+` slots absorb
+ * qualifiers like source/existing/other, and are bounded so the phrase cannot
+ * span a whole paragraph.
  */
 const CATEGORY_NOUN = String.raw `(?:any|no)\s+(?:\w+\s+){0,3}?files?\b`;
 const EXCEPT_KEYWORD = String.raw `(?:outside(?:\s+of)?|other\s+than|except(?:\s+for)?|besides|apart\s+from|beyond)`;
@@ -108,8 +72,8 @@ const ACTIVE_CATEGORY_RE = new RegExp(String.raw `\b(?:do\s+not|do\s+NOT|don'?t|
     + String.raw `(?:(?!\b(?:creat|add|introduc|generat)\w*\b)[\s\S]){0,200}?`
     + String.raw `\b${CATEGORY_NOUN}[^\n]{0,40}?\b${EXCEPT_KEYWORD}\b`, 'i');
 /**
- * Passive family: "No files other than `package.json` are modified." — run 18's
- * ACCEPTANCE line, identical in force to the CONSTRAINTS freeze above it.
+ * Passive family: "No files other than `package.json` are modified." — the shape
+ * an ACCEPTANCE line takes, identical in force to a CONSTRAINTS freeze.
  */
 const PASSIVE_CATEGORY_RE = new RegExp(String.raw `\b${CATEGORY_NOUN}[^\n]{0,40}?\b${EXCEPT_KEYWORD}\b`
     + String.raw `[^\n]{0,120}?\b(?:are|is|may|must|should|can|will)\s+(?:be\s+|been\s+)?(?:${MOD_VERB})\w*`, 'i');
@@ -147,8 +111,8 @@ function tokensWithOrigin(text) {
                 continue;
             }
             // A leading `/` is a route literal or an absolute path — never a
-            // repo-relative source file, and `/api` is named by the very clause
-            // that is the true positive, so this one is not hypothetical.
+            // repo-relative source file. Behavioural clauses routinely name routes
+            // (`/api`) beside the file that serves them.
             if (token.startsWith('/'))
                 continue;
             const n = token.replace(/^\.\//, '').replace(/\/+$/, '');
@@ -164,8 +128,7 @@ function tokensWithOrigin(text) {
  * Does the requirement claim anything about the files it names BEYOND quoting a
  * command that mentions them?
  *
- * This is what separates the two build-contract clauses of mx5 run 18's
- * TASK_0023, which are otherwise the same shape:
+ * This is what separates two build-contract clauses of the same shape:
  *
  *   "**Client CSS:** `bunx @tailwindcss/cli -i src/client/index.css -o dist/app.css`"
  *   "**Server:** `bun run --watch src/server/index.ts` — serves `/api` + static `dist/`."
@@ -191,7 +154,7 @@ function hasClaimOutsideCommand(requirement) {
  * The clause the exception keyword governs: from the keyword to the first
  * clause break (an em dash, a semicolon, or a sentence end). Everything else on
  * the line — notably the "— all engine modules (`document.ts`, …) must remain
- * untouched" tail of gofer-pixel's freeze — is NOT an exemption.
+ * untouched" tail of a freeze — is NOT an exemption.
  */
 function exemptClause(line) {
     const m = new RegExp(String.raw `\b${EXCEPT_KEYWORD}\b`, 'i').exec(line);
@@ -231,8 +194,8 @@ const basename = (p) => p.slice(p.lastIndexOf('/') + 1);
  * Is `p` inside the freeze — i.e. NOT one of the exempted paths, a file under
  * an exempted directory, or the same file spelled shorter?
  *
- * The last clause is load-bearing. gofer-pixel TASK_0011 exempts
- * `src/components/Canvas.tsx` while its owned requirement quotes the design's
+ * The last clause is load-bearing. A spec can exempt
+ * `src/components/Canvas.tsx` while its owned requirement quotes a design's
  * table cell, which says just `Canvas.tsx` — the same file, and the spec is
  * correctly formed. A bare basename is matched against the exempted paths'
  * basenames; a path WITH a directory must match exactly or by prefix, so
@@ -300,8 +263,8 @@ export function findOwnedFreezeConflicts(spec, opts = {}) {
         if (named.length === 0)
             continue;
         // One finding per requirement: the FIRST freeze that covers any of its
-        // files. A spec that restates the same freeze under ACCEPTANCE (run 18
-        // does) must not double the rewrite's work.
+        // files. A spec that restates the same freeze under ACCEPTANCE must not
+        // double the rewrite's work.
         for (const f of freezes) {
             const paths = named.filter(p => insideFreeze(p, [...f.exempt, ...granted]));
             if (paths.length === 0)
@@ -313,7 +276,7 @@ export function findOwnedFreezeConflicts(spec, opts = {}) {
     return out;
 }
 /**
- * The measured `isSource` oracle: a token counts only when git tracks it in
+ * The production `isSource` oracle: a token counts only when git tracks it in
  * `cwd`. Tracked ⇒ it exists, it is not a build output, and it is not ignored —
  * exactly the "source file" the category freezes talk about. `git` missing or
  * the tree not a repo ⇒ every token counts (the broad reading), so the detector
@@ -332,11 +295,15 @@ export function trackedSourceOracle(lsFiles) {
     };
 }
 /**
- * The forced critique-rewrite defect text, in the shape the existing four
- * families use: MANDATORY, self-contained, naming the exact resolutions. Prose
- * surrender and silently dropping the requirement are called out as
- * non-resolutions because narrowing the clause is precisely what run 16 did and
- * freezing its file is precisely what run 18 did.
+ * A forced-rewrite defect block in the shape the CRITIQUE_PROBES entries use:
+ * MANDATORY, self-contained, naming the exact resolutions. Prose surrender and
+ * silently dropping the requirement are called out as non-resolutions — narrowing
+ * the clause and freezing its file are both ways a rewrite makes the
+ * contradiction disappear without satisfying the requirement.
+ *
+ * UNWIRED. Nothing in src/ or test/ calls this. The shipped resolution is the
+ * DETACH in `owned-freeze-reassign.ts`, which needs no model rewrite; this text
+ * is what a rewrite-based resolution would say if one were ever added.
  */
 export function ownedFreezeConflictProbeText(conflicts) {
     const items = conflicts.map(c => `- the spec carries the AUTHORITATIVE owned requirement `

package/dist/task/owned-freeze-reassign.d.ts

@@ -1,69 +1,49 @@
 /**
  * owned-freeze-reassign — the DETERMINISTIC resolution for the owned/freeze
- * unsatisfiable pair (nexttask 2): an AUTHORITATIVE owned requirement whose only
- * implementing file the same spec FREEZES. No model, no prose edit. The
- * requirement text is never altered — only which task's ledger entry carries it,
- * so "resolution by deletion" is structurally impossible.
- *
- * WHY NOT A REWRITE. Measured on mx5 run 18 (scripts/live-owned-freeze-conflict
- * -ab.ts, 20 trials/arm): forcing the pair through the critique seam drives
- * pair-present 8/20 → 0/20, but 11 of the 20 resolutions DELETE the
- * AUTHORITATIVE clause instead of moving it, and the delivered VERIFY still
- * greps `package.json` in both arms (6/20). Removal of the pair is not
- * satisfaction of the requirement.
+ * unsatisfiable pair: an AUTHORITATIVE owned requirement whose only implementing
+ * file the same spec FREEZES. No model, no prose edit. The requirement text is
+ * never altered — only which task's ledger entry carries it, so "resolution by
+ * deletion" is structurally impossible. That is the whole point: a model asked to
+ * remove a contradiction can satisfy the request by deleting the requirement, and
+ * removal of the pair is not satisfaction of the requirement.
  *
  * ── THE MECHANISM: DETACH, then CLAIM ───────────────────────────────────────
  *
  * Two steps, each run where the information it needs actually exists:
  *
- *   DETACH  at the conflicting task's own critique (right after the braces
- *           stamp the bullet, which is the first moment the pair exists): the
- *           entry is marked `pending: [frozen paths]` in the ledger and its
- *           stamped bullet is dropped from this spec. It is now owned by
- *           nobody; `ownedForTitle` skips it; the quote is still there, byte for
- *           byte.
- *   CLAIM   at every LATER task's compose, before the belt block is built: if
- *           that task's REFINED PROMPT shows a write intent on one of the
- *           pending paths, the entry becomes that task's own — belt into its
- *           compose, braces onto its spec.
- *
- * ── WHY NOT "PICK THE TARGET AT DETACH TIME", WHICH IS WHAT nexttask2.md ASKS ─
- *
- * nexttask2.md's branch 1 is "if exactly one OTHER task in the plan names path
- * `P` — its title or its spec's file list contains `P` — move the requirement
- * there". Measured over all 60 recorded composed specs on disk
- * (scripts/owned-freeze-reassign-baserate.ts), on the one conflict the corpus
- * contains (mx5 run 19 TASK_0015, path `src/server/index.ts`):
+ *   DETACH  at the conflicting task's own critique (`critiquePhase`, right after
+ *           `appendOwnedConstraints` stamps the bullet, which is the first moment
+ *           the pair exists): the entry is marked `pending: [frozen paths]` in the
+ *           ledger and its stamped bullet is dropped from this spec. It is now
+ *           owned by nobody; `ownedForTitle` skips it; the quote is still there,
+ *           byte for byte.
+ *   CLAIM   at every LATER task's compose, before the belt block is built: if that
+ *           task's REFINED PROMPT shows a write intent on one of the pending
+ *           paths, the entry becomes that task's own — belt into its compose,
+ *           braces onto its spec. First claimant wins.
  *
- *     title-only    3 candidates   TASK_0014 TASK_0016 TASK_0017
- *     FILES-only    7 candidates   TASK_0016 … TASK_0025
- *     either        8 candidates   → "exactly one" NEVER holds
+ * ── WHY NOT "PICK THE TARGET AT DETACH TIME" ─────────────────────────────────
  *
- * and, decisively, that measurement is against RECORDED SPECS, which production
- * does not have: at the conflicting task's compose the later tasks are still
- * bare plan titles. None of run 19's 26 plan titles contains the string
- * `src/server/index.ts` — TASK_0017's reads "Client API layer — typed
- * hono/client hc<AppType> in api.ts, small fetch/mutation hooks, SPA fallback
- * route on server". A path-lexical target rule at detach time is therefore
- * BLIND IN PRODUCTION (0 candidates), the same way the run-18 critique probe was.
+ * The obvious rule is "if exactly one OTHER task in the plan names path `P`, move
+ * the requirement there". It needs COMPOSED SPECS, and at the conflicting task's
+ * compose the later tasks are still bare plan titles. A plan title describes a
+ * slice of behaviour, not a file list, so a path-lexical target rule at detach
+ * time finds nothing to point at.
  *
- * The claimant knows what the planner did not. By its own compose, TASK_0017 has
- * a refined prompt that says "add an SPA fallback route to the existing server
- * `src/server/index.ts`". Over run 19's 26 refined prompts, `writeIntent` on that
- * path fires on exactly two: TASK_0014 (which created the file, already run) and
- * TASK_0017. Nothing else in the plan claims it — six other specs mention the
- * path, all of them to fence themselves off it.
+ * The claimant knows what the planner did not. By its own compose the later task
+ * has a REFINED prompt, which does say which files it will write — and
+ * `writeIntent` reads exactly that, while its negation fence keeps every sibling
+ * that merely mentions the path in order to fence itself off it.
  *
- * ── WHY NOT nexttask2.md's BRANCH 2 (CARRY EVERYTHING CROSS-CUTTING) ────────
+ * ── WHY NOT CARRY IT AS CROSS-CUTTING ────────────────────────────────────────
  *
  * The cross-cutting channel is for prohibitions and product-wide rules
- * (`isCrossCuttingRequirement`; `accountCoverage` only routes those there). The
- * corpus conflict is a task-specific deliverable clause — carrying it would push
- * "the server serves static `dist/`" into the 11 tasks that had not yet run,
- * none of which owns the server file. That is spec inflation dressed as a fix.
- * An entry nobody claims stays `pending` and is surfaced at the end of the run
- * (`unclaimedPendingRequirements`), which is a debt the run can see rather than
- * an obligation that quietly evaporated.
+ * (`isCrossCuttingRequirement`; `accountCoverage` only routes those there). A
+ * task-specific deliverable clause carried that way lands in every task that has
+ * not run yet, none of which owns the file — spec inflation dressed as a fix. An
+ * entry nobody claims stays `pending` and `unclaimedPendingRequirements` surfaces
+ * it at the end of the run (run-final-gate.ts), so it becomes a debt the run can
+ * see rather than an obligation that quietly evaporated.
  */
 import { type OwnedFreezeOptions } from './owned-freeze-conflict.js';
 import { type OwnedRequirement } from './requirements.js';
@@ -96,11 +76,10 @@ export interface DetachResult {
  * Does this text CLAIM a write on `p` — a create/modify verb reaching a mention
  * of the path, not fenced by a negation?
  *
- * The negation half is not decoration. Every sibling task's refined prompt names
- * the files it must not touch ("Do not create or modify any other files outside
- * this slice (e.g., no changes to `src/server/index.ts`, …)" — mx5 run 19
- * TASK_0008). Without the fence check that spec claims the server file; with it,
- * run 19's 26 refined prompts yield exactly the two tasks that do write it.
+ * The negation half is not decoration. A refined prompt routinely names the files
+ * its task must NOT touch, in the same sentence as a write verb — "Do not create
+ * or modify any other files outside this slice (e.g. no changes to `X`)". Without
+ * the fence check, every such sibling claims `X`.
  */
 export declare function writeIntent(text: string, p: string): boolean;
 /**
@@ -124,8 +103,9 @@ export interface ClaimResult {
  * pending paths its refined prompt writes. Run at the START of compose, so the
  * claimed obligation rides the same belt block every owned requirement does.
  *
- * First claimant wins (`inv-single-owner`): the entry stops being pending the
- * moment it is claimed, so a later task cannot take it as well.
+ * First claimant wins: `delete entry.pending` runs before the entry is retitled,
+ * so a later task finds nothing pending to take. The test named
+ * `inv-single-owner` pins that.
  */
 export declare function claimPendingRequirements(args: {
     /** The claiming task's refined prompt — the text that says what it will write. */

package/dist/task/owned-freeze-reassign.js

@@ -1,69 +1,49 @@
 /**
  * owned-freeze-reassign — the DETERMINISTIC resolution for the owned/freeze
- * unsatisfiable pair (nexttask 2): an AUTHORITATIVE owned requirement whose only
- * implementing file the same spec FREEZES. No model, no prose edit. The
- * requirement text is never altered — only which task's ledger entry carries it,
- * so "resolution by deletion" is structurally impossible.
- *
- * WHY NOT A REWRITE. Measured on mx5 run 18 (scripts/live-owned-freeze-conflict
- * -ab.ts, 20 trials/arm): forcing the pair through the critique seam drives
- * pair-present 8/20 → 0/20, but 11 of the 20 resolutions DELETE the
- * AUTHORITATIVE clause instead of moving it, and the delivered VERIFY still
- * greps `package.json` in both arms (6/20). Removal of the pair is not
- * satisfaction of the requirement.
+ * unsatisfiable pair: an AUTHORITATIVE owned requirement whose only implementing
+ * file the same spec FREEZES. No model, no prose edit. The requirement text is
+ * never altered — only which task's ledger entry carries it, so "resolution by
+ * deletion" is structurally impossible. That is the whole point: a model asked to
+ * remove a contradiction can satisfy the request by deleting the requirement, and
+ * removal of the pair is not satisfaction of the requirement.
  *
  * ── THE MECHANISM: DETACH, then CLAIM ───────────────────────────────────────
  *
  * Two steps, each run where the information it needs actually exists:
  *
- *   DETACH  at the conflicting task's own critique (right after the braces
- *           stamp the bullet, which is the first moment the pair exists): the
- *           entry is marked `pending: [frozen paths]` in the ledger and its
- *           stamped bullet is dropped from this spec. It is now owned by
- *           nobody; `ownedForTitle` skips it; the quote is still there, byte for
- *           byte.
- *   CLAIM   at every LATER task's compose, before the belt block is built: if
- *           that task's REFINED PROMPT shows a write intent on one of the
- *           pending paths, the entry becomes that task's own — belt into its
- *           compose, braces onto its spec.
- *
- * ── WHY NOT "PICK THE TARGET AT DETACH TIME", WHICH IS WHAT nexttask2.md ASKS ─
- *
- * nexttask2.md's branch 1 is "if exactly one OTHER task in the plan names path
- * `P` — its title or its spec's file list contains `P` — move the requirement
- * there". Measured over all 60 recorded composed specs on disk
- * (scripts/owned-freeze-reassign-baserate.ts), on the one conflict the corpus
- * contains (mx5 run 19 TASK_0015, path `src/server/index.ts`):
+ *   DETACH  at the conflicting task's own critique (`critiquePhase`, right after
+ *           `appendOwnedConstraints` stamps the bullet, which is the first moment
+ *           the pair exists): the entry is marked `pending: [frozen paths]` in the
+ *           ledger and its stamped bullet is dropped from this spec. It is now
+ *           owned by nobody; `ownedForTitle` skips it; the quote is still there,
+ *           byte for byte.
+ *   CLAIM   at every LATER task's compose, before the belt block is built: if that
+ *           task's REFINED PROMPT shows a write intent on one of the pending
+ *           paths, the entry becomes that task's own — belt into its compose,
+ *           braces onto its spec. First claimant wins.
  *
- *     title-only    3 candidates   TASK_0014 TASK_0016 TASK_0017
- *     FILES-only    7 candidates   TASK_0016 … TASK_0025
- *     either        8 candidates   → "exactly one" NEVER holds
+ * ── WHY NOT "PICK THE TARGET AT DETACH TIME" ─────────────────────────────────
  *
- * and, decisively, that measurement is against RECORDED SPECS, which production
- * does not have: at the conflicting task's compose the later tasks are still
- * bare plan titles. None of run 19's 26 plan titles contains the string
- * `src/server/index.ts` — TASK_0017's reads "Client API layer — typed
- * hono/client hc<AppType> in api.ts, small fetch/mutation hooks, SPA fallback
- * route on server". A path-lexical target rule at detach time is therefore
- * BLIND IN PRODUCTION (0 candidates), the same way the run-18 critique probe was.
+ * The obvious rule is "if exactly one OTHER task in the plan names path `P`, move
+ * the requirement there". It needs COMPOSED SPECS, and at the conflicting task's
+ * compose the later tasks are still bare plan titles. A plan title describes a
+ * slice of behaviour, not a file list, so a path-lexical target rule at detach
+ * time finds nothing to point at.
  *
- * The claimant knows what the planner did not. By its own compose, TASK_0017 has
- * a refined prompt that says "add an SPA fallback route to the existing server
- * `src/server/index.ts`". Over run 19's 26 refined prompts, `writeIntent` on that
- * path fires on exactly two: TASK_0014 (which created the file, already run) and
- * TASK_0017. Nothing else in the plan claims it — six other specs mention the
- * path, all of them to fence themselves off it.
+ * The claimant knows what the planner did not. By its own compose the later task
+ * has a REFINED prompt, which does say which files it will write — and
+ * `writeIntent` reads exactly that, while its negation fence keeps every sibling
+ * that merely mentions the path in order to fence itself off it.
  *
- * ── WHY NOT nexttask2.md's BRANCH 2 (CARRY EVERYTHING CROSS-CUTTING) ────────
+ * ── WHY NOT CARRY IT AS CROSS-CUTTING ────────────────────────────────────────
  *
  * The cross-cutting channel is for prohibitions and product-wide rules
- * (`isCrossCuttingRequirement`; `accountCoverage` only routes those there). The
- * corpus conflict is a task-specific deliverable clause — carrying it would push
- * "the server serves static `dist/`" into the 11 tasks that had not yet run,
- * none of which owns the server file. That is spec inflation dressed as a fix.
- * An entry nobody claims stays `pending` and is surfaced at the end of the run
- * (`unclaimedPendingRequirements`), which is a debt the run can see rather than
- * an obligation that quietly evaporated.
+ * (`isCrossCuttingRequirement`; `accountCoverage` only routes those there). A
+ * task-specific deliverable clause carried that way lands in every task that has
+ * not run yet, none of which owns the file — spec inflation dressed as a fix. An
+ * entry nobody claims stays `pending` and `unclaimedPendingRequirements` surfaces
+ * it at the end of the run (run-final-gate.ts), so it becomes a debt the run can
+ * see rather than an obligation that quietly evaporated.
  */
 import { findOwnedFreezeConflicts } from './owned-freeze-conflict.js';
 import { ownedForTitle } from './requirements.js';
@@ -72,11 +52,10 @@ import { PROHIBITION_RE } from './prohibition-probe.js';
  * Does this text CLAIM a write on `p` — a create/modify verb reaching a mention
  * of the path, not fenced by a negation?
  *
- * The negation half is not decoration. Every sibling task's refined prompt names
- * the files it must not touch ("Do not create or modify any other files outside
- * this slice (e.g., no changes to `src/server/index.ts`, …)" — mx5 run 19
- * TASK_0008). Without the fence check that spec claims the server file; with it,
- * run 19's 26 refined prompts yield exactly the two tasks that do write it.
+ * The negation half is not decoration. A refined prompt routinely names the files
+ * its task must NOT touch, in the same sentence as a write verb — "Do not create
+ * or modify any other files outside this slice (e.g. no changes to `X`)". Without
+ * the fence check, every such sibling claims `X`.
  */
 export function writeIntent(text, p) {
     const re = new RegExp(String.raw `\b(?:creat|add|implement|modif|updat|extend|wir|writ|mount|chang)\w*\b`
@@ -84,7 +63,7 @@ export function writeIntent(text, p) {
         + p.replace(/[.*+?^${}()|[\]\\]/g, '\\$&'), 'gi');
     for (const m of text.matchAll(re)) {
         // The negation usually sits BEFORE the verb, so the window reaches back
-        // past it — matching only the verb→path span misses TASK_0008 entirely.
+        // past it — matching only the verb→path span misses a fenced spec entirely.
         const from = Math.max(0, (m.index ?? 0) - 90);
         const window = text.slice(from, (m.index ?? 0) + m[0].length);
         if (NEGATED_RE.test(window) || PROHIBITION_RE.test(window))
@@ -171,8 +150,9 @@ export function detachUnsatisfiableRequirements(args) {
  * pending paths its refined prompt writes. Run at the START of compose, so the
  * claimed obligation rides the same belt block every owned requirement does.
  *
- * First claimant wins (`inv-single-owner`): the entry stops being pending the
- * moment it is claimed, so a later task cannot take it as well.
+ * First claimant wins: `delete entry.pending` runs before the entry is retitled,
+ * so a later task finds nothing pending to take. The test named
+ * `inv-single-owner` pins that.
  */
 export function claimPendingRequirements(args) {
     const out = { ledger: args.ledger.map(o => ({ ...o })), actions: [] };

package/dist/task/parsers.d.ts

@@ -12,8 +12,10 @@
  *     bare recommendation): a genuine open fork carrying a best-effort suggestion.
  *   - 'api-synthesis' — the answer was ANSWERED, then DEMOTED because it names an
  *     API identifier absent from the research and the question, in a namespace the
- *     research covers (mx5 run 13: an invented `Bun.mkdirSync` reached requirements
- *     AND the VERIFY block). The suggestion rides along for a HUMAN to judge.
+ *     research covers. `Bun.mkdirSync` is the shape: bun-types declares no such
+ *     member, but an answer naming it reads as authoritative and can reach both
+ *     requirements and the VERIFY block. The suggestion rides along for a HUMAN
+ *     to judge.
  *   - 'integration' — an integration/build-wiring unknown no fetched doc grounded;
  *     a wrong guess is a structural landmine, so the model's answer is offered as
  *     a recommendation instead of being taken silently.

package/dist/task/parsers.js

@@ -224,10 +224,10 @@ export function deriveTitle(refined) {
 }
 // ─── Display label ───────────────────────────────────────────────────────────
 //
-// `title` is stored in full (a refine GOAL paragraph can be 1000+ chars — see
-// the "no truncation at storage" contract in deriveTitle). These helpers shrink
-// it for status surfaces (widget head, /task list) WITHOUT touching what's
-// stored: the pipeline always reads the full title. A model-compressed `label`
+// `title` is stored in full: `deriveTitle` returns the GOAL line whole, however
+// long it is, and nothing clamps it on the way to disk. These helpers shrink it
+// for status surfaces (widget head, /task list) WITHOUT touching what is stored —
+// the pipeline always reads the full title. A model-compressed `label`
 // is preferred when present (see title-label.ts); otherwise we fall back to a
 // deterministic, word-boundary truncation so a label-less task still reads
 // cleanly.