@mjasnikovs/pi-task 0.38.30 → 0.38.32

package/dist/workers/single-read-guard.js

@@ -21,14 +21,14 @@
  *
  *   - RepeatedCallGuard: "no identical search twice", for grep/find/ls — the
  *     shapes the read guard cannot see, such as the same grep pattern re-run
- *     against the same path. Keyed on `${toolName}\0${stableStringify(args)}`,
- *     byte-identical to the key `LoopDetector.record` builds, so argument key
- *     order never causes a miss and only an identical repeat trips. A different
- *     pattern on the same file still passes.
+ *     against the same path. Keyed with `loopKey`, the same identity
+ *     `LoopDetector.record` uses, so argument key order never causes a miss and
+ *     only an identical repeat trips. A different pattern on the same file still
+ *     passes.
  *
  * Pure logic, no I/O — the extension does path resolution and tool routing.
  */
-import { stableStringify } from '../task/loop-detector.js';
+import { loopKey } from '../task/loop-detector.js';
 /**
  * The error text the model receives in place of the re-read's contents.
  *
@@ -105,11 +105,11 @@ export class RepeatedCallGuard {
     /**
      * Record a `toolName` call with `args`. Returns a ReadBlock the second time
      * the same (toolName, stable-stringified args) pair is seen (and every time
-     * after), else null on the first. Uses the LoopDetector's stableStringify so
-     * argument key-order never causes a miss; only byte-identical calls collapse.
+     * after), else null on the first. Shares the LoopDetector's key, so argument
+     * key-order never causes a miss; only byte-identical calls collapse.
      */
     check(toolName, args) {
-        const key = `${toolName}\x00${stableStringify(args)}`;
+        const key = loopKey({ name: toolName, args });
         if (this.seen.has(key)) {
             return { block: true, reason: repeatedCallReason(toolName) };
         }

package/dist/workers/worker-profiles.d.ts

@@ -242,15 +242,15 @@ export declare const DEFAULT_LOOP_PROGRESS: {
     readonly limit: 8;
     readonly churnFactor: 2;
 };
-export type WorkerProfileId = 'research' | 'gate' | 'adhoc';
+export type WorkerProfileId = 'research' | 'gate' | 'adhoc' | 'phase';
 /**
  * The facts a profile needs that are NOT policy: user config, and which of the
  * four research workers is the docs-capable one.
  */
 export interface WorkerPolicyInputs {
-    /** gate: `config.requestTimeoutMs`. */
+    /** gate, phase: `config.requestTimeoutMs`. */
     commandTimeoutMs?: number;
-    /** gate: `config.streamInactivityMs`. */
+    /** gate, phase: `config.streamInactivityMs`. */
     streamInactivityMs?: number;
     /** research: only `worker:apis` fans out, so only it can be scaled. */
     fanoutBounded?: boolean;
@@ -289,6 +289,14 @@ export declare const WORKER_PROFILES: {
             carryForward: false;
         };
     };
+    readonly phase: {
+        readonly id: "phase";
+        readonly why: string;
+        readonly resolve: (inputs: WorkerPolicyInputs) => {
+            guards: WorkerGuards;
+            carryForward: false;
+        };
+    };
 };
 /** Resolve one profile. The only way a caller should obtain a policy. */
 export declare function workerPolicy(id: WorkerProfileId, inputs?: WorkerPolicyInputs): WorkerGuardPolicy;

package/dist/workers/worker-profiles.js

@@ -50,7 +50,10 @@
  *   `RESTART_ORDER` and `FAILURE_ORDER` are untouched. This is a third view of
  *   the same key, not a merge of the two orderings.
  */
