chore(release): prepare v0.10.0

.github/workflows/release.yml

@@ -110,5 +110,5 @@ jobs:
             gh release create "${TAG}" dist/* \
               --title "${TAG}" \
               --verify-tag \
-              --generate-notes
+              --notes-file RELEASE_NOTES.md
           fi

Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "push"
-version = "0.9.0"
+version = "0.10.0"
 edition = "2021"
 license = "MIT"
 description = "A tiny messaging gateway that turns coding agents into a personal assistant you text."

RELEASE_NOTES.md

@@ -1,15 +1,48 @@
-# Push v0.7.0
-
-- Render Markdown as Telegram HTML for chat and scheduled-job output, with safe
-  plain-text fallback when Telegram rejects formatting.
-- Add reusable agent evaluations for scheduled jobs and persist evaluation,
-  execution, and delivery state separately.
-- Add `help`, `reload`, `restart`, and `version` commands, including `--help`
-  and `--version` flags that work without loading configuration.
-- Recover stalled message queues, support `/stop`, and harden scheduled delivery
-  with durable chunk progress, bounded retries, and impossible-cron validation.
-- Add configurable voice credentials and voices. Removed runtime settings now
-  fail with migration guidance, backend commands resolve from `PATH`, and
-  Telegram environment credentials use `TELEGRAM_BOT_TOKEN`.
-
-**Full changelog:** https://github.com/owainlewis/push/compare/v0.6.0...v0.7.0
+# Push v0.10.0
+
+- Derive private runtime storage from one `PUSH_HOME`, while keeping the
+  Git-versioned assistant repository and its jobs outside that boundary.
+- Add a stable, redacted JSON CLI contract for paths, status, diagnostics,
+  job inspection, validation, runs, and schedule reviews.
+- Compose backend instructions from explicit policy, identity, workspace,
+  request, and history sections.
+- Install one versioned Push capability skill for Claude Code, Codex, and Pi.
+- Move channel cursors and backend session mappings into the canonical SQLite
+  database with crash-safe, repeatable migration from `state.json`.
+- Require durable owner review before a new or changed enabled schedule can
+  activate, including fail-closed queued-run checks and replayable audit events.
+
+## Upgrade notes
+
+Upgrade in this order:
+
+1. Stop the Push service. Back up `PUSH_HOME`, the assistant repository, and
+   any explicit runtime paths that live outside `PUSH_HOME`.
+2. Before the first v0.10 command that opens job state, such as `push doctor`,
+   confirm `primary_delivery` names an enabled, allowlisted destination if
+   existing enabled schedules should receive the one-time migration baseline.
+3. Install v0.10.0 and set one absolute `PUSH_HOME` in the service definition.
+4. Run `push init <assistant_root>` to complete an older configured assistant
+   layout and install or update the managed Push skill.
+5. Run `push doctor` and `push job validate`, then restart the service and
+   confirm `push status`.
+
+- Existing `assistant_root` configurations continue to load jobs from
+  `<assistant_root>/jobs`. Default runtime paths remain under `PUSH_HOME`.
+- Explicit compatibility overrides such as `state_path`, `database_path`,
+  `audit_log_path`, and `jobs_run_dir` remain authoritative. Back up and
+  restore those paths separately when they point outside `PUSH_HOME`.
+- If an older `$PUSH_HOME/jobs` directory remains after adopting
+  `assistant_root`, its files are not active. Move any jobs you still want into
+  `<assistant_root>/jobs`, then archive the legacy directory.
+- Push imports legacy cursor and session state from `state.json` once and keeps
+  the JSON file as a recovery copy.
+- Existing valid enabled schedules receive a one-time migration baseline only
+  when the first v0.10 command that opens job state has a valid primary delivery
+  destination. If it does not, migration closes without grandfathering those
+  schedules and they require review. Later schedule changes require approval
+  of the exact revision.
+- The service and interactive CLI must use the same `PUSH_HOME` so they share
+  the runtime database and lock directory.
+
+**Full changelog:** https://github.com/owainlewis/push/compare/v0.9.0...v0.10.0

assistant/skills/push/SKILL.md

@@ -4,7 +4,7 @@ description: Operate a Push personal assistant, inspect its health and jobs, and
 license: MIT
 compatibility: Requires the Push CLI and an initialized assistant repository.
 metadata:
-  push-managed-version: "2"
+  push-managed-version: "3"
 ---
 
 # Push
@@ -37,6 +37,8 @@ are:
 - `push init [path]`
 - `push`
 - `push doctor`
+- `push status`
+- `push paths`
 - `push reload` or `push restart`
 - `push job validate`
 - `push job list`
@@ -45,9 +47,16 @@ are:
 - `push job runs [<name>]`
 - `push job reviews [<name>]`
 
-All commands accept `--config <path>`. Do not assume machine-readable output
-unless `push help` documents it in the installed version. Never expose tokens,
-message content, or sensitive runtime state in diagnostics or replies.
+All commands accept `--config <path>`, although service status and restart use
+the installed service definition. Inspection commands support `--json` where
+documented by `push help`: help, version, doctor, status, paths, job validation,
+job inspection, runs, and reviews. Commands that start the gateway, change
+service state, scaffold files, or run a job reject JSON mode. The first upgraded
+inspection that loads configuration and job state records the one-time schedule
+migration baseline; follow the release upgrade notes before running it. Prefer
+JSON for automation, but still treat paths, handles, and operational metadata
+as sensitive. Never expose tokens, message content, or sensitive runtime state
+in diagnostics or replies.
 
 ## Author jobs safely
 

docs/designing-an-assistant.md

@@ -198,12 +198,13 @@ jobs/morning-brief.md    scheduled request with timeout and delivery
 ```
 
 Keep job bodies self-contained because every job starts a fresh backend
-session without conversation history. Chat turns start in `assistant_root`, but
-jobs start in the job's configured work directory, which must stay outside the
-assistant repository. A job therefore does not automatically discover skills
-linked under the assistant root. Keep required procedures in the job body, or
-make the skill available through the backend's global skill location or the
-job work directory.
+session without conversation history. Chat turns start in `assistant_root`, and
+jobs use `assistant_root` as their default work directory. Jobs can therefore
+discover project instructions and skills linked there. An explicit alternate
+work directory changes that discovery context and must not overlap Push-owned
+runtime paths. Keep every required procedure in the job body, or make the
+needed skill available through the backend's global skill location or the
+selected work directory.
 
 Put stable preferences in `SOUL.md` or `context/`, and put the schedule, work
 directory, constraints, required procedure, and requested output in the job.

docs/getting-started.md

@@ -156,9 +156,10 @@ have a configured model provider or authenticated account for the service user.
 
 If you replace the config file created by `push init`, keep its
 `assistant_root` setting. Running the same init command again is safe for a
-complete assistant repository. It preserves user-owned files and refreshes the
-Push-managed skill only when the installed checksum proves that the managed
-copy is unmodified.
+complete assistant repository. It can also complete an older partial layout
+when the selected config already names that exact root. It preserves user-owned
+files and refreshes the Push-managed skill only when the installed checksum
+proves that the managed copy is unmodified.
 
 ## 5. Validate and run
 

docs/jobs.md

@@ -227,12 +227,12 @@ updating the repository keeps its checked-in guidance accurate.
 Pending draft-install approvals from older Push versions are cancelled during
 database migration. Replying to one explains that the job must be requested
 again. On upgrade to schedule activation review, each valid enabled schedule
-whose exact revision exists at the first config-aware Push command is captured
-as the migration baseline. Those revisions are recorded as approved and
-activated once when a valid primary destination exists. If that first command
-has no valid primary destination, Push records an empty baseline and closes the
-migration without grandfathering any schedules. Disabled and invalid jobs are
-not grandfathered.
+whose exact revision exists when the first upgraded command opens job state is
+captured as the migration baseline. Those revisions are recorded as approved
+and activated once when a valid primary destination exists. If that first
+command has no valid primary destination, Push records an empty baseline and
+closes the migration without grandfathering any schedules. Disabled and invalid
+jobs are not grandfathered.
 
 !!! warning
 

docs/reference/cli.md

@@ -61,9 +61,11 @@ ignores `--config`. Run `push doctor` separately when you want to validate those
 settings from the current shell.
 
 `push init` accepts an empty target, the selected config by itself, or a
-complete existing assistant layout. It refuses unrelated and partial non-empty
-directories, preserves user-owned `SOUL.md` and `AGENTS.md`, persists one
-canonical `assistant_root`, and initializes Git when needed.
+complete existing assistant layout. It can also safely complete a partial
+layout when the selected config already names that exact `assistant_root`.
+It refuses unrelated partial non-empty directories, preserves user-owned
+`SOUL.md` and `AGENTS.md`, persists one canonical `assistant_root`, and
+initializes Git when needed.
 
 Initialization also installs the versioned Push capability skill at
 `skills/push/` and exposes that one directory through relative links under
@@ -83,10 +85,13 @@ available for:
 - `doctor`, `status`, and `paths`
 - `job validate`, `job list`, `job show`, `job runs`, and `job reviews`
 
-Commands that start or mutate runtime state reject `--json`. This includes the
-gateway, `init`, `reload`, `restart`, and `job run`. In particular, Push does
-not claim that an interrupted mutation is safe to retry when its outcome is
-unknown.
+Commands that start the gateway, change service state, scaffold files, or run a
+job reject `--json`. This includes the gateway, `init`, `reload`, `restart`, and
+`job run`. Config-loading inspection commands can still migrate the database
+schema and capture the one-time upgraded schedule baseline. They do not start a
+job or decide a schedule review, but they are not filesystem-state-free. Push
+does not claim that an interrupted mutation is safe to retry when its outcome
+is unknown.
 
 A successful command writes exactly one JSON document and a trailing newline to
 stdout. It writes nothing to stderr:

docs/services.md

@@ -55,10 +55,12 @@ databases, logs, locks, and service credentials outside it.
 
 ## macOS launchd
 
-Create the log directory:
+Create private service logs:
 
 ```sh
 mkdir -p ~/Library/Logs
+touch ~/Library/Logs/push.err.log ~/Library/Logs/push.out.log
+chmod 600 ~/Library/Logs/push.err.log ~/Library/Logs/push.out.log
 ```
 
 Create `~/Library/LaunchAgents/com.owainlewis.push.plist`. You can start from
@@ -133,8 +135,8 @@ override when service-level secret injection is preferred.
 
 ## Linux systemd
 
-Use this for Telegram-only deployments. The iMessage channel still requires
-macOS.
+Use this for Telegram or Slack deployments. The iMessage channel still
+requires macOS.
 
 Create the service directories: