@kingcrab/pi-imessage 1.1.1 → 1.2.0

package/docs/workspace-extensions.md

@@ -6,9 +6,9 @@ Business code belongs in `WORKING_DIR/extensions/<name>/index.ts` with its own
 host code, not a sandbox or an SDK `ExtensionAPI` adapter. Back up the extension
 directories with their configuration. The
 [system-context](../examples/workspace-extensions/system-context/) example loads
-an optional workspace summary into the prompt (ADR 0036).
+an optional workspace summary into the prompt.
 
-Tools without `replay` rerun after an interruption (ADR 0039). Declare
+Tools without `replay` rerun after an interruption. Declare
 `replay: "unsafe"` for an effect that must not repeat.
 
 ## Factory and reload
@@ -49,8 +49,12 @@ module.exports = ({ config, defineExtension, defineTask }) => {
 ```
 
 The factory receives `workingDir`, parsed `config`, `Type`, `defineExtension`,
-`defineTool`, `defineDoc`, `defineTask`, `configure`, `section`, and the generic
-`ScheduledOutbox` document token. All primitives are the host's pinned versions.
+`defineTool`, `defineDoc`, `defineTask`, `configure`, `section`, `hook` with
+`GenerationTask` (generation hooks such as a per-request `beforeRequest` message
+rewrite), the generic `ScheduledOutbox` document token, and `durable`, the whole
+Durable SDK, for anything else a plain Durable extension uses (for example
+`durable.LiveDoc` or `durable.ResetEntry`). All primitives are the host's pinned
+versions.
 Return a native extension with optional `schedules`; tools and multiple tasks
 work without any schedules. Startup and `/reload` scan direct, non-hidden child
 directories only, never skills or attachments. `reload_extensions` lets the chat

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@kingcrab/pi-imessage",
-	"version": "1.1.1",
+	"version": "1.2.0",
 	"description": "A minimal, self-managing iMessage bot powered by Pi Durable",
 	"license": "MIT",
 	"repository": {
@@ -10,9 +10,7 @@
 	"files": [
 		"dist",
 		"docs",
-		"examples",
-		"ops/README.md",
-		"ops/preflight.mjs"
+		"examples"
 	],
 	"publishConfig": {
 		"access": "public",
@@ -28,7 +26,7 @@
 	"scripts": {
 		"build": "tsc -p tsconfig.build.json && cp src/web/app.js src/web/style.css dist/web/",
 		"prepack": "npm run build",
-		"test:package": "npm run build && node ops/package-smoke.mjs",
+		"test:package": "npm run build && node scripts/package-smoke.mjs",
 		"start": "node --use-env-proxy --experimental-strip-types src/cli.ts serve",
 		"check": "tsc --noEmit && biome check .",
 		"test": "vitest run"
@@ -36,6 +34,7 @@
 	"dependencies": {
 		"@earendil-works/chord": "1.4.0",
 		"@earendil-works/pi-ai": "1.4.0",
+		"@earendil-works/pi-codemode": "1.4.0",
 		"@earendil-works/pi-coding-agent": "1.4.0",
 		"@earendil-works/pi-durable": "1.4.0",
 		"better-sqlite3": "13.0.3",

package/dist/agent/compaction.js

@@ -1,51 +0,0 @@
-import { BACKGROUND_CONTEXT } from "@earendil-works/chord/context";
-import { CompactionEntry, LiveDoc, ResetEntry } from "@earendil-works/pi-durable";
-import { Chats } from "./chats.js";
-// Native compact() uses reason "manual" for both a command and a maintenance tick.
-// Record exact timer task IDs, not conversation IDs, so concurrent manual work stays visible.
-const scheduled = new WeakMap();
-/** Resolve admission before classifying: the commit may be observed before compact() returns its ID. */
-export async function takeScheduledCompaction(harness, taskId) {
-    const state = scheduled.get(harness);
-    if (!state)
-        return false;
-    await Promise.allSettled([...state.admissions]);
-    return state.tasks.delete(taskId);
-}
-/** Admit native compactions, not another summarization loop; Durable decides whether a cut is needed. */
-export async function compactChats(harness, admissionFailed) {
-    const tasks = [];
-    const chats = await harness.snapshot(Chats, BACKGROUND_CONTEXT);
-    for (const chat of chats?.items ?? []) {
-        try {
-            if ((await harness.snapshot(LiveDoc, chat.conversationId, BACKGROUND_CONTEXT))?.compactions?.length)
-                continue;
-            const conversation = await harness.conversation(chat.conversationId, BACKGROUND_CONTEXT);
-            const newest = (await conversation?.entries({}, 1, undefined, BACKGROUND_CONTEXT))?.items[0];
-            if (!conversation || !newest || CompactionEntry.is(newest) || ResetEntry.is(newest))
-                continue;
-            let state = scheduled.get(harness);
-            if (!state) {
-                state = { admissions: new Set(), tasks: new Set() };
-                scheduled.set(harness, state);
-            }
-            const quiet = state;
-            const admission = conversation.compact(undefined, BACKGROUND_CONTEXT).then((taskId) => {
-                quiet.tasks.add(taskId);
-                return taskId;
-            });
-            quiet.admissions.add(admission);
-            try {
-                tasks.push(await admission);
-            }
-            finally {
-                quiet.admissions.delete(admission);
-            }
-        }
-        catch (error) {
-            admissionFailed?.();
-            console.warn("Scheduled compaction admission failed", chat.chatGuid, error);
-        }
-    }
-    return tasks;
-}

package/dist/agent/error-log.js

@@ -1,37 +0,0 @@
-const REASON_LIMIT = 200;
-const failedAssistant = (message) => message.role === "assistant" && message.stopReason === "error";
-/**
- * Service-log error lines for failures that break normal operation (ADR 0053). Durable keeps a failed
- * task only in its records, so without this an exhausted provider quota leaves stdout silent while the
- * process, port and HTTP checks look healthy. Each error kind is one branch here; the first is a model
- * call that ends failed, which leaves the chat or scheduled job without the answer it was waiting for.
- */
-export function logErrors(harness) {
-    return harness.subscribeCommits(({ changes }) => {
-        for (const change of changes) {
-            if (change.type !== "task" || change.value.kind !== "pi.generation")
-                continue;
-            const task = change.value;
-            if (task.state.status !== "terminal")
-                continue;
-            const { outcome } = task.state;
-            if (outcome.status === "completed" || outcome.status === "aborted")
-                continue;
-            // The failing assistant message is committed together with the task and names provider and model.
-            const failed = changes
-                .flatMap((item) => item.type === "entry" && item.value.conversationId === task.conversationId
-                ? (item.value.model ?? [])
-                : [])
-                .find(failedAssistant);
-            console.error(new Date().toISOString(), "Model call failed", {
-                kind: task.kind,
-                task: task.id,
-                conversation: task.conversationId,
-                status: outcome.status,
-                provider: failed?.provider,
-                model: failed?.model,
-                reason: (outcome.error?.message ?? outcome.reason ?? "").slice(0, REASON_LIMIT),
-            });
-        }
-    });
-}

package/dist/extensions/restart.js

@@ -1,100 +0,0 @@
-import { execFile } from "node:child_process";
-import { access, chmod, copyFile, mkdtemp, writeFile } from "node:fs/promises";
-import { dirname, join } from "node:path";
-import { promisify } from "node:util";
-import { Type } from "@earendil-works/pi-ai";
-import { defineExtension, defineTool } from "@earendil-works/pi-durable";
-const execFileAsync = promisify(execFile);
-/** Variables that describe the old shell session or that the controller sets itself. */
-const EXCLUDED_ENVIRONMENT = new Set(["_", "PWD", "OLDPWD", "SHLVL", "TERM_SESSION_ID"]);
-function shellQuote(value) {
-    return `'${value.replaceAll("'", "'\\''")}'`;
-}
-async function processField(field) {
-    const { stdout } = await execFileAsync("ps", ["-p", String(process.pid), "-o", `${field}=`]);
-    // Exactly what the controller's `$(ps ...)` yields: trailing newlines stripped, nothing else.
-    return stdout.replace(/\n+$/, "");
-}
-/** Writes the private controller directory of ops/README.md step 3 for the target release; starts nothing. */
-export async function prepareRestart(options, release) {
-    if (!/^[0-9a-f]{40}$/.test(release))
-        throw new Error("release must be the full commit hash of a prepared release directory");
-    const target = join(dirname(options.currentRelease), release);
-    for (const entry of ["src/cli.ts", "node_modules", "ops/restart.command"]) {
-        await access(join(target, entry)).catch(() => {
-            throw new Error(`Release directory is not prepared: ${join(target, entry)} is missing`);
-        });
-    }
-    const [started, command] = await Promise.all([processField("lstart"), processField("command")]);
-    const deployDir = await mkdtemp(join(options.deployRoot, "pi-imessage-restart."));
-    // The whole process environment, including .env values loaded at startup; the controller deletes the file.
-    const environment = Object.entries(process.env)
-        .filter(([name, value]) => value !== undefined && /^[A-Za-z_][A-Za-z0-9_]*$/.test(name) && !EXCLUDED_ENVIRONMENT.has(name))
-        .map(([name, value]) => `export ${name}=${shellQuote(value ?? "")}`);
-    await writeFile(join(deployDir, "environment.sh"), `${environment.join("\n")}\n`, { mode: 0o600 });
-    const control = {
-        OLD_PID: String(process.pid),
-        OLD_STARTED: started,
-        EXPECTED_COMMAND: command,
-        REPO: target,
-        NODE: process.execPath,
-        WORKING_DIR: options.workingDir,
-        WEB_PORT: process.env.WEB_PORT ?? "7750",
-        LOG_FILE: join(options.workingDir, "service.log"),
-    };
-    await writeFile(join(deployDir, "control.sh"), `${Object.entries(control)
-        .map(([name, value]) => `${name}=${shellQuote(value)}`)
-        .join("\n")}\n`, { mode: 0o600 });
-    const controller = join(deployDir, "restart.command");
-    await copyFile(join(target, "ops", "restart.command"), controller);
-    await chmod(controller, 0o700);
-    return { target, deployDir, controller };
-}
-/** The claw baseline: a Terminal window keeps the controller alive independently of this process. */
-export async function launchInTerminal(controller) {
-    await execFileAsync("open", ["-a", "Terminal", controller], { timeout: 15_000 });
-}
-/** The chat assistant restarts the service through the host instead of a bash command that stops its own host. */
-export function restartExtension(options) {
-    let scheduled;
-    return defineExtension({
-        name: "restart",
-        tools: [
-            defineTool({
-                name: "restart_service",
-                description: "Restart this service into a prepared release directory: a sibling of the running one named by its full commit hash, with npm ci and ops/preflight.mjs done. The service stops only after this call has settled; end the call at once and verify in a later call: controller.log and new.pid in the returned directory, then the service log, the listener and the running release directory. Never call it again before the first outcome is known.",
-                parameters: Type.Object({
-                    release: Type.String({ description: "Full commit hash of the prepared release directory" }),
-                }),
-                // A rerun would launch a second controller (#39); an interrupted call is reported to the model instead.
-                replay: "unsafe",
-                async execute(args, api) {
-                    if (scheduled)
-                        throw new Error(`A restart is already scheduled from ${scheduled}`);
-                    const prepared = await prepareRestart(options, args.release);
-                    scheduled = prepared.deployDir;
-                    console.log(new Date().toISOString(), "Restart requested", {
-                        release: args.release,
-                        controller: prepared.deployDir,
-                        task: api.taskId,
-                    });
-                    void options
-                        .settled(api.taskId)
-                        .then(() => options.launch(prepared.controller))
-                        .catch((error) => {
-                        scheduled = undefined;
-                        console.error(new Date().toISOString(), "Restart launch failed", error);
-                    });
-                    return {
-                        output: [
-                            {
-                                type: "text",
-                                text: `Restart into ${prepared.target} is scheduled; the service stops after this call settles. Controller directory: ${prepared.deployDir}. Verify in a later call.`,
-                            },
-                        ],
-                    };
-                },
-            }),
-        ],
-    });
-}

package/docs/adr/0003-replies-at-most-once.md

@@ -1,11 +0,0 @@
-# 0003. Replies are sent at most once
-
-Status: accepted (2026-10-04; owner accepted 2026-10-05)
-
-**Context.** Sending through Messages.app and recording it in Durable cannot be one atomic step. A crash in between either loses or repeats a reply.
-
-**Decision.** For each final answer: record `sending` in the conversation, send, then record `sent`. On restart, `sending` becomes `unknown`: it is logged and shown in the web UI, and never resent automatically; to resend, use `/send`. This covers agent replies; `/send`, cron and reminders report their result to the caller or run log.
-
-**Consequences.** A crash in that window of a few milliseconds can drop one reply. Nothing is ever sent twice.
-
-**Rejected.** Send, then record (can send twice). Confirming delivery through `chat.db` GUIDs (complex and unreliable).

package/docs/adr/0005-history-migration.md

@@ -1,11 +0,0 @@
-# 0005. Import old history once; start with an empty context
-
-Status: accepted (2026-10-04; owner accepted 2026-10-05)
-
-**Context.** Old data per chat: `WORKING_DIR/<chat>/log.jsonl` (about 28,000 lines across 12 chats on claw), plus SDK sessions, goals, subagents and several GB of images.
-
-**Decision.** `migrate/migrate.ts` runs once at cutover. Each `log.jsonl` becomes user and assistant entries in that chat's conversation, followed by one reset, so the model starts with an empty context. Attachments move to `WORKING_DIR/attachments/<chat>/`, and entries keep the path. The agent searches old messages by grepping `WORKING_DIR/durable/`; the system prompt says where. SDK sessions, goals, subagents and scratch are archived once, then deleted.
-
-**Consequences.** The model doesn't remember pre-cutover talk until it searches. The web UI shows old and new history the same way.
-
-**Rejected.** Importing the SDK context (different format). A summary per chat at reset (one model call per chat). A separate archive folder.

package/docs/adr/0008-compaction-and-run.md

@@ -1,11 +0,0 @@
-# 0008. Compact every 6 hours; `/run` replaces `/goal`
-
-Status: accepted (2026-10-04; owner accepted 2026-10-05)
-
-**Context.** The old bot reset every chat nightly, and used `pi-goal-x` for long tasks, which brought task trees, contracts and reviewers we don't need.
-
-**Decision.** Every 6 hours, each chat with new entries since its last compaction is compacted in the background; no chat notifications. Durable's automatic compaction near the context limit stays on. `/run <duration> [task]` keeps the run going through an `onYield` hook until the task is done, the user is needed, or the deadline passes. One run per conversation; `/run-stop`, `/stop` and `/new` end it; it does not survive a restart.
-
-**Consequences.** Context is never wiped on a schedule. `/run` spends tokens until it stops.
-
-**Rejected.** Nightly reset. Migrating `pi-goal-x`.

package/docs/adr/0009-one-shot-cutover.md

@@ -1,11 +0,0 @@
-# 0009. Switch over in one step
-
-Status: accepted (2026-10-04; owner accepted 2026-10-05)
-
-**Context.** Running old and new pipelines side by side (a per-chat canary) needs guards against processing a message twice. That was much of #31's complexity.
-
-**Decision.** Build in a new repository, `pi-imessage-next`. At cutover: stop the old service, run the migration (which also saves the current `chat.db` row as the watch cursor), start the new service, then push the new code to `daya0576/pi-imessage` as one commit. Rollback: stop the new service, restore the `WORKING_DIR` backup, start the old release.
-
-**Consequences.** Minutes of downtime; messages that arrive meanwhile are picked up from the cursor, and losing a few is acceptable. No code for running two pipelines.
-
-**Rejected.** Per-chat canary.

package/docs/adr/0013-thin-adapters-around-durable.md

@@ -1,18 +0,0 @@
-# 0013. Use Durable directly; keep adapters thin
-
-Status: accepted (2026-10-04; owner accepted 2026-10-05)
-
-**Context.** The drafts grew host state that Durable already keeps (per-command receipts with running/unknown recovery, a reply scan over every settled submission) and copies of other systems (a gzip/base64 Python memory backend inside TypeScript, a vendored 1,000-line scheduler). [0001](0001-durable-owns-state.md) says Durable owns chat state; this records where our code stops.
-
-**Decision.**
-
-- **Commands** call Durable APIs directly (`configure`, `compact`, `reset`, task abort). Each command is first written to the chat conversation as a passive entry with the message GUID as request ID, so a repeated row is skipped by Durable's dedupe. An interrupted command is not replayed. No command receipt state.
-- **`/reload`** rereads settings, models and auth, AGENTS and skills, and reinstalls our extensions under the same names; Durable's registry replaces them in place. Running calls finish on their old code. Nothing is paused or cancelled.
-- **Memory tools** run the store's own CLI, `WORKING_DIR/skills/file-memory/memory_cli.py`, which finds its data next to itself. No embedded or rewritten backend; a missing CLI is a tool error.
-- **Scheduler** keeps the clock: cron expressions, timezones, reminders and their files (`cron/jobs.json`, reminders). When a job fires it submits to Durable with a stable request ID, or sends directly with a receipt. After acceptance, Durable owns execution and recovery; the scheduler never retries model work. Durable 1.0.2 has task `sleep` but no cron or reminder service, so it is not used as one.
-- **Web pages** are read-only: they show Harness state and watches (history, live state, task graph, usage) and have no buttons. They keep no execution log of their own. The endpoints in [the HTTP API](../api.md) stay; endpoints used only by the old page buttons (per-chat reply toggle, PT task actions) are removed. Replies are enabled through the settings allowlist; cron jobs are run or paused through the API.
-- **Our documents** hold only what Durable cannot know: the `chat.db` cursor, the chat-to-conversation map, send receipts and the active run with its deadline.
-
-**Consequences.** Little host recovery code beyond send receipts. Memory needs Python and the store's CLI at runtime (Python is already a prerequisite). The scheduler stays a larger, separate module, isolated behind one submit or send call.
-
-**Rejected.** Command receipts and a command state machine. Pausing work around `/reload`. Embedding or reimplementing the memory backend. Rewriting cron and reminders as Durable tasks. A separate execution log for the UI. Page buttons, including a resend button for `unknown` replies.

package/docs/adr/0014-ephemeral-private-storage.md

@@ -1,13 +0,0 @@
-# 0014. Keep ephemeral transcripts in disposable private storage
-
-Status: superseded by [0018](0018-tasks-without-prompt-api.md) (2026-10-05). Was: proposed (2026-10-04)
-
-**Context.** The retained HTTP `ephemeral:true` contract removes an isolated session after its queued work finishes. Durable 1.0.2 has reset/compaction but no public single-conversation deletion API. Reset hides old context from the model; it does not erase stored prompts, tool results or child conversations.
-
-**Example.** An automated task reads private files. Its final answer may stay in the destination chat, but its private task transcript must not remain searchable in the ordinary conversation store after cleanup.
-
-**Decision proposed for owner acceptance.** Give each active ephemeral `(chatGuid, sessionKey)` its own private JSONL storage and native Harness. Let Durable own that storage's inbox, dedupe, steering, tasks and recovery. The main store keeps only opaque identity/lifecycle metadata needed to locate it and external send receipts, not its private prompt/tool transcript. Admission success follows persisted private admission. On restart, reopen recorded private storage and resume its native work; never replay a whole turn in the host. Deliver completed answers with stable main-store receipts. Once the private Harness is idle and its completed answers have an authoritative sent/unknown disposition, close it and remove its directory with restart-safe cleanup. A later batch with the same key starts a fresh private context. Do not remove an active directory or silently lose queued work.
-
-**Consequences.** Extra storage/lifecycle wiring is necessary for the old privacy promise, but no second model loop or mirrored inbox. Repeated request IDs and uncertain sends need checks across cleanup/restart. HTTP ephemeral admission remains blocked until this design is accepted, implemented and verified. Ordinary API/cron contexts stay in the shared store.
-
-**Rejected.** Calling reset and claiming deletion. Editing shared append-only storage behind Durable. Retaining private transcripts in the main store. Dropping ephemeral behavior without owner approval.

package/docs/adr/0015-ordinary-stop-keeps-native-inbox.md

@@ -1,21 +0,0 @@
-# 0015. Ordinary `/stop` keeps the native inbox
-
-Status: superseded by [0018](0018-tasks-without-prompt-api.md) (2026-10-05). Was: proposed (2026-10-04). Replaces only the no-active-run `/stop` clause of proposed [0012](0012-run-in-owned-conversation.md) if accepted. Does not approve its other behavior changes.
-
-**Problem.** Ordinary `/stop` must cancel current work and foreground children, suppress unclaimed old replies, and preserve later unprocessed ordinary messages. `Conversation.abort()` in Durable 1.0.2 cancels the conversation's foreground scope but withdraws queued inputs. Looking up `LiveDoc.run.taskId` and calling `abortTask()` preserves the parent inbox, but is not equivalent: generation hands over to a new conversation-owned task between turns. The old task can become terminal between lookup and abort; aborting it then does nothing to the new generation.
-
-**Example.** A request reads a file and continues into another model turn. A later ordinary message is queued. `/stop` must cancel the ongoing request, even at that turn boundary, without losing or resubmitting the later message.
-
-**Decision.**
-
-- Preserve this ordinary-chat behavior; do not silently replace it with “nothing is running” or queue withdrawal.
-- Require a supported native conversation-scope cancellation operation that atomically selects current foreground work while retaining the root chat's queued inputs. Cancellation of work owned below that scope must still follow Durable's ownership rules. The operation must define admission during cancellation and behavior across generation handover.
-- Use the native operation directly. After cancellation settles, suppress old unclaimed drafts using existing delivery records; never change `sending`, `sent` or `unknown` receipts or claim that a started send was undone.
-- If preserved inputs require a new boundary, submit one passive cancellation note through the public conversation API. Durable places existing inbox items; the host never copies their content, creates replacement input submissions, or replays the cancelled request.
-- Keep `/run` cancellation and isolated API/cron/background/health sessions separately scoped. This decision does not accept dropping queued run messages or cancelling unrelated sessions.
-
-**API boundary.** Durable 1.0.2 exposes no retain-inbox option on `Conversation.abort()`, and its public transaction API has no atomic task-abort operation. An upstream API change and dependency upgrade are required before this design can be implemented as specified. Do not patch installed package files or write the built-in live/inbox documents to simulate that operation.
-
-**Evidence.** The [inbox example](https://github.com/earendil-works/pi/blob/main/packages/durable/test/examples/20-inbox.ts), installed `harness/generation.js` (`createGeneration`, `handOver`), `harness/scheduler.js` (`abort`, `abortConversation`) and public `Tx` declarations establish the distinction. A bounded faux-provider experiment reproduces generation-ID handover and the stale-ID abort no-op; aborting the current generation preserves the queued input, and a passive write places it without a replacement submission. That experiment does not establish a race-free host cancellation implementation.
-
-**Rejected.** Repeated lookup/abort polling, a host cancellation epoch or mirrored inbox, withdrawing and resubmitting queued inputs, direct edits of Durable internals, and treating a cancelled wait as cancelled work. Also rejected: claiming a single generation-task abort cancels a whole multi-turn request.

package/docs/adr/0016-process-http-transport.md

@@ -1,21 +0,0 @@
-# 0016. Initialize one process-owned HTTP transport
-
-Status: accepted (2026-10-05; owner accepted 2026-10-05)
-
-**Problem.** Pi's global `httpProxy` and `httpIdleTimeoutMs` settings need HTTP transport setup, not just request-option forwarding. Coding-agent's experimental Durable startup calls `applyHttpProxySettings()` and `configureHttpDispatcher()`, but neither is a public export of coding-agent 1.0.2. Merely assigning `HTTP_PROXY` and `HTTPS_PROXY` after Node starts does not reconfigure the dispatcher created by `--use-env-proxy`.
-
-**Example.** An operator sets `httpProxy` in Pi settings without shell proxy variables. The service must use that proxy for authentication and model HTTP requests. Setting the variables at service startup can otherwise leave fetch connecting directly. A provider request timeout also does not replace a socket's inactivity timeout.
-
-**Decision.**
-
-- The host owns one process-wide HTTP setup, initialized before opening model/auth runtime. Individual chats and private Harness instances do not install global dispatchers.
-- Use public Undici APIs, with an exact direct dependency matching the supported SDK implementation, rather than importing private coding-agent files. Supply the global Pi proxy setting only as environment defaults; retain explicit environment proxy values, lowercase precedence and NO_PROXY behavior. Do not accept project-local proxy overrides where Pi accepts only global configuration.
-- Configure native HTTP headers/body idle timeouts from Pi settings, including disabled timeout semantics. Keep transport fetch and dispatcher on the same Undici implementation so compressed responses are decoded consistently. Preserve deliberately supplied fetch implementations. Follow the SDK's connection-family and client-error handling rather than inventing transport retries.
-- `/reload` may replace transport for subsequent requests without cancelling active work. Track transport resources in memory only, let active requests finish on their original clients, and retire old clients safely. During shutdown, stop producers and Harness work before releasing transport; restore globals only if they are still ours. Never close a dispatcher owned by another caller.
-- Durable/provider retry policy and request timeout options remain unchanged. This setup is not a host activity timer, prompt deadline, compaction deadline, inbox or execution loop.
-
-**Consequences.** Process-global HTTP setup belongs to application lifecycle, not per-conversation configuration. Standalone callers with an injected runtime/fetch keep control of their transport. The implementation must verify proxy precedence/bypass, compressed responses, idle timeout enable/disable, reload with active requests, cleanup and custom-fetch preservation against loopback fixtures before claiming compatibility.
-
-**Evidence.** The installed coding-agent `core/http-dispatcher.js` and experimental [harness setup](https://github.com/earendil-works/pi/blob/main/packages/coding-agent/src/experimental/durable/harness-setup.ts) use Undici EnvHttpProxyAgent and matching fetch globals. A bounded Node 26 loopback experiment confirms late environment defaults leave built-in fetch direct, while public Undici 8.10.2 dispatcher plus matching fetch routes through the configured proxy. This establishes an implementation path, not completed lifecycle/timeout behavior or real-provider connectivity.
-
-**Rejected.** Environment mutation as proof of effective transport, request timeout as proof of socket-idle enforcement, private SDK imports, patching installed packages, a new HTTP retry algorithm, and relying on newer Node-only proxy-reset APIs while retaining Node >=22.22.2 support.

package/docs/adr/0017-browser-cli-owned-scope.md

@@ -1,22 +0,0 @@
-# 0017. Invoke browser CLI in a native conversation-owned scope
-
-Status: accepted (2026-10-05; owner accepted 2026-10-05). Replaces only the browser-through-unrestricted-bash part of proposed [0004](0004-native-extensions.md) if accepted.
-
-**Problem.** `PI_BROWSER_HOME` scopes the pi-browser wrapper's profiles/output, not Playwright CLI's daemon registry. CLI 0.1.19 keeps that registry in the user's cache directory, derives daemon workspace identity from `.playwright` or the installed package, and enumerates other workspaces. All chats currently share the same shell environment and working directory. A named session or separate profile directory alone therefore does not preserve the old browser adapter's private-session rules.
-
-**Example.** Two chats both use `-s=task`. Even with different PI_BROWSER_HOME values, they can resolve the same daemon/session and see other registry entries. Giving the model a suggested name is not enforcement.
-
-**Decision.**
-
-- Offer a thin native Durable browser tool that invokes the installed, pinned pi-browser CLI by argv. Do not load an SDK browser extension, emulate ExtensionAPI, vendor CLI internals or implement another browser driver.
-- Derive browser scope from canonical storage identity plus native conversation identity, not a model-selected name. Ordinary chats, runs and isolated API/cron contexts get distinct scope; disallowed read-only contexts do not get the tool.
-- Give only browser child processes a dedicated HOME, profile/output root and scoped working directory. Leave ordinary coding tools' HOME/cwd unchanged. Use public process/CLI controls rather than PWTEST daemon/socket environment variables. Verify daemon discovery and attachment cannot escape the scope, including environment-inherited external browser targets.
-- Always select the owned session/profile and headless mode. Deny attachment/discovery, global close/kill, arbitrary profile/config paths and headed overrides, retaining the old service's restrictions. Expose the ordinary browsing operations needed by the product through validated arguments; operation results remain untrusted data.
-- Close owned browsers at the agreed stop/shutdown boundaries without touching unrelated sessions. Track only external browser resources and cleanup facts, not a second task state machine. Define restart cleanup and privacy retention before claiming isolation. Do not silently delete saved login profiles or replay uncertain browser mutations.
-- Do not mistake this tool boundary for an OS sandbox: unrestricted bash/read can still access host files and invoke other executables. State that limit explicitly; stronger containment requires a separate decision.
-
-**Consequences.** Native tool registration replaces browser instructions as the enforcement boundary for normal product use. The browser skill can still explain workflows, but cannot be the sole privacy mechanism. Actual Chrome/CLI fixtures must verify same-name sessions in different scopes, registry isolation, profile/config rejection and owned cleanup before release.
-
-**Evidence.** The installed wrapper source separates PI_BROWSER_HOME from Playwright's registry. In a temporary copy installed with the locked manifests (`npm ci --ignore-scripts`), CLI 0.1.19's `cli-client/registry.js` uses OS HOME/cache, scans every workspace and exposes only a PWTEST-specific daemon-root override. A bounded temporary-HOME experiment confirms different PI_BROWSER_HOME values share the daemon directory and registry enumeration sees another synthetic workspace. No browser or personal profile was opened. The experiment describes the pinned implementation; production must not import those private files.
-
-**Rejected.** Profile-directory changes or prompt-only session naming as proof of isolation, private PWTEST controls, changing HOME/cwd for all bash tools, SDK extension adaptation, unscoped global browser cleanup and claiming unrestricted coding tools are sandboxed.

package/docs/adr/0018-tasks-without-prompt-api.md

@@ -1,19 +0,0 @@
-# 0018. Ordinary `/stop`; scheduled tasks without HTTP `/prompt` and `/send`
-
-Status: accepted (2026-10-05; owner accepted 2026-10-05). Supersedes proposed [0014](0014-ephemeral-private-storage.md) and [0015](0015-ordinary-stop-keeps-native-inbox.md). Replaces the HTTP `/prompt` clause of proposed [0012](0012-run-in-owned-conversation.md) and the `/send` resend hint of [0003](0003-replies-at-most-once.md).
-
-**Context.** Every production caller of HTTP `/prompt` and `/send` is a script or cron job on the same machine, plus the agent sending files through curl. The work they start runs in a separate context, but its result never reaches the chat's own conversation: when the user replies to a morning summary, the chat does not know what was sent. 0014 and 0015 wait for storage lifecycle work and an upstream Durable API.
-
-**Example.** At 08:00 a cron job runs a script that builds the newsletter prompt; the agent works in its own conversation and sends five links. The user replies "expand the third one". The chat conversation must already hold the five links, not the prompt or tool calls that produced them.
-
-**Decision.**
-
-- **Ordinary `/stop`** (no active `/run`) aborts the generation task that owns the current inputs (`LiveDoc.run`), not the conversation, so later queued messages stay in the inbox. If generation hands the same inputs to a new task meanwhile, abort that one too. Then write a passive `[/stop]` entry so Durable places the queued messages. `/stop` during a run is unchanged.
-- **Tasks.** Cron `prompt` jobs, `schedule_task` firings and background summaries each run in a fresh ownerless conversation, keyed by request ID. Nothing carries over between runs; continuity lives in the chat conversation and memory. Transcripts are kept, not deleted. The model health check reuses one conversation.
-- **The chat records what was sent.** A delivered task answer, and every service or tool send (reminders, cron `send`, background summaries, Automation, `send_message`), is written to the chat conversation as one passive entry with its delivery status, deduplicated by request ID. No extra model turn; the chat's next turn sees it.
-- **No HTTP `/prompt`, `/send` or `ephemeral`.** Cron `send` and `prompt` actions accept an optional `command` (absolute argv). Its stdout replaces the text or prompt; empty output skips the run. Scripts print instead of POSTing, and are scheduled in `cron/jobs.json`. The agent sends files and extra messages with the native `send_message` tool, using the existing direct-send receipts (tool task ID as request ID). Remaining HTTP: read-only pages, reminders, cron management and model health.
-- **Cutover.** The old service still needs `/prompt` and `/send`, so production scripts, crontab entries and `jobs.json` change in the same step as the cutover ([0009](0009-one-shot-cutover.md)).
-
-**Consequences.** One way to start agent work from outside a chat, and one place (the chat conversation) that knows what the user saw. `/stop` uses a bounded lookup/abort retry instead of an atomic native operation. Old `ephemeral` deletion is dropped; private tool output stays searchable under `durable/`. External callers on other machines can no longer prompt the agent; a future multi-entry design decides that. The shared scheduler's `jobs.json` parser gains the optional `command` field.
-
-**Rejected.** Handing task results to the chat as input (an extra model turn, interrupts current work, rewrites the sent text). Private per-session storage (0014). Waiting for an upstream cancellation API (0015). Keeping `/prompt` and `/send` as thin HTTP entries.

package/docs/adr/0019-remove-scheduled-services.md

@@ -1,41 +0,0 @@
-# 0019. Remove scheduled services from the chat application
-
-Status: proposed
-
-**Problem.** The owner wants scheduling removed from this project and will design
-it separately later. Keeping empty job files or startup switches still leaves
-scheduled effects and their dependencies in the chat application's lifecycle.
-
-**Example.** Starting messaging must not create reminder databases, register cron
-jobs, run PT checks or watch completion files, even when old configuration exists.
-
-**Decision.**
-
-- Remove cron, reminders, delayed/repeating prompts, background completion
-  watchers/summaries and PT Automation from source, tools, routes, pages, startup,
-  preflight and direct dependencies. Do not replace them with disabled stubs.
-- Keep messaging, immediate `send_message`, foreground subagents, `/run`, ordinary
-  `/stop`, native task inspection and explicit tool-less model health checks.
-  Keep the six-hour context compaction required by ADR 0008; it is a chat
-  maintenance timer, not user scheduling.
-- Keep existing settings, memory, history, receipts and offline backup/import
-  data intact. Removal does not authorize deleting stored job data, modifying
-  installed Pi extensions, or changing the operating system's crontab/launchd.
-  This application does not manage or stop independent operating-system jobs.
-- Removed scheduling and Automation endpoints return 404. There is no
-  compatibility adapter or automatic migration to another scheduler.
-- Retain historical isolated-conversation metadata for read-only inspection,
-  but do not deliver answers from retired scheduled conversations.
-
-This proposal supersedes the scheduled-service clauses of ADR 0013 and ADR 0018
-only when accepted. Their ordinary stop, immediate sending and receipt decisions
-remain unchanged. Accepted ADR files are not edited. Scope and implementation
-progress are tracked in GitHub #33, not in this document.
-
-**Consequences.** A future scheduler needs its own design and approval. Startup
-still needs independent old producers to be reviewed, and model/Messages live
-acceptance remains separate from removal of scheduled services.
-
-**Rejected.** Merely clearing job definitions, hiding tools while retaining
-workers, reviving HTTP `/prompt` or `/send`, and deleting production state as
-part of a source-code change.

package/docs/adr/0020-chat-task-progress.md

@@ -1,41 +0,0 @@
-# 0020. Report native task calls in iMessage
-
-Status: accepted (owner approved the format, exclusions, implementation and restart)
-
-**Problem.** Final-only replies leave the owner unable to see tool and task
-progress in iMessage while work is running.
-
-**Example.** A search emits `[tool] web_search · query=上海浦东 私立医院`
-before the final answer. Other custom tasks emit their native task name. A
-foreground subagent's calls use `[subagent/tool]` and go to its parent chat.
-
-**Decision.**
-
-- Observe committed native task admission with Durable's public commit API;
-  do not wrap tools, poll task phases or introduce another execution loop.
-- With `settings.json` setting `progressMessages: true`, send one plain-text
-  notice per new task to its owning, reply-enabled chat, except `pi.generation`
-  which the owner excludes. A `pi.tool` task is one tool notice, not a duplicate
-  task notice. Keep IDs internal for deduplication; do not display them.
-- Include native names, parent names and bounded argument summaries, not tool
-  outputs, thinking, free-form commands, prompts or document contents. Path and
-  search-query previews are screened for known credential indicators; URL
-  previews omit user info, paths, queries and fragments. Arbitrary user-authored
-  secrets cannot be guaranteed detectable.
-- Follow Durable's conversation ownership for child/subagent attribution.
-  Health and unrelated ownerless conversations stay local.
-- Use existing direct-send receipts keyed by task ID. Unknown sends are not
-  retried. Do not replay pre-existing live tasks on startup or generate model
-  context entries for progress notices.
-- Notifications do not gate task execution; drain admitted notices before
-  automatic final replies. Stop observation and join pending sends on shutdown.
-- Missing or false configuration retains final-only delivery. No stored
-  settings or receipt formats are removed.
-
-**Consequences.** iMessage can receive many notices. Progress reflects task
-admission, not confirmed completion. Final answers retain their existing
-reconciliation and at-most-once rules. This expands final-only chat behavior;
-accepted ADR files remain unchanged. Scope and validation belong in GitHub #33.
-
-**Rejected.** Asking the model to narrate every call, forwarding raw outputs,
-replaying old task history, or using unreliable delivery confirmation to retry.

package/docs/adr/0021-readable-progress-without-link-previews.md

@@ -1,33 +0,0 @@
-# 0021. Readable progress without automatic link previews
-
-Status: accepted (owner approved implementation and restart on 2026-10-05)
-
-Supersedes the argument-display details of ADR 0020; routing, admission,
-receipts, exclusions and recovery remain unchanged.
-
-**Problem.** `command=[128 chars]` does not explain the work. Clickable URLs
-in progress and default answers create unwanted iMessage preview cards.
-
-**Example.** `[tool] bash · 搜索上海天气 · timeout=30` reports intent without
-revealing a shell command. `url=weather．com．cn` identifies a source without
-a clickable URL.
-
-**Decision.**
-
-- Add an optional short `description` to the native bash schema. Ask the model
-  for a non-sensitive purpose in the user's language; delegate execution,
-  timeout validation and output handling unchanged to native bash.
-- Show the screened, bounded description instead of the command or its length.
-  Missing or credential-like descriptions use `执行命令`. Raw commands remain
-  private. Descriptions report intent, not verified completion.
-- URL arguments show only hostnames with fullwidth dots, never schemes,
-  user information, paths, queries or fragments. Screened path/query previews
-  omit explicit HTTP(S) URLs.
-- Default answers name sources without URLs. Provide original links when the
-  user asks. This is prompt policy, not a transport-level preview toggle or
-  a prohibition on explicitly requested links.
-- Credential screening is best effort; arbitrary secrets in model-authored
-  labels cannot be guaranteed detectable.
-
-**Rejected.** Raw shell snippets, another model call to summarize commands,
-transport retries, and claiming an unsupported Messages preview-disable option.

package/docs/adr/0022-progress-admission-and-settlement.md

@@ -1,35 +0,0 @@
-# 0022. Arrow and settlement progress notices
-
-Status: accepted (owner requested arrow/checkmark style and omitted timeout on 2026-10-05)
-
-Supersedes the admission-only notification/display decisions of ADR 0020 and
-the displayed timeout example in ADR 0021. Other safety and routing decisions
-remain unchanged.
-
-**Problem.** Character counts and bracketed tool headers are noisy. The owner
-prefers the earlier arrow/checkmark style and does not need timeout parameters
-in chat.
-
-**Example.** `→ bash: 搜索上海天气`, then `✓ bash (0.8s)` on successful settlement.
-An unsuccessful call gets `× bash (0.8s)`, never a success checkmark.
-
-**Decision.**
-
-- Observe native committed task admission and terminal settlement through the
-  existing public commit subscription, without another execution loop.
-- Emit one arrow at admission and one checkmark/cross at settlement for tasks
-  admitted during this process lifetime. Exclude generation tasks and retain
-  native parent/child ownership, allowlist and private-health routing.
-- For native tools, success requires both a completed task outcome and the
-  stored tool-result message having no error flag. Aborted, failed and missing
-  or error tool results are not success.
-- Duration is local elapsed admission-to-settlement time, including queueing;
-  it is not exact subprocess-only runtime or recipient delivery latency.
-- Keep separate direct-send receipt IDs for admission and settlement. Do not
-  replay historical starts/completions or retry uncertain sends after restart.
-- Omit timeout from displayed argument summaries only; native enforcement is
-  unchanged. Keep short screened purpose labels and non-clickable hostnames,
-  never raw commands or outputs.
-- Final replies drain already queued progress notices. Progress remains
-  optional through the existing setting. This intentionally doubles most
-  task progress notices compared with admission-only reporting.

package/docs/adr/0023-retain-progress-type-prefixes.md

@@ -1,18 +0,0 @@
-# 0023. Retain progress type prefixes
-
-Status: accepted (owner explicitly corrected the format on 2026-10-05)
-
-Supersedes the prefix-free display examples of ADR 0022 only. Admission,
-settlement, privacy, elapsed time and receipt/recovery behavior are unchanged.
-
-**Problem.** Arrows and checkmarks replaced useful type labels. The owner wants
-bracketed prefixes retained alongside the new status markers.
-
-**Example.** `[tool] → bash: 搜索上海天气`, followed by `[tool] ✓ bash (0.8s)`.
-Owned child tools use `[subagent/tool] → read: path=…` and
-`[subagent/tool] ✓ read (0.8s)`. Native non-tool tasks retain `[task]` and
-parent-qualified task prefixes. Unsuccessful settlement uses `×`.
-
-**Decision.** Render the native type/parent prefix first, then the status marker,
-then the native tool/task name and short safe summary or elapsed time. Do not
-restore timeout, raw shell commands or clickable URLs.