@kingcrab/pi-imessage 1.1.1 → 1.2.0

package/docs/adr/0024-status-marker-before-type-prefix.md

@@ -1,13 +0,0 @@
-# 0024. Status marker before the type prefix
-
-Status: accepted (owner explicitly corrected marker placement on 2026-10-05)
-
-Supersedes the prefix-first display order in ADR 0023 only. Preserve all
-native routing, safe descriptions, settlement verification and receipt rules.
-
-**Example.** `→ [tool] bash: Check the weather`, then `✓ [tool] bash (0.8s)`.
-Child tools use `→ [subagent/tool] read: path=…`. Failure uses `×` first.
-
-**Decision.** Put the status marker at the very beginning, immediately followed
-by the retained bracketed type/parent label. Ask for short everyday action
-wording instead of implementation jargon. Omit timeout and raw commands.

package/docs/adr/0025-reusable-progress-and-command-preview.md

@@ -1,49 +0,0 @@
-# 0025. Reusable progress data and short command previews
-
-Status: accepted (owner approved option 5, then clarified request/response names and app reuse on 2026-10-05)
-
-Supersedes the command-opaque/request-name display rules of ADR 0021 and the
-request display examples of ADR 0024. Native lifecycle, routing, receipt IDs,
-uncertain-effect handling and response formatting are unchanged.
-
-**Problem.** The owner wants readable request purposes, a useful short bash
-preview, no tool names in any request, and reusable rules for a future app.
-
-**Example.**
-
-```text
-→ [tool] Check the weather
-node search.mjs "Shanghai weather" --count 5
-✓ [tool] bash (0.8s)
-```
-
-**Decision.**
-
-- Requests keep the leading arrow and bracketed type/parent label. Tool names
-  do not appear as separate request labels or parenthetical suffixes. Responses
-  keep the deployed format: marker, type/parent label, native name and elapsed
-  time. This latest clarification replaces the earlier proposed hidden-bash
-  response and option-5 parenthetical response examples.
-- Bash requests add a second line with at most 100 Unicode code points,
-  including a trailing ellipsis when truncated. Screen the whole command
-  before truncation. Recognized credential indicators suppress the entire
-  preview; explicit URLs and common bare domains are defanged. Native
-  execution and timeout enforcement remain unchanged.
-- Screening is conservative and best effort, not a guarantee against arbitrary
-  unknown secrets. Do not restore raw tool outputs or document-content notices.
-- `src/agent/progress-format.ts` defines a transport-independent structured
-  ProgressEvent and pure summarization, screening and text formatting functions.
-  The native observer creates safe request/response events; iMessage is the
-  current plain-text adapter. Future apps can render event fields and reuse
-  the safety functions without parsing iMessage text or copying its lifecycle.
-- The event retains the native name internally, allowing app rendering and
-  response formatting, even though request text omits it. Raw command strings
-  do not belong in exported progress events; only screened previews do.
-- No app transport, new scheduler, listener, database or delivery replay is
-  introduced in this change. A future app connection must wire its own
-  delivery/receipt policy explicitly.
-
-**Verification.** Isolated regressions cover the request/response event format,
-all-request name omission, native command execution/failure, preview length and
-Unicode, screening before truncation, credential suppression, URL defanging,
-child attribution, unknown receipts and no restart replay.

package/docs/adr/0026-inline-command-only-requests.md

@@ -1,16 +0,0 @@
-# 0026. Inline command-only requests
-
-Status: accepted (owner specified `bash: <command>` and a 50-character limit on 2026-10-05)
-
-Supersedes the request-name omission, second-line preview and 100-character
-limit in ADR 0025. Preserve shared ProgressEvent data, screening, native
-execution, ownership, response formatting and receipt/recovery rules.
-
-**Example.** `→ [tool] bash: printf hi`, then `✓ [tool] bash (0.8s)`.
-Other tools retain the screenshot format, e.g. `→ [tool] read: path=/tmp/a.jpg`.
-
-**Decision.** Requests show native name and safe arguments inline. Bash uses
-only its screened command preview, not purpose/description text. The preview
-is at most 50 Unicode code points including an ellipsis when truncated.
-Screen the entire original command before truncation. No actual execution
-limit or output handling changes. Response notices remain unchanged.

