@mjasnikovs/pi-task 0.38.29 → 0.38.31

package/dist/task/decompose-fidelity.js

@@ -1,13 +1,13 @@
 /**
- * decompose-fidelity — verbatim fidelity of plan derivations (mx5 run 11, goal B).
+ * decompose-fidelity — verbatim fidelity of plan derivations.
  *
- * The failure this closes: the design's §12 milestone lines 2 and 4 end in
- * "guards + tests" / "contact + tests"; the decomposed titles carried everything
+ * The failure this closes: a design's milestone line ends in an additive
+ * constraint — "… guards + tests" — and the decomposed title carries everything
  * BUT the "+ tests" suffix. A title is ALL a per-task pipeline ever sees, so a
- * silently dropped constraint fragment vanishes from the whole run — the dropped
- * tests were exactly the instrument that would have caught the shipped 404 bug.
- * Decompose paraphrases freely and NOTHING compared a title to the spec line it
- * derives from.
+ * silently dropped fragment vanishes from the whole run, and the dropped thing is
+ * disproportionately the instrument that would have caught the bug. Decompose
+ * paraphrases freely, and without this nothing compares a title to the spec line
+ * it derives from.
  *
  * Mechanism (contracts.ts pattern, applied to decompose itself): the decompose
  * prompt asks each task line to cite its origin as a trailing
@@ -20,9 +20,11 @@
  *   3. RE-ATTACHES the missing fragments to the title verbatim.
  *
  * Scope is deliberately the additive-suffix class (`+`-joined fragments): those
- * are constraints by construction, so re-attachment can never inject noise that
- * the cited line doesn't demand — worst case is redundancy with what the title
- * already says, never fabrication. Whole-line paraphrase drift is NOT judged here
+ * are constraints by construction, so re-attachment can never inject noise the
+ * cited line does not demand — worst case is redundancy with what the title
+ * already says, never fabrication. In practice not even that: a title that
+ * already carries the fragment restores nothing, and the singular/plural
+ * allowance means "a test" counts as covering "tests". Whole-line paraphrase drift is NOT judged here
  * (a title is a paraphrase by design); requirement-level coverage owns that.
  * No similarity thresholds anywhere: grounding is exact normalised substring,
  * presence is exact word membership (with a singular/plural `s` allowance).
@@ -45,17 +47,15 @@ const SOURCE_RE = /^\[source:\s*"([\s\S]*)"\s*\]$/i;
  *
  * BACKTICKS ARE THE SAME CLASS and were the larger half. A code span renders as
  * bare text, so `3. **Invites** — create/validate/redeem, \`/join/:token\` page.`
- * comes back as `Invites — create/validate/redeem, /join/:token page.` Measured
- * on the mx5 fixture, screening every spec line in its RENDERED form:
- * 107/216 grounded with backticks kept, 216/216 with them dropped.
+ * comes back as `Invites — create/validate/redeem, /join/:token page.` Screening
+ * every spec line in its RENDERED form is what makes those quotes match at all.
  *
- * MEASURED 2026-08-27 over the 20 recorded decompose runs in
- * ab-grouplab/ledger-planning.jsonl, and screened both ways first:
- *   FLOOR   real spec lines with ONE content word altered: 0/216 pass.
- *   CEILING real spec lines quoted without their markup: 209/257 = 81.3% passed
- *           before, 257/257 after. 48 genuine lines were being rejected.
- * Re-screened by scripts/decompose-fidelity-screen.ts, which is the standing
- * check: CEILING raw 216/216, CEILING rendered 216/216, FLOOR 0/216.
+ * The two directions this has to hold in, both run:
+ *   FLOOR   a real spec line with ONE content word altered must NOT be grounded —
+ *           changing `sessions` to `tokens`, or `redeem` to `revoke`, drops it.
+ *   CEILING a real spec line quoted without its markup MUST be grounded — both the
+ *           `2. **Auth** —` numbering-and-bold case and the backticked
+ *           `` `/join/:token` `` case still match.
  */
 function demark(s) {
     return s
@@ -69,10 +69,13 @@ function demark(s) {
  * Undo the backslash-escaping a model applies to a quote it is putting INSIDE a
  * double-quoted clause. `[source: "… \`import { sql } from \\"bun\\"\` gotcha …"]`
  * is a faithful copy of a line the document stores with plain quotes; the
- * backslashes are an artefact of the delimiter, not content. Measured live: 4 of
- * the 19 ungrounded clauses in the n=30/arm planning run were this and nothing
- * else. Only `\"` is undone — no other escape sequence is interpreted, so this
- * cannot rewrite a quote into something the document happens to contain.
+ * backslashes are an artefact of the delimiter, not content, so without this an
+ * otherwise-faithful quote fails to match for that reason alone.
+ *
+ * Only `\"` is undone — no other escape sequence is interpreted, so this cannot
+ * rewrite a quote into something the document happens to contain. Confirmed both
+ * ways: the escaped-quote citation grounds, and a citation carrying a literal
+ * `\n` does not.
  */
 function unescapeQuotes(s) {
     return s.replace(/\\"/g, '"');
@@ -80,15 +83,17 @@ function unescapeQuotes(s) {
 /**
  * Split a decompose title into its base and its GROUNDED source citations.
  *
- * PLURAL, because the model emits plural. The prompt asks for one trailing
- * citation and a quarter of real titles carry more — 62 of 244 across the 20
- * recorded runs. The old pattern was `\[source:\s*"(.+)"\]$`: greedy `.+`
- * against an end anchor, so on `[source: "A"] [source: "B"]` it matched from the
- * FIRST clause to the LAST quote and produced the superstring `A"] [source: "B`,
- * which of course is not in the document. Two real citations became one
- * fabricated one, and both were discarded. Peeling from the end with
- * lastIndexOf is the fix; a lazy quantifier is NOT, because leftmost-first
- * matching plus the `$` anchor expands it across the later clauses just the same.
+ * PLURAL, because the model emits plural: the prompt asks for one trailing
+ * citation and a real share of titles carry more than one.
+ *
+ * A single anchored pattern cannot read them. Run on `[source: "A"] [source: "B"]`,
+ * `\[source:\s*"(.+)"\]$` captures the superstring `A"] [source: "B` — from the
+ * FIRST clause to the LAST quote — which is of course not in the document, so two
+ * real citations become one fabricated one and both are discarded. Making the
+ * quantifier LAZY changes nothing: `(.+?)` against the same input captures the
+ * identical superstring, because leftmost-first matching plus the `$` anchor
+ * expands it across the later clauses just the same. Peeling from the end with
+ * lastIndexOf is what actually works — confirmed, both citations come back.
  *
  * An absent clause yields no sources; a fabricated (ungrounded) one is dropped
  * — exactly like keepGroundedContracts rejects a paraphrased quote.

package/dist/task/decompose-granularity.d.ts

@@ -2,18 +2,15 @@
  * decompose-granularity — the deterministic FLOOR on how finely /task-auto cuts
  * a feature into tasks.
  *
- * The failure this closes (mx5, Jul 25 vs Jul 27): the SAME design doc, from the
- * SAME base commit, with a byte-identical planning path, planned once into 41
- * tasks and once into 11. The whole 4x difference is one line of clarify text.
- * /task-auto's clarify head asks a plan-shape question first ("one task per
- * milestone, or split smaller?" — 8/8 live reps), the answer-side triage
- * auto-resolves it 8/8 and stamps it "already settled by the spec", so the user
- * never sees the fork; and the answer decides the whole plan. Live A/B, run 18's
- * transcript with ONLY that line swapped (n=8/arm): coarse mean 11.4 titles vs
- * fine mean 28.6, 63.5/64 pairwise wins, p<0.001.
+ * The failure this closes: the SAME design doc, from the SAME base commit, with a
+ * byte-identical planning path, plans several times coarser or finer depending on
+ * ONE line of clarify text. /task-auto's clarify head asks a plan-shape question
+ * first ("one task per milestone, or split smaller?"), the answer-side triage
+ * auto-resolves it and stamps it "already settled by the spec", so the user never
+ * sees the fork — and that answer decides the whole plan.
  *
- * The spec does NOT settle it. mx5's §12 is titled "Build order (milestones)" —
- * an ORDER, 9 items, not a task breakdown. So the plan's granularity, the single
+ * The spec does NOT settle it. A section titled "Build order (milestones)" is an
+ * ORDER, not a task breakdown. So the plan's granularity, the single
  * highest-leverage decision in a run (each title is handed to its own pipeline
  * that researches and specs it alone), was being decided by a coin flip nobody
  * could see, review, or reproduce.
@@ -25,10 +22,10 @@
  *
  *   floor = ceil(ownable requirements / MAX_REQUIREMENTS_PER_TASK)
  *
- * MAX_REQUIREMENTS_PER_TASK = 2 is anchored on the two real mx5 plans, not on
- * taste: the 41-task plan carried 0.8 ownable requirements per task, the collapsed
- * 11-task plan carried 2.8. A ceiling of 2 sits between them — it rejects the
- * collapse without demanding the finest plan ever observed.
+ * MAX_REQUIREMENTS_PER_TASK = 2 sits deliberately between the two shapes: a plan
+ * cut fine enough to work carries roughly one ownable requirement per task, and a
+ * collapsed one bundles several. A ceiling of 2 rejects the collapse without
+ * demanding the finest possible plan.
  *
  * Spec-shape-agnostic: the only inputs are two integers. A CLI, a library, a
  * refactor, a docs job all flow through the same arithmetic, and a feature with
@@ -37,7 +34,7 @@
  */
 /**
  * The most distinct grounded requirements one task may carry before the plan is
- * judged too coarse. See the module docstring for the mx5 anchoring.
+ * judged too coarse. See the module docstring for where the number comes from.
  */
 export declare const MAX_REQUIREMENTS_PER_TASK = 2;
 /**
@@ -47,14 +44,14 @@ export declare const MAX_REQUIREMENTS_PER_TASK = 2;
  * Also zero below MIN_REQUIREMENTS_FOR_PLAN_SHAPE, for the reason that constant
  * already documents: under a handful of requirements the plan is one or two tasks
  * either way, and the requirement COUNT at that scale is an artifact of extraction
- * granularity rather than real breadth. Measured (2026-07-28 size smoke): the
- * 78-char feature "Add a `--version` flag to the CLI that prints the package
- * version and exits 0" extracted THREE ownable requirements — the flag, the
- * print, the exit code — yielding a floor of 2 for what is unambiguously one
- * task. Both arms correctly shipped 1 title, so the floor bought nothing and cost
- * a split-retry child; had anything ever made it binding it would have forced a
- * bad split. The same cut governs both because it is the same judgement: the
- * requirement channel is not load-bearing for shape until a feature has real breadth.
+ * granularity rather than real breadth. A one-line feature request — "add a
+ * --version flag that prints the version and exits 0" — extracts three ownable
+ * requirements (the flag, the print, the exit code) for what is unambiguously one
+ * task, and an ungated floor would demand two. The same cut governs both checks
+ * because it is the same judgement.
+ *
+ * Run: the floor is 0 for 0-4 ownable requirements, then ceil(n/2) — 5 gives 3,
+ * 10 gives 5, 21 gives 11.
  */
 export declare function granularityFloor(ownable: number): number;
 /** Is this plan too coarse for the requirements it has to carry? */
@@ -76,25 +73,31 @@ export declare function planShapeIsHostsToAnswer(ownable: number): boolean;
 /**
  * Does this clarify question decide how finely the feature is CUT into tasks?
  *
- * Deterministic and narrow on purpose. It must fire on the fork the triage keeps
- * answering for itself ("follow the milestones as-is, or split more granularly?")
- * and stay off ordinary scope questions — an over-eager classifier would replace
- * a real user decision with the host's. Matched against the plain-text question.
+ * Deterministic and narrow on purpose: it must fire on the fork the triage keeps
+ * answering for itself and stay off ordinary scope questions, because an
+ * over-eager classifier would replace a real user decision with the host's.
+ * Matched against the plain-text question.
+ *
+ * BOTH halves must hold — a breakdown phrase AND a plan-unit noun — and the unit
+ * list is SINGULAR except for tasks. Measured across the units it names:
+ *   milestone / section / step / phase / task / tasks   fire
+ *   milestones / sections / steps / phases              do NOT
+ * So "one task per milestone, or split smaller?" fires, while the same fork
+ * phrased "follow the milestones as-is, or split more granularly?" does not —
+ * the breakdown half matches, the plural unit does not.
  */
 export declare function isPlanShapeQuestion(question: string): boolean;
 /**
  * BELT — the host's own answer to that fork, recorded in the clarify transcript in
  * place of the triage's.
  *
- * WHY A CLARIFICATION AND NOT A DECOMPOSE RULE. Both were measured live. As a
- * RULES line replacing "prefer a handful of substantial tasks", the same directive
- * removed the collapse but destroyed plan-size control: 66, then 81 and 85 titles
- * for a spec whose healthy plan is ~30, plus one decompose child that blew the
- * model's 120k context window and killed the planning phase (the baseline produced
- * no such failure in 27 reps). Naming a target count made it worse, not better.
- * In the CLARIFICATIONS block, with the "prefer a handful" counterweight left
- * intact, the identical directive held 20–39 titles across 16 reps. The channel is
- * part of the lever, not a detail.
+ * WHY A CLARIFICATION AND NOT A DECOMPOSE RULE. The identical directive behaves
+ * very differently depending on where it lands. As a RULES line REPLACING "prefer
+ * a handful of substantial tasks", it removes the collapse but takes the
+ * counterweight with it, and plan size runs away — far enough that a decompose
+ * child can exhaust its context window and kill the planning phase outright. In
+ * the CLARIFICATIONS block, with that counterweight left intact, the same words
+ * land as one input among several. The channel is part of the lever, not a detail.
  *
  * Deliberately count-free: the spec-derived floor stays host-side, where it is
  * enforced silently and cannot be chased.
@@ -105,6 +108,6 @@ export declare const PLAN_SHAPE_ANSWER: string;
  * BRACES — the reprompt when the returned plan lands under the floor. Also
  * countless, for the reason above: it asks for a SPLIT of the plan in hand rather
  * than a fresh roll (a regeneration is a new stochastic draw over the whole plan
- * and can drop an area the current one covers — mx5 run 12).
+ * and can drop an area the current one covers).
  */
 export declare function granularitySplitHint(titles: number, ownable: number): string;

package/dist/task/decompose-granularity.js

@@ -2,18 +2,15 @@
  * decompose-granularity — the deterministic FLOOR on how finely /task-auto cuts
  * a feature into tasks.
  *
- * The failure this closes (mx5, Jul 25 vs Jul 27): the SAME design doc, from the
- * SAME base commit, with a byte-identical planning path, planned once into 41
- * tasks and once into 11. The whole 4x difference is one line of clarify text.
- * /task-auto's clarify head asks a plan-shape question first ("one task per
- * milestone, or split smaller?" — 8/8 live reps), the answer-side triage
- * auto-resolves it 8/8 and stamps it "already settled by the spec", so the user
- * never sees the fork; and the answer decides the whole plan. Live A/B, run 18's
- * transcript with ONLY that line swapped (n=8/arm): coarse mean 11.4 titles vs
- * fine mean 28.6, 63.5/64 pairwise wins, p<0.001.
+ * The failure this closes: the SAME design doc, from the SAME base commit, with a
+ * byte-identical planning path, plans several times coarser or finer depending on
+ * ONE line of clarify text. /task-auto's clarify head asks a plan-shape question
+ * first ("one task per milestone, or split smaller?"), the answer-side triage
+ * auto-resolves it and stamps it "already settled by the spec", so the user never
+ * sees the fork — and that answer decides the whole plan.
  *
- * The spec does NOT settle it. mx5's §12 is titled "Build order (milestones)" —
- * an ORDER, 9 items, not a task breakdown. So the plan's granularity, the single
+ * The spec does NOT settle it. A section titled "Build order (milestones)" is an
+ * ORDER, not a task breakdown. So the plan's granularity, the single
  * highest-leverage decision in a run (each title is handed to its own pipeline
  * that researches and specs it alone), was being decided by a coin flip nobody
  * could see, review, or reproduce.
@@ -25,10 +22,10 @@
  *
  *   floor = ceil(ownable requirements / MAX_REQUIREMENTS_PER_TASK)
  *
- * MAX_REQUIREMENTS_PER_TASK = 2 is anchored on the two real mx5 plans, not on
- * taste: the 41-task plan carried 0.8 ownable requirements per task, the collapsed
- * 11-task plan carried 2.8. A ceiling of 2 sits between them — it rejects the
- * collapse without demanding the finest plan ever observed.
+ * MAX_REQUIREMENTS_PER_TASK = 2 sits deliberately between the two shapes: a plan
+ * cut fine enough to work carries roughly one ownable requirement per task, and a
+ * collapsed one bundles several. A ceiling of 2 rejects the collapse without
+ * demanding the finest possible plan.
  *
  * Spec-shape-agnostic: the only inputs are two integers. A CLI, a library, a
  * refactor, a docs job all flow through the same arithmetic, and a feature with
@@ -37,7 +34,7 @@
  */
 /**
  * The most distinct grounded requirements one task may carry before the plan is
- * judged too coarse. See the module docstring for the mx5 anchoring.
+ * judged too coarse. See the module docstring for where the number comes from.
  */
 export const MAX_REQUIREMENTS_PER_TASK = 2;
 /**
@@ -47,14 +44,14 @@ export const MAX_REQUIREMENTS_PER_TASK = 2;
  * Also zero below MIN_REQUIREMENTS_FOR_PLAN_SHAPE, for the reason that constant
  * already documents: under a handful of requirements the plan is one or two tasks
  * either way, and the requirement COUNT at that scale is an artifact of extraction
- * granularity rather than real breadth. Measured (2026-07-28 size smoke): the
- * 78-char feature "Add a `--version` flag to the CLI that prints the package
- * version and exits 0" extracted THREE ownable requirements — the flag, the
- * print, the exit code — yielding a floor of 2 for what is unambiguously one
- * task. Both arms correctly shipped 1 title, so the floor bought nothing and cost
- * a split-retry child; had anything ever made it binding it would have forced a
- * bad split. The same cut governs both because it is the same judgement: the
- * requirement channel is not load-bearing for shape until a feature has real breadth.
+ * granularity rather than real breadth. A one-line feature request — "add a
+ * --version flag that prints the version and exits 0" — extracts three ownable
+ * requirements (the flag, the print, the exit code) for what is unambiguously one
+ * task, and an ungated floor would demand two. The same cut governs both checks
+ * because it is the same judgement.
+ *
+ * Run: the floor is 0 for 0-4 ownable requirements, then ceil(n/2) — 5 gives 3,
+ * 10 gives 5, 21 gives 11.
  */
 export function granularityFloor(ownable) {
     if (ownable < MIN_REQUIREMENTS_FOR_PLAN_SHAPE)
@@ -84,10 +81,18 @@ export function planShapeIsHostsToAnswer(ownable) {
 /**
  * Does this clarify question decide how finely the feature is CUT into tasks?
  *
- * Deterministic and narrow on purpose. It must fire on the fork the triage keeps
- * answering for itself ("follow the milestones as-is, or split more granularly?")
- * and stay off ordinary scope questions — an over-eager classifier would replace
- * a real user decision with the host's. Matched against the plain-text question.
+ * Deterministic and narrow on purpose: it must fire on the fork the triage keeps
+ * answering for itself and stay off ordinary scope questions, because an
+ * over-eager classifier would replace a real user decision with the host's.
+ * Matched against the plain-text question.
+ *
+ * BOTH halves must hold — a breakdown phrase AND a plan-unit noun — and the unit
+ * list is SINGULAR except for tasks. Measured across the units it names:
+ *   milestone / section / step / phase / task / tasks   fire
+ *   milestones / sections / steps / phases              do NOT
+ * So "one task per milestone, or split smaller?" fires, while the same fork
+ * phrased "follow the milestones as-is, or split more granularly?" does not —
+ * the breakdown half matches, the plural unit does not.
  */
 export function isPlanShapeQuestion(question) {
     const q = question.toLowerCase();
@@ -102,15 +107,13 @@ export function isPlanShapeQuestion(question) {
  * BELT — the host's own answer to that fork, recorded in the clarify transcript in
  * place of the triage's.
  *
- * WHY A CLARIFICATION AND NOT A DECOMPOSE RULE. Both were measured live. As a
- * RULES line replacing "prefer a handful of substantial tasks", the same directive
- * removed the collapse but destroyed plan-size control: 66, then 81 and 85 titles
- * for a spec whose healthy plan is ~30, plus one decompose child that blew the
- * model's 120k context window and killed the planning phase (the baseline produced
- * no such failure in 27 reps). Naming a target count made it worse, not better.
- * In the CLARIFICATIONS block, with the "prefer a handful" counterweight left
- * intact, the identical directive held 20–39 titles across 16 reps. The channel is
- * part of the lever, not a detail.
+ * WHY A CLARIFICATION AND NOT A DECOMPOSE RULE. The identical directive behaves
+ * very differently depending on where it lands. As a RULES line REPLACING "prefer
+ * a handful of substantial tasks", it removes the collapse but takes the
+ * counterweight with it, and plan size runs away — far enough that a decompose
+ * child can exhaust its context window and kill the planning phase outright. In
+ * the CLARIFICATIONS block, with that counterweight left intact, the same words
+ * land as one input among several. The channel is part of the lever, not a detail.
  *
  * Deliberately count-free: the spec-derived floor stays host-side, where it is
  * enforced silently and cannot be chased.
@@ -125,7 +128,7 @@ export const PLAN_SHAPE_ANSWER = 'subdivide into smaller per-deliverable tasks
  * BRACES — the reprompt when the returned plan lands under the floor. Also
  * countless, for the reason above: it asks for a SPLIT of the plan in hand rather
  * than a fresh roll (a regeneration is a new stochastic draw over the whole plan
- * and can drop an area the current one covers — mx5 run 12).
+ * and can drop an area the current one covers).
  */
 export function granularitySplitHint(titles, ownable) {
     return (`[SYSTEM NOTE: your plan of ${titles} task(s) is too coarse for the`

package/dist/task/deep-render-check.d.ts

@@ -12,15 +12,18 @@ export type DeepRenderOutcome = {
 export interface LoginCredentials {
     identifier: string;
     password: string;
-    /** Key names only — the value is never logged or surfaced anywhere. */
+    /** Key NAMES only. The values are read from the project's own dotenv and typed
+     *  into the page; neither ever reaches a log line, a skip note or a failure
+     *  detail — those quote the key names and the request paths only. */
     identifierKey: string;
     passwordKey: string;
 }
 /**
- * Parse a dotenv-style file into a plain record. Deliberately minimal (KEY=VALUE,
- * `export ` prefix, # comments, optional matching quotes) — this reads the same
- * file the app's own runtime reads, and anything it cannot parse simply yields no
- * credentials, which is a SKIP.
+ * Parse a dotenv-style file into a plain record. Deliberately minimal — KEY=VALUE,
+ * an optional `export ` prefix, `#` comments, and matching quotes that preserve
+ * inner spaces while an unquoted value drops a trailing ` #` comment. This reads
+ * the same file the app's own runtime reads, and anything it cannot parse simply
+ * yields no credentials, which is a SKIP rather than a failure.
  */
 export declare function parseEnvFile(text: string): Record<string, string>;
 /** The variables the booted app itself sees: its dotenv files, overlaid by the real
@@ -37,7 +40,7 @@ export declare function findLoginCredentials(vars: Record<string, string>): Logi
  * The LOCAL port the project's own client was built to call, when its dotenv pins
  * one (`APP_URL=http://localhost:3000`, `VITE_API_URL=…`), else null.
  *
- * Why the boot check wants it (measured on mx5@373e88d, both directions): a bundler
+ * Why the boot check wants it: a bundler
  * bakes that base URL into the client at BUILD time, so a client served on the
  * gate's freshly-reserved private port calls an origin nothing is listening on. The
  * app is then unusable for reasons that have nothing to do with the code, and the
@@ -45,7 +48,7 @@ export declare function findLoginCredentials(vars: Record<string, string>): Logi
  * origin and never reaches the server we booted. Serving on the app's own declared
  * port makes the session same-origin and the evidence real.
  *
- * This deliberately narrows the private-port ownership evidence of run 14, so it
+ * This deliberately narrows the private-port ownership evidence, so it
  * only applies when the port is LOCAL, DECLARED by the project itself, and CURRENTLY
  * FREE — the caller checks freeness and falls back to a reserved port otherwise.
  */
@@ -117,18 +120,23 @@ export declare function deriveLegacyFacts(log: SessionRequest[]): Pick<DeepSessi
  * Judge a recorded session. The ONE thing that may FAIL is a session the SERVER
  * authenticated (2xx on the sign-in request) whose client then could not use it:
  *
- *   - never left the wall                → the run-17 signature exactly;
+ *   - never left the wall                → the signature exactly;
  *   - data calls attempted, none 2xx     → the same class one page deeper;
- *   - post-sign-in page renders blank    → the run-16 class behind the wall.
+ *   - post-sign-in page renders blank    → the class behind the wall.
  *
  * Everything else is an environment or shape gap and SKIPs. Note what is NOT a
  * failure: zero data calls attempted after sign-in. A server-rendered app that
  * redirects to a fresh document legitimately issues no XHR at all, so the missing
- * half is reported UNOBSERVED in the detail instead. (The task text asked for
- * "≥1 same-origin /api/* 2xx during the session" as a hard assertion; STEP 0
- * refuted that wording — the BROKEN mx5 build satisfies it with the probe's own
- * login POST — so the assertion is registered post-auth and excludes the sign-in
- * request. See the scratch REGISTERED-METRIC record quoted in the commit.)
+ * half is reported UNOBSERVED in the detail instead.
+ *
+ * The data assertion is deliberately POST-AUTH and EXCLUDES the sign-in request.
+ * A plain "at least one same-origin 2xx during the session" would be satisfied by
+ * the probe's own login POST and nothing else — a broken build passes it.
+ *
+ * Run across every branch: only those three FAIL. No wall PASSes; no credentials,
+ * an undriveable form, no sign-in request, a server that REJECTED the credentials,
+ * and a client pinned to a foreign origin all SKIP; and zero post-auth data calls
+ * PASSes with the gap noted.
  */
 export declare function judgeDeepSession(f: DeepSessionFacts): DeepRenderOutcome;
 /** Whole-session wall-clock cap, including browser launch (I4). */

package/dist/task/deep-render-check.js

@@ -1,19 +1,20 @@
 /**
  * deep-render-check — sign in on the booted app and prove the AUTHENTICATED half
- * of it is alive (mx5 run 17).
+ * of it is alive.
  *
  * The failure class this closes: the shallow render check (render-check.ts) loads
- * ONE url and judges the rendered DOM. mx5 run 17 satisfies it completely while
+ * ONE url and judges the rendered DOM. An app can satisfy it completely while
  * being unusable — GET / redirects to /login, the login page renders fully, and
- * that is the whole check. Behind it, src/client/hooks/useAuth.ts called
- * `typedClient.api.auth.me.get()`; hono RPC methods are `$get`/`$post`, so a bare
- * `.get` is just another path segment in hono's createProxy and the call returns a
- * request BUILDER that never issues a request. Login POSTs 200 and sets the
- * session cookie, zero /api/auth/me requests are ever made, and the app bounces to
- * /login forever. Seven call sites were dead the same way, mixed in the same files
- * with correct `$get` ones — the signature of code no runtime ever executed. The
- * server was healthy throughout: 134/134 tests, tsc clean, login 200, me-with-
- * cookie 200. Nothing static could see it.
+ * that is the whole check.
+ *
+ * Behind that wall lives the DEAD CLIENT CALL. A typed RPC client whose method
+ * names are proxied (hono's `$get`/`$post`, say) turns a wrong-but-plausible
+ * spelling into just another path segment: the call returns a request BUILDER and
+ * never issues a request. Login POSTs 200 and sets the session cookie, the
+ * follow-up data call is never made at all, and the app bounces back to the wall
+ * forever. The dead spellings sit in the same files as correct ones, which is the
+ * signature of code no runtime ever executed — and everything static stays green:
+ * the suite passes, tsc is clean, and both endpoints answer 200 to curl.
  *
  * The generic instrument is a NETWORK FACT: after a real sign-in, did the client
  * actually leave the wall, and did its data calls actually reach the server. No
@@ -24,8 +25,8 @@
  *
  * SCOPE HONESTY: this is WEB-ONLY. It runs only behind detectsServedApp() and does
  * nothing for C++, Godot, CLI or library projects, which are most of the fleet. It
- * is here because the class is the most expensive one observed — it ended run 16
- * (blank page) and run 17 (dead login) outright.
+ * is here because the class is the most expensive one observed: a blank page, or
+ * a login that does not work, ends a run outright.
  *
  * Mechanism, dependency-free: the same discovered Chrome-family binary the shallow
  * check uses, driven over the DevTools protocol through the `ws` dependency the
@@ -47,7 +48,9 @@ import { findHeadlessBrowser, judgeRenderedDom } from './render-check.js';
 const IDENTIFIER_SUFFIXES = ['PHONE', 'EMAIL', 'USERNAME', 'USER', 'LOGIN', 'IDENTIFIER'];
 const PASSWORD_SUFFIXES = ['PASSWORD', 'PASSWD', 'PASS'];
 /** Prefixes whose `_PASSWORD` belongs to infrastructure, not to an app account.
- *  `DB_USER`/`DB_PASSWORD` pair perfectly and would otherwise be tried as a login. */
+ *  `DB_USER`/`DB_PASSWORD` pair perfectly and would otherwise be tried as a login.
+ *  Confirmed: that pair alone yields no credentials, and so does POSTGRES_*, while
+ *  an ADMIN pair in the same file is chosen over both. */
 const INFRA_PREFIX_RE = /^(DATABASE|DB|POSTGRES|POSTGRESQL|PG|MYSQL|MARIADB|MONGO|MONGODB|REDIS|RABBIT|RABBITMQ|AMQP|KAFKA|SMTP|IMAP|MAIL|MAILER|S3|MINIO|AWS|GCP|AZURE|DOCKER|REGISTRY|NPM|GITHUB|GITLAB|PROXY|LDAP|VAULT|GRAFANA|SENTRY)$/i;
 /** Prefixes that name a seeded APP account, tried before any other pair. */
 const ACCOUNT_PREFIX_ORDER = ['ADMIN', 'TEST', 'E2E', 'SEED', 'DEV', 'DEFAULT', 'USER', 'LOGIN'];
@@ -65,10 +68,11 @@ function splitKey(key, suffixes) {
     return null;
 }
 /**
- * Parse a dotenv-style file into a plain record. Deliberately minimal (KEY=VALUE,
- * `export ` prefix, # comments, optional matching quotes) — this reads the same
- * file the app's own runtime reads, and anything it cannot parse simply yields no
- * credentials, which is a SKIP.
+ * Parse a dotenv-style file into a plain record. Deliberately minimal — KEY=VALUE,
+ * an optional `export ` prefix, `#` comments, and matching quotes that preserve
+ * inner spaces while an unquoted value drops a trailing ` #` comment. This reads
+ * the same file the app's own runtime reads, and anything it cannot parse simply
+ * yields no credentials, which is a SKIP rather than a failure.
  */
 export function parseEnvFile(text) {
     const out = {};
@@ -166,7 +170,7 @@ export function findLoginCredentials(vars) {
  * The LOCAL port the project's own client was built to call, when its dotenv pins
  * one (`APP_URL=http://localhost:3000`, `VITE_API_URL=…`), else null.
  *
- * Why the boot check wants it (measured on mx5@373e88d, both directions): a bundler
+ * Why the boot check wants it: a bundler
  * bakes that base URL into the client at BUILD time, so a client served on the
  * gate's freshly-reserved private port calls an origin nothing is listening on. The
  * app is then unusable for reasons that have nothing to do with the code, and the
@@ -174,7 +178,7 @@ export function findLoginCredentials(vars) {
  * origin and never reaches the server we booted. Serving on the app's own declared
  * port makes the session same-origin and the evidence real.
  *
- * This deliberately narrows the private-port ownership evidence of run 14, so it
+ * This deliberately narrows the private-port ownership evidence, so it
  * only applies when the port is LOCAL, DECLARED by the project itself, and CURRENTLY
  * FREE — the caller checks freeness and falls back to a reserved port otherwise.
  */
@@ -219,18 +223,23 @@ const MISSING_ROUTE_STATUS = new Set([404, 405, 501]);
  * Judge a recorded session. The ONE thing that may FAIL is a session the SERVER
  * authenticated (2xx on the sign-in request) whose client then could not use it:
  *
- *   - never left the wall                → the run-17 signature exactly;
+ *   - never left the wall                → the signature exactly;
  *   - data calls attempted, none 2xx     → the same class one page deeper;
- *   - post-sign-in page renders blank    → the run-16 class behind the wall.
+ *   - post-sign-in page renders blank    → the class behind the wall.
  *
  * Everything else is an environment or shape gap and SKIPs. Note what is NOT a
  * failure: zero data calls attempted after sign-in. A server-rendered app that
  * redirects to a fresh document legitimately issues no XHR at all, so the missing
- * half is reported UNOBSERVED in the detail instead. (The task text asked for
- * "≥1 same-origin /api/* 2xx during the session" as a hard assertion; STEP 0
- * refuted that wording — the BROKEN mx5 build satisfies it with the probe's own
- * login POST — so the assertion is registered post-auth and excludes the sign-in
- * request. See the scratch REGISTERED-METRIC record quoted in the commit.)
+ * half is reported UNOBSERVED in the detail instead.
+ *
+ * The data assertion is deliberately POST-AUTH and EXCLUDES the sign-in request.
+ * A plain "at least one same-origin 2xx during the session" would be satisfied by
+ * the probe's own login POST and nothing else — a broken build passes it.
+ *
+ * Run across every branch: only those three FAIL. No wall PASSes; no credentials,
+ * an undriveable form, no sign-in request, a server that REJECTED the credentials,
+ * and a client pinned to a foreign origin all SKIP; and zero post-auth data calls
+ * PASSes with the gap noted.
  */
 export function judgeDeepSession(f) {
     if (!f.landingHadAuthWall) {
@@ -753,9 +762,9 @@ export async function driveSession(cdp, { url, credentials, judge, quietMs }) {
     lastActivity = Date.now();
     await settle(() => lastActivity, POST_SUBMIT_CAP_MS, quietMs);
     // The sign-in request: the first same-origin non-GET issued by the submit. Its
-    // own 2xx is the precondition for judging anything, and it is excluded from the
-    // data evidence (STEP 0: the broken build satisfies "≥1 same-origin 2xx" with
-    // exactly this request and nothing else).
+    // own 2xx is the precondition for judging anything, and it is EXCLUDED from the
+    // data evidence — a broken build satisfies "at least one same-origin 2xx" with
+    // exactly this request and nothing else.
     const after = new Map([...requests].filter(([, r]) => r.at >= submitMark));
     let authId = null;
     for (const [id, r] of after) {
@@ -770,7 +779,7 @@ export async function driveSession(cdp, { url, credentials, judge, quietMs }) {
     const domJudgment = judgeRenderedDom(now?.html ?? '');
     const leftAuthWall = !(now?.hasPassword ?? false) || (now?.pathname ?? '') !== before.pathname;
     // Exercise the authenticated app once. A sign-in page that ends on a success
-    // card — mx5's does — issues NOTHING after the login POST, so the authenticated
+    // card can issue NOTHING after the login POST, so the authenticated
     // data path is never observed at all and every request-shaped fact below is a
     // fact about the login form. Re-entering the landing URL with the session cookie
     // is the cheapest way to make the app fetch its own data. Deliberately gated on