@kingcrab/pi-imessage 1.1.1 → 1.2.0

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

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

package/docs/adr/0047-one-scheduling-path.md

@@ -1,158 +0,0 @@
-# 0047. One scheduling path for recurring and one-off work
-
-Status: accepted (owner requested the minimal implementation on 2026-10-06)
-
-## Problem
-
-Recurring workspace jobs currently enter through a native scheduler task, while
-`serve --run-scheduled JOB --request-id ID` calls `runOnce()` and creates an
-occurrence directly. Both use Durable, but admission follows two paths, and a
-manual trial requires a service restart.
-
-Calling all work "scheduled" is not sufficient. The common path must own deadline
-persistence, deduplication and non-overlap. A trial must also retain the original
-job's business state, rather than create an empty English learning history or
-bypass the monthly quota.
-
-## Example
-
-Workplace English has a daily 07:45 trigger. An operator requests one trial now.
-The trial receives its own stable trigger ID, but targets the existing English
-job and business conversation. Reloading twice does not run it twice, and the
-regular 07:45 deadline does not move. Existing per-date card deduplication still
-applies: a trial is not permission to resend today's card.
-
-## Evaluation
-
-- **One common scheduling path:** recommended. Recurrence and an immediate trial
-  differ in their deadlines and repetition, not their executor or delivery path.
-- **One physical configuration file:** unnecessary. Keep trusted business code
-  and configuration in the workspace extensions required by ADR 0042. Their
-  declarations pass through one framework admission function.
-- **Automatic configuration polling:** unnecessary for the first version. The
-  existing `reload_extensions` tool and `/reload` already apply configuration
-  through the owning service without restart. Polling would add partial-write,
-  repeated-load and failure-handling concerns without helping deadline execution.
-- **A local CLI/socket or HTTP run API:** unnecessary here. A trial can be a
-  one-off declaration followed by the existing reload. This trades one explicit
-  reload operation for avoiding another control protocol.
-- **A separate business executor for every cadence:** rejected. Reminder,
-  script and model workflows remain native business tasks; they do not become
-  separate schedulers.
-
-## Decision
-
-### One admission and execution path
-
-```text
-Workspace extension configuration
-                |
-      startup / reload_extensions / /reload
-                |
-       validate and register triggers
-                |
-       native background Scheduler task
-                |
-       sleep(persisted absolute deadline)
-                |
-       native occurrence wrapper
-                |
-       registered native business task
-                |
-       native receipts -> read-only Scheduled Web
-                |
-       optional outbox -> existing send receipts
-```
-
-The reload commands are configuration-loading entry points, not direct execution
-paths. No file edit alone invokes business work. An immediate trial becomes due
-once its declaration has been accepted; it is not a promise of zero latency.
-The service must be running, and publication of validated code/configuration must
-complete before newly due work can execute under that definition.
-
-The framework retains one owning Harness. Do not introduce another daemon,
-operating-system timer, SDK scheduler bridge, database, or polling watcher.
-
-### Job identity and trigger identity
-
-- A **job** names registered business code, input, destination and its existing
-  business conversation/state. It is not an arbitrary command or prompt supplied
-  by a new public execution API.
-- A **trigger** names when that job is eligible to run. Recurring triggers and
-  one-off triggers use the same registration function and scheduler definition.
-- The minimal version preserves elapsed-time intervals and one local daily slot,
-  and adds a one-off absolute deadline or `now`. Multiple daily slots and monthly
-  calendars are deferred, not part of this first change. Do not add a cron parser.
-- Resolve `now` to an absolute timestamp once, in the admission transaction.
-  Persist the stable trigger ID, target job and deadline together. Subsequent
-  reloads/restarts recover that trigger, including a terminal one; they never
-  reevaluate `now`. A new intended trial needs a new trigger ID. Conflicting reuse
-  of a one-off ID fails explicitly.
-- A one-off declaration targets an existing registered job. Do not give it a
-  fresh business conversation, reset learning/checkpoints, or change the regular
-  trigger's deadline. A workspace extension must provide this declarative trial
-  binding; trial requests do not require generating a new extension per run.
-- Enforce non-overlap by target job, not merely by trigger. A due one-off can wait
-  for that job's active occurrence, then admit its own occurrence. Do not report
-  another trigger's work as completion of the new request.
-- Commit occurrence admission and the scheduler checkpoint together. A one-off
-  scheduler becomes terminal after its occurrence; a recurring scheduler saves
-  the next deadline. Failures remain visible in native occurrence records.
-
-### Recovery, reload and delivery
-
-- Preserve ADR 0042's machine-local calendar/DST rules, saved absolute deadlines,
-  daily/interval overdue behavior and lack of historical backfill. A one-off
-  admitted before shutdown runs once when overdue after restart.
-- Load and validate a complete candidate before accepting declarations. A failed
-  reload leaves old definitions and schedules active and must not start a trial.
-  Reload does not interrupt existing business calls. Pausing/removing a declaration
-  prevents future admission, not undoing already admitted effects.
-- Use native task versions/migrations where persisted structures change. Preserve
-  existing job/conversation/task IDs, learning state, checkpoints, execution
-  history and delivery receipts. Do not recreate terminal trials on startup.
-- Business tasks keep their own replay and success policy under ADR 0041. A shared
-  clock does not make a script's external effects transactional or replay-safe.
-  Reflection advances its checkpoint and starts backup only after verified success.
-- Keep the existing outgoing queue and at-most-once transport receipts. An
-  interrupted send becomes `unknown` and is not automatically resent. One-off
-  execution does not override a business quota, per-date dedupe or a send receipt.
-- Reuse the compact Scheduled page and native occurrence history. Show one-off
-  executions under their target job, with links to their Task tree. Viewing the
-  page starts no work; add no execution buttons.
-
-### Entry points removed or deferred
-
-After the unified one-off path is available, remove the operator startup-run
-flags and the direct-occurrence `runOnce()` bypass. Keep their historical request
-and execution records; do not replay them during migration. Do not add a CLI or
-Unix socket replacement.
-
-ADR 0045 remains a separate proposal about chat scheduling tools. This ADR does
-not enable or reject those tools. If accepted, their declarations must use this
-same admission/clock/occurrence path, preserve chat ownership boundaries, and
-must not introduce another scheduler or call a business executor directly.
-
-## Scope and consequences
-
-Framework changes concern the schedule declaration contract, common admission,
-calendar calculation, scheduler lifecycle and removal of the operator bypass.
-Personal messages, weather/news logic, memory updates, photo-date checks and
-Reflection remain workspace extensions, not framework-specific branches.
-
-Restoring the selected legacy jobs uses this path. Stop only their competing old
-cron producers during the authorized cutover; do not disable unrelated system
-jobs. Fixed-message business tasks do not restore the retired reminder service,
-PT workers or HTTP `/prompt` / `/send`. No restoration or migration is performed
-by accepting a file reload alone
-unless those jobs are explicitly declared.
-
-The first version requires an explicit reload after editing configuration. This
-is intentional: it avoids a new watcher and a new management service. Persistence
-cannot wake a stopped process or machine. Exactly-once external delivery is not
-claimed.
-
-This supersedes only ADR 0042's operator-run clause (which
-consolidated ADR 0033), and extends its cadence/declaration contract. Its workspace
-ownership, recovery and delivery rules remain in force. Accepted ADRs stay
-unchanged.