package/docs/adr/0027-command-preview-width.md

@@ -1,10 +0,0 @@
-# 0027. Modest command preview width
-
-Status: accepted (owner delegated a slightly longer preview on 2026-10-05)
-
-Supersedes only ADR 0026's fixed 50-character width. The current default is
-80 Unicode code points, including a trailing ellipsis when truncated. This
-balances useful context with phone readability. Keep the same inline
-`→ [tool] bash: <screened command>` format and unchanged response notices.
-Whole-command screening still occurs before truncation; no purpose text,
-raw output, tool execution or channel architecture changes.

package/docs/adr/0028-command-preview-120.md

@@ -1,8 +0,0 @@
-# 0028. Use 120 characters for command previews
-
-Status: accepted (owner selected120 after viewing80/120/150/180 examples on 2026-10-05)
-
-Supersedes only ADR 0027's80-character default. Show at most120 Unicode code
-points in the command portion, including a trailing ellipsis when truncated.
-Retain the inline command-only request, existing response, whole-command
-screening before truncation and transport-independent event/formatter.

package/docs/adr/0030-shared-web-read-cache.md

@@ -1,33 +0,0 @@
-# 0030. Share a versioned web read cache
-
-Status: rejected (owner decided on 2026-10-06: a cold read takes about 40 ms, and every commit invalidated the cache anyway; the cache was removed)
-
-**Context.** The chat overview requests each conversation separately and repeats
-reads on refresh and navigation. Large native payloads include model-only data
-that the page never renders. Time-based caching would hide recent changes.
-
-**Decision.** Keep one bounded, process-local cache in `web/`, shared by pages
-and read-only APIs. Read through the owning Harness, never its storage files.
-Every non-empty Durable commit changes the native cache version. File-backed
-views validate inode, size and nanosecond modification/change timestamps on
-each access; enumerate memory namespaces on each request to detect additions
-and removals. Coalesce concurrent reads and recheck the version after loading;
-retry if it changed. Do not retain rejected reads or oversized results.
-
-Limit the cache to 128 entries and a 16 MiB serialized-size budget using
-least-recently-used eviction. This budget is not an exact JavaScript heap limit.
-Do not cache model health requests or resolved registry-dependent agent choices.
-
-Embed display-only chat data in the initial HTML and batch overview refreshes.
-Keep existing native data response shapes. SSE readiness includes a process and
-revision marker so the client can detect changes between HTML loading and stream
-attachment, without always fetching the initial view twice. Refreshes already
-in flight do not discard subsequent change notices.
-
-**Consequences.** Restart discards the cache. There is no second durable state,
-execution log, writer or model call. A response reflects versions checked while
-it is read; changes during network transit still require a later refresh. File
-freshness relies on filesystem metadata, not a fixed stale-data interval.
-
-**Rejected.** Browser-local copies as the shared cache, fixed cache TTLs,
-persistent materialized views, and rebuilding all page data on every commit.

package/docs/adr/0031-quiet-compaction-progress.md

@@ -1,32 +0,0 @@
-# 0031. Hide only six-hour compaction progress
-
-Status: proposed (owner clarified trigger-specific visibility on 2026-10-06)
-
-Narrows ADR 0020's compaction notices only for six-hour maintenance ticks.
-
-**Problem.** The six-hour timer emits `pi.compaction` progress into chat. The
-owner wants that timer quiet, but wants progress for manual `/compact` and
-automatic context-threshold/overflow compaction.
-
-**Example.** A timer tick sends neither a start nor completion notice. Manual
-`/compact` shows both notices and its command result. A native context-triggered
-compaction shows both notices.
-
-**Decision.** Track exact task IDs admitted by `compactChats` using process-local
-Harness-scoped state. Before a compaction admission notice, wait for in-flight
-timer admissions to resolve so the observer can classify the committed task
-before `compact()` has returned its ID. Suppress only a matching timer task's
-notice; without an admission notice its settlement also remains quiet. Consume
-the classification after observation. Do not mute an entire conversation or
-filter by native reason: both the timer and `/compact` use reason `manual`.
-
-Native manual, threshold and overflow task progress keeps its existing routing,
-receipts and settlement formatting. Timer execution, logs, six-hour cadence,
-manual command results and other progress are unchanged. Classification is not
-persisted because pre-start task progress is never replayed.
-
-**Verification.** An existing isolated faux-provider messaging regression with
-progress enabled checks timer admission/settlement create no notices or progress
-receipts, manual `/compact` shows progress and its result, and native tasks with
-threshold/overflow reasons retain both progress receipts. Existing tool and
-child-task progress regressions remain enabled.

