@mjasnikovs/pi-task 0.17.0 → 0.17.2

package/dist/task/task-gates.js

@@ -0,0 +1,135 @@
+import { resolutionOptions, classifyResolutionAnswer } from './verify-resolution.js';
+import { SessionUI } from '../remote/bridge.js';
+/**
+ * Show the boxed two-choice picker after a verify FAIL and return what the user
+ * decided. The model-recommended card is placed first so the renderer tints it
+ * green; the user ALWAYS makes the final call (there is no auto-pick). Mirrors the
+ * clarify/grill dialog: the same SessionUI.ask races the local boxed picker against
+ * a remote answer, with the two actions also surfaced as remote buttons.
+ */
+export async function askVerifyResolution(ctx, title, failReason, rec) {
+    const options = resolutionOptions(rec.recommend);
+    const question = `Verification FAILED for "${title}".\n\n${failReason}\n\n`
+        + `Recommended: ${rec.recommend.toUpperCase()} — ${rec.rationale}`;
+    const answer = await new SessionUI(ctx).ask({
+        localTitle: 'Verification failed — how should pi proceed?',
+        displayQuestion: question,
+        question,
+        recommended: options[0].label,
+        recommended2: options[1].label,
+        allowSkip: false,
+        options
+    });
+    return classifyResolutionAnswer(answer);
+}
+/**
+ * Run the verify + enforce gates against a task's just-finished implementation.
+ *
+ * Lifted verbatim from /task-auto's per-task loop so the two commands gate
+ * identically. Returns a GateResult; `done` means the caller should proceed (the
+ * work is verified-or-accepted, checked off, committed, and enforced), every other
+ * kind is a terminal stop the caller announces. Never throws for a gate outcome —
+ * only a user cancel inside a gate child propagates (handled by the caller's
+ * USER_CANCELLED path).
+ */
+export async function runGatesForTask(ctxIn, deps, p) {
+    let active = ctxIn;
+    // GATE: actually RUN the task's verification against the just-finished work
+    // BEFORE it is checked off or committed. Whether this produced a GENUINE clean
+    // pass (a real signal ran and the work met it) also decides how the enforce pass
+    // below may behave: only a genuine pass gives a signal to revert against, so only
+    // then may enforce edit in place. A no-op pass (no spec), a disabled gate, or an
+    // accept-override leaves this false → enforce runs flag-only.
+    let verifyCleanPass = false;
+    if (deps.verify) {
+        active.ui.notify(`${p.tag}: verifying "${p.title}"…`, 'info');
+        let verified = await deps.verify(active, p.cwd, p.title, p.taskId);
+        // A FAIL no longer dead-stops: offer the boxed AUTOFIX / ACCEPT / dismiss
+        // picker. The USER always decides; AUTOFIX loops straight back to the gate
+        // as many times as they keep choosing it (no attempt cap).
+        while (!verified.ok) {
+            const failReason = verified.reason ?? 'did not verify';
+            const rec = deps.recommend ?
+                await deps.recommend(active, p.cwd, p.title, p.taskId, failReason)
+                : { recommend: 'autofix', rationale: failReason };
+            const choice = await askVerifyResolution(active, p.title, failReason, rec);
+            if (choice.action === 'cancel') {
+                return { kind: 'paused', ctx: active, reason: failReason };
+            }
+            if (choice.action === 'accept') {
+                active.ui.notify(`${p.tag}: accepted "${p.title}" despite verify FAIL (${failReason.slice(0, 120)}) — proceeding.`, 'warning');
+                break;
+            }
+            // AUTOFIX: re-run the implementation turn with the failure (and any typed
+            // guidance) prepended as a RE-ATTEMPT banner, then re-verify.
+            active.ui.notify(`${p.tag}: autofixing "${p.title}"…`, 'info');
+            const fixInstruction = choice.guidance ? `${failReason}\n\nUser guidance: ${choice.guidance}` : failReason;
+            const fixRes = await deps.runTask(active, p.cwd, p.title, {
+                resumeId: p.taskId,
+                planContext: p.planContext,
+                fixInstruction
+            });
+            active = fixRes.ctx ?? active;
+            if (fixRes.sessionCancelled)
+                return { kind: 'session-cancelled', ctx: active };
+            if (fixRes.interrupted)
+                return { kind: 'interrupted', ctx: active };
+            if (!fixRes.ok)
+                return { kind: 'failed', ctx: active, reason: fixRes.reason };
+            // Resume reuses the same inner task id, so p.taskId is stable.
+            verified = await deps.verify(active, p.cwd, p.title, p.taskId);
+        }
+        // Loop exited because the work verified OR the user accepted the artifact. A
+        // genuine clean pass is ok===true with NO reason; a no-op pass or an
+        // accept-override (verified.ok still false at break) is NOT a guardable signal.
+        verifyCleanPass = verified.ok && !verified.reason;
+    }
+    // Mark the work verified (parent task-list check-off for /task-auto; no-op for
+    // /task) BEFORE committing, so the commit captures the check-off too.
+    await p.onVerified?.();
+    // Commit the task's work as one snapshot FIRST — before guideline enforcement —
+    // so a passing task is durably recorded no matter what enforcement later finds.
+    const commit = await deps.commit(p.cwd, `task: ${p.title} (${p.taskId})`);
+    if (commit.committed) {
+        active.ui.notify(`${p.tag}: committed "${p.title}".`, 'info');
+    }
+    else {
+        active.ui.notify(`${p.tag}: not committed (${commit.reason ?? 'unknown'}) — continuing.`, 'warning');
+    }
+    // With the task committed, hold its work to AGENTS.md / CLAUDE.md — but as a step
+    // INSIDE the validation gate, gated by the verify signal (see GateDeps.enforce).
+    // Skipped when nothing was committed this round, when enforce is off, or in tests
+    // with no enforce dep.
+    if (deps.enforce && commit.committed) {
+        const mode = verifyCleanPass ? 'edit' : 'flag';
+        active.ui.notify(mode === 'edit' ?
+            `${p.tag}: enforcing AGENTS.md/CLAUDE.md on "${p.title}"…`
+            : `${p.tag}: reviewing "${p.title}" against AGENTS.md/CLAUDE.md (no verify signal — report only)…`, 'info');
+        const verdict = await deps.enforce(active, p.cwd, p.title, mode);
+        if (!verdict.ok) {
+            active.ui.notify(`${p.tag}: guideline ${mode === 'edit' ? 'enforcement' : 'review'} on "${p.title}" — ${verdict.reason ?? 'not clean'} — continuing.`, 'warning');
+        }
+        if (mode === 'edit') {
+            // Commit whatever the pass fixed as its own snapshot. A no-op when it made
+            // no edits (nothing to commit) — then there is nothing to re-verify/revert.
+            const enforceCommit = await deps.commit(p.cwd, `ENFORCE GUIDELINES: ${p.title} (${p.taskId})`);
+            if (enforceCommit.committed) {
+                // Differential guard: re-run the verify signal against the enforced
+                // tree. A regression ⇒ drop the enforce commit, keep the verified work.
+                const after = deps.verify ?
+                    await deps.verify(active, p.cwd, p.title, p.taskId)
+                    : { ok: true };
+                if (!after.ok) {
+                    if (deps.revert)
+                        await deps.revert(p.cwd);
+                    active.ui.notify(`${p.tag}: guideline fixes regressed verification on "${p.title}" (${(after.reason ?? 'now fails').slice(0, 120)}) — ${deps.revert ? 'reverted them, kept the verified work' : 'left in place (no revert available)'}.`, 'warning');
+                }
+                else {
+                    active.ui.notify(`${p.tag}: committed guideline fixes for "${p.title}".`, 'info');
+                }
+            }
+        }
+        // 'flag' mode makes no edits — nothing to commit or revert.
+    }
+    return { kind: 'done', ctx: active };
+}

