pi-dispatch v0.6.0

The setup overhaul (issues #80, #81, #82). Setup drops from a scavenger hunt to one command, and every new power asks first.

New commands and options

• pi-dispatch up [--yes]: one consented pass over the whole quickstart. Checks Docker, offers to pull and tag the job image, offers to start Valkey, scaffolds the config files (never clobbers), generates WEBHOOK_SECRET when empty, runs doctor, prints a summary. Every docker action shows its exact command and asks first; --yes accepts the prompts but still shows everything.
• pi-dispatch doctor --fix: per failing check, offers to run the exact fix doctor already prints (y/N, default No). Closed tiers: it will scaffold missing files and mkdir declared paths, offer the default image pull and the loopback Valkey start, and never rewrite malformed config, never touch trigger contents, never pull a trigger-named image.
• pi-dispatch service render|install|uninstall|status|start|stop|restart [--drain] [--drain-timeout <s>] [--receiver] [--user|--system] [--force] [--print]: renders the deploy/ unit templates with your real node path and repo root and installs user-level without sudo (launchd, systemd --user, or nssm). --system prints the sudo commands instead of running them. restart --drain composes pause, wait for idle, restart, resume. A policy refusal (exit 2) never relaunches on any OS.
• pi-dispatch setup github [--org <org>] [--name <name>] (--webhook-url <URL> | --no-webhook): GitHub's App Manifest flow against your own loopback. One browser click mints the App id, private key and webhook secret; every .env line is shown before one consent, the key lands with mode 0600, and no secret is ever printed. --no-webhook creates the App hook-inactive for polling.
• pi-dispatch-receiver (its own bin now): serve runs the webhook edge, poll fetches issue events, comments and PRs over TLS instead (no port, no tunnel, no DNS, no webhook secret; about 60s latency). Poll repos come from POLL_REPOS or the App installation's repo list; POLL_INTERVAL_SECONDS tunes the cadence.

New distribution

• The worker + CLI and the receiver are on npm: @edgehero/pi-dispatch and @edgehero/pi-dispatch-receiver. Clone-free quickstart: mkdir my-dispatch && cd my-dispatch && npx @edgehero/pi-dispatch up. A clone is only needed to build a custom job image.
• docker compose --profile receiver up -d runs the receiver beside Valkey from the prebuilt ghcr.io/edgehero/pi-dispatch-receiver image. No docker socket anywhere; the worker stays on the host.

Changed behavior

• The receiver no longer silently reads deploy/triggers.json (the demo triggers) when PI_TRIGGERS_FILE is unset. It reads ./triggers.json from the folder it starts in (what pi-dispatch init scaffolds) and refuses to start, with guidance, when neither exists. The admin panel moved to the same cwd defaults.
• doctor grew the receiver-side checks it never had: WEBHOOK_SECRET, Forgejo and Azure credentials, GitHub App auth completeness, and a branch-protection statement at setup time.

Changes

• chore(release): pi-dispatch 0.6.0, admin 0.3.0
• feat: pi-dispatch-receiver poll -- GitHub triggers without a public URL (issue #81)
• feat: pi-dispatch setup github -- App credentials in one browser click (issue #81)
• feat: ship the receiver as a compose profile with a prebuilt image (issue #82)
• feat: publish the worker and receiver as scoped npm packages (issue #80)
• feat: pi-dispatch service -- render and install the deploy units with computed paths (issue #80)
• feat: pi-dispatch up and doctor --fix -- the consented bootstrap (issue #80)
• fix: give the receiver a start path and unify the triggers-file defaults (issue #80)

Full changelog: v0.5.0...v0.6.0