one-code-extension 0.4.0 → 0.5.0

package/extensions/background/loop-fire.ts

@@ -0,0 +1,136 @@
+/**
+ * Claude Code's `/loop` sentinels (2.1.282). A loop
+ * with no prompt schedules a sentinel as its prompt; at fire time the
+ * sentinel expands to the full instructions on first delivery (and, for a
+ * loop.md tasks file, whenever the file changed) and to a short tick
+ * reminder after that, so the long text stays in the cached prefix
+ * (findings §21). The texts are Claude Code's, verbatim with our tool names;
+ * the "tell the user" addenda are dropped (no counterpart tool here).
+ *
+ * Pure apart from reading loop.md (`<cwd>/.claude/loop.md`, then `~/.claude/loop.md`;
+ * the corresponding `.onecode` directories in independent mode).
+ */
+
+import { projectConfigDir, userConfigDir } from "../lib/config-mode.ts";
+import { readFileSync } from "node:fs";
+import { homedir } from "node:os";
+import { join } from "node:path";
+
+const yl = "schedule_wakeup";
+const il = "monitor";
+const Um = "task_stop";
+const jb = "task_output";
+
+export const AUTONOMOUS_LOOP = "<<autonomous-loop>>";
+export const AUTONOMOUS_LOOP_DYNAMIC = "<<autonomous-loop-dynamic>>";
+export const LOOP_FILE_SENTINEL = "<<loop.md>>";
+export const LOOP_FILE_DYNAMIC_SENTINEL = "<<loop.md-dynamic>>";
+/** Claude Code's cap on loop.md, in characters (its text says bytes). */
+export const LOOP_FILE_CAP = 25000;
+/** Marks "the autonomous preamble went out because loop.md was absent". */
+const PREAMBLE_MARK = "__autonomous_preamble__";
+
+export interface LoopFile {
+	path: string;
+	content: string;
+}
+
+/** What went out already this session; compaction resets it (the first fire after it resends everything). */
+export interface LoopDeliveryState {
+	autonomousPreambleDelivered: boolean;
+	lastLoopFileDelivered: string | null;
+}
+
+export function freshDeliveryState(): LoopDeliveryState {
+	return { autonomousPreambleDelivered: false, lastLoopFileDelivered: null };
+}
+
+export function isAutonomousSentinel(prompt: string): boolean {
+	return prompt === AUTONOMOUS_LOOP || prompt === AUTONOMOUS_LOOP_DYNAMIC;
+}
+
+export function isLoopFileSentinel(prompt: string): boolean {
+	return prompt === LOOP_FILE_SENTINEL || prompt === LOOP_FILE_DYNAMIC_SENTINEL;
+}
+
+function cronTick(): string {return`# Autonomous loop tick
+
+Run the autonomous check using the loop instructions established earlier in this conversation. If you cannot find them, treat this as a no-op tick. The recurring cron will fire the next tick automatically \u2014 do not call ${yl} from this tick.`}
+const DYNAMIC_MONITOR_NOTE=`
+
+If a ${il} is armed (check ${jb}), keep \`delaySeconds\` at 1200\u20131800s \u2014 the ${il} is the wake signal and this is only the fallback heartbeat. If you were woken by a \`<task-notification>\`, handle the event before deciding whether to re-arm. To stop the loop, call ${yl} with \`stop: true\` and ${Um} the monitor (use ${jb} to find its task ID if no longer in context).`;
+function dynamicTick(): string {return`# Autonomous loop tick (dynamic pacing)
+
+Run the autonomous check using the loop instructions established earlier in this conversation. If you cannot find them, treat this as a no-op tick.
+
+You scheduled this tick via the ${yl} tool (not a recurring cron). To keep the loop alive, call ${yl} again at the end of this turn with \`prompt\` set to the literal sentinel \`${AUTONOMOUS_LOOP_DYNAMIC}\` and \`noop\` set to \`true\` if this tick changed nothing (or \`false\` if it did) \u2014 otherwise the loop ends after this tick.${DYNAMIC_MONITOR_NOTE}`}
+function resolveAutonomous(e: LoopDeliveryState, t: string, preamble: string): string | null {if(!isAutonomousSentinel(t))return null;let o=t===AUTONOMOUS_LOOP_DYNAMIC?dynamicTick():cronTick();if(e.autonomousPreambleDelivered||e.lastLoopFileDelivered!==null)return o;return e.autonomousPreambleDelivered=!0,`${preamble}
+
+---
+
+${o}`}
+function loopFileCronTick(): string {return`# /loop tick \u2014 loop.md tasks
+
+Work the tasks from the loop.md contents established earlier in this conversation. If you cannot find them, treat this as a no-op tick. The recurring cron will fire the next tick automatically \u2014 do not call ${yl} from this tick.`}
+function loopFileDynamicTick(): string {return`# /loop tick \u2014 loop.md tasks (dynamic pacing)
+
+Work the tasks from the loop.md contents established earlier in this conversation. If you cannot find them, treat this as a no-op tick.
+
+You scheduled this tick via the ${yl} tool (not a recurring cron). To keep the loop alive, call ${yl} again at the end of this turn with \`prompt\` set to the literal sentinel \`${LOOP_FILE_DYNAMIC_SENTINEL}\` and \`noop\` set to \`true\` if this tick changed nothing (or \`false\` if it did) \u2014 otherwise the loop ends after this tick.${DYNAMIC_MONITOR_NOTE}`}
+function loopFileAbsentDynamicTick(): string {return`# /loop tick \u2014 loop.md absent (dynamic pacing)
+
+loop.md is not currently present. Run the autonomous check using the loop instructions established earlier in this conversation.
+
+You scheduled this tick via the ${yl} tool (not a recurring cron). To keep the loop alive \u2014 and to pick up loop.md if it is recreated \u2014 call ${yl} again at the end of this turn with \`prompt\` set to the literal sentinel \`${LOOP_FILE_DYNAMIC_SENTINEL}\` and \`noop\` set to \`true\` if this tick changed nothing (or \`false\` if it did) \u2014 otherwise the loop ends after this tick.${DYNAMIC_MONITOR_NOTE}`}
+function capLoopFile(e: string): string {if(e.length<=LOOP_FILE_CAP)return e;let t=e.lastIndexOf(`
+`,LOOP_FILE_CAP);return`${e.slice(0,t>0?t:LOOP_FILE_CAP)}
+
+> WARNING: loop.md was truncated to ${LOOP_FILE_CAP} bytes. Keep the task list concise.`}
+/**
+ * One loop.md candidate, or null. Every read error counts as absent (Claude
+ * Code rethrows all but a missing file or a directory): this runs from the
+ * cron timer, where a throw would take the process down.
+ */
+function readLoopFileAt(path: string): LoopFile | null {
+	let text: string;
+	try {
+		text = readFileSync(path, "utf-8");
+	} catch {
+		return null;
+	}
+	const trimmed = text.trim();
+	if (trimmed.length === 0) return null;
+	return { path, content: capLoopFile(trimmed) };
+}
+
+/**
+ * The loop-tasks file: the project's `.claude/loop.md` (`.onecode/loop.md` in
+ * independent mode, lib/config-mode.ts), else the user config directory's
+ * `loop.md` (Claude Code 2.1.296: `~/.claude/loop.md` or `CLAUDE_CONFIG_DIR`).
+ */
+export function readLoopFile(cwd: string, home = homedir()): LoopFile | null {
+	return readLoopFileAt(join(projectConfigDir(cwd), "loop.md")) ?? readLoopFileAt(join(userConfigDir(home), "loop.md"));
+}
+
+function resolveLoopFile(e: LoopDeliveryState, t: string, o: LoopFile | null, preamble: string): string {let n=t===LOOP_FILE_DYNAMIC_SENTINEL;if(o){let s=n?loopFileDynamicTick():loopFileCronTick();if(e.lastLoopFileDelivered===o.content)return s;return e.lastLoopFileDelivered=o.content,`# /loop tick \u2014 tasks from ${o.path}
+
+The user configured a loop-tasks file. Work through the tasks defined below; these are the instructions for this tick and every subsequent tick (the reminder on later fires refers back to this message).
+
+---
+
+${o.content}
+
+---
+
+${s}`}let r=n?loopFileAbsentDynamicTick():cronTick();if(e.lastLoopFileDelivered===PREAMBLE_MARK||e.autonomousPreambleDelivered)return r;return e.lastLoopFileDelivered=PREAMBLE_MARK,e.autonomousPreambleDelivered=!0,`${preamble}
+
+---
+
+${r}`}
+/**
+ * The text a fired prompt delivers, as in Claude Code:
+ * a sentinel expands, updating `state`; any other prompt passes through.
+ */
+export function resolveLoopFire(state: LoopDeliveryState, prompt: string, cwd: string, preamble: string, home?: string): string {
+	return resolveAutonomous(state, prompt, preamble) ?? (isLoopFileSentinel(prompt) ? resolveLoopFile(state, prompt, readLoopFile(cwd, home), preamble) : prompt);
+}