package/docs/adr/0048-quiet-attachment-reads.md

@@ -1,11 +0,0 @@
-# 0048. Quiet attachment reads
-
-Status: proposed (owner-requested behavior in #38, 2026-10-07)
-
-**Problem.** Reading an archived attachment adds noisy tool notices containing long private archive paths.
-
-**Example.** A native `read` of `WORKING_DIR/attachments/<chat>/<file>` produces no request or completion notice. An ordinary file read still shows the existing progress pair.
-
-**Decision.** Add a narrow exception to ADR 0040's all-tool progress rule: suppress both admission and settlement notices for native `read` calls under the active workspace attachment root, including owned child calls and failed reads. Normalize relative, home, @ and file-URL paths and resolve filesystem aliases using metadata only. Match directory boundaries, not a generic attachment substring. Other reads, tools, task progress, manual compaction and final replies remain unchanged.
-
-The existing native observer filters before assigning notice routing or making direct-send receipts. Execution, result/error history, receipt/no-replay rules and the single pipeline are unchanged. No new poller, sender, permission boundary, data removal or credential policy is introduced.

package/docs/adr/0049-per-chat-progress-notices.md

@@ -1,21 +0,0 @@
-# 0049. Per-chat progress notices
-
-Status: proposed (owner-requested implementation, 2026-10-24)
-
-**Problem.** `progressMessages` in `settings.json` turns tool progress notices on or off for every chat at once. A busy group wants only the final messages while an admin chat wants to watch the tools.
-
-**Example.**
-
-```text
-/verbose            -> Verbose: on (default)
-/verbose off        -> Verbose: off (this chat only)
-/verbose default    -> Verbose: on (default)
-```
-
-**Decision.**
-
-- Each chat record in the native `imessage.chats` document gets an optional `progress` boolean. `/verbose on|off` sets it and `/verbose default` removes it; `/verbose` alone reports the effective state. The record version is unchanged; old records have no field.
-- The progress observer (ADR 0040) resolves the owning chat first and then gates both the admission and the settlement notice by `chat.progress ?? settings.progressMessages`. Reply-enabled allowlisting, formatting, screening, receipts and no-replay rules are unchanged.
-- `settings.json` stays the default and is never rewritten by a command; the per-chat choice lives only in Durable.
-
-**Consequences.** A `/verbose off` chat still runs tools and records their results; it only stops seeing the two notice lines. Child notices follow the owning chat's choice. Changing the global default does not touch chats with an explicit choice.

package/docs/adr/0052-host-owned-self-restart.md

@@ -1,53 +0,0 @@
-# 0052. The host owns its own restart
-
-Status: accepted (owner accepted on 2026-10-24)
-
-**Problem.** A chat assistant restarts the service by writing a controller
-script and running it from a `bash` tool call. The host cannot tell that this
-call is about to stop it. When the call is still running at the stop, ADR 0041
-reruns it on the next start, which launches another controller and stops the
-service again (#39: about 70 restarts in eleven minutes). A host-side stop
-heuristic that aborts a tool interrupted twice in a row was tried the same
-day; it limits the damage after the fact, does not remove the cause, and
-aborts any long tool that two deployments happen to interrupt in a row.
-
-**Example.**
-
-```text
-restart_service({ release: "d627232…" })
--> Restart into /Users/clawbot/pi-imessage-releases/d627232… is scheduled;
-   the service stops after this call settles. Controller directory:
-   /tmp/pi-imessage-restart.Xy12ab. Verify in a later call.
-```
-
-The call settles, the host opens the controller in Terminal, the controller
-stops the old process and becomes the new one. The next turn verifies the
-listener, the log and the running release directory.
-
-**Decision.**
-
-- A built-in `restart_service` tool takes the full commit hash of a prepared
-  release directory, a sibling of the running one. It refuses a hash that is not
-  a directory with `src/cli.ts`, `node_modules` and `ops/restart.command`, and
-  a second request while one is scheduled.
-- The tool writes the private controller directory of ops/README.md step 3
-  itself: `environment.sh` from the process environment, `control.sh` from the
-  process's own PID, start time and command line, and a copy of
-  `ops/restart.command` from the target release. The controller deletes
-  `environment.sh` after sourcing it.
-- The tool returns at once. The host launches the controller only after the
-  tool task has settled, so the stop can never interrupt the call that asked
-  for it.
-- The tool is `replay: "unsafe"`. If it is interrupted anyway, the model gets
-  an interrupted result and checks what is running instead of a rerun
-  launching a second controller.
-- Ordinary tools keep the rerun default of ADR 0041. Operators keep the manual
-  procedure for a cold start when no service is running.
-
-**Consequences.** A self-restart costs one restart and no extra model turn.
-The stop still happens at a tool boundary of the requesting chat, so that chat's
-next model request is repeated after the restart, as ADR 0041 accepts. The
-restart loop of #39 cannot recur through this tool, so the stop heuristic is
-removed and ADR 0041 applies unchanged to every other tool. A chat that writes
-its own controller through `bash` is still subject to the ops rule of ending
-the call right after `open`.

package/docs/adr/0053-service-log-errors.md

@@ -1,44 +0,0 @@
-# 0053. Service-log errors for failures that break normal operation
-
-Status: proposed
-
-**Problem.** Durable records every task outcome, but only in its storage.
-`service.log` shows startup, sends and a few delivery warnings. On 2026-10-25
-the nightly memory reflection failed three times because the model child had
-exhausted a provider quota; the process, the port and the root HTTP check
-looked healthy and `service.log` had no line about it. The failure was only
-visible by reading `durable/main.jsonl` or by a chat notice that was deduped.
-
-**Example.**
-
-```text
-2026-10-25T00:14:48.924Z Model call failed {
-  kind: 'pi.generation', task: 183434, conversation: 183426, status: 'failed',
-  provider: 'openai-codex', model: 'gpt-6.1-sol',
-  reason: 'You have hit your ChatGPT usage limit (plus plan). Try again in ~291 min.'
-}
-```
-
-**Decision.**
-
-- `service.log` gets a `console.error` line with an ISO timestamp for a failure
-  that breaks normal operation. A failure qualifies when either holds: a chat
-  or scheduled job does not get the result it was waiting for, or the system
-  enters a state that needs an operator. Transient errors that recover on
-  their own, such as a retried provider error or a delivery whose status is
-  later confirmed, do not qualify.
-- One module, `src/agent/error-log.ts`, owns these lines. It observes Durable
-  commits synchronously and never calls Session APIs. Each error kind is one
-  branch with its own message name; adding a kind states which of the two
-  conditions it meets.
-- The first kind is a model call that ends `failed` or `faulted`: the line
-  carries the task, conversation, provider, model and the reason truncated to
-  200 characters. It carries no prompt, tool argument or input content.
-- Other task kinds, including scheduled jobs that fault, are not logged yet;
-  they are added under the same conditions when needed.
-
-**Consequences.** A quota, auth or provider outage is visible in the service
-log within the same commit that records it, so a health check that reads the
-log catches it without a paid model probe. The web `/logs` page shows the same
-lines. Durable records remain the full source of truth; the log is a pointer
-to them, not a replacement.

package/ops/README.md

@@ -1,250 +0,0 @@
-# Operations: installation, deployment and restart
-
-The owner has authorized deployment after each completed change, including
-verification, plus committing and pushing each completed intended project change
-after the required checks. Do not ask again for routine deployment or commit/push
-approval in that scope. Stage explicit intended paths; exclude unrelated drafts,
-temporary files and credentials. Verify the pushed remote revision; stop on a
-rejected push, never force push. This does not authorize paid probes, test messages,
-data cleanup or unrelated service changes. Stop for a new material safety or
-data-integrity risk.
-Never run old/new pipelines concurrently or use production data in tests.
-Implementation readiness and open decisions are tracked in GitHub #33.
-
-For ordinary updates, use [Routine deployment and restart](#routine-deployment-and-restart).
-The one-time legacy migration is archived at tag `archive/legacy-migration` (ADR 0043).
-
-## Prerequisites
-
-- macOS, Node >=22.22.2, Python 3 and authenticated Pi models.
-- Terminal/Node Full Disk Access for Messages' SQLite database; Automation and
-  Accessibility permissions for Messages.app/rich-text sends; `/usr/bin/sips`.
-- The existing memory CLI at `WORKING_DIR/skills/file-memory/memory_cli.py`.
-- The installed `pi-browser` CLI and its pinned Playwright runtime. Run
-  `pi-browser setup` when needed and authorized; preflight never installs it. Preflight
-  resolves the wrapper in Pi's agent `bin/`, or a preflight-only
-  `PI_BROWSER_CLI_PATH` override, and runs `--version` with temporary browser state
-  that is removed afterward. A wrapper whose `doctor` reports MISSING is not ready.
-  Version readiness does not prove browser privacy, login or per-chat isolation.
-- Reviewed native SQLite and image dependencies. Install dependencies with
-  `npm ci --ignore-scripts`; if native binaries are missing, review and approve
-  their build/download separately rather than silently enabling install scripts.
-
-Safe local checks (no live models/messages/workspace):
-
-```sh
-npm run check
-npm test
-node --experimental-strip-types ops/preflight.mjs
-node --experimental-strip-types src/cli.ts --help
-```
-
-For changes to the built-in browser, also run
-`node --experimental-strip-types ops/browser-smoke.mjs`. This uses real headless
-Chrome and the installed pinned CLI with temporary HOME/profiles, loopback pages
-and synthetic login state; it never opens a personal profile or sends a message.
-See [browser isolation and retention](../docs/browser.md).
-
-`WORKING_DIR`, `WEB_HOST`, `WEB_PORT`, `WEB_ENABLED` and `MESSAGES_DB_PATH`
-are explicit host configuration. `npm start`, the
-executable CLI and the generated launchd job enable Node's environment proxy
-support. `HTTP_PROXY`, `HTTPS_PROXY`, `NO_PROXY` (and their lowercase forms) and
-`NODE_OPTIONS` are retained when generating the job; review them before install.
-CLI execution loads the current directory's `.env` using Node's parser; existing
-environment values take precedence and a missing file is allowed. Set
-`DOTENV_CONFIG_PATH` for another file. Module imports and `--help` do not load it.
-Other read errors stop startup without printing file contents. `.env` is trusted
-operator configuration, not a message attachment. Keep it private and out of Git.
-Installation pins its current directory as the job's working directory, so the
-same configuration path is used at launch. Selected environment values in the
-plist are a snapshot; regenerate a reviewed job to change those overrides.
-The job also pins the selected Pi agent directory as an absolute
-`PI_CODING_AGENT_DIR` (including the default). Relative paths and `~` are resolved
-at installation, after `.env` loading, so daemon HOME/cwd changes do not select a
-different auth.json, models.json, settings.json or skill root. This selects a
-configuration location; it does not copy credentials or grant access to it.
-
-No proxy credentials are printed by installation. Application startup configures
-one process-owned Undici transport after `.env` loading and before model/auth
-refresh. Global Pi `httpProxy` supplies HTTP/HTTPS defaults; explicit environment
-values win, lowercase proxy/bypass values take precedence, and `NO_PROXY` is
-honored. Project-local `httpProxy` is ignored. `/reload` applies changed settings
-for subsequent requests while old clients drain active requests. Shutdown stops
-messaging and Harness work before releasing owned HTTP resources. Standalone
-callers with injected runtimes retain transport control; deliberate fetch
-overrides and dispatchers owned by other callers are not replaced on cleanup.
-
-Pi settings in the agent directory and `WORKING_DIR/.pi/settings.json` supply
-request policy; `/reload` refreshes it. `retry.provider.timeoutMs` overrides the
-provider request timeout, otherwise `httpIdleTimeoutMs` supplies that default
-(300000 ms; 0 uses Pi's effectively unlimited value). This forwards a request
-option to supporting providers. Separately, application HTTP transport uses
-`httpIdleTimeoutMs` for native header/body inactivity timers; 0 disables those
-timers. An explicit provider request timeout can still limit a request when
-socket-idle timers are disabled. Provider retry limits/delay caps and `retry`
-generation policy are executed by Pi/Durable; transport remains SSE. These do
-not replace the old host activity timer, prompt maximum-duration or
-compaction-deadline behavior.
-
-Web defaults to localhost:7750 and has no authentication. Never expose it to
-untrusted networks.
-
-Lifecycle logs use ISO timestamps on stdout/stderr: application startup (PID,
-Node version and workspace), agent readiness/reload, the actual Web bind address
-or disabled state, messaging readiness (cursor and poll/compaction intervals),
-shutdown signal, resource cleanup and failures. Readiness is logged only after
-the corresponding initialization succeeds; it is not a model or delivery health
-check. Idle polls do not produce log lines. These lifecycle entries do not include
-message text, tool arguments or proxy/auth configuration.
-The generated launchd job redirects both streams to `WORKING_DIR/service.log`.
-Foreground runs use the terminal or the controller's selected redirection; the
-application does not open a second log file.
-
-## npm publishing
-
-The public package contains compiled JavaScript and Web assets, not a TypeScript
-executable under `node_modules`. `npm pack` builds through `prepack`;
-`npm run test:package` verifies the packed executable and inert installer in a
-temporary HOME/workspace without models or Messages.
-
-`.github/workflows/publish.yml` uses the existing npm trusted publisher with
-GitHub OIDC, Node 24 and `id-token: write`; no local npm login or token is needed.
-It runs the full checks, tests and package smoke before publishing with provenance.
-Future releases push a matching `v<package-version>` tag. To publish an existing
-version after fixing packaging, dispatch the workflow on main with that exact
-version; never move an already published GitHub tag.
-
-```sh
-gh workflow run publish.yml --ref main -f version=1.0.0
-```
-
-An installed npm service runs `dist/cli.js`; source deployments continue to use
-`src/cli.ts`. Package installation does not start or reload a service.
-
-## Service identity
-
-New `install` output uses `org.pi-imessage.service` and
-`org.pi-imessage.service.plist`. For an installed
-`me.changchen.pi-imessage-durable` job, privately preserve its plist/environment,
-gracefully stop and unload that exact controller, verify PID/lock/port release,
-then write and load the reviewed neutral job. Do not leave the old KeepAlive
-controller loaded or start a Terminal copy alongside launchd. A foreground
-Terminal service with no old-label job needs no controller change. Never rename
-unrelated legacy jobs as part of this migration.
-
-## Routine deployment and restart
-
-### Choose the smallest operation
-
-| Change | Action |
-|---|---|
-| Server, agent, transport or imported TypeScript | Restart from a new release directory; verify the change. |
-| Web `app.js` / `style.css` only | Verify the served assets; no restart (the file cache checks metadata). |
-| Documentation only | Commit and push; no reload or restart. |
-| Configuration supported by `/reload` | Reload; restart only for startup-only configuration. Never send an iMessage to trigger it. |
-
-Deploying means the change is live and verified, then committed and pushed.
-
-### Release directories
-
-The service runs a fixed commit, never the main checkout:
-
-```sh
-SHA=$(git -C /Users/clawbot/pi-imessage-next rev-parse origin/main)
-RELEASE=/Users/clawbot/pi-imessage-releases/$SHA
-git -C /Users/clawbot/pi-imessage-next worktree add --detach "$RELEASE" "$SHA"
-(cd "$RELEASE" && npm ci --ignore-scripts && node --experimental-strip-types ops/preflight.mjs)
-```
-
-Never edit a release directory; rollback is a routine restart from the previous
-one. Keep the latest three; remove older ones with `git worktree remove` (no
-`--force`) when no process or plist uses them. A release directory has no `.env`:
-set `DOTENV_CONFIG_PATH` to the main checkout's `.env`.
-
-### 1. Identify the running service
-
-```sh
-launchctl list | grep -Ei 'pi-imessage|pi-web' || true
-lsof -nP -iTCP:7750 -sTCP:LISTEN          # take PID from here, never from notes
-ps -p "$PID" -o pid,ppid,lstart,command
-lsof -a -p "$PID" -d cwd,1,2 -Fn
-```
-
-The claw baseline is a **Terminal foreground process** (not launchd) running from
-a release directory, with `WORKING_DIR=~/.pi/imessage-next`,
-`PI_CODING_AGENT_DIR=~/.pi/agent`, Node 22, logs in `WORKING_DIR/service.log`, and
-the owner-selected unauthenticated bind `0.0.0.0:7750` (trusted networks only).
-A similarly named Pi web job does not control this service. Do not switch
-controllers, install launchd or upgrade Node during a routine restart.
-
-### 2. Record the baseline (ADR 0038)
-
-Restart at any time; no running work defers it. Before stopping, record the
-counts of `sending` / `unknown` receipts from `/chat/data` (counts only, no chat
-text). Never reset cursors, delete state or replay uncertain sends. Do not use
-`/health/model`: it is a paid request.
-
-### 3. Run one private controller
-
-From a chat, the assistant calls `restart_service` with the full commit hash of
-the prepared release directory (ADR 0052). The host writes the controller
-directory below itself and opens the controller only after that tool call has
-settled; the call returns the directory and the next call verifies (step 4).
-The manual procedure below is for operators and for a cold start when no
-service is running.
-
-In a `mktemp -d /tmp/pi-imessage-restart.XXXXXX` directory with `umask 077`:
-
-- `environment.sh`: shell-quoted exports of the running process's `WORKING_DIR`,
-  `PI_CODING_AGENT_DIR`, `DOTENV_CONFIG_PATH`, Web/DB overrides, proxy variables
-  (both cases), `NODE_OPTIONS`, search keys, HOME, locale, `TZ` and PATH (keep
-  `~/.pi/agent/bin` and the Node directory). Write it directly; never print
-  values, `ps eww` output or credentials.
-- `control.sh`: shell-quoted `OLD_PID`, `OLD_STARTED` (exact `ps -o lstart=`),
-  `EXPECTED_COMMAND`, `REPO` (the release directory), `NODE`, `WORKING_DIR`,
-  `WEB_PORT` and `LOG_FILE`.
-- `restart.command`: a copy of [`ops/restart.command`](restart.command) from the
-  release directory. It checks the old PID's start time and command, sends
-  SIGTERM, waits up to 30 s, refuses to start while the lock or port is held,
-  writes `controller.log` and `new.pid`, deletes `environment.sh` and then
-  `exec`s the new service process.
-
-Launch it once with `chmod 700` and `open -a Terminal "$DEPLOY_DIR/restart.command"`
-(`osascript` `do script` times out on claw). The separate Terminal keeps the
-controller alive when the initiating agent's own turn is interrupted. For a
-launchd controller, use that job's lifecycle instead; never `launchctl kickstart -k`
-from inside the service.
-
-A chat that writes its own controller through `bash` instead of
-`restart_service` must end that call right after `open`: no `sleep`, polling or
-verification in the same call. Tools are replay-safe by default (ADR 0041), so a
-call still running when the controller stops the service reruns on every start,
-launches another controller and loops (#39). Verify in a later call.
-
-### 4. Verify
-
-In a new tool call, read `controller.log`, `new.pid`, the service log and the
-listener first. Never launch the controller twice before the first outcome is
-known. Require:
-
-1. Old PID gone; exactly one new process and listener, cwd in the release
-   directory.
-2. Fresh `Application starting`, `Agent ready`, `Web server listening`,
-   `Messaging ready` and `Application started`; no startup error.
-3. Root and changed endpoints return 200; check UI changes in a browser.
-4. Interrupted work continues; scheduler deadlines are unchanged; receipt
-   counts change only by new sends and sends interrupted by the stop. After
-   `restart_service`, the old log shows `Restart requested` with the
-   controller directory.
-
-On a timeout, lock, occupied port or startup failure, stop and report it. Do not
-force-kill, steal the lock, reinstall dependencies or restore a workspace snapshot.
-
-Routine deployments do not run the live smoke. Only when the owner authorizes a
-paid model request and a real message, run
-`node --experimental-strip-types ops/smoke.ts --live --chat CHAT_GUID`: it checks
-`/health/model`, waits for the operator's message from the device and reports
-the new reply's receipt. Never resend a reply that is not `sent`.
-Record the deployment (time, commit, PID, checks, unverified limits) with
-`pi-memory`, delete the `/tmp` controller directory, and report **deployed and
-verified** or the blocker. Release gates and evidence live in GitHub #33.

package/ops/preflight.mjs

@@ -1,28 +0,0 @@
-import assert from "node:assert/strict";
-import { execFile } from "node:child_process";
-import { mkdtemp, rm } from "node:fs/promises";
-import { tmpdir } from "node:os";
-import { join } from "node:path";
-import { promisify } from "node:util";
-import { getAgentDir } from "@earendil-works/pi-coding-agent";
-import Database from "better-sqlite3";
-import sharp from "sharp";
-
-assert.equal(process.platform, "darwin", "Messages transport requires macOS");
-const version = process.versions.node.split(".").map(Number);
-assert.ok(version[0] > 22 || (version[0] === 22 && (version[1] > 22 || (version[1] === 22 && version[2] >= 2))), "Node 22.22.2 or newer is required");
-const database = new Database(":memory:");
-try { assert.equal(database.prepare("SELECT 1 AS value").get().value, 1); } finally { database.close(); }
-assert.equal((await sharp({ create: { width: 1, height: 1, channels: 3, background: "white" } }).jpeg().toBuffer()).length > 0, true);
-const browserState = await mkdtemp(join(tmpdir(), "imessage-browser-preflight-"));
-try {
-  // doctor can report MISSING with exit 0; --version must reach the installed runtime.
-  await promisify(execFile)(process.env.PI_BROWSER_CLI_PATH ?? join(getAgentDir(), "bin", "pi-browser"), ["--version"], {
-    env: { ...process.env, PI_BROWSER_HOME: browserState }, timeout: 10000, maxBuffer: 65536,
-  });
-} catch (error) {
-  throw new Error("Browser CLI readiness failed; install the pinned runtime with pi-browser setup", { cause: error });
-} finally {
-  await rm(browserState, { recursive: true, force: true });
-}
-console.log("Preflight passed: macOS, Node, native SQLite/image dependencies and browser CLI runtime. No model, Messages or production workspace was accessed.");