package/dist/task/verify-work.js

@@ -17,17 +17,27 @@
  * 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 must verify the REAL deliverable, not a stand-in. The spec's VERIFY block is
- * authored by the same weak model that did the work, so it frequently grades a
- * SIMULATION it controls: it reconstructs the build in a scratch dir, compiles with
- * options the project does not ship, or only greps the SOURCE for a string — all of
- * which pass while the project's own build ships broken output. The prompt therefore
- * anchors the child to the project's OWN build/run command and the artifact it SHIPS,
- * treats source-text presence as insufficient (a build artifact that still contains an
- * un-processed source directive means the build never ran), and treats "I had to add a
- * dependency/flag/config the project lacks to make it pass" as the defect itself.
- * A/B-proven on the live local model: the old prompt false-passed 3/3 on a
- * broken-pipeline fixture; the anchored prompt caught it 3/3, naming the real defect.
+ * It must verify the REAL deliverable AS SHIPPED, not a run the verifier itself
+ * prepared into passing. The failure class is broader than a bad VERIFY block: the
+ * child has `bash`, so it can quietly make almost anything go green — export an env
+ * var, source a config file, run a different command, rebuild in a scratch dir,
+ * fabricate the artifact by hand — and then report PASS, masking a defect a fresh
+ * checkout or CI run would hit. (This is exactly what sank an mx5 run: the verify
+ * child `export`ed the test DB URL its own shell, watched the suite go green, and
+ * passed a project whose documented command failed unaided.) The prompt therefore
+ * anchors the child to ONE principle: run the project's own commands verbatim in the
+ * tree as found, and treat any preparation/repair/substitution it had to perform to
+ * reach green as ITSELF the defect — while still distinguishing a genuinely-absent
+ * EXTERNAL service (an environment gap, not a code fault) from the project mis-wiring
+ * how it connects. This generalises across languages and toolchains and assumes no
+ * tests, build, or particular runtime.
+ *
+ * A/B-proven on the live local model (Qwen3.6-35B), 5 runs/arm on a work-around-to-pass
+ * fixture (documented command fails unaided; greppable env file makes it pass): the old
+ * prompt false-passed 2/5; the new prompt caught it 5/5, each time naming the unwired
+ * config. Guards (3 runs/arm): a healthy project still PASSes 3/3 (no false-fail), a
+ * genuinely-broken shipped build FAILs 3/3, and a genuine external-service gap — which
+ * the OLD prompt wrongly blamed on the code 3/3 — now correctly PASSes 3/3.
  *
  * 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
