Docs: cockpit-exposure runbook — per-project tunnel, Access-gated DNS, multi-project conventions, WSL2 autostart

[robercano-ghbot]

Blocked by #143

Context

The cockpit-exposure feature (#142/#143/#144) needs a generic, consumer-facing runbook so any reCode user can go from "loop armed locally" to "cockpit on my own domain behind Cloudflare Access" without reverse-engineering the scripts. reDeploy's docs/ALWAYS-ON-TUNNEL.md is a strong project-specific template to generalize — same shape, minus the studio/Vite specifics (httpHostHeader etc.).

Proposal

Add a runbook to docs/ covering, provider-agnostically where possible but Cloudflare-concretely:

1. Prereqs: a Cloudflare-managed zone, cloudflared install, one-time tunnel login.
2. The per-project model: one named tunnel / config / unit per project; why the default ~/.cloudflared/config.yaml is a hazard and every command uses explicit --config + tunnel UUID.
3. gates.json reference for the cockpit and expose blocks (port uniqueness and naming conventions for multi-project machines).
4. The Access-before-DNS ordering rule and why it exists (unauthenticated origin).
5. Walkthrough of the cockpit-expose skill, its idempotency, and teardown.
6. Operations: loop-scoped vs always-on tunnel trade-off (Access-authenticated visitors see a Cloudflare 1033/error while the loop is down — expected); WSL2 survival (loginctl enable-linger + unattended-autostart notes); verifying SSE /events through the tunnel.
7. Origin JWT validation (Cockpit: defense-in-depth — validate Cf-Access-Jwt-Assertion at the origin when tunneled #144) configuration, once available.

Acceptance criteria

• A consumer-repo user with a Cloudflare zone can complete exposure end-to-end from the doc alone.
• USAGE.md / ARCHITECTURE.md cross-reference the runbook where the cockpit is introduced.
• No user-specific values (domains, hostnames, UUIDs) in examples — placeholders throughout.

🤖 Generated with Claude Code