@mjasnikovs/pi-task 0.38.15 → 0.38.17

package/dist/task/question-source.d.ts

@@ -0,0 +1,117 @@
+/**
+ * Where the NEXT question comes from — the other half of `question-dialog.ts`.
+ *
+ * `question-dialog.ts` unified the ANSWER side of the adaptive dialogs (the picker
+ * cards, the reply mapping) and its own docstring makes the argument for doing so:
+ * *"It was written three times… the two mirrors were never converted, and they had
+ * already drifted apart in three ways… The next edit to any of them is where the
+ * bug lands."* The QUESTION side — generate → parse → pick the real question →
+ * dedupe → spend one corrective re-prompt → yield or exhaust — was left behind,
+ * and it had drifted between the two loops that use the SAME parser on the SAME
+ * prompt format (`plan-prompts.ts` says `parseClarifyList` parses it "UNCHANGED";
+ * `auto-prompts.ts` specifies the identical shape).
+ *
+ * The five drifts, all in clarify's favour of being wrong:
+ *
+ *  1. **Which entry is the question.** `parseClarifyList` pushes an entry for
+ *     EVERY numbered line, and the local model writes numbered analysis notes
+ *     before the question it was asked for (measured live). `pickQuestion` prefers
+ *     the first entry carrying a `SUGGESTED:` line; clarify took `parsed[0]`
+ *     blindly, showing the note as the question and losing the recommendation
+ *     attached further down.
+ *  2. **NONE vs unparseable.** The parser returns `[]` for both. Clarify's
+ *     `if (parsed.length === 0) break` ended the whole clarify — and decomposed the
+ *     feature with ZERO clarifications — on a formatting slip.
+ *  3. **A re-typed sentinel.** `isNoneReply`'s regex was a byte-identical second
+ *     copy of the parser's own.
+ *  4. **Missing SUGGESTED** bought one corrective re-prompt in plan and none in
+ *     clarify, so clarify showed a card-less question.
+ *  5. **The deferral guard.** 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 VERIFY asserted 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.
+ *
+ * NOT unified here: grill's generation loop. It uses a different parser
+ * (`parseGrillQuestions`, which yields bare strings) and has no `SUGGESTED` at
+ * generation time at all — grill's recommendation comes from `phaseAutoAnswer`
+ * one step later, so every quality rule below is inapplicable to it. Folding it in
+ * would mean a generic over the parsed shape with one consumer opting out of the
+ * entire rule table: a wider interface for less behaviour.
+ */
+import { type ClarifyQuestion } from './parsers.js';
+/**
+ * The cap on distinct questions ONE adaptive dialog may ask.
+ *
+ * Clarify and plan each declared their own `8`, linked only by a comment saying
+ * "matches /task-auto's MAX_CLARIFY_QUESTIONS, for the same reason". They bound
+ * the same thing for the same reason; this is that reason, once.
+ */
+export declare const MAX_DIALOG_QUESTIONS = 8;
+/** True when the reply is the deliberate "nothing left to ask" sentinel, as
+ *  opposed to output the parser simply could not read. */
+export declare function isNoneReply(raw: string): boolean;
+/**
+ * Which of the parsed entries is the actual question.
+ *
+ * `parseClarifyList` turns EVERY numbered line into an entry, and the local model
+ * sometimes writes a numbered analysis note or two before the question it was
+ * asked for (measured live: the first numbered line was a note like
+ * "1. gateDebugWriter in orchestrator.ts — wraps a raw append function"). Taking
+ * entry 0 blindly then shows the note as the question and loses the SUGGESTED line
+ * attached further down. The prompt requires exactly one SUGGESTED, and the parser
+ * attaches it to the entry it follows.
+ */
+export declare function pickQuestion<T extends {
+    suggested?: string;
+}>(parsed: T[]): T | undefined;
+/**
+ * One QUALITY rule: a defect in an otherwise-usable question that is worth exactly
+ * one corrective re-prompt.
+ *
+ * `detect` returns the hint to re-prompt with, or null to pass. `repair` is what
+ * to do when the SAME defect survives the re-prompt — a question with a bad
+ * default still beats no question, so a rule degrades rather than discards.
+ */
+export interface QuestionRule {
+    id: string;
+    detect: (q: ClarifyQuestion, plain: string) => string | null;
+    /** Applied only when the defect survived its one re-prompt. */
+    repair?: (q: ClarifyQuestion) => ClarifyQuestion;
+}
+export interface QuestionSourceDeps {
+    /**
+     * Ask the model for the next question. `hint` is the corrective re-prompt to
+     * prepend, or null. The caller closes over its own transcript and prompt — the
+     * source never builds one.
+     */
+    generate: (hint: string | null) => Promise<string>;
+    /** The corrective re-prompt for a reply the parser could not read. */
+    formatHint: string;
+    /** Ordered quality rules; each may fire at most once per question. */
+    rules?: ReadonlyArray<QuestionRule>;
+    cap?: number;
+    log?: (msg: string) => void;
+}
+export type NextQuestion = {
+    kind: 'question';
+    q: ClarifyQuestion;
+    plain: string;
+    index: number;
+} | {
+    kind: 'exhausted';
+    why: 'none' | 'cap' | 'dups' | 'unparseable';
+};
+/**
+ * A deep module over a state machine that was five mutable locals per site.
+ *
+ * The interface is one method. Behind it: the cap, the duplicate backstop and its
+ * strike budget, the NONE-vs-unparseable distinction, `pickQuestion`, the one-shot
+ * budget shared by every quality rule, and the hint precedence between a format
+ * re-prompt and a duplicate re-prompt.
+ */
+export declare function makeQuestionSource(deps: QuestionSourceDeps): {
+    next: () => Promise<NextQuestion>;
+    asked: () => ReadonlyArray<string>;
+    reopen: () => void;
+};

