@kingcrab/pi-imessage 0.0.43 → 1.1.0

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

@@ -0,0 +1,32 @@
+# 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/0032-native-background-schedules.md

@@ -0,0 +1,58 @@
+# 0032. Native background schedules and read-only execution history
+
+Status: proposed (owner requested native scheduling, compact migration and Web history)
+
+**Problem.** The retired scheduler called HTTP `/prompt`, which no longer exists.
+The six-hour maintenance `setInterval` also loses its next deadline on restart.
+
+**Example.** Restart at 07:40 must retain tomorrow's English deadline and the
+maintenance deadline, without starting another message pipeline or recreating
+uncertain sends. A Web refresh must show both jobs without invoking a model.
+
+**Decision.**
+
+- Register one Durable scheduling extension in the agent layer. Each configured
+  job has a dedicated ownerless conversation and a conversation-owned task with
+  `background: true`. Its saved `sleep` checkpoint contains the absolute next
+  deadline. `runtime.sleep()` is an invocation-local wait, not a persisted timer.
+- An occurrence is a child task admitted atomically with the scheduler's waiting
+  checkpoint. Join with `allSettled`, then compute the next deadline, including
+  after generation failure. Native task records are the execution history; there
+  is no separate host worker database or UI execution log.
+- Support exactly six-hour chat compaction and the explicitly configured daily
+  English card. Keep native compaction, its quiet maintenance progress routing,
+  and automatic/manual compaction behavior. No arbitrary cron parser or LLM
+  scheduling tools. Do not revive legacy job files, HTTP prompt/send, reminders,
+  background completion watchers or PT Automation.
+- Daily English uses Asia/Shanghai calendar deadlines. A late start processes
+  only the current day after its scheduled time; missed days are not backfilled.
+  Compaction processes one overdue tick and skips missed interval slots. Long
+  executions never overlap themselves. Configuration is read at startup; existing
+  saved deadlines remain, with changed cadence applied to the following slot.
+- Import the configured English `used.json` once, read-only, preserving unknown
+  fields. Durable owns subsequent learning progress. Code selects due reviews
+  and enforces the existing three-expression daily limit and new-learning quota;
+  a tool-less, isolated model conversation provides wording, never updates files
+  or sends. Commit learning changes, the actual card and its outbox together.
+  Per-date card records and stable submission/request IDs prevent regeneration.
+- Deliver the outbox using existing direct-send receipts and passive chat records.
+  Sending is not transactional with Messages.app. `sending` becomes `unknown` on
+  restart; uncertain or previously accepted sends are not automatically replayed.
+  Stored learning progress means generated/displayed content, not proof of delivery.
+- `/scheduled` and `/scheduled/data` show all native configured schedules, their
+  task state/deadline, per-job latest ten occurrence tasks, and the latest ten
+  across all jobs. Show generation result separately from delivery receipt. These
+  are read-only routes; viewing them never resumes tasks or starts inference.
+
+This proposal supersedes ADR 0013's rejection of native recurring task adapters
+and ADR 0019's removal of these two scheduling features only. Other retired
+features and at-most-once transport safeguards remain unchanged.
+
+**Consequences.** The service must be running to act at a deadline. Stored
+checkpoints recover execution but cannot wake a stopped machine or process.
+Schedules remain independent of chat abort/reset. Explicitly aborting their task
+pauses them; startup does not silently recreate a terminal scheduler.
+
+**Rejected.** An external cron daemon, a second message pipeline, restoring
+`/prompt`, a timer that reschedules from each process startup, asking the model
+to remember to schedule tomorrow, and claiming exactly-once external delivery.

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

@@ -0,0 +1,23 @@
+# 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

@@ -0,0 +1,36 @@
+# 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

@@ -0,0 +1,56 @@
+# 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

@@ -0,0 +1,37 @@
+# 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

@@ -0,0 +1,30 @@
+# 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

@@ -0,0 +1,25 @@
+# 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

@@ -0,0 +1,24 @@
+# 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

@@ -0,0 +1,44 @@
+# 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

@@ -0,0 +1,28 @@
+# 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

@@ -0,0 +1,44 @@
+# 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

@@ -0,0 +1,23 @@
+# 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

@@ -0,0 +1,32 @@
+# 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

@@ -0,0 +1,51 @@
+# 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.

package/docs/adr/0046-selective-command-redaction.md

@@ -0,0 +1,31 @@
+# 0046. Selective command-preview redaction
+
+Status: proposed (owner requested `***` value masking on 2026-10-06; implementation tracked in #36)
+
+Supersedes only ADR 0040's whole-command credential suppression rule.
+
+**Problem.** A mention of `token`, `password`, `.env` or `auth.json` hides the
+entire command, even when it is just a source search or filename.
+
+**Example.** `TOKEN=demo123 curl --retry 3` becomes
+`→ [tool] bash: TOKEN=*** curl --retry 3`. `rg 'token' src` remains readable.
+
+**Decision.** Replace recognized credential values with `***`, retaining the
+surrounding command instead of a hidden-command placeholder. Cover sensitive
+assignments, options, authorization headers, URL userinfo, structured values,
+known credential prefixes and PEM private-key blocks. Read complete shell words,
+including quoted fragments, escaped spaces and command substitutions. Opaque
+escaped JSON and ambiguous substitutions may lose additional argument text to
+avoid showing a partial credential. Filenames and keyword mentions alone do not
+trigger hiding. Screening remains best effort, not an arbitrary-secret guarantee.
+
+Apply masking to the full command before whitespace normalization, URL/domain
+defanging and the existing 120-Unicode-code-point bound. Native execution,
+non-bash summaries, progress ownership, settlement and durable receipts remain
+unchanged. No new scheduler, pipeline, tool execution or delivery replay.
+
+**Verification.** Extend the existing isolated messaging regression with exact
+preview examples, quote/escape cases, structured credentials, line continuations,
+substitutions, known prefixes, private keys, keyword-only searches and masking
+before truncation. Existing native execution, ownership and uncertain-send
+regressions remain in force.