package/docs/adr/0033-operator-scheduled-run.md

@@ -1,23 +0,0 @@
-# 0033. Explicit operator run at startup
-
-Status: proposed (owner requested one real Workplace English trial)
-
-**Problem.** A configured job cannot be exercised on demand through the read-only
-Web UI. Opening another Harness on the live workspace is unsafe.
-
-**Decision.** An authorized owning-service restart may pass
-`serve --run-scheduled JOB --request-id ID`. The existing owner admits one native
-background occurrence in the configured job's conversation, after installing its
-extension. It saves the request ID and task ID atomically; repeating that startup
-request returns the same task. Refuse missing/disabled jobs or another live
-occurrence. Do not alter the recurring task or its saved deadline.
-
-Normal startup without the flags remains unchanged. The local startup request
-is not stored in settings or installed into launchd. There is no new HTTP route,
-Web action button, alternate writer, polling worker or operating-system job.
-English still enforces the existing per-date card dedupe and learning policy;
-this is not permission to bypass a quota or replay an uncertain send.
-
-**Consequences.** This small operator entry requires a safe restart to trigger.
-It is deliberately not a general interactive scheduler-management API. A live
-trial can invoke the configured model and send its card, requiring owner consent.

package/docs/adr/0034-machine-local-schedule-time.md

@@ -1,36 +0,0 @@
-# 0034. Use the service machine's local time for schedules
-
-Status: proposed (owner requested the complete local-time change)
-
-**Problem.** Daily deadlines, learning dates and schedule history are hard-coded
-for Asia/Shanghai, even when the service runs on a machine in another timezone.
-
-**Example.** A daily 07:45 job on a New York machine should run at 07:45 there,
-including after a daylight-saving change, not at 07:45 Shanghai time.
-
-**Decision.**
-
-- Use the service process's local calendar for daily deadlines and learning dates.
-  By default this is the machine timezone; an explicit `TZ` environment override
-  is respected and retained by installation and routine restart.
-- Calculate the next daily slot by calendar date, not by adding 24 hours. Use
-  JavaScript Date's local-time rules: nonexistent spring-forward times move
-  forward through the gap; repeated fall-back times select the first occurrence.
-- Include the service timezone in each configured job's read-only projection.
-  The Web UI formats deadlines and history in that timezone, not the browser's.
-- Retain saved absolute deadlines, occurrence dates, task IDs, learning history
-  and send receipts. The next computed slot uses local time. A timezone change
-  does not authorize regenerating cards, backfilling dates or replaying sends.
-- Six-hour compaction remains an elapsed-time interval, independent of timezone
-  and daylight-saving changes.
-
-This proposal supersedes only ADR 0032's fixed Asia/Shanghai calendar policy.
-All other scheduling, recovery and at-most-once delivery decisions remain intact.
-
-**Consequences.** Moving a deployment or changing `TZ` changes future calendar
-slots. An already saved deadline remains an absolute instant until processed;
-restart does not silently replace its checkpoint.
-
-**Rejected.** Changing only README text, hard-coded UTC offsets, adding 24 hours
-for calendar recurrence, using the browser timezone for server schedules, and
-rewriting production learning or receipt data.

package/docs/adr/0035-external-business-task-extensions.md