package/dist/task/question-source.js

@@ -0,0 +1,174 @@
+/**
+ * Where the NEXT question comes from — the other half of `question-dialog.ts`.
+ *
+ * `question-dialog.ts` unified the ANSWER side of the adaptive dialogs (the picker
+ * cards, the reply mapping) and its own docstring makes the argument for doing so:
+ * *"It was written three times… the two mirrors were never converted, and they had
+ * already drifted apart in three ways… The next edit to any of them is where the
+ * bug lands."* The QUESTION side — generate → parse → pick the real question →
+ * dedupe → spend one corrective re-prompt → yield or exhaust — was left behind,
+ * and it had drifted between the two loops that use the SAME parser on the SAME
+ * prompt format (`plan-prompts.ts` says `parseClarifyList` parses it "UNCHANGED";
+ * `auto-prompts.ts` specifies the identical shape).
+ *
+ * The five drifts, all in clarify's favour of being wrong:
+ *
+ *  1. **Which entry is the question.** `parseClarifyList` pushes an entry for
+ *     EVERY numbered line, and the local model writes numbered analysis notes
+ *     before the question it was asked for (measured live). `pickQuestion` prefers
+ *     the first entry carrying a `SUGGESTED:` line; clarify took `parsed[0]`
+ *     blindly, showing the note as the question and losing the recommendation
+ *     attached further down.
+ *  2. **NONE vs unparseable.** The parser returns `[]` for both. Clarify's
+ *     `if (parsed.length === 0) break` ended the whole clarify — and decomposed the
+ *     feature with ZERO clarifications — on a formatting slip.
+ *  3. **A re-typed sentinel.** `isNoneReply`'s regex was a byte-identical second
+ *     copy of the parser's own.
+ *  4. **Missing SUGGESTED** bought one corrective re-prompt in plan and none in
+ *     clarify, so clarify showed a card-less question.
+ *  5. **The deferral guard.** 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 VERIFY asserted 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.
+ *
+ * NOT unified here: grill's generation loop. It uses a different parser
+ * (`parseGrillQuestions`, which yields bare strings) and has no `SUGGESTED` at
+ * generation time at all — grill's recommendation comes from `phaseAutoAnswer`
+ * one step later, so every quality rule below is inapplicable to it. Folding it in
+ * would mean a generic over the parsed shape with one consumer opting out of the
+ * entire rule table: a wider interface for less behaviour.
+ */
+import { parseClarifyList } from './parsers.js';
+import { DUP_REPROMPT_HINT, isDuplicateQuestion, MAX_DUP_STRIKES } from './question-dedup.js';
+import { stripInlineMarkdown } from './inline-markdown.js';
+/**
+ * The cap on distinct questions ONE adaptive dialog may ask.
+ *
+ * Clarify and plan each declared their own `8`, linked only by a comment saying
+ * "matches /task-auto's MAX_CLARIFY_QUESTIONS, for the same reason". They bound
+ * the same thing for the same reason; this is that reason, once.
+ */
+export const MAX_DIALOG_QUESTIONS = 8;
+/** True when the reply is the deliberate "nothing left to ask" sentinel, as
+ *  opposed to output the parser simply could not read. */
+export function isNoneReply(raw) {
+    return /^\s*NONE\s*$/m.test(raw);
+}
+/**
+ * Which of the parsed entries is the actual question.
+ *
+ * `parseClarifyList` turns EVERY numbered line into an entry, and the local model
+ * sometimes writes a numbered analysis note or two before the question it was
+ * asked for (measured live: the first numbered line was a note like
+ * "1. gateDebugWriter in orchestrator.ts — wraps a raw append function"). Taking
+ * entry 0 blindly then shows the note as the question and loses the SUGGESTED line
+ * attached further down. The prompt requires exactly one SUGGESTED, and the parser
+ * attaches it to the entry it follows.
+ */
+export function pickQuestion(parsed) {
+    return parsed.find(q => q.suggested !== undefined && q.suggested.length > 0) ?? parsed[0];
+}
+/**
+ * A deep module over a state machine that was five mutable locals per site.
+ *
+ * The interface is one method. Behind it: the cap, the duplicate backstop and its
+ * strike budget, the NONE-vs-unparseable distinction, `pickQuestion`, the one-shot
+ * budget shared by every quality rule, and the hint precedence between a format
+ * re-prompt and a duplicate re-prompt.
+ */
+export function makeQuestionSource(deps) {
+    const cap = deps.cap ?? MAX_DIALOG_QUESTIONS;
+    const rules = deps.rules ?? [];
+    const asked = [];
+    let dupStrikes = 0;
+    let dupHint = null;
+    // The one-shot budget is per QUESTION, not per dialog: a fresh draw starts
+    // with every rule available again. `hint` being non-null is also what spends
+    // it — a rule may not fire while another rule's re-prompt is in flight, which
+    // is what stops two rules ping-ponging a stateless child forever.
+    let hint = null;
+    async function next() {
+        for (;;) {
+            if (asked.length >= cap) {
+                deps.log?.(`question cap (${cap}) reached`);
+                return { kind: 'exhausted', why: 'cap' };
+            }
+            const raw = await deps.generate(hint ?? dupHint);
+            const parsed = parseClarifyList(raw);
+            if (parsed.length === 0) {
+                // `[]` means BOTH "deliberate NONE" and "could not parse". Ending
+                // the dialog on the second is how a formatting slip becomes a
+                // feature decomposed with zero clarifications.
+                if (!isNoneReply(raw) && hint === null) {
+                    deps.log?.('unparseable question reply — one format re-prompt');
+                    hint = deps.formatHint;
+                    continue;
+                }
+                // A SECOND unreadable reply is not a NONE. Recording it as one is
+                // the very conflation this module exists to end — it would put
+                // "model has no further questions" on the trail for a run where
+                // the model produced two malformed replies.
+                if (!isNoneReply(raw)) {
+                    deps.log?.('second unparseable reply — giving up on this draw');
+                    hint = null;
+                    return { kind: 'exhausted', why: 'unparseable' };
+                }
+                deps.log?.('model has no further questions (NONE)');
+                hint = null;
+                return { kind: 'exhausted', why: 'none' };
+            }
+            let picked = pickQuestion(parsed);
+            const plain = stripInlineMarkdown(picked.question);
+            // The duplicate backstop runs BEFORE any quality re-prompt: a question
+            // about to be discarded as a re-ask must not first buy itself an extra
+            // child call to be polished.
+            if (isDuplicateQuestion(asked, plain)) {
+                dupStrikes++;
+                deps.log?.(`duplicate question, strike ${dupStrikes}/${MAX_DUP_STRIKES}`);
+                hint = null;
+                if (dupStrikes >= MAX_DUP_STRIKES)
+                    return { kind: 'exhausted', why: 'dups' };
+                dupHint = DUP_REPROMPT_HINT;
+                continue;
+            }
+            let reprompted = false;
+            for (const rule of rules) {
+                const h = rule.detect(picked, plain);
+                if (h === null)
+                    continue;
+                if (hint === null) {
+                    deps.log?.(`${rule.id} — one re-prompt`);
+                    hint = h;
+                    reprompted = true;
+                    break;
+                }
+                // Survived its re-prompt: degrade rather than discard.
+                if (rule.repair) {
+                    deps.log?.(`${rule.id} — survived the re-prompt, repaired`);
+                    picked = rule.repair(picked);
+                }
+            }
+            if (reprompted)
+                continue;
+            hint = null;
+            dupStrikes = 0;
+            dupHint = null;
+            asked.push(plain);
+            return { kind: 'question', q: picked, plain, index: asked.length };
+        }
+    }
+    /**
+     * Clear the DUP strike budget after the caller supplies new context.
+     *
+     * `/task-plan` lets the user ask the model a question or state a decision
+     * mid-session; that is new context, so a generator that had struck out may now
+     * have something novel. The plan loop reset its own `dupStrikes` at two sites
+     * for exactly this; the budget lives here now, so the reset has to.
+     */
+    function reopen() {
+        dupStrikes = 0;
+        dupHint = null;
+    }
+    return { next, asked: () => asked, reopen };
+}

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