package/extensions/background/loop-preamble.ts

@@ -0,0 +1,59 @@
+/**
+ * Claude Code's autonomous-loop instructions (2.1.282, verbatim): the text a
+ * bare `/loop` (or `/loop <interval>` with no prompt) runs on, when no
+ * loop.md tasks file exists. There are two; the
+ * persistent one is chosen by `CLAUDE_CODE_LOOP_PERSISTENT` (Claude Code also
+ * reads a remote flag, default off). Findings §21.
+ *
+ * Verbatim; never hand-edit the text.
+ */
+
+export const AUTONOMOUS_PREAMBLE = `# Autonomous loop check
+
+You're being invoked on a timer while the user is away or occupied. The point is to keep work moving forward without the user driving every step - finishing things they started, maintaining PRs they're building, catching problems before they come back to find them. You're a steward, not an initiator. The user set you loose on their work, and the value you provide comes from reliably advancing things they've already set in motion, not from finding new things to do.
+
+The key tension to navigate: the user trusts you enough to run autonomously, but that trust is easily lost. Acting on what the conversation already established is safe and valuable. Inventing new work or making irreversible changes without clear authorization erodes trust fast. When you're unsure whether something falls into "continuing established work" or "inventing new work," lean toward the former only when the transcript provides clear evidence the user wanted it done. If you find yourself reaching for justifications about why a push is probably fine, that's a signal to wait.
+
+## What to act on
+
+The current conversation is your highest-signal source - re-read the transcript above, since everything there is something the user was actively engaged with. The strongest signal is an in-progress PR you've been building together: review comments to address and resolve, failing CI checks to diagnose (and re-enqueue if they're flakes), merge conflicts to fix. The goal is to get the PR into a state where it's ready to merge pending only human review - the user shouldn't come back to find a PR blocked on things you could have handled. After that, look for unfinished implementation where the last exchange left something half-done, and explicit "I'll also..." or "next I'll..." commitments the conversation made and didn't honor. Weaker but still real: dangling questions you could now answer, verification steps that were skipped, edge cases that were mentioned but not handled, and natural continuations that don't require new decisions.
+
+If you find anything in this category, act on it - actually do the work, don't describe what could be done. Run the tests, don't say "you could run the tests." The whole point of autonomous operation is that work gets done while the user is away.
+
+When the conversation transcript has nothing left, the current branch's pull/merge request on the user's SCM is the next-best place to look. This is maintenance work - valuable, but lower priority than continuing the user's active work. Find the PR/MR for the current branch via the SCM's CLI, then check three things: CI status, unresolved review threads, and whether the branch has fallen behind the base. For failing CI, pull the failing job's logs and diagnose before acting - flaky-shaped failures (timeout, runner died, transient network) can be re-enqueued; real failures need a reproduction and a minimal fix. For unresolved review threads, fetch the comment, address the feedback, push, and resolve the thread via, for example, the GitHub GraphQL \`resolveReviewThread\` mutation (or the equivalent for whichever SCM the project uses). Before pushing anything, check whether someone else has pushed to the branch while you were working - if so, rebase (don't merge) to keep history clean.
+
+When CI is green, threads are clear, and there's idle time, sweeping the branch for issues is a good use of that time - bug-hunt or simplification passes catch problems before reviewers do, saving everyone a round-trip.
+
+If everything is genuinely quiet - no conversation work, no PR maintenance - say so in one sentence and stop. No summary of what you checked, no list of what you might do later. The user will see your message in the transcript when they come back; three consecutive "nothing to do" results means you should scale back to a quick CI check and stop, not narrate.
+
+## Repeated invocations
+
+If you see earlier autonomous checks in this conversation, adjust your scope accordingly. If a previous check left a question the user hasn't answered, the cost of acting depends on reversibility: for reversible actions (local edits, running tests), make your best call and proceed; for irreversible ones (pushing, deleting, sending), keep waiting - the cost of acting wrongly on something irreversible is much higher than the cost of waiting one more cycle. If three or more consecutive checks have found nothing actionable, things are quiet - do one quick CI/threads check and stop in a single line. Repeated "nothing to do" messages clutter the transcript and waste the user's attention when they come back to review.
+
+Read and analyze freely - understanding the state of things has no blast radius. Make edits and run tests when you're confident they continue established work. Commit and push only when you're clearly continuing something the user authorized, or when the work pattern makes the intent obvious - like fixing CI on a PR you've been building together.
+`;
+
+export const AUTONOMOUS_PREAMBLE_PERSISTENT = `# Autonomous loop check
+
+You're being invoked on a timer while the user is away or occupied. The point is to keep work moving forward without the user driving every step - finishing things they started, maintaining PRs they're building, catching problems before they come back to find them, and following through on the *spirit* of the task they gave you, not just its literal scope. The user set you loose on their work, and the value you provide comes from reliably advancing things they've already set in motion.
+
+The key tension to navigate: the user trusts you enough to run autonomously, but that trust is easily lost. Acting on what the conversation already established is safe and valuable. For irreversible actions (push, delete, send), require clear authorization in the transcript or use a reversible alternative (a draft, a local commit, a queued message). For reversible actions (edits, tests, drafts, exploration), bias toward acting - the cost of an unneeded local edit is near zero, and the cost of a stalled loop is high. When you're unsure whether something falls into "continuing established work" or "inventing new work," lean toward continuing whenever the transcript gives you any reasonable thread to pull on.
+
+## What to act on
+
+The current conversation is your highest-signal source - re-read the transcript above, since everything there is something the user was actively engaged with. The strongest signal is an in-progress PR you've been building together: review comments to address and resolve, failing CI checks to diagnose (and re-enqueue if they're flakes), merge conflicts to fix. The goal is to get the PR into a state where it's ready to merge pending only human review - the user shouldn't come back to find a PR blocked on things you could have handled. After that, look for unfinished implementation where the last exchange left something half-done, and explicit "I'll also..." or "next I'll..." commitments the conversation made and didn't honor. Weaker but still real: dangling questions you could now answer, verification steps that were skipped, edge cases that were mentioned but not handled, and natural continuations that don't require new decisions.
+
+If you find anything in this category, act on it - actually do the work, don't describe what could be done. Run the tests, don't say "you could run the tests." The whole point of autonomous operation is that work gets done while the user is away.
+
+When the conversation transcript has nothing left, the current branch's pull/merge request on the user's SCM is the next-best place to look. This is maintenance work - valuable, but lower priority than continuing the user's active work. Find the PR/MR for the current branch via the SCM's CLI, then check three things: CI status, unresolved review threads, and whether the branch has fallen behind the base. For failing CI, pull the failing job's logs and diagnose before acting - flaky-shaped failures (timeout, runner died, transient network) can be re-enqueued; real failures need a reproduction and a minimal fix. For unresolved review threads, fetch the comment, address the feedback, push, and resolve the thread via, for example, the GitHub GraphQL \`resolveReviewThread\` mutation (or the equivalent for whichever SCM the project uses). Before pushing anything, check whether someone else has pushed to the branch while you were working - if so, rebase (don't merge) to keep history clean.
+
+When CI is green, threads are clear, and there's idle time, sweeping the branch for issues is a good use of that time - bug-hunt or simplification passes catch problems before reviewers do, saving everyone a round-trip.
+
+If everything is genuinely quiet - no conversation work, no PR maintenance - say so in one sentence and keep the loop alive. Before stopping, broaden once: re-read the original task framing, check whether earlier ticks deferred anything ("I'll wait for X"), and look at sibling PRs/branches the user owns. Persistence is the point of autonomous mode. Only stop if the original task is provably complete or the user said to stop. (Pacing - how long to wait before the next tick - is handled by the per-mode reminder appended to this preamble; don't try to manage delay from here.)
+
+## Repeated invocations
+
+If you see earlier autonomous checks in this conversation, adjust your scope accordingly. If a previous check left a question the user hasn't answered, the cost of acting depends on reversibility: for reversible actions (local edits, running tests), make your best call and proceed; for irreversible ones (pushing, deleting, sending), keep waiting - the cost of acting wrongly on something irreversible is much higher than the cost of waiting one more cycle. If three or more consecutive checks have found nothing actionable, broaden scope once before considering stopping - re-read the original task, check sibling work, look for verification or polish steps that were skipped. A loop that quits the moment work goes quiet is less useful than one that waits.
+
+Read and analyze freely - understanding the state of things has no blast radius. Make edits and run tests when you're confident they continue established work. Commit and push only when you're clearly continuing something the user authorized, or when the work pattern makes the intent obvious - like fixing CI on a PR you've been building together.
+`;