@@ -1,56 +0,0 @@
-# 0035. Workspace-owned business extensions
-
-Status: accepted
-
-**Problem.** Personal business logic, such as English learning, does not belong
-in the reusable messaging framework.
-
-**Example.** Changing a personal task should change a workspace extension, not
-framework scheduling, settings, prompts or Web code.
-
-**Decision.**
-
-- Put personal code and configuration in
-  `WORKING_DIR/extensions/<name>/index.ts` and `config.json`. Each native Durable
-  extension may provide tools, define multiple tasks and optionally schedule them.
-  Both the owner and chat assistant may create extensions; add no permission list
-  or extra confirmation gate.
-- Scan direct child directories at startup and on `/reload`. Reject duplicate
-  extension/task names. Validate before replacing definitions; failed reloads keep
-  the old definitions. Do not execute skills or attachments as extensions.
-- Keep generic daily/interval scheduling, non-overlapping execution, recovery,
-  outgoing queues, send receipts and read-only Web history in the framework.
-  Six-hour compaction remains built-in maintenance using the same components.
-  Durable owns persisted tasks and business state; there is no second pipeline.
-- Reload does not interrupt current calls. The next tool/task invocation uses
-  new code and configuration; do not proactively reset saved deadlines. Extensions
-  provide native migrations when saved task structures change.
-- Removing an extension stops future scheduling, not current calls, and retains
-  history, business data and receipts. Keep definitions needed by unfinished work
-  in memory; missing required task code on restart must fail explicitly.
-- Move English code and configuration into its workspace extension. Remove all
-  English-specific framework branches and personal job IDs. Preserve existing
-  settings, task IDs, checkpoints, deadlines, learning records and send IDs during
-  migration; never regenerate saved cards or replay uncertain sends. Verify with
-  faux models and temporary storage, then migrate under the single service owner
-  with source/configuration rollback copies.
-
-```mermaid
-sequenceDiagram
-    participant W as Workspace Extensions
-    participant S as Service
-    participant D as Durable
-
-    S->>W: Scan code and configuration
-    W-->>S: Tools, tasks and schedules
-    S->>D: Register or replace definitions
-    D->>D: Wait for the deadline
-    D->>W: Invoke task
-    W->>D: Persist state and results
-    D->>D: Save next deadline
-```
-
-**Consequences.** Workspace extensions are trusted code and need backup with their
-configuration. This is the target design, not an implementation claim. It replaces
-ADR 0032's embedded English logic; Durable ownership, at-most-once delivery and
-ADR 0034's machine-local time rules remain unchanged.

package/docs/adr/0036-workspace-policy-and-neutral-service-id.md

@@ -1,37 +0,0 @@
-# 0036. Workspace policy and a neutral service identity
-
-Status: accepted (owner accepted on 2026-10-06)
-
-**Problem.** A reusable message service should not hard-code an operator's system
-record layout, fallback model, billing tier or personal launchd identifier.
-
-**Example.** One workspace can explicitly retain its current fallback and priority
-tier, while another fails on an unavailable default rather than choosing a model
-or spending preference on the user's behalf.
-
-**Decision.**
-
-- Keep memory and the other shared native tools built in. ADR 0035 owns personal
-  business code and its scheduling configuration.
-- Move `SYSTEM.md` summary loading into an optional workspace extension; its
-  path, boundary and byte budget are configuration. Move system-record update
-  instructions into workspace `AGENTS.md`, not the framework prompt.
-- `settings.json.modelPolicy.fallback` optionally selects a provider/model pair.
-  An absent fallback fails explicitly when the selected default is unavailable.
-  Use only an available model with configured authentication.
-- `modelPolicy.codexServiceTier` optionally chooses `default` or `priority`.
-  Absence leaves the provider payload unchanged. Reload applies policy to future
-  requests; it does not interrupt existing calls.
-- Generate launchd jobs with neutral identity `org.pi-imessage.service`. Do not
-  silently rename a loaded controller or start another pipeline. Migrate an
-  installed personal-label job only under the operations handover procedure.
-- Existing configuration remains compatible. The offline migration preserves
-  unknown settings and explicitly records the prior fallback/tier, rather than
-  silently changing live model or cost behavior. It retains source/configuration
-  rollback copies and never rewrites Durable state.
-
-**Consequences.** The workspace owns and backs up its personal code and policy.
-New installations have no implicit fallback or priority preference. A foreground
-Terminal deployment needs no controller migration when no old-label job exists.
-This supersedes ADR 0004's hard-coded Codex fast wrapper choice only, not its
-native-extension or no-SDK-adapter decisions.

