@mjasnikovs/pi-task 0.14.12 → 0.14.14

package/dist/config/config.d.ts

@@ -4,6 +4,7 @@ export interface PiTaskConfig {
     autoCommit: boolean;
     orientation: boolean;
     enforceGuidelines: boolean;
+    verifyWork: boolean;
 }
 export declare function getConfig(): PiTaskConfig;
 export declare function saveConfig(config: PiTaskConfig): Promise<void>;

package/dist/config/config.js

@@ -7,7 +7,8 @@ const DEFAULTS = {
     compressReasoning: true,
     autoCommit: true,
     orientation: true,
-    enforceGuidelines: false
+    enforceGuidelines: false,
+    verifyWork: false
 };
 const CONFIG_PATH = path.join(os.homedir(), '.config', 'pi-task', 'config.json');
 const _g = globalThis;

package/dist/config/register.js

@@ -22,6 +22,11 @@ const ITEMS = [
         id: 'enforceGuidelines',
         label: 'enforce guidelines',
         description: 'Before each /task-auto commit, re-check the work against AGENTS.md/CLAUDE.md and fix drift'
+    },
+    {
+        id: 'verifyWork',
+        label: 'verify work',
+        description: "After each /task-auto task, RUN its spec's VERIFY block in the workspace and report a PASS/FAIL verdict"
     }
 ];
 function makeTheme(theme) {

package/dist/task/auto-orchestrator.d.ts

@@ -2,6 +2,7 @@ import type { ExtensionAPI, ExtensionCommandContext } from '@earendil-works/pi-c
 import type { RunSingleTaskResult } from './orchestrator.js';
 import { type CommitResult } from './auto-commit.js';
 import { type EnforceOutcome } from './enforce-guidelines.js';
+import { type VerifyOutcome } from './verify-work.js';
 /**
  * Injectable seams so the planner and loop are testable without spawning pi.
  * `runChild` is used by planAuto; `runTask` is used by runAutoLoop.
@@ -29,6 +30,16 @@ export interface AutoDeps {
      * enforcement runs and using it for the loader widget throws "stale ctx".
      */
     enforce?: (ctx: ExtensionCommandContext, cwd: string, taskTitle: string) => Promise<EnforceOutcome>;
+    /**
+     * Verify the just-finished task's work by RUNNING its composed spec's VERIFY
+     * block in the real workspace (a fresh child of the same local model, with a
+     * `bash` tool), then reporting a PASS/FAIL verdict. Optional: absent in tests
+     * or when the `verifyWork` flag is off, in which case the loop treats it as a
+     * pass. Runs BEFORE the task is checked off/committed and is a hard GATE: ok
+     * === false stops the run and fails the task (left unchecked so resume re-runs
+     * it). Needs the inner taskId to read that task's spec.
+     */
+    verify?: (ctx: ExtensionCommandContext, cwd: string, taskTitle: string, taskId: string) => Promise<VerifyOutcome>;
 }
 /**
  * Expand any @file references in the feature text by appending each referenced

package/dist/task/auto-orchestrator.js

@@ -16,6 +16,7 @@ import { allocateAutoId, buildAutoBody, parseDecomposeList, parseTaskList, check
 import { writeTaskFile, readTaskFile, updateTaskFrontMatter, taskFilePath, tasksDir } from './task-io.js';
 import { gitCommitAll } from './auto-commit.js';
 import { runGuidelineEnforcement, classifyEnforceChildFailure } from './enforce-guidelines.js';
+import { runWorkVerification, extractSpecForVerification } from './verify-work.js';
 import { runWorker } from '../workers/pi-worker-core.js';
 import { findPhantomImports, rewritePhantomSpecifiers } from '../workers/phantom-imports.js';
 import { runPhaseChild, prependHint, formatLoopHint, USER_CANCELLED } from './child-runner.js';
@@ -481,6 +482,86 @@ function defaultDeps(ctx, cwd, signal, title) {
                     }
                 }
             });
+        },
+        verify: async (verifyCtx, cwd2, taskTitle, taskId) => {
+            if (!getConfig().verifyWork) {
+                return { ok: true, reason: 'disabled' };
+            }
+            // The spec to verify against is the composed spec committed in the
+            // task file. A task that never reached compose has no spec section —
+            // runWorkVerification treats a null spec as a no-op pass.
+            let spec;
+            try {
+                const { body } = await readTaskFile(cwd2, taskId);
+                spec = extractSpecForVerification(body);
+            }
+            catch {
+                spec = null;
+            }
+            return runWorkVerification({
+                cwd: cwd2,
+                signal,
+                spec,
+                // Same unguarded child as enforce: no wall-clock timeout (a build
+                // or test suite legitimately takes minutes) and exact-match loop
+                // guard only. Re-running the same VERIFY command is the job, so the
+                // path-revisit heuristic is disabled; only a literally-identical
+                // call repeated past threshold trips, and that warns rather than
+                // blocks.
+                runChild: async (tools, prompt, sig) => {
+                    lastLine = undefined;
+                    contextUsage = undefined;
+                    const startedAt = Date.now();
+                    const verifyLogPath = path.join(tasksDir(cwd2), 'verify-debug.log');
+                    const logVerify = (msg) => {
+                        void fsp
+                            .appendFile(verifyLogPath, `${new Date().toISOString()} ${msg}\n`)
+                            .catch(() => { });
+                    };
+                    logVerify(`=== verify start: ${taskTitle} ===`);
+                    const stopLoader = startAutoLoader(verifyCtx, () => ({
+                        title: taskTitle,
+                        kind: 'verify',
+                        step: 'verify',
+                        stepNum: 1,
+                        stepTotal: 1,
+                        startedAt,
+                        lastLine,
+                        contextUsage
+                    }));
+                    try {
+                        const r = await runWorker({
+                            prompt,
+                            cwd: cwd2,
+                            signal: sig,
+                            tools,
+                            timeoutMs: 0,
+                            loop: { pathThreshold: Number.POSITIVE_INFINITY },
+                            onLine: line => {
+                                lastLine = line;
+                                logVerify(line);
+                            },
+                            onContextUsage: snapshot => {
+                                contextUsage = resolveContextUsage(snapshot, contextUsage, parentContextWindow);
+                            }
+                        });
+                        if (r.loopHit) {
+                            logVerify(`=== verify LOOP WARNING — ${formatLoopHint(r.loopHit)} ===`);
+                            verifyCtx.ui.notify(`${taskTitle}: verify worker looped past the nudges — continuing (not blocked).`, 'warning');
+                        }
+                        const failure = classifyEnforceChildFailure(r);
+                        logVerify(failure ?
+                            `=== verify end: FAIL — ${failure} ===`
+                            : '=== verify end: verdict captured ===');
+                        if (failure)
+                            throw new Error(failure);
+                        return r.text;
+                    }
+                    finally {
+                        stopLoader();
+                    }
+                }
+            });
         }
     };
 }
@@ -586,6 +667,24 @@ export async function runAutoLoop(ctx, cwd, id, deps) {
                 announceDone(active, `${id} stopped at "${next.title}"${why} — fix and run /task-auto-resume.`, 'error');
                 return;
             }
+            // GATE: actually RUN the task's verification against the just-finished
+            // work BEFORE it is checked off or committed. The composed spec ships a
+            // VERIFY block, but nothing in the pipeline ever executed it — a task
+            // that did not work was checked off identically to one that did. Run it
+            // now in the real workspace; a FAIL stops the whole run exactly like an
+            // implementation failure — the task is left UNCHECKED and UNCOMMITTED so
+            // /task-auto-resume re-runs it (rather than blessing broken work). Off
+            // by default (deps.verify returns a disabled no-op) and a no-op when the
+            // task has no composed spec to verify against.
+            if (deps.verify) {
+                active.ui.notify(`${id}: verifying "${next.title}"…`, 'info');
+                const verified = await deps.verify(active, cwd, next.title, res.taskId);
+                if (!verified.ok) {
+                    await updateTaskFrontMatter(cwd, id, { state: 'failed' });
+                    announceDone(active, `${id} stopped at "${next.title}" — ${verified.reason ?? 'did not verify'} — fix and run /task-auto-resume.`, 'error');
+                    return;
+                }
+            }
             // res.ok === true means runner.run() completed, so res.taskId is the
             // allocated TASK_NNNN id (never empty here). checkOffTask tolerates an
             // empty id by writing a plain checked line, but that path is unreachable.

package/dist/task/question-box.js

@@ -17,8 +17,12 @@
  */
 import { getKeybindings, visibleWidth, wrapTextWithAnsi } from '@earendil-works/pi-tui';
 // ─── Constants ───────────────────────────────────────────────────────────────
