pi-goal-list-loop-audit 0.37.2 → 0.38.0

package/CHANGELOG.md

@@ -1,5 +1,27 @@
 # Changelog
 
+## 0.38.0 — event-driven supervision and drafting discipline (2026-09-02)
+
+### Fixed
+  Keep-checking supervision: scheduling is now event-driven for every plane (including `isMonitorGoal` daemons) — lifecycle/durable/child-progress signals via `ContinuousSupervisor` plus 250ms→15s adaptive fallback poll, not a guessed task-duration wait. The 120s `GLLA_MONITOR_INTERVAL_MS` throttle that made a 10s task wait up to 120s is deprecated (`void MONITOR_CHECK_INTERVAL_MS`) and kept only for display parity (`👁 MONITORING` badge). A 10s task is now picked up after ~10s even when guessed at 10m.
+
+  Pinned context-growth fixtures (`tests/context-growth-measurement.test.ts`, `tests/context-checkpoint.test.ts`) refreshed for the larger continuation prompt (23015 chars, 23123 bytes) so `npm run test:all` stays green.
+
+### Changed
+  Drafting-batches zero mid-execution questions: `buildSeedGrillMessage` now batches 2-4 sharp, seed-specific questions up front in one `ask_user_question` picker with recommended defaults per question. `LONG_RUNNING_JUDGMENT_POLICY` and `ACTIVE_EXECUTION_QUESTION_GUIDANCE` plus `prompts/goal-loop-continuation.md` enforce drafting as the only place to gather scope/acceptance — active execution targets zero further clarification unless irreversible/destructive, missing permission, or comparable-cost, picking the safest contract-preserving default otherwise and deferring preferences to the completion summary.
+
+  `docs/DESIGN-long-running-supervision.md` now documents both Now requirements and the display-only monitor contract.
+
+## 0.37.3 — pi 0.84 loop stall fix — agent_start fallback for continuation start proof (2026-09-02)
+
+### Fixed
+  `continuation_start_unacknowledged` stall on every `/loop` iteration under pi >=0.84 — `before_agent_start` is not emitted for `sendMessage({ deliverAs: "followUp" })` continuations, so the start proof never arrived (10/10 `loop_turn_sent` unacknowledged in issue #40). `dispatchStartAcknowledged` now accepts `agent_start`/`turn_start` as fallback while keeping `before_agent_start`+marker as primary; owner/generation/foreign fences still apply so only an unrelated manual turn in the same session could falsely settle — strictly better than 0% success. Ledger records `startProofSource` as `agent_start`/`turn_start` when fallback fires.
+
+  Hardcoded 60s retry backoff after the first 30s start-proof window is now env-configurable (`GLLA_CONTINUATION_RETRY_BACKOFF_MS`, legacy `GLLA_CONTINUATION_START_RETRY_BACKOFF_MS`) independent of `GLLA_CONTINUATION_START_TIMEOUT_MS`, so slow local models can extend both windows (observed 5m + 60s hard cap in issue #40 secondary).
+
+### Added
+  Regression pins for the fallback path and env var (`tests/loop-start-proof-fallback.test.ts`, `tests/stale-api-terminal.test.ts`, `tests/stall-handling.test.ts`).
+
 ## 0.37.2 — queued vs monitoring visuals and long-running daemon handling (2026-09-01)
 
 ### Added

package/docs/DESIGN-long-running-supervision.md

@@ -39,6 +39,27 @@ The shared checker covers all GLLA-owned work planes: ordinary goals, list
 items and their queue, metric/spec/audit loops, detached completion auditors,
 tracked subagents, provider recovery, and lifecycle/session transitions.
 
+Two Now requirements are enforced alongside the checker:
+
+- **Keep checking, not waiting.** The checker is the primary reason to inspect
+  work; a guessed task duration is never a wait. A 10 s task is picked up
+  within the 250 ms → 15 s adaptive fallback, not after a 10 m estimate.
+  `isMonitorGoal` (daemon / old-goal name or age > 1 h) remains shared for
+  display parity (the dim 👁 MONITORING badge), but scheduling is event-driven
+  for every plane — the legacy 120 s monitor throttle (`GLLA_MONITOR_INTERVAL_MS`)
+  is retired and kept only as deprecated env-var compatibility (the checker
+  already backs off to 15 s when idle).
+- **Zero mid-execution questions — compensate up front.** Drafting batches 2–4
+  sharp scope/acceptance questions with recommended defaults via a single
+  `ask_user_question` invocation, so active execution needs no further
+  clarification. During `active` execution the target is zero questions unless
+  proceeding would cross an irreversible/destructive external boundary, require
+  a missing permission/credential, or face two genuinely comparable options
+  with materially different outcomes. `LONG_RUNNING_JUDGMENT_POLICY` encodes the
+  durable-fix default; `ACTIVE_EXECUTION_QUESTION_GUIDANCE` encodes the
+  drafting-only discipline; `buildSeedGrillMessage` enforces the floor
+  (propose is blocked until the user has replied).
+
 ## Aggressive automation
 
 Aggressive mode is the default effective keep-going policy unless the user

package/docs/INDEX.md

@@ -18,7 +18,7 @@ For shipped docs, the relevant entry points are:
   failback; v0.35.9 hardened cross-version npm tarball checks; v0.35.10
   handles multi-entry npm dry-run reports; v0.35.11 accepts both npm report
   shapes; v0.35.12 supports npm 12's keyed pack reports; v0.35.13 fixes stale-API recovery loops.
-  v0.35.14–v0.37.2 continue through the supervisor freeze (`/glla pause`),
+  v0.35.14–v0.38.0 continue through the supervisor freeze (`/glla pause`),
   load hold, auditor picker parity, Windows launch fix, zombie-watchdog
   subagent carve-out, due-wait backstop, the `/glla agents` visibility panel,
   durable state-root selection, blank-until-resume auditor context, frozen

package/extensions/goal-continuation.ts

@@ -65,11 +65,18 @@ import {
 import { BACKOFF_IDLE_RETRY_MS, HEARTBEAT_MAX_NUDGES } from "./goal-loop-backoff.js";
 import { LENGTH_CONTINUE_MAX, LENGTH_CONTINUE_TEXT } from "./length-continue.js";
 
+// v0.38.0: GLLA_MONITOR_INTERVAL_MS throttling is deprecated — scheduling is
+// event-driven (250ms→15s adaptive fallback) for every plane, including
+// monitoring goals (see scheduleContinuation comment). Kept for env-var
+// compatibility; display parity still uses isMonitorGoal, but the checker no
+// longer waits a fixed 120s. The constants remain so an explicit env var does
+// not silently disappear from process state during a rolling upgrade.
 const DEFAULT_MONITOR_CHECK_INTERVAL_MS = 120_000;
 const configuredMonitorIntervalMs = Number(process.env.GLLA_MONITOR_INTERVAL_MS);
 const MONITOR_CHECK_INTERVAL_MS = Number.isFinite(configuredMonitorIntervalMs) && configuredMonitorIntervalMs > 0
   ? Math.max(1_000, configuredMonitorIntervalMs)
   : DEFAULT_MONITOR_CHECK_INTERVAL_MS;
+void MONITOR_CHECK_INTERVAL_MS; // deprecated throttle — scheduling is now event-driven
 import { VISION_ASSIST_GUIDANCE } from "./vision-assist.js";
 import { loadSettings } from "./goal-settings.js";
 import { clearLoopTimer, isLoopActive } from "./goal-loop.js";
@@ -204,7 +211,11 @@ export function createGoalContinuation(flagsArg: ContinuationFlags, d: Continuat
 // self-heal; only the second window failure declares unacknowledged (the
 // explicit /list|/goal|/loop resume fallback for genuine provider stalls).
 const CONTINUATION_START_TIMEOUT_MS = Number(process.env.GLLA_CONTINUATION_START_TIMEOUT_MS ?? 30_000);
-const NO_TURN_START_RETRY_BACKOFF_MS = 60_000;
+const NO_TURN_START_RETRY_BACKOFF_MS = Number(
+  process.env.GLLA_CONTINUATION_RETRY_BACKOFF_MS ??
+  process.env.GLLA_CONTINUATION_START_RETRY_BACKOFF_MS ??
+  60_000,
+);
 let continuationStartTimeoutOverrideMs: number | null = null;
 let continuationRetryBackoffOverrideMs: number | null = null;
 function continuationStartTimeoutMs(): number {
@@ -568,21 +579,43 @@ export function dispatchStartAcknowledged(ctx: ExtensionContext, source: string,
   }
   // A dispatch has one accepted window and one start proof. Once a start was
   // recorded, later low-level events must not re-settle it; before that,
-  // events without the exact before_agent_start marker are unrelated manual
-  // activity and cannot clear the watchdog.
+  // only a marker-carrying before_agent_start or the pi>=0.84 fallback
+  // (agent_start/turn_start without a prompt) may clear the watchdog.
   const pending = pendingContinuationDispatch;
   if (!pending || pending.phase !== "accepted") return false;
-  if (source !== "before_agent_start" && !pending.startProofSource) return false;
+  // v0.37.3 (issue #40): pi >=0.84 does not emit before_agent_start for
+  // followUp continuations (sendMessage { deliverAs: "followUp" }) — the
+  // only delivery path for continuations. Gate on the strongest proof when
+  // available, but accept agent_start/turn_start as fallback so the
+  // continuation is not stuck at 0% success. Owner/generation/foreign
+  // checks below still fence the fallback to the same session/generation.
+  if (
+    source !== "before_agent_start" &&
+    source !== "agent_start" &&
+    source !== "turn_start" &&
+    !pending.startProofSource
+  )
+    return false;
   const record = pendingContinuationDispatch;
   if (!record || flags.sessionHandoffPending || flags.extensionApiStale || flags.staleTerminalDone || flags.zombieStoodDown) return false;
   if (record.generation !== flags.sessionGeneration || isForeignCtx(ctx)) return false;
   if (!dispatchMatchesOwner(record, flags.sessionGeneration, sessionManagerId(ctx))) return false;
   if ((record.kind === "goal" || record.kind === "stall") && (!state.goal || state.goal.id !== record.goalId || state.goal.status !== "active")) return false;
-  // before_agent_start is the required proof: it must carry this exact
-  // dispatch marker. Older low-level events without a prompt are liveness
-  // signals only; accepting them would let an unrelated manual turn settle
-  // this dispatch and suppress its recovery watchdog.
-  if (source !== "before_agent_start" || !dispatchPromptMatches(record, prompt)) return false;
+  // before_agent_start must carry this exact dispatch marker. The fallback
+  // (agent_start/turn_start) carries no prompt in pi >=0.84 for followUp
+  // turns — owner/generation/foreign above already fence it to the same
+  // session, so an unrelated manual turn in the same session is the only
+  // remaining false-positive, strictly better than never acknowledging.
+  if (source === "before_agent_start") {
+    if (!dispatchPromptMatches(record, prompt)) return false;
+  } else if (source === "agent_start" || source === "turn_start") {
+    // fallback — no prompt to match
+  } else {
+    // message_update / agent_end / other liveness signals cannot settle
+    // without an existing proof, and pending.phase !== "accepted" already
+    // blocks re-settlement after the first proof.
+    return false;
+  }
   const settledAt = Date.now();
   const started: ContinuationDispatch = {
     ...transitionDispatch(record, "started"),
@@ -998,10 +1031,16 @@ export function scheduleContinuation(ctx: ExtensionContext, force = false, delay
   } catch {
     return;
   }
-  // v0.37.x: monitor goals (daemon, long-running >1h) check less frequently to avoid constant QUEUED churn.
-  if (delayMs === undefined && state.goal && isMonitorGoal(state.goal)) {
-    delay = Math.max(delay, MONITOR_CHECK_INTERVAL_MS);
-  }
+  // v0.38.0 (note.md Now — "keep checking instead of waiting"): monitoring
+  // goals remain visually distinct (👁 MONITORING badge via isMonitorGoal, shared
+  // with the TUI), but scheduling is event-driven for every plane — the 120s
+  // throttle used to delay implicit continuations for daemon/old goals and
+  // made a 10s task wait up to 120s. The durable-state / lifecycle event +
+  // 250ms→15s adaptive fallback in ContinuousSupervisor is the primary checker;
+  // implicit continuation delay is 0 when idle, 50ms otherwise, never a guessed
+  // task-duration wait. isMonitorGoal stays pure for display parity, not for
+  // throttling the checker — a monitoring goal that actually finishes or
+  // progresses is picked up within the fallback window, not after a fixed age.
   // v0.34.104 ([Image-#1]): the post-list-completion settle window delays
   // the first continuation after a queue auto-advance. Any real agent
   // activity during the window clears `postCompletionSettleUntil`, so a

package/extensions/goal-loop-core.ts

@@ -783,7 +783,7 @@ export function goalArgsNeedDrafting(args: string): boolean {
  * via draftProposalBlock: propose is blocked until the user has replied.
  */
 export function buildSeedGrillMessage(tmpl: string, seed: string, tool: string): string {
-  return `${tmpl}\n\n${LONG_RUNNING_JUDGMENT_POLICY}\n\nThe user's initial objective (verbatim): ${seed}\n\nGRILL THEM ABOUT THIS SEED BEFORE PROPOSING. ${tool} is BLOCKED until the user has replied to at least one of your questions — proposing without interviewing returns an error.\n\nHow to grill:\n- Ask ONE sharp, seed-specific question at a time — about THIS objective, not generic filler. If an ask_user_question tool is available in this session, prefer it (structured options render better); plain conversation is fine for free-form answers.\n- Every question ships with a recommended default the user can accept with "yes".\n- Probe what matters: what "done" concretely looks like (checkable evidence — files, commands, behaviors), scope boundaries (what is explicitly OUT), constraints (what must not change), and priorities when the seed bundles several wishes.\n- A non-answer ("not sure", "none", "whatever") is a trigger to offer 2-3 concrete options to pick from — never silently proceed on a non-answer.\n- Do targeted read-only research first when it makes your questions sharper (repo layout, existing docs).\n- Do NOT activate the raw seed. Do NOT implement anything. When the contract is concrete, call ${tool}.`;
+  return `${tmpl}\n\n${LONG_RUNNING_JUDGMENT_POLICY}\n\nThe user's initial objective (verbatim): ${seed}\n\nGRILL THEM ABOUT THIS SEED BEFORE PROPOSING. ${tool} is BLOCKED until the user has replied to at least one of your questions — proposing without interviewing returns an error.\n\nHow to grill:\n- Ask 2-4 sharp, seed-specific questions UP FRONT in ONE batched ask_user_question call when multiple unknowns exist — about THIS objective, not generic filler. Each question ships with a recommended default the user can accept with "yes" (one picker, 2-4 concrete options per question). If only one unknown remains, one focused question is fine. Prefer the structured ask_user_question picker; plain conversation is fine for free-form answers.\n- Probe what matters in that single upfront batch: what "done" concretely looks like (checkable evidence — files, commands, behaviors), scope boundaries (what is explicitly OUT), constraints (what must not change), and priorities when the seed bundles several wishes. One well-batched interview up front eliminates mid-execution interruptions — do not dribble questions out one by one during execution.\n- A non-answer ("not sure", "none", "whatever") is a trigger to offer 2-3 concrete options to pick from — never silently proceed on a non-answer.\n- Do targeted read-only research first when it makes your questions sharper (repo layout, existing docs).\n- Do NOT activate the raw seed. Do NOT implement anything. When the contract is concrete, call ${tool}.`;
 }
 
 /**
@@ -2775,7 +2775,7 @@ ${formatDurableDeferPolicyLine()}
 - Use an opportunistic workaround only when the durable fix is genuinely unsafe, impossible, or blocked right now; the workaround must be reversible and testable, and its durable follow-up is recorded (ledger or comment) instead of silently treated as final.
 - Premium engineering standards are mandatory: code must be cleanly typed, tested, architecturally sound, and resilient across lifecycle boundaries. Never lower test standards, fake assertions, or bypass types.
 - Autonomous pivot strategy: if an implementation approach fails verification after 2 attempts, do not loop on the same failing line. Autonomously step back, diagnose the root invariant, and pivot to a clean alternative architecture.
-- Non-interruption & sensible defaults: never pause a multi-hour run for obvious choices, cosmetic naming, or non-blocking secondary questions. Pick the sensible architectural default, implement it, record the rationale, and continue. Defer non-blocking notes to the final completion summary.
+- Non-interruption & sensible defaults: never pause a multi-hour run for obvious choices, cosmetic naming, or non-blocking secondary questions. Pick the sensible architectural default, implement it, record the rationale, and continue. Defer non-blocking notes to the final completion summary. Compensate for zero mid-run questions by asking MORE up front: during drafting, batch 2-4 critical scope/acceptance questions with recommended defaults via a single ask_user_question invocation, so active execution needs no further clarification.
 - Decide autonomously through local implementation choices without interrupting the user. Ask one focused question ONLY at a genuine trade-off where the user's preference materially changes the outcome: an irreversible/destructive external action, a missing permission/credential, or two options with comparable real cost.
 - In unattended mode, choose the safest contract-preserving path and continue. If no safe choice exists, raise a concrete DECIDE question with a recommended default; never ask a vague progress question or wait on a guessed provider/quota reset.`;
 
@@ -2785,12 +2785,11 @@ ${formatDurableDeferPolicyLine()}
  * reversible local choices or turn them into user-facing pauses.
  */
 export const ACTIVE_EXECUTION_QUESTION_GUIDANCE = `ACTIVE-EXECUTION QUESTION DISCIPLINE:
-- Drafting is the default place to gather scope, acceptance criteria, constraints, and trade-offs. Once active, treat the confirmed objective and verification contract as sufficient context.
-- During active execution, do not ask about reversible implementation choices, naming, formatting, test shape, or whether to continue. Choose the maintainable contract-preserving option, record the rationale, and proceed.
+- Drafting is the ONLY place to gather scope, acceptance criteria, constraints, and trade-offs — batch 2-4 sharp questions up front with recommended defaults via one ask_user_question call. Once active, treat the confirmed objective and verification contract as sufficient context and do NOT reopen reversible local choices.
+- During active execution, do NOT ask about reversible implementation choices, naming, formatting, test shape, or whether to continue. Choose the maintainable contract-preserving option, record the rationale, and proceed. The target is zero mid-execution questions unless proceeding would cross an irreversible/destructive external boundary, require a missing permission/credential, or face two genuinely comparable options with materially different results.
 - Defer non-blocking preferences and alternatives to the completion summary (or a durable note); do not turn them into a pause or question.
-- Ask one focused user question only when proceeding would cross an irreversible or destructive external boundary, requires a missing permission or credential, or two genuinely comparable options would materially change the result or acceptance.
-- For a necessary question, state the exact impact, include a recommended default, and pause only the dependent action; continue independent work when possible.
-- Never ask a vague progress or "what next?" question, and never wait on a guessed provider or quota reset; use bounded recovery or choose the safe default.`;
+- For the rare necessary mid-run question, state the exact impact, include a recommended default, and pause only the dependent action; continue independent work when possible.
+- Never ask a vague progress or "what next?" question, and never wait on a guessed provider or quota reset; use bounded recovery or choose the safe default. If drafting left an ambiguity, pick the safest contract-preserving default and record it rather than interrupting a multi-hour run.`;
 
 /**
  * v0.23.5: normalize a drafter-supplied verification contract for the

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-goal-list-loop-audit",
-  "version": "0.37.2",
+  "version": "0.38.0",
   "description": "Mission control for autonomous pi: interview-drafted goals, an audited task queue, and forever-loops (metric, spec, project-audit) that run for hours. A detached extension-less auditor process re-verifies every completion with raw evidence without holding the main pi turn; confirmed drafts, decision pauses and consent gates keep you in charge.",
   "license": "AGPL-3.0-only",
   "author": "dracon",

package/prompts/goal-loop-continuation.md

@@ -73,7 +73,7 @@ When the agent calls any of these, the orchestrator tracks the call and persists
   - **Auditor rehearsal**: When the verification contract has checks a subagent can re-run, spawn ONE fresh-context `reviewer` agent to rehearse the contract before calling `complete_goal`.
 - **Eager continuation.** When in doubt, KEEP GOING on sub-tasks. If a subagent fails, retry with a different approach. Don't ask permission to continue — just continue. Pause only when you are genuinely blocked on information that does not exist in the repo, or the user explicitly pauses you.
 - **Premium engineering & autonomous pivot strategy.** Always implement root-cause architectural fixes rather than superficial band-aids or test hacks. If an implementation approach fails tests after 2 attempts, do NOT loop on the same failing line: autonomously step back, diagnose the root invariant, and pivot to an alternative clean architecture.
-- **Non-interruption & sensible defaults law.** Upfront drafting is where you interview the user; once the goal is active, you are in UNATTENDED autonomous mode. Never pause a multi-hour goal for obvious decisions, naming preferences, or non-blocking secondary questions. Choose the sensible architectural default, implement it, record the rationale, and continue. Defer non-blocking notes to the final completion summary.
+- **Non-interruption & sensible defaults law.** Batch 2–4 sharp questions UP FRONT in drafting (one `ask_user_question` picker with recommended defaults per question — scope, done-criteria, constraints, priorities) so active execution needs zero further clarification. Once the goal is ACTIVE, you are in UNATTENDED autonomous mode: never pause a multi-hour goal for obvious decisions, naming preferences, or non-blocking secondary questions. Compensate for zero mid-run questions by asking more upfront. Choose the sensible architectural default, implement it, record the rationale, and continue. Defer non-blocking notes to the final completion summary.
 - **Bound every long command.** Wrap test suites, builds, and dev servers in `timeout <seconds>` (e.g. `timeout 120 bun test src/lib`). An unbounded command that hangs burns an hour; a bounded one burns two minutes and tells you it hung. If a command produces no output for many minutes, treat it as hung: kill it, diagnose why, rerun bounded.
 - **Chunk output near context-full & microcompaction.** When the conversation is heavy (long-running audit, deep debug, big rollout), prefer smaller commits, smaller tool outputs, and focused reasoning — one or two punchy paragraphs, one well-scoped tool call at a time. Don't try to fit a thousand lines of work into one reply. Spool massive stdout/diffs to disk logs if needed. glla's auto-continue fires on `stop_reason="length"` and will reschedule you; chunking is cheaper than recovering from the cap. Save large file writes for their own turns.