package/docs/adr/0037-restart-during-in-flight-work.md

@@ -1,30 +0,0 @@
-# 0037. Restart during in-flight work
-
-Status: accepted
-
-**Problem.** Routine deployment waits for an idle service. An active chat can keep
-the service busy for a long time, so a finished change stays undeployed.
-
-**Example.** A deployment waited while a chat ran a long model request. The owner
-restarted anyway: the old process exited in about one second and the new one
-resumed the same conversation, which continued its tool calls.
-
-**Decision.**
-
-- Do not wait for idle. Model generations, queued submissions, admitted scheduled
-  occurrences and imminent scheduler wakes do not defer a routine restart.
-  Durable owns their recovery, and saved deadlines are absolute.
-- Stop only at a moment when no tool is running and no message send is in
-  progress. Recheck immediately before stopping.
-- Stop with SIGTERM only. A shutdown timeout stops the deployment; never force-kill,
-  steal the lock or start a second pipeline.
-- Accept the recovery costs: an interrupted model request is sent again. A tool
-  that started anyway is not replayed; the model sees the interruption. A send
-  that started anyway becomes `unknown` and is never resent.
-- After startup, verify that interrupted work continues, and that send receipt
-  counts are unchanged apart from new sends.
-
-**Consequences.** Deployment no longer depends on chat activity. A restart may
-cost one repeated model request and delay a reply by a few seconds. This changes
-only the idle requirement in the routine restart procedure (`ops/README.md`);
-at-most-once delivery (ADR 0003) and the one-owner rule are unchanged.

package/docs/adr/0038-restart-any-time.md

@@ -1,25 +0,0 @@
-# 0038. Restart at any time
-
-Status: accepted (owner decided on 2026-10-06)
-
-**Problem.** ADR 0037 still waits for a moment with no running tool and no send
-in progress. That check adds a step and can still delay a deployment.
-
-**Example.** A chat runs a long bash command. Under ADR 0037 the deployment
-waits for it; under this decision the restart proceeds, and the model sees the
-interrupted command after recovery.
-
-**Decision.**
-
-- A routine restart may stop the service at any time. No task, tool, send or
-  scheduler state defers it.
-- Stop with SIGTERM only. A shutdown timeout stops the deployment; never
-  force-kill, steal the lock or start a second pipeline.
-- Recovery is Durable's: an interrupted model request is sent again, an
-  interrupted tool is not replayed, and an interrupted send becomes `unknown`
-  and is never resent.
-
-**Consequences.** A restart can lose one reply (left `unknown`) or leave a tool
-half-done for the model to check. This supersedes ADR 0037's stop-moment rule;
-its verification steps, at-most-once delivery (ADR 0003) and the one-owner rule
-remain.

package/docs/adr/0039-rerun-interrupted-tools.md

@@ -1,24 +0,0 @@
-# 0039. Rerun interrupted tools by default
-
-Status: accepted (owner decided on 2026-10-06)
-
-**Problem.** Durable reruns an interrupted tool only when the tool declares
-`replay: "safe"`; its default is `unsafe`. Bash, file edits, image reads and
-workspace tools therefore fail after a restart, although almost all of them can
-simply run again.
-
-**Example.** A restart interrupts `bash` listing a directory. Before, the model
-received "interrupted and may have partially run" and had to decide what to do;
-now the command runs again and the turn continues.
-
-**Decision.**
-
-- The host treats every tool without an explicit `replay` as `safe`, including
-  built-in, Durable and workspace extension tools.
-- A tool whose effect must not repeat declares `replay: "unsafe"`.
-- Replies and `send_message` keep at-most-once delivery through their own send
-  receipts (ADR 0003): a rerun never resends a `sending` or `unknown` message.
-
-**Consequences.** Restarts rarely surface interrupted tools to the model. A
-rerun tool may repeat a partial effect, such as appending to a file twice. This
-supersedes the interrupted-tool clause of ADR 0038.