-import { LOOP_THRESHOLD, LOOP_WINDOW, MAX_LOOP_RESTARTS } from '../task/child-runner.js';
+// From loop-detector.ts, NOT child-runner.ts: child-runner reads this table, and
+// these are evaluated at module top level below, so that import would close a
+// cycle whose only symptom is a TDZ ReferenceError on import order.
+import { LOOP_THRESHOLD, LOOP_WINDOW, MAX_LOOP_RESTARTS } from '../task/loop-detector.js';
 import { CONTEXT_CHURN_FACTOR, NO_PROGRESS_LIMIT } from '../task/stall-detector.js';
 import { fanoutTimeoutPolicy, workerCarryForward, workerProgressCeilingMs } from '../task/research-fanout-budget.js';
 /**
@@ -198,6 +201,35 @@ export const WORKER_PROFILES = {
             guards['stream-stall'] = inputs.streamInactivityMs ?? 0;
             return { guards, carryForward: false };
         }
+    },
+    phase: {
+        id: 'phase',
+        why: 'The spec-pipeline and planning children (runPhaseChild). Every call site '
+            + "but one passes `read` or `''`, and none of them EDITS, so the "
+            + 'path-revisit rule stays ON, unlike gate: re-reading one file here is '
+            + 'the thrash it was written for, not the job. '
+            + 'THE COMMAND WATCHDOG IS WHY THIS ROW EXISTS. verify-tooling holds '
+            + '`read,bash`, and a hung command there was unkillable: the stream '
+            + 'watchdog SUSPENDS for the duration of a tool call, the dead-backend '
+            + 'probe reads a reachable endpoint as alive, and both runaway detectors '
+            + 'wait on a result that never arrives. Only a user ESC could end it. '
+            + 'The wall clock stays OFF as PHASE_CHILD_TIMEOUT_MS decided for a FIXED '
+            + "cap; that does not settle research's progress-based ceiling. "
+            + 'PARTIALLY CONSUMED: runPhaseChild has its own strike loop and reads '
+            + 'only `command-timeout`, `stream-stall`, `stalled` and `loop`, so '
+            + 'setting `worker-timeout` or `connection-error` here does NOTHING.',
+        resolve: inputs => {
+            const guards = baseGuards();
+            // INERT for this profile — runPhaseChild never reads it. Zeroed anyway
+            // so the row cannot be mistaken for research's armed 240s cap.
+            guards['worker-timeout'] = { timeoutMs: 0, progressCeilingMs: null, fanout: null };
+            // Both ceilings are the user's own settings, as they are for gate: the
+            // number is theirs, the decision to arm it is this row's. 0 from a
+            // caller that hands none, so a harness cannot silently acquire a guard.
+            guards['command-timeout'] = inputs.commandTimeoutMs ?? 0;
+            guards['stream-stall'] = inputs.streamInactivityMs ?? 0;
+            return { guards, carryForward: false };
+        }
         // `as const satisfies`, not an annotation — the same reason RESTART_ORDER
         // gives: an annotation widens each row back to `WorkerProfile`, and the
         // `why` strings and literal ids stop being visible to a reader or a test.

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@mjasnikovs/pi-task",
-    "version": "0.38.30",
+    "version": "0.38.32",
     "description": "Deterministic task planning and spec-orchestration for local models — crash-safe /task pipelines with verify/enforce gates, a real-time remote web view, and web/docs/fetch/worker subagent tools.",
     "type": "module",
     "main": "./dist/index.js",

package/dist/config/reasoning-args.d.ts

@@ -1,23 +0,0 @@
-/**
- * The live-config bridge for reasoning profiles: group in, argv fragment out.
- *
- * Separate from reasoning.ts because that module must take no import with a
- * runtime side effect — see its header. The `getConfig()` read lives here
- * instead: this file imports both, and nothing in config/ imports it back, so
- * the graph stays a tree.
- *
- * Read PER CALL, never cached at module scope, so a /task-config change lands on
- * the next child without a restart. Same contract `childBaseArgs` keeps.
- */
-import { type PiTaskConfig } from './config.js';
-import { type ReasoningGroup } from './reasoning.js';
-/**
- * The `['--thinking', level]` fragment for a group, or `[]` when the group is
- * `inherit` and the child should keep falling back to settings.json.
- *
- * Every argv builder calls this rather than reading config itself. The two
- * callers that skip it are not argv builders: the host-session turn
- * (implementation-thinking.ts) and the settings UI (register.ts) both need the
- * level itself, not a flag, so they call `resolveReasoning` directly.
- */
-export declare function groupThinkingArgs(group: ReasoningGroup, cfg?: PiTaskConfig): string[];

package/dist/config/reasoning-args.js

@@ -1,28 +0,0 @@
-/**
- * The live-config bridge for reasoning profiles: group in, argv fragment out.
- *
- * Separate from reasoning.ts because that module must take no import with a
- * runtime side effect — see its header. The `getConfig()` read lives here
- * instead: this file imports both, and nothing in config/ imports it back, so
- * the graph stays a tree.
- *
- * Read PER CALL, never cached at module scope, so a /task-config change lands on
- * the next child without a restart. Same contract `childBaseArgs` keeps.
- */
-import { getConfig } from './config.js';
-import { resolveReasoning, thinkingArgs } from './reasoning.js';
-/**
- * The `['--thinking', level]` fragment for a group, or `[]` when the group is
- * `inherit` and the child should keep falling back to settings.json.
- *
- * Every argv builder calls this rather than reading config itself. The two
- * callers that skip it are not argv builders: the host-session turn
- * (implementation-thinking.ts) and the settings UI (register.ts) both need the
- * level itself, not a flag, so they call `resolveReasoning` directly.
- */
-export function groupThinkingArgs(group, cfg) {
-    // The default is evaluated HERE, per call. Hoisting the read to module scope
-    // would leave every test green, so the optional parameter is what makes the
-    // per-call contract assertable.
-    return thinkingArgs(resolveReasoning(group, cfg ?? getConfig()));
-}

