Cockpit: loop-managed lifecycle — opt-in gates.json cockpit block, start/stop with arm/halt

[robercano-ghbot]

Blocked by #133

Context

The cockpit (.claude/scripts/cockpit-serve.sh) is a dependency-free node HTTP dashboard bound to 127.0.0.1:8090, currently started manually via pnpm cockpit and entirely decoupled from the loop lifecycle: arm-loop.sh, loop-daemon.sh, and loop-halt.sh never touch it (zero grep hits for "cockpit"). The loop only writes the state files the cockpit reads.

Goal: the cockpit should be served automatically while the cron-less loop is armed, per project. This is the foundation for per-project external exposure (see the blocked follow-up), but is useful standalone: localhost cockpit-on-arm, no Cloudflare required.

Multi-project constraint: several consumer repos (reDeploy, reDeFi, …) may run loops on one machine, so the hard-coded default port 8090 and any fixed unit name collide. Port and unit name must be per-project.

Proposal

1. Add an opt-in cockpit block to gates.json: { "enabled": false, "port": <unique per repo> }. Default off — the loop must not silently start web servers in repos that didn't ask.
2. arm-loop.sh: when enabled, launch cockpit-serve.sh as a transient systemd user unit, namespaced by a project slug (mirror the driver-unit naming), pinned with --working-directory to the repo root (PR fix(loop): pin transient driver units to the repo root via --working-directory #131 pattern) and inheriting the driver's environment (gh auth, PATH — cockpit.sh shells out to gh).
3. Idempotent arming: re-arm must not double-start or fight over the port; detect the live unit and leave it.
4. loop-halt.sh and disarm stop the cockpit unit alongside the driver.
5. Keep the 127.0.0.1 bind (cockpit-serve.sh:802) — no interface change in this issue.

Acceptance criteria

• With cockpit.enabled: true, arming the loop serves the dashboard on the configured port; halting/disarming stops it.
• With the block absent or enabled: false, behavior is exactly today's (manual pnpm cockpit still works).
• Re-arm while the cockpit unit is live is a no-op for the cockpit (no duplicate unit, no port clash).
• Two repos on one machine with different ports/slugs run cockpits side by side without collision.
• Covered by tests alongside the existing arm-loop/loop-halt test files.

Notes

• Consumer repos only benefit once the plugin update/re-stamp path delivers script changes (see the plugin-update-mechanism work; reDeploy's vendored-script drift is the live example).

🤖 Generated with Claude Code

[robercano-ghbot]

Cross-link from the packaging/migration assessment session (issues #136–#141):

No Blocked by edge added, deliberately. Implementation here is self-hosted-testable and doesn't depend on the migration chain; consumer delivery arrives via #141 (sync v2), which is re-runnable — consumers pick up whatever main has at each sync.

One hard requirement instead: this issue modifies arm-loop.sh, a MANAGED file re-stamped by today's 4-file sync. A consumer can therefore receive the new arm-loop while its vendored sibling scripts still lack cockpit-serve.sh (the reDeploy/reDeFi drift documented in #134). arm-loop.sh must degrade gracefully — warn and skip the cockpit unit — when the cockpit scripts are absent, or a partial re-stamp bricks arming in stale consumers.

Related: #133 (manual /cockpit command — the other entry point), #141 (rollout vehicle).