package/docs/adr/0040-chat-progress-notices.md

@@ -1,44 +0,0 @@
-# 0040. Chat progress notices
-
-Status: accepted (owner accepted on 2026-10-06; consolidates ADRs 0020–0028 and 0031 without changing behavior)
-
-**Problem.** The current progress format is spread over ten ADRs that each
-replace a detail of the previous one.
-
-**Example.**
-
-```text
-→ [tool] bash: node search.mjs "Shanghai weather" --count 5
-✓ [tool] bash (0.8s)
-→ [subagent/tool] read: path=/tmp/a.jpg
-× [subagent/tool] read (0.1s)
-```
-
-**Decision.**
-
-- With `settings.json` `progressMessages: true`, observe native task admission
-  and settlement through Durable's commit subscription. No wrapper, polling or
-  second execution loop. `pi.generation` tasks are not reported.
-- Send one request notice at admission and one response notice at settlement,
-  to the owning reply-enabled chat. Child tasks follow Durable ownership and are
-  labelled with their parents, such as `[subagent/tool]`. Health and unrelated
-  ownerless conversations stay quiet.
-- Format: status marker first (`→` request, `✓` success, `×` anything else),
-  then `[parents/type]`, then the native name. Success requires a completed task
-  and a tool result without an error flag. Responses show elapsed time from
-  admission, including queueing.
-- Bash requests show the command inline, at most 120 Unicode code points. Screen
-  the whole command first: a credential indicator hides it, and URLs and common
-  domains are defanged so iMessage shows no link preview. Other tools show
-  bounded argument summaries; URLs show only a defanged hostname; timeouts are
-  omitted. Never show outputs, thinking, prompts or document contents.
-- Six-hour maintenance compaction is quiet. Manual `/compact` and Durable's
-  automatic threshold/overflow compactions are reported.
-- `src/agent/progress-format.ts` holds a transport-independent `ProgressEvent`
-  and pure formatting and screening functions; iMessage is one adapter.
-- Each notice uses a direct-send receipt keyed by task ID. Unknown sends are not
-  retried, and work admitted before startup is not replayed. Final replies wait
-  for queued notices first.
-
-**Consequences.** A busy turn sends many notices. Screening is best effort and
-cannot detect every secret. This supersedes ADRs 0020–0028 and 0031.

package/docs/adr/0041-restart-and-recovery.md

@@ -1,28 +0,0 @@
-# 0041. Restart and recovery
-
-Status: accepted (owner accepted on 2026-10-06; consolidates ADRs 0037–0039 without changing behavior)
-
-**Problem.** Restart rules are spread over three ADRs, each replacing part of
-the previous one.
-
-**Example.** A chat is running `bash` when a deployment restarts the service.
-The old process exits within seconds, the new one starts, the command runs
-again and the turn continues.
-
-**Decision.**
-
-- A routine restart may happen at any time; no task, tool, send or scheduler
-  state defers it.
-- Stop with SIGTERM only. A shutdown timeout stops the deployment; never
-  force-kill, steal the lock or start a second pipeline.
-- Durable recovers everything else. An interrupted model request is sent again.
-  A tool without an explicit `replay` reruns; a tool whose effect must not
-  repeat declares `replay: "unsafe"`.
-- Replies and `send_message` stay at most once (ADR 0003): an interrupted send
-  becomes `unknown` and is never resent.
-- After startup, verify that interrupted work continues and that receipt counts
-  change only by new and interrupted sends.
-
-**Consequences.** Deployment never waits for chat activity. A restart can cost
-one repeated model request, lose one reply or repeat a partial tool effect;
-the owner accepts these as rare. This supersedes ADRs 0037–0039.

package/docs/adr/0042-background-schedules-and-workspace-extensions.md