package/extensions/background/loop-skill.ts

@@ -0,0 +1,163 @@
+/**
+ * Claude Code's `/loop` bundled skill (2.1.288): the
+ * prompt each form of `/loop` sends the model. The model then schedules the
+ * loop itself (cron_create, or schedule_wakeup for self-pacing) and runs the
+ * first iteration, as in Claude Code (findings §21).
+ *
+ * The templates are Claude Code's, verbatim; only the tool names are ours. Dropped branches: the cloud-schedule offer, the
+ * "tell the user" addenda and the confirm-before-arming order (Claude Code
+ * gates them on claude.ai features and a per-model flag One Code has no
+ * counterpart for), and `TaskList`, which becomes task_output
+ * (our task_list is the to-do list and shows no monitor; decisions/tools.md,
+ * "Session cron").
+ *
+ * Pure: no pi imports.
+ */
+
+import { AUTONOMOUS_PREAMBLE, AUTONOMOUS_PREAMBLE_PERSISTENT } from "./loop-preamble.ts";
+import { LOOP_FILE_DYNAMIC_SENTINEL, LOOP_FILE_SENTINEL, AUTONOMOUS_LOOP, AUTONOMOUS_LOOP_DYNAMIC, type LoopFile } from "./loop-fire.ts";
+import { RECURRING_MAX_AGE_DAYS as Ofe } from "./cron.ts";
+import { envFlag } from "./wakeup.ts";
+
+const yl = "schedule_wakeup";
+const ky = "cron_create";
+const vA = "cron_delete";
+const il = "monitor";
+const Um = "task_stop";
+const jb = "task_output";
+const PVe = AUTONOMOUS_LOOP;
+const gve = AUTONOMOUS_LOOP_DYNAMIC;
+/** Claude Code's monitor-TTL branch is off here: our monitor has `persistent`. */
+const b8 = (): boolean => false;
+const gDe = (): number => 0;
+const Ktn = (ms: number): string => `${ms}ms`;
+/** The interval a bare `/loop` uses. */
+const N = "10m";
+/** The self-paced forms confirm after arming the wakeup, as visible text, and say how a stopped loop ended. */
+const VISIBLE_UPDATE = "This must be ordinary visible response text \u2014 the user cannot see your thinking/reasoning, so an update written only there is invisible to them. Make it the last thing in the turn, then end the turn.";
+const STOP_OUTCOME = "Then write the loop's outcome for the user as ordinary visible response text \u2014 a stopped loop has no next tick to surface it.";
+
+export const LOOP_SKILL = {
+	name: "loop",
+	description: "Run a prompt or slash command on a recurring interval (e.g. /loop 5m /foo). Omit the interval to let the model self-pace.",
+	whenToUse: 'When the user wants to set up a recurring task, poll for status, or run something repeatedly on an interval (e.g. "check the deploy every 5 minutes", "keep running /babysit-prs"). Do NOT invoke for one-off tasks.',
+	argumentHint: "[interval] [prompt]",
+} as const;
+
+/** The autonomous-loop instructions: the persistent variant with `CLAUDE_CODE_LOOP_PERSISTENT` on. */
+export function autonomousPreamble(env: NodeJS.ProcessEnv = process.env): string {
+	return envFlag(env.CLAUDE_CODE_LOOP_PERSISTENT, false) ? AUTONOMOUS_PREAMBLE_PERSISTENT : AUTONOMOUS_PREAMBLE;
+}
+
+const INTERVAL_ONLY=/^\d+[smhd]$/;
+const EVERY_ONLY=/^every\s+(\d+)\s*(s|sec|secs|second|seconds|m|min|mins|minute|minutes|h|hr|hrs|hour|hours|d|day|days)\s*$/i;
+function normalizeEvery(e: RegExpMatchArray): string {let o=e[1],t=e[2].toLowerCase();if(t.startsWith("s"))return`${o}s`;if(t.startsWith("h"))return`${o}h`;if(t.startsWith("d"))return`${o}d`;return`${o}m`}
+const I="| Interval pattern      | Cron expression     | Notes                                    |\n|-----------------------|---------------------|------------------------------------------|\n| `Nm` where N \u2264 59   | `*/N * * * *`     | every N minutes                          |\n| `Nm` where N \u2265 60   | `0 */H * * *`     | round to hours (H = N/60, must divide 24)|\n| `Nh` where N \u2264 23   | `0 */N * * *`     | every N hours                            |\n| `Nd`                | `0 0 */N * *`     | every N days at midnight local           |\n| `Ns`                | treat as `ceil(N/60)m` | cron minimum granularity is 1 minute  |\n\n**If the interval doesn't cleanly divide its unit** (e.g. `7m` \u2192 `*/7 * * * *` gives uneven gaps at :56\u2192:00; `90m` \u2192 1.5h which cron can't express), pick the nearest clean interval and tell the user what you rounded to before scheduling.";
+
+function armMonitor(): string {return b8()?`arm one now with \`timeout_ms: ${gDe()}\``:"arm one now with `persistent: true`"}
+function rearmReminder(e: "iterations" | "ticks"): string {if(b8())return`A monitor expires after at most ${Ktn(gDe())} and tells you; on later ${e} call ${jb} first and re-arm only if no monitor for it is still running.`;return e==="iterations"?`Arm once; on later iterations call ${jb} first and skip this step if a monitor is already running.`:`Arm once; on later ticks call ${jb} first and skip if a monitor is already running.`}
+function explicitPrompt(e: string): string {let o=`The user wants you to self-pace. Decide what makes the next iteration worth running \u2014 a passage of time, or an observable event.
+
+1. **Run the parsed prompt now.** If it's a slash command, invoke it via the skill tool; otherwise act on it directly.
+2. **If the next run is gated on an event** (CI finishing, a log line matching, a file changing, a PR comment) and no ${il} is already running for it: ${armMonitor()}. Its events arrive as \`<task-notification>\` messages and wake this loop immediately \u2014 you do not wait for the ${yl} deadline. ${rearmReminder("iterations")}
+3. **Decide whether the loop continues.** If the task needs another iteration, call ${yl} with:
+   - \`delaySeconds\`: with a ${il} armed this is the **fallback heartbeat** \u2014 how long to wait if no event fires (lean 1200\u20131800s; idle ticks more frequent than the task needs are pure overhead). Without a ${il} this is the cadence \u2014 pick based on what you observed. Read the tool's own description for cache-aware delay guidance.
+   - \`reason\`: one short sentence on why you picked that delay.
+   - \`prompt\`: the full original /loop input verbatim, prefixed with \`/loop \` so the next firing re-enters this skill and continues the loop. For example, if the user typed \`/loop check the deploy\`, pass \`/loop check the deploy\` as the prompt.
+   - \`noop\`: \`true\` if this tick changed nothing ("still waiting", "quiet hold"); \`false\` if it did something worth keeping. Consecutive \`noop: true\` ticks collapse in the terminal.
+   If it doesn't need another iteration, stop instead (step 6) \u2014 re-arming is a per-turn choice, not a default.
+4. **After the wakeup is armed, briefly confirm**: that you're self-pacing, whether a ${il} is the primary wake signal, that you ran the task now, and what fallback delay you picked. ${VISIBLE_UPDATE}
+5. **If you were woken by a \`<task-notification>\`** rather than this prompt: handle the event in the context of the loop task, then make the same decision. If the loop should continue, call ${yl} again with the same \`prompt\` and the same 1200\u20131800s \`delaySeconds\` from the schedule step above (the ${il} remains the wake signal; the new wakeup is only the fallback heartbeat), then write the same brief update as visible text. If the event means the work is finished, stop (step 6).
+6. **To stop the loop** \u2014 the task is complete, further iterations can't make progress, or the user asked you to stop \u2014 call ${yl} with \`stop: true\` (no other fields) and ${Um} any ${il} you armed (use ${jb} to find the task ID if it is no longer in context). ${STOP_OUTCOME} Stopping is the loop's normal ending \u2014 the user can restart it anytime with /loop.`;return`# /loop \u2014 schedule a recurring or self-paced prompt
+
+Parse the input below into \`[interval] <prompt\u2026>\` and schedule it.
+
+## Parsing (in priority order)
+
+1. **Leading token**: if the first whitespace-delimited token matches \`^\\d+[smhd]$\` (e.g. \`5m\`, \`2h\`), that's the interval; the rest is the prompt.
+2. **Trailing "every" clause**: otherwise, if the input ends with \`every <N><unit>\` or \`every <N> <unit-word>\` (e.g. \`every 20m\`, \`every 5 minutes\`, \`every 2 hours\`), extract that as the interval and strip it from the prompt. Only match when what follows "every" is a time expression \u2014 \`check every PR\` has no interval.
+3. **No interval**: otherwise, the entire input is the prompt and you'll self-pace dynamically (see "Dynamic mode" below).
+
+If the resulting prompt is empty, show usage \`/loop [interval] <prompt>\` and stop.
+
+Examples:
+- \`5m /babysit-prs\` \u2192 interval \`5m\`, prompt \`/babysit-prs\` (rule 1)
+- \`check the deploy every 20m\` \u2192 interval \`20m\`, prompt \`check the deploy\` (rule 2)
+- \`run tests every 5 minutes\` \u2192 interval \`5m\`, prompt \`run tests\` (rule 2)
+- \`check the deploy\` \u2192 no interval \u2192 dynamic mode, prompt \`check the deploy\` (rule 3)
+- \`check every PR\` \u2192 no interval \u2192 dynamic mode, prompt \`check every PR\` (rule 3 \u2014 "every" not followed by time)
+- \`5m\` \u2192 empty prompt \u2192 show usage
+
+## Fixed-interval mode (rules 1 and 2)
+
+Convert the interval to a cron expression:
+
+${I}
+
+Then:
+1. Call ${ky} with: \`cron\` (the expression above), \`prompt\` (the parsed prompt verbatim), \`recurring: true\`.
+2. Briefly confirm: what's scheduled, the cron expression, the human-readable cadence, that recurring tasks auto-expire after ${Ofe} days, and that the user can cancel sooner with ${vA} (include the job ID).
+3. **Then immediately execute the parsed prompt now** \u2014 don't wait for the first cron fire. If it's a slash command, invoke it via the skill tool; otherwise act on it directly.
+
+## Dynamic mode (rule 3 \u2014 no interval)
+
+${o}
+
+## Input
+
+${e}`}
+function noPromptBody(e: LoopFile | null, o: boolean, t: string): string {let s: string=e?`## Loop tasks (from ${e.path})`:"## Autonomous-loop instructions (for the immediate execution and every fire)";let r: string;if(e)r=e.content;else r=autonomousPreamble();let h=e?"the loop.md tasks":"the autonomous check";if(o){let c=e?LOOP_FILE_DYNAMIC_SENTINEL:gve,O=e?`# /loop \u2014 loop.md tasks with dynamic pacing
+
+The user invoked \`/loop\` with no prompt and no interval and has a loop-tasks file at \`${e.path}\`. Run those tasks now, then self-pace the next iteration via ${yl} \u2014 no cron.`:`# /loop \u2014 autonomous default with dynamic pacing
+
+The user invoked \`/loop\` with no prompt and no interval. Run the autonomous check now, then self-pace the next iteration via ${yl} \u2014 no cron.`,b=e?`that you're running tasks from \`${e.path}\` in dynamic-pacing mode, that you ran the first tick now`:"that this is the autonomous default in dynamic-pacing mode, that you ran the check now",_=`1. **Run ${h} now**, following the instructions inlined below.
+2. **If the next tick is gated on an event** (CI finishing, a PR comment, a log line) and no ${il} is already running for it: ${armMonitor()}. Its events wake this loop immediately \u2014 you do not wait for the ${yl} deadline. ${rearmReminder("ticks")}
+3. **Decide whether the loop continues.** If the next check is worth running, call ${yl} with:
+   - \`delaySeconds\`: with a ${il} armed this is the fallback heartbeat (lean 1200\u20131800s). Without one, pick based on what you observed this turn \u2014 quiet branch? wait longer. Lots in flight? wait shorter. Read the tool's own description for cache-aware delay guidance.
+   - \`reason\`: one short sentence on why you picked that delay.
+   - \`prompt\`: the literal string \`${c}\` \u2014 the dynamic-mode sentinel expands at fire time to the full instructions (first fire / first fire post-compact / loop.md edited) or a dynamic-pacing-specific short reminder (subsequent fires). Do not pass the full instructions; that is handled automatically.
+   - \`noop\`: \`true\` if this tick changed nothing ("still waiting", "quiet hold"); \`false\` if it did something worth keeping. Consecutive \`noop: true\` ticks collapse in the terminal.
+   If it isn't, stop instead (step 6) \u2014 re-arming is a per-turn choice, not a default.
+4. **After the wakeup is armed, briefly confirm**: ${b}, whether a ${il} is the primary wake signal, and what fallback delay you picked. ${VISIBLE_UPDATE}
+5. **If woken by a \`<task-notification>\`** rather than this prompt: handle the event, then make the same decision. If the loop should continue, call ${yl} again with \`${c}\` and the same 1200\u20131800s \`delaySeconds\` (the ${il} remains the wake signal; the new wakeup is only the fallback heartbeat), then write the same brief update as visible text. If the event means the work is finished, stop (step 6).
+6. **To stop the loop** \u2014 the task is complete, further iterations can't make progress, or the user asked you to stop \u2014 call ${yl} with \`stop: true\` (no other fields) and ${Um} any ${il} you armed (use ${jb} to find the task ID if it is no longer in context). ${STOP_OUTCOME} Stopping is the loop's normal ending \u2014 the user can restart it anytime with /loop.`;return`${O}
+
+## Action
+
+${_}
+
+${s}
+
+${r}`}let l=e?LOOP_FILE_SENTINEL:PVe,u=e?`# /loop \u2014 schedule loop.md tasks
+
+The user invoked \`/loop\` with no prompt (input was empty or just the interval \`${t}\`) and has a loop-tasks file at \`${e.path}\`. Schedule a recurring cron that runs those tasks each tick, then run the first tick immediately.`:`# /loop \u2014 schedule the autonomous default
+
+The user invoked \`/loop\` with no prompt (input was empty or just the interval \`${t}\`). Schedule the autonomous-loop default and then run the first autonomous check immediately.`,k=e?"it expands at fire time to the full loop.md contents on first delivery (and whenever loop.md has been edited since last fire), and to a short reminder on subsequent unchanged fires. The long instructions stay in the cached message-prefix.":"it expands at fire time to the full autonomous-loop instructions on first delivery, and to a short reminder on subsequent fires (the long instructions stay in the cached message-prefix).",v=e?`what's scheduled, the cron expression, the human-readable cadence, that it's running tasks from \`${e.path}\`, that recurring tasks auto-expire after ${Ofe} days, and that the user can cancel sooner with ${vA} (include the job ID).`:`what's scheduled, the cron expression, the human-readable cadence, that recurring tasks auto-expire after ${Ofe} days, and that they can cancel sooner with ${vA} (include the job ID). Mention this is the autonomous default and that the autonomous-loop instructions are baked in.`;return`${u}
+
+## Action
+
+1. Convert \`${t}\` to a 5-field cron expression. Supported suffixes: \`s\` \u2192 ceil to nearest minute, \`m\` (minutes), \`h\` (hours), \`d\` (days). Examples: \`5m\` \u2192 \`*/5 * * * *\`, \`1h\` \u2192 \`0 * * * *\`, \`1d\` \u2192 \`0 0 * * *\`. If the interval doesn't cleanly divide its unit, round to the nearest clean interval and tell the user what you rounded to.
+2. Call ${ky} with:
+   - \`cron\`: the expression from step 1
+   - \`prompt\`: the literal string \`${l}\` \u2014 ${k}
+   - \`recurring\`: \`true\`
+3. Briefly confirm: ${v}
+4. **Then immediately run ${h} now**, following the instructions inlined below. Don't wait for the first cron fire.
+
+${s}
+
+${r}`}
+
+/**
+ * What `/loop <args>` sends the model, as in Claude Code:
+ * no prompt runs the autonomous default, self-paced when there is no
+ * interval either; anything else goes to the model to parse.
+ */
+export function loopSkillPrompt(args: string, loopFile: LoopFile | null): string {
+	const t = args.trim();
+	const every = t.match(EVERY_ONLY);
+	if (!t || INTERVAL_ONLY.test(t) || every !== null) {
+		return noPromptBody(loopFile, !t, every ? normalizeEvery(every) : t || N);
+	}
+	return explicitPrompt(t);
+}