package/dist/task/implementation-thinking.d.ts

@@ -1,56 +0,0 @@
-/**
- * Hold the host session at the `implementation` group's thinking level for the
- * duration of one implementation turn, then put it back.
- *
- * WHY THIS GROUP IS NOT LIKE THE OTHERS
- * -------------------------------------
- * Every other reasoning group runs in a child process, so its level is one argv
- * flag (`--thinking <level>`, built in reasoning-args.ts) and it dies with the
- * child. The implementation turn runs in the USER'S OWN session
- * (orchestrator.ts `sendSpec` -> `sendUserMessage` -> `superviseImplementation`),
- * so the only lever is `pi.setThinkingLevel`, which is session-global.
- *
- * THREE THINGS pi DOES that this has to survive:
- *
- *  1. IT PERSISTS. pi-coding-agent's agent-session `setThinkingLevel` calls
- *     `settingsManager.setDefaultThinkingLevel(...)` whenever the effective
- *     level actually changes, and that writes pi's global settings file
- *     (`~/.pi/agent/settings.json`). Without the restore, running one task would
- *     silently rewrite the user's global default. That makes `release()`
- *     load-bearing, not tidy-up.
- *  2. IT CLAMPS, to the levels the model declares. A model with no reasoning
- *     support offers only `off`, so asking for `medium` yields `off`. The
- *     restore therefore writes back what was READ after setting, never what was
- *     asked for — otherwise a clamp would ratchet the stored default a little
- *     further every run.
- *  3. IT IS OBSERVABLE, and the user can change it mid-turn: `shift+tab` is the
- *     default binding for `app.thinking.cycle`, and a change invalidates the
- *     footer. Restoring blindly would clobber a choice they just made. We detect
- *     it by comparing the live level at release against what we applied: if it
- *     has moved, somebody else moved it, and we leave it alone.
- *
- * We compare rather than subscribe because the extension API's `on(...)` returns
- * `void` — there is no unsubscribe handle — so a per-turn listener could only
- * ever be added, never removed. The comparison answers the same question with no
- * accumulating state.
- */
-import type { ThinkingLevel } from '@earendil-works/pi-agent-core';
-import { type GroupSetting } from '../config/reasoning.js';
-/**
- * The slice of the extension API this needs, named so tests can drive the
- * hold-and-restore with a fake object instead of a live pi session.
- */
-export interface ThinkingControl {
-    get(): ThinkingLevel;
-    set(level: ThinkingLevel): void;
-}
-/**
- * Put the session at the implementation group's level and return the function
- * that puts it back. Always call the returned function — `finally`, not the
- * happy path.
- *
- * `inherit` makes NO call at all, not even a redundant set-to-current. It means
- * the same thing here as in `thinkingArgs`, which emits no `--thinking` flag for
- * it: leave the level wherever it already is.
- */
-export declare function holdImplementationThinking(control: ThinkingControl, setting?: GroupSetting): () => void;

package/dist/task/implementation-thinking.js

@@ -1,32 +0,0 @@
-import { getConfig } from '../config/config.js';
-import { resolveReasoning } from '../config/reasoning.js';
-/**
- * Put the session at the implementation group's level and return the function
- * that puts it back. Always call the returned function — `finally`, not the
- * happy path.
- *
- * `inherit` makes NO call at all, not even a redundant set-to-current. It means
- * the same thing here as in `thinkingArgs`, which emits no `--thinking` flag for
- * it: leave the level wherever it already is.
- */
-export function holdImplementationThinking(control, setting = resolveReasoning('implementation', getConfig())) {
-    if (setting === 'inherit')
-        return () => { };
-    const before = control.get();
-    control.set(setting);
-    // Post-clamp, so a model that cannot do `medium` does not leave us believing
-    // it is at `medium` and treating the user's later change as our own.
-    const applied = control.get();
-    if (applied === before)
-        return () => { };
-    let released = false;
-    return () => {
-        // Idempotent by contract: only the first call restores. A later call
-        // would write `before` on top of whatever the level is by then.
-        if (released)
-            return;
-        released = true;
-        if (control.get() === applied)
-            control.set(before);
-    };
-}