@@ -1,44 +0,0 @@
-# 0042. Background schedules and workspace extensions
-
-Status: accepted (owner accepted on 2026-10-06; consolidates ADRs 0019 and 0032–0035 without changing behavior)
-
-**Problem.** Scheduling was removed (0019), rebuilt natively (0032–0034) and
-then separated from personal business code (0035). The current rules are
-spread over five ADRs that partly contradict each other.
-
-**Example.** A daily 07:45 workspace task and six-hour compaction both keep
-their deadlines across a restart. Changing the task's code changes only
-`WORKING_DIR/extensions/<name>/`, not the framework.
-
-**Decision.**
-
-- **Retired services stay removed:** cron, reminders, delayed prompts,
-  completion watchers, PT Automation and HTTP `/prompt` / `/send`. Their
-  endpoints return 404; stored old data is kept but unused.
-- **Workspace extensions** hold personal code: `WORKING_DIR/extensions/<name>/`
-  with `index.ts` and `config.json`. Each is a trusted native Durable extension
-  with tools, tasks and optional schedules. The owner and the chat assistant
-  may both create them. Startup, `/reload` and `reload_extensions` scan direct
-  child directories. Duplicate names are rejected; a failed reload keeps the
-  old definitions; running calls keep their code.
-- **Framework scheduling** gives each schedule a dedicated conversation with a
-  background task whose checkpoint saves the absolute next deadline. Each
-  occurrence is a child task; occurrences never overlap. Daily slots run only
-  today's slot, without backfill; interval slots skip missed ticks. Six-hour
-  compaction uses the same mechanism and stays built in.
-- **Time** is the service machine's local timezone (or `TZ`). Daily slots are
-  computed by calendar date, so daylight-saving changes keep the wall-clock
-  time. Saved deadlines are never reset by reload, restart or timezone change.
-- **Delivery** commits business state and the outgoing item together. The host
-  sends through existing receipts at most once; `unknown` is never resent.
-- **Operator run:** `serve --run-scheduled JOB --request-id ID` admits one
-  occurrence at startup; repeating the same request ID returns the same task.
-- **History:** `/scheduled` shows each schedule, its deadline and the latest
-  ten occurrences from native task records. Viewing never starts work.
-- **Removal:** removing an extension stops future scheduling only. Unfinished
-  work keeps its code in memory; restart fails explicitly if required code is
-  missing.
-
-**Consequences.** The service must be running to act at a deadline. Workspace
-extensions are trusted code and need backup. This supersedes ADRs 0019 and
-0032–0035, and the scheduler clause of ADR 0013.

package/docs/adr/0043-remove-legacy-migration.md

@@ -1,23 +0,0 @@
-# 0043. Remove the legacy migration code
-
-Status: accepted (owner decided on 2026-10-06)
-
-**Problem.** The one-time cutover from the legacy service is done, but its code
-and runbook remain: `src/migrate/`, the `pi-imessage import` command, a test and
-`ops/CUTOVER.md`. Readers must learn a whole layer that will never run again.
-
-**Example.** A new contributor reads the package table, finds `migrate/` next to
-`main.ts`, and spends time on history import rules unrelated to any change.
-
-**Decision.**
-
-- Delete `src/migrate/`, the `import` CLI command, `test/migrate.test.ts` and
-  `ops/CUTOVER.md`.
-- Keep them reachable at the annotated tag `archive/legacy-migration`, the last
-  revision that contains them. A tag is fixed and runnable; a wiki copy is not.
-- The rule "never run old and new message pipelines concurrently" stays in
-  `AGENTS.md` and `ops/README.md`.
-
-**Consequences.** Imported history already lives in Durable storage and is
-unaffected. Rerunning a migration means checking out the tag in a separate
-worktree. This replaces ADRs 0005 and 0009, whose work is complete.

package/docs/adr/0044-message-channels.md

