perpetualsoftware/pad/connect

/pad:connect opts THIS session into Pad's live stream: it declares consent to receive pad push notifications (the security gate — no consent, no stream), wakes the session's push monitor, and on the FIRST connect of a session runs the workspace's boot ritual. The stream starts in this session as soon as step 1's pad session arm returns, with no restart; run this once per session you want connected.

If the pad CLI is missing (command not found), say so and point at https://getpad.dev/install — don't retry or guess at alternate paths. If no .pad.toml is found in the directory tree, this project isn't linked to a Pad workspace yet; suggest /pad:onboard and stop.

Do these in order:

1. Arm the session. Run pad session arm. This declares consent; the monitor

announces it to the server on connect, and only armed sessions receive pushes. Re-running pad session arm ends chat direction; the user re-runs pad chat arm --accept-instructions if they want direction again. After the monitor first resolves chat identity, it ensures your owner↔agent DM in the background once per monitor process (existing DMs are uncharged). Reconnects do not repeat it; a final failure prints one stderr line without stopping delivery.

1. First-connect check + boot ritual. Run pad session first-connect --format json.

• If first_connect is true: load the workspace context with `pad bootstrap

--format json, then look at its playbooks array for entries with trigger = on-session-start and status = active. For each, load the body with pad playbook show <invocation_slug> --format markdown` and follow it. This is the workspace's own operating ritual firing for whoever connects. (Many workspaces have none — that's fine; just skip.)

• If first_connect is false: this is a reconnect. Do NOT re-run the boot ritual;

just re-affirm the connection.

1. Report the state. Run pad session status --format json. Report it honestly:

announced_armed true means this session is set to accept pushes (consent is on), not that the monitor has connected yet — so say "This session is set to accept pushes." Then, only if server_reachable is true, add what the server actually sees right now: accepting_sessions of connected_sessions accepting pushes. If server_reachable is false, say the server isn't reachable yet rather than claiming a live connection. If auto_arm is on, mention this repo auto-arms new sessions. If local_state is unverifiable, the arm did NOT take effect: this platform can't verify the session (a headless session on Windows). Say so plainly, and point at push.auto_arm = true in .pad.toml as the way to receive pushes here.

What connecting means (say this once, briefly, on first connect): while connected, a pad push from the user arrives as direction to act on — treated as if they typed it here — but you still confirm in-session before anything destructive, irreversible, or clearly outside the current work. Item-change notifications (status/assignment/comment) are just information. Run /pad:disconnect to stop receiving pushes for this session.