package/extensions/background/monitor-batch.ts

@@ -58,3 +58,56 @@ export function formatMonitorEvents(id: string, batch: MonitorBatch): string {
 	const more = hidden > 0 ? `\n… +${hidden} more line(s) not shown — task_output ${id} has the full stream` : "";
 	return `${lines.join("\n")}${more}`;
 }
+
+/** The longest line kept waiting for its newline; past it the text so far goes out as an event. */
+export const MONITOR_MAX_LINE_CHARS = 16_000;
+
+/**
+ * A carriage return overwrites the line, as a terminal shows it: keep the text
+ * after the last `\r` that has anything after it (a trailing `\r`, as in
+ * `\r\n`, is dropped first).
+ */
+function overwriteLine(text: string): string {
+	const trimmed = text.replace(/\r+$/, "");
+	const at = trimmed.lastIndexOf("\r");
+	return at === -1 ? trimmed : trimmed.slice(at + 1);
+}
+
+/**
+ * Splits a monitor's stdout into event lines, bounded. Complete lines come out
+ * as they arrive; `end()` returns the last line when the stream stopped
+ * without a newline (a `curl` body, a `printf 'READY'`), which the monitor
+ * used to drop and then report "no output". A `\r` progress meter never grows
+ * the buffer past its latest segment, and a line longer than
+ * MONITOR_MAX_LINE_CHARS goes out at the cap instead of waiting forever.
+ */
+export class MonitorLineSplitter {
+	private buffer = "";
+
+	push(text: string): string[] {
+		this.buffer += text;
+		const lines: string[] = [];
+		let idx: number;
+		while ((idx = this.buffer.indexOf("\n")) !== -1) {
+			const line = overwriteLine(this.buffer.slice(0, idx)).trimEnd();
+			this.buffer = this.buffer.slice(idx + 1);
+			if (line) lines.push(line);
+		}
+		// Only the latest `\r` segment can still show; a lone trailing `\r` may be half of `\r\n`.
+		const cr = this.buffer.lastIndexOf("\r", this.buffer.length - 2);
+		if (cr !== -1) this.buffer = this.buffer.slice(cr + 1);
+		if (this.buffer.length > MONITOR_MAX_LINE_CHARS) {
+			const line = overwriteLine(this.buffer).trimEnd();
+			this.buffer = "";
+			if (line) lines.push(line);
+		}
+		return lines;
+	}
+
+	/** The stream ended: the unterminated last line, if any. */
+	end(): string[] {
+		const line = overwriteLine(this.buffer).trimEnd();
+		this.buffer = "";
+		return line ? [line] : [];
+	}
+}