@@ -1,32 +0,0 @@
-# 0044. Organize message sources as channels
-
-Status: proposed
-
-**Problem.** `transport/` is iMessage-only: it polls `chat.db` and sends through
-Messages.app. A second message source, such as Telegram, has no place to go, and
-the name "transport" suggests a network layer. `transport/http.ts` is the shared
-outgoing HTTP client, not a message source.
-
-**Example.** Adding Telegram today would mean putting `telegram-watch.ts` beside
-`watch.ts`, while `agent/` imports `MessageSender` from the iMessage `send.ts`.
-
-**Decision.** Apply this when the second channel is implemented, not before
-(no abstraction until needed):
-
-- Rename `transport/` to `channels/`, with one directory per channel:
-  `channels/imessage/` (`watch.ts`, `send.ts`, `rich-text.ts`,
-  `attachments.ts`), `channels/telegram/`, and so on.
-- Put the shared contract in `channels/types.ts`: the incoming message shape and
-  `MessageSender`. `agent/` depends on this contract, never on one channel.
-- Move the process HTTP client (ADR 0016) out of the channel package, for example
-  to `config/` or a small `net/` package at the bottom layer.
-- Identify chats as `<channel>:<id>` for new channels. Existing iMessage chat
-  GUIDs stay unchanged, so `settings.json` allowlists and Durable `Chats`
-  records remain valid.
-
-**Consequences.** One rename and an import update when the second channel
-arrives; until then the code stays as it is. The layer rule (ADR 0002) is
-unchanged: channels stay below `agent/` and contain no agent logic.
-
-**Rejected.** A generic plugin loader for channels: there is one real channel
-today, and workspace extensions (ADR 0042) already cover tool plugins.

package/docs/adr/0045-chat-scheduling-tools.md

@@ -1,51 +0,0 @@
-# 0045. Native chat scheduling tools
-
-Status: proposed
-
-**Problem.** A simple deferred chat request currently requires the assistant to
-write a trusted workspace extension and reload it. That is useful for reusable
-business code, but unnecessarily complex for an ordinary reminder or agent task.
-
-**Example.** In iMessage, "remind me in ten minutes" should create a task through
-`schedule_task`, just as it does in the coding agent. "Every day at 09:00,
-summarize new items" should not require generated TypeScript either.
-
-**Decision.**
-
-- Add built-in `schedule_task`, `list_scheduled_tasks` and
-  `cancel_scheduled_task` tools for chat conversations. The scheduling tool takes
-  a time and a prompt, with optional explicit daily or interval repetition.
-  Support durations, clock times and absolute datetimes; do not add a cron parser.
-- Bind each task to its originating chat in host code. List and cancellation
-  operate only on that chat's interactive schedules, never framework maintenance
-  or workspace extension schedules. Return a stable ID and the actual deadline.
-- Use native Durable background tasks and documents in the existing owning
-  service. Creation must be atomic and deduplicated by the scheduling tool call;
-  interruption must not create a second schedule. Persist absolute deadlines,
-  configuration and cancellation. No detached timer, operating-system scheduler,
-  legacy job files, HTTP prompt/send endpoint or second pipeline.
-- Execute each occurrence in a fresh isolated agent conversation with the
-  normal authorized tools. Send its final result back to the originating chat
-  through the existing at-most-once receipts and passive chat records, without
-  steering an unrelated active chat turn. A scheduled prompt is a saved user
-  request, not a system instruction.
-- Recurring occurrences never overlap and skip missed slots. One-shot tasks
-  execute once when overdue, including after restart. Cancellation prevents
-  future admission; it does not undo an already admitted occurrence or resend
-  uncertain effects. Keep existing restart recovery and unknown-send safeguards.
-- Use the service machine's timezone, including explicit `TZ`, and expose native
-  deadlines and occurrence records on the existing read-only Scheduled page.
-  The service must be running to execute work; persistence does not wake a
-  stopped service or machine.
-- Keep workspace extensions for reusable business tools and tasks. Existing
-  extension schedules and six-hour compaction retain their IDs, deadlines and
-  behavior. Reload must not disable or reset interactive schedules.
-- Replace the chat prompt's extension-writing requirement for ordinary scheduled
-  work with brief instructions to use these tools. Do not remove unrelated chat
-  steering or delivery safeguards.
-
-**Consequences.** This deliberately replaces ADR 0042's retirement of ordinary
-reminders and delayed agent prompts, but not its retired external services or
-workspace extension contract. It also replaces that clause of ADR 0018. It is a
-small native management interface over Durable, not a return to the old cron
-service. Implementation follows owner acceptance; accepted ADRs stay unchanged.