@@ -1,3 +1,4 @@
+import { type CommandRunner } from './command-run.js';
 export interface HealthOutcome {
     /** true → every discovered static check passed, or there was nothing to run.
      *  false → a discovered command actually ran and exited non-zero. */
@@ -29,38 +30,37 @@ export declare function discoverHealthCommands(cwd: string): {
     ecosystem: string | null;
     cmds: HealthCommand[];
 };
+/** Progress hook: called with each command's label as it STARTS, so a caller can
+ *  keep a live status line naming what is currently running. */
+export type HealthProgress = (command: string) => void;
 /**
  * Run the discovered static checks whole-repo and let the real exit codes decide.
- * Deterministic and synchronous under the hood (a wrapper keeps the caller async).
  *
  *  - No manifest / no static command  → ok (nothing can regress).
- *  - A command that CANNOT run (ENOENT / null exit — tool not installed) → skipped,
+ *  - A command that CANNOT run (ENOENT / null exit / 127 inside the chain) → skipped,
  *    treated as an environment gap, not a fault.
  *  - A command that ran and exited non-zero → the first such failure is returned.
  *
- * A generous per-command timeout guards against a wedged tool; a timeout is treated
- * as an inconclusive skip, not a fault (it is an environment problem, not the code's).
+ * This module owns DISCOVERY and its own output policy; running a command and
+ * deciding what its ending MEANS is `command-run.ts`'s. It used to own those too —
+ * `HealthRun`, `classifyHealthRun` and `spawnHealthCommand` were a second statement
+ * of the gap ladder, with no injectable runner, so every classification case in the
+ * suite spawned a real shell. `command-run.ts`'s own header notes that this module
+ * "had solved exactly this shape years earlier" and the gate never adopted it; this
+ * is the adoption, in the other direction.
  *
- * SYNCHRONOUS — it blocks the event loop for as long as the project's own lint takes
- * (MEASURED: 15s on mx5, 69s on aiz-client), so nothing can render or animate while
- * it runs. Gate callers must use {@link runRepoHealthCheckAsync} instead; this stays
- * for callers that genuinely have no async seam.
- */
-export declare function runRepoHealthCheck(cwd: string, timeoutMs?: number): HealthOutcome;
-/** Progress hook: called with each command's label as it STARTS, so a caller can
- *  keep a live status line naming what is currently running. */
-export type HealthProgress = (command: string) => void;
-/**
- * Same check, same verdicts, without blocking the event loop.
+ * `captureHealthOutput` stays this module's own: 40 lines of a linter's report is a
+ * real difference from `outputTail`'s 400 characters, and that is a parameter, not a
+ * thing to unify.
  *
- * The gate runs this immediately after the implementation turn ends, when the impl
- * widget has just been cleared — the sync version froze the whole TUI there for the
- * duration of the project's lint (MEASURED: 0 of 686 expected 100ms timer ticks
- * fired during a 69s aiz-client run), so no spinner, clock or queued notify could
- * paint. `onCommand` lets the caller name the running command in a live status line.
+ * `onCommand` lets the caller name the running command in a live status line — the
+ * gate runs this immediately after the implementation turn ends, when the impl
+ * widget has just been cleared.
  */
-export declare function runRepoHealthCheckAsync(cwd: string, opts?: {
+export declare function runRepoHealthCheck(cwd: string, opts?: {
     timeoutMs?: number;
     signal?: AbortSignal;
     onCommand?: HealthProgress;
+    /** The spawner. Injected so a verdict is testable without a real shell. */
+    run?: CommandRunner;
 }): Promise<HealthOutcome>;

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

@@ -29,10 +29,10 @@
  * environment gap, not a code fault, so that command is SKIPPED — only a command that
  * actually ran and returned non-zero fails the check.
  */
-import { spawn, spawnSync } from 'node:child_process';
 import { existsSync, readFileSync } from 'node:fs';
 import * as path from 'node:path';
-import { resolveRunner, runnerEnv, isCommandNotFound } from './runner-resolve.js';
+import { resolveRunner, runnerEnv } from './runner-resolve.js';
+import { classifyCommandRun, spawnCommand } from './command-run.js';
 /** How much of a failing command's output to keep — bounded so a wedged tool that
  *  spews megabytes cannot bloat the trail. stderr leads (a crash trace lives there). */
 const HEALTH_OUTPUT_MAX_LINES = 40;
@@ -106,141 +106,72 @@ export function discoverHealthCommands(cwd) {
     }
     return { ecosystem: null, cmds: [] };
 }
-/**
- * Verdict for ONE finished command: 'skip' (environment gap — cannot conclude),
- * 'pass', or the FAIL outcome. Shared by the sync and async runners so their
- * semantics cannot drift apart — the async runner exists only to stop blocking the
- * event loop, and a behaviour difference between the two would be a silent gate
- * change rather than a UI fix.
- */
-function classifyHealthRun(bin, args, ecosystem, r) {
-    // Tool missing (ENOENT) or killed by timeout → cannot conclude; skip it.
-    if (r.failedToStart || r.status === null)
-        return 'skip';
-    // "Command not found" INSIDE the script chain (e.g. `bun run lint` before
-    // node_modules exists — seen live failing TASK_0001's first verify). Same
-    // environment gap as ENOENT, just surfaced through the runner's shell —
-    // as exit 127 where a posix shell ran it, else by the runner's own wording
-    // (Windows bun reports the miss itself and exits 1).
-    if (isCommandNotFound(r.status, `${r.stdout ?? ''}\n${r.stderr ?? ''}`))
-        return 'skip';
-    if (r.status !== 0) {
-        return {
-            ok: false,
-            reason: `\`${bin} ${args.join(' ')}\` exited ${r.status}`,
-            ecosystem,
-            output: captureHealthOutput(r.stdout, r.stderr)
-        };
-    }
-    return 'pass';
-}
 /** The nothing-to-run outcome, shared by both runners. */
 function noCommandOutcome(ecosystem) {
     return { ok: true, reason: 'no repo-wide static-analysis command found', ecosystem, output: '' };
 }
 /**
  * Run the discovered static checks whole-repo and let the real exit codes decide.
- * Deterministic and synchronous under the hood (a wrapper keeps the caller async).
  *
  *  - No manifest / no static command  → ok (nothing can regress).
- *  - A command that CANNOT run (ENOENT / null exit — tool not installed) → skipped,
+ *  - A command that CANNOT run (ENOENT / null exit / 127 inside the chain) → skipped,
  *    treated as an environment gap, not a fault.
  *  - A command that ran and exited non-zero → the first such failure is returned.
  *
- * A generous per-command timeout guards against a wedged tool; a timeout is treated
- * as an inconclusive skip, not a fault (it is an environment problem, not the code's).
+ * This module owns DISCOVERY and its own output policy; running a command and
+ * deciding what its ending MEANS is `command-run.ts`'s. It used to own those too —
+ * `HealthRun`, `classifyHealthRun` and `spawnHealthCommand` were a second statement
+ * of the gap ladder, with no injectable runner, so every classification case in the
+ * suite spawned a real shell. `command-run.ts`'s own header notes that this module
+ * "had solved exactly this shape years earlier" and the gate never adopted it; this
+ * is the adoption, in the other direction.
  *
- * SYNCHRONOUS — it blocks the event loop for as long as the project's own lint takes
- * (MEASURED: 15s on mx5, 69s on aiz-client), so nothing can render or animate while
- * it runs. Gate callers must use {@link runRepoHealthCheckAsync} instead; this stays
- * for callers that genuinely have no async seam.
+ * `captureHealthOutput` stays this module's own: 40 lines of a linter's report is a
+ * real difference from `outputTail`'s 400 characters, and that is a parameter, not a
+ * thing to unify.
+ *
+ * `onCommand` lets the caller name the running command in a live status line — the
+ * gate runs this immediately after the implementation turn ends, when the impl
+ * widget has just been cleared.
  */
-export function runRepoHealthCheck(cwd, timeoutMs = 600_000) {
+export async function runRepoHealthCheck(cwd, opts = {}) {
     const { ecosystem, cmds } = discoverHealthCommands(cwd);
     if (!ecosystem || cmds.length === 0)
         return noCommandOutcome(ecosystem);
+    const run = opts.run ?? spawnCommand;
     for (const [bin, args] of cmds) {
+        opts.onCommand?.(`${bin} ${args.join(' ')}`);
         // Runner resolution (mx5 run 16): a PATH-stripped environment must not
         // silently skip the statics when the runner sits at a known install
         // location; the resolved dir also rides on PATH for the script chain.
         const runner = resolveRunner(bin);
-        const r = spawnSync(runner.bin, args, {
+        const r = await run({
             cwd,
-            encoding: 'utf8',
-            timeout: timeoutMs,
-            env: runnerEnv(runner)
+            bin: runner.bin,
+            args,
+            timeoutMs: opts.timeoutMs ?? 600_000,
+            env: runnerEnv(runner),
+            ...(opts.signal === undefined ? {} : { signal: opts.signal })
         });
-        const verdict = classifyHealthRun(bin, args, ecosystem, {
-            failedToStart: r.error !== undefined,
-            status: r.status,
-            stdout: r.stdout ?? '',
-            stderr: r.stderr ?? ''
-        });
-        if (verdict === 'skip' || verdict === 'pass')
+        // The DECISION comes from the shared ladder; the OUTPUT is this module's own
+        // policy. `captureHealthOutput` keeps 40 lines of a linter's report where the
+        // ladder's `tail` keeps 400 characters, and that difference is real — a
+        // truncated lint report is unactionable. So the run is classified, not
+        // consumed: the verdict decides, the raw streams are what we show.
+        // `runtimeGap: false` — this ladder is NARROWER than the gate's. The
+        // browser/runtime row was written for the gate's TEST commands; here the
+        // commands are lint and typecheck, and its pattern matches ordinary
+        // English, so a genuine report quoting "browsers are not installed" would
+        // skip the static check and certify the repo healthy.
+        const verdict = classifyCommandRun(r, [], { runtimeGap: false });
+        if (verdict.outcome !== 'fail')
             continue;
-        return verdict;
-    }
-    return { ok: true, reason: `${ecosystem}: static checks passed`, ecosystem, output: '' };
-}
-/** Spawn one health command without blocking the event loop. Mirrors spawnSync's
- *  result shape (status null when killed, failedToStart on ENOENT). */
-function spawnHealthCommand(bin, args, cwd, timeoutMs, signal) {
-    return new Promise(resolve => {
-        const runner = resolveRunner(bin);
-        let stdout = '';
-        let stderr = '';
-        let settled = false;
-        const child = spawn(runner.bin, args, { cwd, env: runnerEnv(runner) });
-        const done = (r) => {
-            if (settled)
-                return;
-            settled = true;
-            clearTimeout(timer);
-            signal?.removeEventListener('abort', onAbort);
-            resolve(r);
-        };
-        const kill = () => {
-            try {
-                child.kill('SIGKILL');
-            }
-            catch {
-                /* already gone */
-            }
+        return {
+            ok: false,
+            reason: `\`${bin} ${args.join(' ')}\` exited ${verdict.status}`,
+            ecosystem,
+            output: captureHealthOutput(r.stdout, r.stderr)
         };
-        const timer = setTimeout(kill, timeoutMs);
-        timer.unref?.();
-        const onAbort = () => kill();
-        signal?.addEventListener('abort', onAbort, { once: true });
-        child.stdout?.on('data', (d) => {
-            stdout += d.toString();
-        });
-        child.stderr?.on('data', (d) => {
-            stderr += d.toString();
-        });
-        child.on('error', () => done({ failedToStart: true, status: null, stdout, stderr }));
-        child.on('close', (code) => done({ failedToStart: false, status: code, stdout, stderr }));
-    });
-}
-/**
- * Same check, same verdicts, without blocking the event loop.
- *
- * The gate runs this immediately after the implementation turn ends, when the impl
- * widget has just been cleared — the sync version froze the whole TUI there for the
- * duration of the project's lint (MEASURED: 0 of 686 expected 100ms timer ticks
- * fired during a 69s aiz-client run), so no spinner, clock or queued notify could
- * paint. `onCommand` lets the caller name the running command in a live status line.
- */
-export async function runRepoHealthCheckAsync(cwd, opts = {}) {
-    const { ecosystem, cmds } = discoverHealthCommands(cwd);
-    if (!ecosystem || cmds.length === 0)
-        return noCommandOutcome(ecosystem);
-    for (const [bin, args] of cmds) {
-        opts.onCommand?.(`${bin} ${args.join(' ')}`);
-        const r = await spawnHealthCommand(bin, args, cwd, opts.timeoutMs ?? 600_000, opts.signal);
-        const verdict = classifyHealthRun(bin, args, ecosystem, r);
-        if (verdict === 'skip' || verdict === 'pass')
-            continue;
-        return verdict;
     }
     return { ok: true, reason: `${ecosystem}: static checks passed`, ecosystem, output: '' };
 }

package/dist/task/run-end.d.ts

@@ -0,0 +1,77 @@
+/**
+ * run-end — how a single /task run ENDED, named once.
+ *
+ * `TaskRunner.run` returned `void` and never threw, so `runSingleTask` learned
+ * what it had just done by RE-READING the task file's front matter, narrowing
+ * that to `ok: boolean`, and smuggling the rest out of the `withSession` closure
+ * through three mutable captures. Both commands then re-derived a cause the
+ * runner already had: `classifyFailure` names the ending exactly, and
+ * `handleFailure` threw the name away.
+ *
+ * The live consequence was a wrong report. `/task-cancel` during a gated run
+ * writes `cancelled` to the file; `ok` is `state === 'completed'`, so it is
+ * false; `!res.ok` calls `markResumable`, which overwrites `cancelled` with
+ * `failed`, and announces a red *"stopped — fix and run /task-resume"*.
+ * `/task-auto` hits the same arm for the same input, because its cancel branch
+ * only consults a module global that `/task-cancel` never sets.
+ *
+ * The file is still written — it is what a RESUME reads. What changed is that it
+ * is no longer the channel this process uses to talk to itself.
+ */
+/** Why a run stopped. Exactly one of these is true of any finished run. */
+export type RunEnd = 
+/** Every phase ran and the spec was delivered. */
+{
+    kind: 'completed';
+}
+/** The user cancelled — via /task-cancel, ESC, or an aborted signal. */
+ | {
+    kind: 'cancelled';
+}
+/** A phase threw. `reason` is `FailureClass.reason`, already trimmed. */
+ | {
+    kind: 'failed';
+    reason?: string;
+}
+/** The implementation turn was interrupted and left resumable. */
+ | {
+    kind: 'interrupted';
+}
+/** No fresh session could be started, so nothing ran at all. */
+ | {
+    kind: 'no-session';
+};
+export type RunEndKind = RunEnd['kind'];
+/**
+ * What a command does about each ending.
+ *
+ * `resumable` and `announce` are the two facts the two hand-written ladders
+ * disagreed about, and the disagreement is where the cancel bug lived: a
+ * `cancelled` run was falling into the `failed` arm and being marked resumable.
+ * The WORDING stays per-command — `/task` says "resume with /task-resume" where
+ * `/task-auto` says "/task-auto-resume" — so only the policy is shared.
+ */
+export interface RunEndPolicy {
+    /** Mark the task resumable (overwrites its state with `failed`). */
+    resumable: boolean;
+    /**
+     * Does this ending FAIL the plan that contains the task?
+     *
+     * Strictly narrower than `resumable`, and the distinction is load-bearing: a
+     * declined-steer interrupt leaves the inner task resumable but the PLAN in
+     * progress, so `/task-auto-resume` re-delivers that task's spec. A fault fails
+     * the plan too. Only `/task-auto` reads this — a bare `/task` has no plan.
+     */
+    failsRun: boolean;
+    /** The notify level for this ending. */
+    level: 'info' | 'warning' | 'error';
+}
+/**
+ * The one table. A run that the USER stopped is not resumable-as-failed: its
+ * file already says `cancelled`, and rewriting that to `failed` both lies in the
+ * ledger and turns a deliberate stop into a red error the user has to read as a
+ * fault.
+ */
+export declare const RUN_END_POLICY: Record<RunEndKind, RunEndPolicy>;
+/** Did the run deliver a spec? The single question the old `ok` boolean answered. */
+export declare function runSucceeded(end: RunEnd): boolean;