package/extensions/background/noop-fold.ts

@@ -0,0 +1,128 @@
+/**
+ * Claude Code's no-op folding for self-paced `/loop` (2.1.282, findings §21).
+ * When a wakeup fires and the tick since the previous wakeup changed nothing
+ * (the model called schedule_wakeup with `noop: true`, and nothing vetoes
+ * it), that tick is folded: its messages leave the model's context and the
+ * new wakeup carries the streak, shown as
+ * `Resuming /loop wakeup (<time>) · <N> no-op ticks since <time>` and told to
+ * the model as `[<N> prior /loop wakeups found nothing actionable; loop is
+ * healthy.]`.
+ *
+ * `decideFold` applies Claude Code's rules to the session branch, run at fire
+ * time; its answer is stored on the new wakeup message, so `applyNoopFolds`
+ * (the `context` handler) gives the same context on every request. pi cannot
+ * remove messages already drawn, so the terminal keeps the folded tick above
+ * the streak line.
+ *
+ * Pure: no pi imports.
+ */
+
+/** The wakeup fire message's details that record a fold. */
+export interface FoldDetails {
+	noOpStreak?: number;
+	streakStartedAt?: number;
+}
+
+/** The slice of a session entry the fold reads. */
+export type FoldEntry =
+	| { kind: "wakeup"; timestamp: number; details?: FoldDetails }
+	| { kind: "fire" }
+	| { kind: "compaction" }
+	| { kind: "assistant"; toolCalls: Array<{ id: string; name: string; noop?: unknown }>; aborted: boolean }
+	| { kind: "toolResult"; toolCallId: string }
+	| { kind: "user" }
+	| { kind: "other" };
+
+export type FoldDecision =
+	| { kind: "none" }
+	| { kind: "veto"; reason: string }
+	| { kind: "fold"; priorStreak: number; since: number };
+
+/** Should the tick since the last wakeup fold into the one firing now? */
+export function decideFold(entries: readonly FoldEntry[]): FoldDecision {
+	let anchorIdx = -1;
+	for (let i = entries.length - 1; i >= 0; i--) {
+		if (entries[i].kind === "wakeup") {
+			anchorIdx = i;
+			break;
+		}
+	}
+	if (anchorIdx === -1) return { kind: "none" };
+	const anchor = entries[anchorIdx] as Extract<FoldEntry, { kind: "wakeup" }>;
+	for (let i = anchorIdx - 1; i >= 0; i--) {
+		const entry = entries[i];
+		if (entry.kind === "wakeup") break;
+		if (entry.kind === "fire" || entry.kind === "compaction") return { kind: "veto", reason: "blocking_system_before_anchor" };
+	}
+	let noop: boolean | undefined;
+	const calls = new Set<string>();
+	for (let i = anchorIdx + 1; i < entries.length; i++) {
+		const entry = entries[i];
+		if (entry.kind === "wakeup" || entry.kind === "fire" || entry.kind === "compaction") return { kind: "veto", reason: "blocking_system_in_span" };
+		if (entry.kind === "assistant") {
+			if (entry.aborted) return { kind: "veto", reason: "tool_abort" };
+			for (const call of entry.toolCalls) {
+				calls.add(call.id);
+				if (call.name === "schedule_wakeup") noop = call.noop === true;
+			}
+		} else if (entry.kind === "toolResult") {
+			if (!calls.has(entry.toolCallId)) return { kind: "veto", reason: "split_tool_pair" };
+		} else if (entry.kind === "user") {
+			return { kind: "veto", reason: "foreign_user_input" };
+		}
+	}
+	if (noop !== true) return { kind: "veto", reason: "model_reported_work" };
+	return { kind: "fold", priorStreak: anchor.details?.noOpStreak ?? 0, since: anchor.details?.streakStartedAt ?? anchor.timestamp };
+}
+
+/** Claude Code's note to the model in place of the folded ticks. */
+export function foldCompanion(streak: number): string {
+	return `[${streak} prior /loop ${streak === 1 ? "wakeup" : "wakeups"} found nothing actionable; loop is healthy.]`;
+}
+
+/** The streak part of the wakeup line, after `Resuming /loop wakeup (<time>)`. */
+export function foldSuffix(streak: number, since: string): string {
+	return ` · ${streak} no-op ${streak === 1 ? "tick" : "ticks"} since ${since}`;
+}
+
+interface ContextMessage {
+	role: string;
+	customType?: string;
+	details?: unknown;
+	timestamp?: number;
+}
+
+const WAKEUP_TYPE = "wakeup";
+
+function streakOf(message: ContextMessage): number {
+	if (message.role !== "custom" || message.customType !== WAKEUP_TYPE) return 0;
+	const streak = (message.details as FoldDetails | undefined)?.noOpStreak;
+	return typeof streak === "number" && streak > 0 ? streak : 0;
+}
+
+/**
+ * The model's context with every folded tick removed: before a wakeup that
+ * carries a streak, drop everything back to (and including) the previous
+ * wakeup and the note in front of it, and put the note for this streak in
+ * front of it. Unchanged when nothing folded.
+ */
+export function applyNoopFolds<M extends ContextMessage>(messages: readonly M[], companion: (text: string, timestamp: number) => M): M[] | undefined {
+	if (!messages.some((m) => streakOf(m) > 0)) return undefined;
+	const out: M[] = [];
+	const companions = new Set<M>();
+	let lastWakeup = -1;
+	for (const message of messages) {
+		const streak = streakOf(message);
+		if (streak > 0 && lastWakeup !== -1) {
+			let cut = lastWakeup;
+			if (cut > 0 && companions.has(out[cut - 1])) cut--;
+			out.length = cut;
+			const note = companion(foldCompanion(streak), message.timestamp ?? Date.now());
+			companions.add(note);
+			out.push(note);
+		}
+		if (message.role === "custom" && message.customType === WAKEUP_TYPE) lastWakeup = out.length;
+		out.push(message);
+	}
+	return out;
+}