@@ -106,37 +116,49 @@ export function buildVerifyPrompt(spec) {
         'THE TASK SPEC (its ACCEPTANCE criteria and VERIFY block are the contract):',
         spec.trim(),
         '',
-        'How to verify — verify the REAL deliverable, not a stand-in:',
-        "1. Run the project's OWN build/run/serve command — the one it actually ships",
-        '   (the scripts in package.json, the command the spec names). Run it exactly as',
-        '   the project defines it, then inspect the artifact it PRODUCES. Also run the',
-        "   spec's VERIFY block — but the project's real build/output is the bar.",
-        '2. NEVER substitute your own build, compile step, plugin, flag, scratch transform,',
-        '   or config to make a check pass. If the VERIFY block reconstructs the output in',
-        '   a temp/scratch dir, builds with options the project does not use, or only greps',
-        '   the SOURCE for a string, that is INSUFFICIENT — it proves the code *could* work,',
-        "   not that the shipping pipeline *does*. You must still run the project's real",
-        '   build and judge its real output.',
-        '3. If, to make any check pass, you find you must add an import, plugin, flag, or',
-        '   config the project itself does not have, STOP: that missing piece IS the defect.',
-        '   Report FAIL and name exactly what the project is missing.',
-        '4. Presence of a token/directive/string in a SOURCE file is NOT verification. Judge',
-        '   the produced/shipped artifact and the actual runtime behavior. (A build directive',
-        '   belongs in the source; if that same raw directive SURVIVES into the built output,',
-        '   the build did not run — that is a FAIL, not a PASS.)',
-        '5. Treat the ACCEPTANCE criteria as the bar. If a VERIFY command fails, or its',
-        '   output (or the real build output) contradicts an ACCEPTANCE criterion, the work',
-        '   has NOT verified.',
-        '6. If a check 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 for a missing external service.',
-        '7. If the spec legitimately has no runnable verification (a pure docs/config change',
+        'How to verify — verify the REAL, shipped deliverable exactly as an unaided fresh',
+        'checkout (or CI run) would experience it:',
+        '',
+        "1. Run the project's OWN commands — the verbatim scripts / targets / binaries it",
+        '   ships (package.json scripts, Makefile targets, the command the spec names) —',
+        '   exactly as written, in the workspace as you found it. Judge the artifact or',
+        "   output they actually PRODUCE. The project's own command and its real output are",
+        "   the bar; also run the spec's VERIFY block, but it does not override that bar.",
+        '',
+        '2. Do NOT prepare, repair, reconfigure, or stand in for the run to make a check',
+        '   pass. Concretely, to reach a green result you must NOT: set or export an',
+        '   environment variable, source an env file, add or change a flag, edit or replace',
+        '   the command, install or add a dependency / plugin / import / config the project',
+        '   lacks, create or pre-populate files or state by hand, or rebuild / compile in a',
+        '   scratch dir or with options the project does not itself use. If a check only goes',
+        '   green AFTER you intervene like that, then the very thing you had to do IS the',
+        '   defect: the project does not work as shipped. Report FAIL and name the missing or',
+        '   broken wiring exactly (e.g. "shipped command `<cmd>` fails unaided because <why>").',
+        '',
+        '3. Presence of a token / directive / string in a SOURCE file is NOT verification.',
+        '   Judge the produced artifact and the real runtime behavior. A raw build directive',
+        '   that SURVIVES into the built output means the build never ran — that is a FAIL.',
+        '',
+        '4. Treat the ACCEPTANCE criteria as the bar. If a command fails, or its real output',
+        '   contradicts an ACCEPTANCE criterion, the work has NOT verified.',
+        '',
+        '5. The ONLY thing you may assume is already provided is a genuinely EXTERNAL running',
+        '   service or network resource (a database server, an API host) that the project',
+        '   documents as a prerequisite. If a command fails purely because such an external',
+        '   service is ABSENT from this machine — and NOT because the project misconfigures',
+        '   how it connects — note that as an environment gap and judge the rest; do not fail',
+        '   the code for it. But a command that fails because of how the PROJECT ITSELF is',
+        '   wired (config it owns but does not load, a wrong default, a command that cannot',
+        '   run unaided) is a defect, not an environment gap.',
+        '',
+        '6. If the spec legitimately has no runnable verification (a pure docs / config change',
         '   with nothing to build or run), validating it cleanly is a PASS.',
-        '8. Do NOT edit anything to make a check pass. Report what you actually saw.',
+        '',
+        '7. 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              (the real build/run produced an artifact that meets the spec)',
-        '  WORK-VERIFIED: FAIL <text>      (the real build/output failed or does not meet the spec; say what failed)',
+        "  WORK-VERIFIED: PASS              (the project's own command, run unaided, met the spec)",
+        '  WORK-VERIFIED: FAIL <text>      (the shipped command failed or did not meet the spec; say what failed)',
         'Output the verdict line verbatim — it is parsed mechanically.'
     ].join('\n');
 }

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@mjasnikovs/pi-task",
-    "version": "0.17.0",
+    "version": "0.17.2",
     "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",