-/** Left gutter: two columns reserved for the "▸ " cursor so boxes stay aligned. */
+/** Left gutter: two columns reserved for the cursor bar so boxes stay aligned. */
 const GUTTER = 2;
+/** Cap the dialog at a readable column count. Without this the boxes stretch the
+ *  full terminal width on wide/ultrawide screens — long question lines become
+ *  hard to scan and short answers leave a huge empty right margin inside the box. */
+const MAX_CONTENT_WIDTH = 96;
 const RECOMMENDED_TAG = 'RECOMMENDED';
 /** Smallest box that still fits "┌─ RECOMMENDED ─┐". Below this we drop the tag. */
 const TAG_MIN_BOX_WIDTH = visibleWidth(`┌─ ${RECOMMENDED_TAG} ─┐`);
@@ -49,9 +53,10 @@ function renderCard(card, selected, boxWidth, c) {
     const bodyLines = wrapTextWithAnsi(card.label, innerWidth);
     const body = (bodyLines.length > 0 ? bodyLines : ['']).map(line => borderFn('│ ') + padTo(line, innerWidth) + borderFn(' │'));
     const bottom = borderFn(`└${dash(boxWidth - 2)}┘`);
-    const arrow = selected ? c.arrow('▸') + ' ' : '  ';
-    const pad = '  ';
-    return [arrow + top, ...body.map(b => pad + b), pad + bottom];
+    // A full-height accent bar in the gutter marks the selected card — far more
+    // visible than a single "▸" glyph on the top border alone.
+    const cursor = selected ? c.arrow('▌') + ' ' : '  ';
+    return [cursor + top, ...body.map(b => cursor + b), cursor + bottom];
 }
 /**
  * Lay the whole dialog out for `width` columns: a QUESTION label + wrapped
@@ -59,7 +64,7 @@ function renderCard(card, selected, boxWidth, c) {
  * highlighted with an accent border and "▸" arrow), and a key-hint footer.
  */
 export function renderQuestionBox(width, question, cards, selected, c, hintText = HINT_TEXT) {
-    const W = Math.max(width, 12);
+    const W = Math.min(Math.max(width, 12), MAX_CONTENT_WIDTH);
     const boxWidth = Math.max(6, W - GUTTER);
     const out = [''];
     out.push('  ' + c.questionLabel(QUESTION_LABEL));

package/dist/task/verify-work.d.ts

@@ -0,0 +1,68 @@
+/**
+ * The verification child gets exactly two tools: `read` and `bash`.
+ *
+ *  - `bash` IS the point: it lets the child actually execute the spec's VERIFY
+ *    commands (or whatever check the ACCEPTANCE criteria imply) and see the real
+ *    exit codes and output, rather than reasoning about whether the code "looks"
+ *    correct.
+ *  - `read` lets it inspect a file the VERIFY output points at (a build error's
+ *    source line, a config it just validated) to characterise a failure precisely.
+ *  - No `edit`/`write`: this pass reports a verdict, it does not change the tree.
+ *    Keeping it read-only means a verify run can never itself introduce a change
+ *    that needs re-verifying, and never scaffolds the junk-file runaway that the
+ *    enforce pass had to drop `write` to stop.
+ */
+declare const VERIFY_TOOLS = "read,bash";
+export interface VerifyOutcome {
+    /** true → the work verified (or verification disabled / nothing to verify).
+     *  false → the child reported the work does NOT satisfy its spec, or the pass
+     *  could not run / produced no verdict. */
+    ok: boolean;
+    /** Short, human-readable reason. Always set when ok === false; on the pass
+     *  path set to the no-op cause ('disabled', 'no spec to verify'). */
+    reason?: string;
+}
+/**
+ * Slice the delivered spec (GOAL / CONSTRAINTS / ACCEPTANCE / VERIFY) out of a
+ * task file body. The composed spec lives under a `## spec` header and runs until
+ * the next top-level `## ` section (`## phase timings`). Returns null when no spec
+ * section is present (e.g. a task that never reached compose), which the caller
+ * treats as a pass — there is nothing to verify against.
+ */
+export declare function extractSpecForVerification(taskBody: string): string | null;
+/**
+ * Build the verification child's prompt. Kept pure so the wording is unit-tested
+ * without spawning pi. The contract: run the spec's own verification in the real
+ * workspace, judge against ACCEPTANCE, and end on exactly one verdict line.
+ */
+export declare function buildVerifyPrompt(spec: string): string;
+/**
+ * Parse the child's verdict. Scans for the LAST `WORK-VERIFIED: PASS|FAIL` marker
+ * (the model discusses before concluding, and bash output may echo the word
+ * "VERIFY", so a distinct token and last-match win matter).
+ *
+ * No marker at all is NOT a pass: a verification that cannot state a verdict is a
+ * gray area, and the contract is that unverified work is reported as such.
+ */
+export declare function parseVerifyVerdict(text: string): {
+    pass: boolean;
+    detail: string;
+};
+export interface VerificationDeps {
+    cwd: string;
+    signal?: AbortSignal;
+    /** The composed spec (GOAL/ACCEPTANCE/VERIFY) of the task just committed. When
+     *  null/empty the pass is a no-op (ok: true). */
+    spec: string | null;
+    /** Runs the verification child and returns its assistant text. Injected so
+     *  the orchestrator wires the real child runner and tests use a fake. */
+    runChild: (tools: string, prompt: string, signal?: AbortSignal) => Promise<string>;
+}
+/**
+ * Run the verification pass for one task. A missing spec is a pass. Otherwise run
+ * the child against the real workspace and turn its verdict into an ok/blocked
+ * outcome. Never throws (except a user cancel, which propagates so the loop's
+ * USER_CANCELLED handler reports a clean "cancelled — resume").
+ */
+export declare function runWorkVerification(deps: VerificationDeps): Promise<VerifyOutcome>;
+export { VERIFY_TOOLS };

package/dist/task/verify-work.js

@@ -0,0 +1,161 @@
+/**
+ * Work verification for /task-auto.
+ *
+ * The root failure this addresses: pi-task never *runs* any verification. Each
+ * task's composed spec carries a VERIFY block (and ACCEPTANCE criteria), but that
+ * block is only authored and presence-checked — never executed. The task is then
+ * marked `completed` at handoff. So a task whose implementation does not actually
+ * work (a SPA that won't build, a route wired to a dead stub, a CI file nobody
+ * runs) is indistinguishable from one that does.
+ *
+ * This pass closes that gap WITHOUT assuming any particular shape of project. It
+ * does NOT hardcode `build`, an HTTP probe, a server boot, or a test command —
+ * many tasks have none of those. Instead it hands the just-committed spec (GOAL /
+ * ACCEPTANCE / VERIFY) to a fresh child of the SAME local model, gives it a `read`
+ * and a `bash` tool in the real workspace, and lets the model do its job: run the
+ * verification the spec already declares, observe the REAL output, and report a
+ * PASS / FAIL verdict. If the spec's VERIFY is legitimately a no-op (config-only
+ * change, re-read of a file), the model says so and that is a PASS.
+ *
+ * It runs as a GATE right after the implementation turn, BEFORE the task is
+ * checked off or committed. A FAIL stops the /task-auto run exactly like an
+ * implementation failure: the task is left unchecked and uncommitted so
+ * /task-auto-resume re-runs it, rather than blessing work that does not run.
+ *
+ * Tools: `read` + `bash` only. No `edit`/`write` — verification observes, it does
+ * not fix (fixing committed work is the enforcement pass's job, and a verify pass
+ * that also edits would blur "did it work" with "make it work"). `bash` is what
+ * makes this real: it is the difference between reading the VERIFY block and
+ * RUNNING it.
+ *
+ * Gated by the `verifyWork` config flag. With the flag off, or with no spec to
+ * verify, this is a pass (ok: true).
+ */
+import { USER_CANCELLED } from './child-runner.js';
+/**
+ * The verification child gets exactly two tools: `read` and `bash`.
+ *
+ *  - `bash` IS the point: it lets the child actually execute the spec's VERIFY
+ *    commands (or whatever check the ACCEPTANCE criteria imply) and see the real
+ *    exit codes and output, rather than reasoning about whether the code "looks"
+ *    correct.
+ *  - `read` lets it inspect a file the VERIFY output points at (a build error's
+ *    source line, a config it just validated) to characterise a failure precisely.
+ *  - No `edit`/`write`: this pass reports a verdict, it does not change the tree.
+ *    Keeping it read-only means a verify run can never itself introduce a change
+ *    that needs re-verifying, and never scaffolds the junk-file runaway that the
+ *    enforce pass had to drop `write` to stop.
+ */
+const VERIFY_TOOLS = 'read,bash';
+/**
+ * Slice the delivered spec (GOAL / CONSTRAINTS / ACCEPTANCE / VERIFY) out of a
+ * task file body. The composed spec lives under a `## spec` header and runs until
+ * the next top-level `## ` section (`## phase timings`). Returns null when no spec
+ * section is present (e.g. a task that never reached compose), which the caller
+ * treats as a pass — there is nothing to verify against.
+ */
+export function extractSpecForVerification(taskBody) {
+    const lines = taskBody.split('\n');
+    let start = -1;
+    for (let i = 0; i < lines.length; i++) {
+        if (/^##\s+spec\s*$/i.test(lines[i])) {
+            start = i + 1;
+            break;
+        }
+    }
+    if (start === -1)
+        return null;
+    let end = lines.length;
+    for (let i = start; i < lines.length; i++) {
+        if (/^##\s+\S/.test(lines[i])) {
+            end = i;
+            break;
+        }
+    }
+    const spec = lines.slice(start, end).join('\n').trim();
+    return spec.length > 0 ? spec : null;
+}
+/**
+ * Build the verification child's prompt. Kept pure so the wording is unit-tested
+ * without spawning pi. The contract: run the spec's own verification in the real
+ * workspace, judge against ACCEPTANCE, and end on exactly one verdict line.
+ */
+export function buildVerifyPrompt(spec) {
+    return [
+        'You are a strict verification pass running right after an AI coding agent',
+        'finished a task and committed it. The agent is known to mark work "done"',
+        'without ever running it, so DO NOT trust that the implementation works —',
+        'prove it by running the verification this task ships with.',
+        '',
+        'You have a `read` tool and a `bash` tool — nothing else. You can run any',
+        'command and read any file, but you CANNOT edit or create files. Your job is',
+        'to VERIFY, not to fix.',
+        '',
+        'THE TASK SPEC (its ACCEPTANCE criteria and VERIFY block are the contract):',
+        spec.trim(),
+        '',
+        'How to verify:',
+        "1. Run the commands in the spec's VERIFY block, in order, with your `bash`",
+        '   tool, from the repository root. Observe the REAL exit codes and output —',
+        '   do not assume success.',
+        '2. Treat the ACCEPTANCE criteria as the bar. If a VERIFY command fails, or',
+        '   its output contradicts an ACCEPTANCE criterion, the work has NOT verified.',
+        '3. If a VERIFY command depends on something this environment genuinely lacks',
+        '   (a service, a network resource) and that is clearly an environment gap',
+        '   rather than a defect in the code, note it and judge the rest. Do not fail',
+        '   the task for a missing external service it cannot control.',
+        '4. If the spec legitimately has no runnable verification (a config-only or',
+        '   docs-only change whose VERIFY just re-reads or validates a file), running',
+        '   that re-read/validation cleanly is a PASS.',
+        '5. Do NOT edit anything to make a check pass. Report what you actually saw.',
+        '',
+        'When you are done, output EXACTLY ONE of these as the final line:',
+        '  WORK-VERIFIED: PASS              (every check ran and the work meets its spec)',
+        '  WORK-VERIFIED: FAIL <text>      (a check failed or the work does not meet its spec; say what failed)',
+        'Output the verdict line verbatim — it is parsed mechanically.'
+    ].join('\n');
+}
+/**
+ * Parse the child's verdict. Scans for the LAST `WORK-VERIFIED: PASS|FAIL` marker
+ * (the model discusses before concluding, and bash output may echo the word
+ * "VERIFY", so a distinct token and last-match win matter).
+ *
+ * No marker at all is NOT a pass: a verification that cannot state a verdict is a
+ * gray area, and the contract is that unverified work is reported as such.
+ */
+export function parseVerifyVerdict(text) {
+    const re = /WORK-VERIFIED:\s*(PASS|FAIL)\b[ \t]*(.*)/gi;
+    let last = null;
+    for (let m = re.exec(text); m !== null; m = re.exec(text))
+        last = m;
+    if (!last)
+        return { pass: false, detail: 'no verdict emitted' };
+    const pass = last[1].toUpperCase() === 'PASS';
+    return { pass, detail: pass ? '' : last[2].trim() || 'unspecified failure' };
+}
+/**
+ * Run the verification pass for one task. A missing spec is a pass. Otherwise run
+ * the child against the real workspace and turn its verdict into an ok/blocked
+ * outcome. Never throws (except a user cancel, which propagates so the loop's
+ * USER_CANCELLED handler reports a clean "cancelled — resume").
+ */
+export async function runWorkVerification(deps) {
+    if (!deps.spec || deps.spec.trim().length === 0) {
+        return { ok: true, reason: 'no spec to verify' };
+    }
+    let text;
+    try {
+        text = await deps.runChild(VERIFY_TOOLS, buildVerifyPrompt(deps.spec), deps.signal);
+    }
+    catch (err) {
+        if (err instanceof Error && err.message === USER_CANCELLED)
+            throw err;
+        const msg = err instanceof Error ? err.message : String(err);
+        return { ok: false, reason: `verification pass could not run: ${msg}` };
+    }
+    const verdict = parseVerifyVerdict(text);
+    if (verdict.pass)
+        return { ok: true };
+    return { ok: false, reason: `work did not verify: ${verdict.detail}` };
+}
+export { VERIFY_TOOLS };

package/dist/task/widget.d.ts

@@ -51,8 +51,9 @@ export interface AutoLoaderState {
     contextUsage?: ContextSnapshot;
     /** Which /task-auto stage this loader is for. Defaults to 'planning' (the
      *  numbered clarify/decompose steps); 'enforce' is the per-task guideline
-     *  pass, which has no step numbering. */
-    kind?: 'planning' | 'enforce';
+     *  pass and 'verify' is the per-task work-verification pass, neither of which
+     *  has step numbering. */
+    kind?: 'planning' | 'enforce' | 'verify';
 }
 export declare function buildAutoLoaderLines(s: AutoLoaderState, theme?: WidgetTheme): string[];
 /**

package/dist/task/widget.js

@@ -121,9 +121,9 @@ export function startWidget(ctx, getState) {
 export function buildAutoLoaderLines(s, theme) {
     const elapsed = formatDuration(Date.now() - s.startedAt);
     const head = `/task-auto · ${s.title}`;
-    let detail = s.kind === 'enforce' ?
-        `enforcing guidelines · ${elapsed}`
-        : `planning ${s.stepNum}/${s.stepTotal} ${s.step} · ${elapsed}`;
+    let detail = s.kind === 'enforce' ? `enforcing guidelines · ${elapsed}`
+        : s.kind === 'verify' ? `verifying work · ${elapsed}`
+            : `planning ${s.stepNum}/${s.stepTotal} ${s.step} · ${elapsed}`;
     if (s.contextUsage) {
         const ctxDetail = formatContextDetail(s.contextUsage, theme);
         if (ctxDetail)

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@mjasnikovs/pi-task",
-    "version": "0.14.12",
+    "version": "0.14.14",
     "description": "Deterministic spec-orchestration for local models, with a bundled real-time remote web view and web/docs/fetch/worker subagent tools.",
     "type": "module",
     "main": "./dist/index.js",