package/extensions/background/switch-guard.ts

@@ -0,0 +1,52 @@
+/**
+ * What a session switch or quit would stop (pure). Running background tasks and
+ * scheduled jobs belong to the session: `/clear`, `/new`, `/resume` and a fork
+ * stop them, and so do `/reload` and quitting. pi lets an extension cancel a
+ * switch (`session_before_switch`, `session_before_fork`), so a switch asks
+ * first; reloading and quitting have no such hook, so the standing widget line
+ * says it up front.
+ */
+
+/** A running task or scheduled job, as the dialog and widget name it. */
+export interface SessionWork {
+	id: string;
+	label: string;
+}
+
+export const SWITCH_CANCEL = "Cancel";
+export const SWITCH_STOP = "Stop them and continue";
+
+/** At most this many items are named in the dialog; the rest are counted. */
+const MAX_NAMED = 6;
+
+const plural = (n: number, word: string) => `${n} ${word}${n === 1 ? "" : "s"}`;
+
+function counts(tasks: number, jobs: number): string {
+	const parts = [tasks > 0 ? plural(tasks, "background task") : "", jobs > 0 ? plural(jobs, "scheduled job") : ""].filter(Boolean);
+	return parts.join(" and ");
+}
+
+/**
+ * The confirm dialog's title, or undefined when nothing would be stopped.
+ * `action` names the switch ("Starting a new session"): pi reports /clear and
+ * /new alike, so the dialog cannot name the command.
+ */
+export function switchWarning(tasks: readonly SessionWork[], jobs: readonly SessionWork[], action: string): string | undefined {
+	if (tasks.length === 0 && jobs.length === 0) return undefined;
+	const items = [...tasks, ...jobs];
+	const named = items.slice(0, MAX_NAMED).map((item) => `  ${item.id}  ${item.label}`);
+	if (items.length > MAX_NAMED) named.push(`  … and ${items.length - MAX_NAMED} more`);
+	const one = items.length === 1;
+	const them = one ? "it" : "them";
+	return [
+		`${counts(tasks.length, jobs.length)} ${one ? "is" : "are"} still active. ${action} stops ${them}:`,
+		named.join("\n"),
+		tasks.length > 0 ? `Cancel to keep ${them} running; /tasks opens or stops a task.` : `Cancel to keep ${them}.`,
+	].join("\n\n");
+}
+
+/** The standing widget line while anything runs, or undefined when nothing does. */
+export function workWidgetLine(tasks: number, jobs: number): string | undefined {
+	if (tasks === 0 && jobs === 0) return undefined;
+	return ` ${counts(tasks, jobs)} · stopped by /clear, /reload or quitting${tasks > 0 ? " · /tasks to manage" : ""}`;
+}