/startup

name: startup
description: "Single entry point for fresh-session bootstrap. Runs optional task-orphan recovery, cron registration, and watcher start in a fixed order. Replaces the current `claude -- '/schedule-crons'` invocation pattern as the canonical CLI startup target."
user-invocable: true

Startup

The canonical entry point for a fresh Sutando session. Bundles every action that must happen once at session start, in the correct order.

**Usage**: `/startup`

ARGUMENTS: $ARGUMENTS — `--worker` selects the worker bootstrap below; empty is the canonical core.

Worker mode (`/startup --worker`)

A pool worker is an instance, not the canonical core. It shares the host's workspace but owns exactly one thing: the watcher on its own delivery folder. **When `$ARGUMENTS` contains `--worker`, run ONLY the sequence in this section and none of the steps below it** — no orphan check (the core owns `tasks/`), no `/schedule-crons` invocation, no ceremony gate (it stamps the core's `schedule-crons-stamp.json`), and no `/startup complete` line. The one exception is step 2.5 below: a `crons.json` entry explicitly pinned to THIS worker's own id (via its `owner` field, see `skills/schedule-crons/SKILL.md`) is this worker's to register — that is not "a second registrant" for it, because `/schedule-crons` skips any entry owned by a worker (`src/cron_ownership.py`). Every entry without an `owner`, or owned by a different worker, stays untouched here.

1. Ask whether this instance's own watcher is already live. **The core's step 1.5 gate is the wrong question here** — it is satisfied by *any* watcher tree on the host, and the core's own always satisfies it, so a worker that consults it never starts the watcher it exists to run:

   "${SUTANDO_PY:?the launcher forwards the resolved interpreter}" "$SUTANDO_WORKER_BOOTSTRAP"

The gate belongs to the optional `worker-pool` skill, not to this one, so it is **named by the spawner in the session's env** and never spelled as a path here — a core install without that skill must still boot. If `$SUTANDO_WORKER_BOOTSTRAP` is unset or names no file, treat it as `unknown`: say so and start nothing.

It answers about THIS instance's sentinel (`util_paths.watcher_sentinel_path`, the same file the watcher stamps) in the assigned workspace — read from the `SUTANDO_WORKSPACE_DIR` variable the spawner sets and the watcher honours, so gate and watcher can never inspect two trees — and prints one word: `start`, `skip`, or `unknown`.

2. If `$SUTANDO_TASK_WATCH_MOD` is `1` and `"$SUTANDO_PY" "$(dirname "$SUTANDO_WATCHER_CMD")/watcher_rearm.py" mod-ready --repo "$(dirname "$SUTANDO_WATCHER_CMD")/.." --workspace "$SUTANDO_WORKSPACE_DIR"` prints `yes`, skip this step: the task-watch Mod runs this watcher, and step 3 adds `(task-watch Mod)` to its line. On `start` only, start the streaming watcher via the `Monitor` tool — `command: 'bash "$SUTANDO_WATCHER_CMD" "$SUTANDO_TASKS_DIR" --role session --inbox "$SUTANDO_TASKS_DIR"'`, `timeout_ms: 1800000` (`Monitor` has no `persistent` option; it kills the command at `timeout_ms`, 30 min at most, and sends one expiry notice — on that notice, re-arm the watcher the same way; a notice that it exited early is the same instruction, and on macOS Claude Code reports a SIGTERM death as `exit code 144`). The positional inbox stays first (the step-1 gate reads a watcher's inbox from its first bare operand); the `--role session --inbox` tag is what lets this seat's own external standby supervisor see the watcher and stand down, and it makes the watcher kill only the standby for this inbox. Both paths are absolute and come from the launcher, because this session's cwd is the spawner's `--cwd` and need not be the repo — a relative `src/watch-tasks-stream.sh` exits 127 there. If `$SUTANDO_WATCHER_CMD` is unset you were not launched as a worker: stop and say so rather than guessing a path.

2.5. **On `start` only** (same gate as step 2 — a fresh incarnation; a `skip` means this instance is already running and re-registering here would duplicate whatever it already has), register any `crons.json` entries pinned to THIS worker's own id. There is no in-session memory of a prior registration to compare against the way `/schedule-crons` step 3 has for a mid-session re-run, so this only ever needs to handle the fresh-boot case:

   REPO="$(cd "$(dirname "$SUTANDO_WATCHER_CMD")/.." && pwd)"
   H="$(bash "$REPO/scripts/sutando-config.sh" host-label)"
   CF="$SUTANDO_WORKSPACE_DIR/hosts/$H/crons.json"
   "$SUTANDO_PY" "$REPO/src/cron_prompt_gate.py" "$CF" --owner "$SUTANDO_INSTANCE_ID" --workspace "$SUTANDO_WORKSPACE_DIR"

The repo root is derived from `$SUTANDO_WATCHER_CMD` rather than assumed from cwd, for the same reason step 2 does. The gate preamble names the gate by its absolute path and checks this worker's assigned workspace (`--workspace`), so it works from any cwd. A missing `crons.json` prints `[]`. For each entry the filter returns, `CronCreate` it exactly as `/schedule-crons` step 3 would: `prompt: <registered_prompt>` from the helper's output, which already carries the owner-task gate preamble when the entry fires more than once a day (`src/cron_prompt_gate.py`; a daily-or-rarer entry is registered verbatim, and `"gate": true` / `"gate": false` on the entry overrides either way) — an entry pinned to a worker is never a `monitor`, `execution: "codex-task"`, or `launchd: true` entry (those ownership models are core-only), so no further filtering is needed. If `crons.json` doesn't exist, or nothing is pinned to `$SUTANDO_INSTANCE_ID`, there is nothing to do here — that is the common case for most workers.

3. Report what actually happened, never a fixed line: `start` → `worker <instance> ready: watching <inbox>` (plus `+ N cron(s) registered` when step 2.5 registered any) — unless the watcher's first line is `WATCHER_HELD:`, which means a holder this session did not start (the gate's `why=` nam