Publish to scoutos.live

[twilson63]

Implements docs/scoutos-live-prd.md — a signed-in user clicks Publish, the project is packaged server-side and deployed to Scout Live, and they get a stable live URL at {subdomain}.scoutos.live. Republishing the same project updates the same URL.

What's in here, by phase

• Phase 0 — ports smoke test: verified hyper-zepto 0.1.0's remote adapters against scout-live's sidecar + data-router source; all six data ops the template uses match. Env mapping documented in the PRD (strip the trailing /_ports from SCOUT_PORTS_URL; no token — the sidecar injects auth). smoke/phase0-live-ports/ is the deployable smoke app; round trip verified locally against a platform-shaped stub.
• Phase 1 — production template: the /api/db bridge moved to zepto-bridge.js (written once), mounted by vite.config.ts in dev and the new server.js (static dist/ + SPA fallback) in production. Remote vs local adapters selected from the Scout Live env. Both template copies, both prompt copies, and both test suites updated in sync.
• Phase 2 — credentials: user_credentials table (PGlite, existing AES-256-GCM keyCrypto), PUT/GET/DELETE /api/credentials. Keys are write-only — responses carry a presence flag only.
• Phase 3 — packaging + publish proxy: hand-rolled USTAR+gzip writer (~70 lines, no new dependency), Dockerfile/.dockerignore injection (numeric USER 1000 for runAsNonRoot; npm install because project maps carry no lockfile — image built and CRUD-tested under real Docker), deployments table, POST /api/publish + GET /api/publish/:buildId with distinct error codes (no_scoutos_key, subdomain_taken, scoutlive_rate_limited + Retry-After...), injectable scoutlive.ts client. Tests assert keys and publish codes never appear in responses or logs.
• Phase 4 — Gleam UI: publish actor state machine, publish modal, toolbar rocket button (managed mode only), write-only ScoutOS key field in the account panel. Client-side subdomain validation mirrors the platform's rules + reserved list. 21 new Gleam tests; scripts/verify-publish-ui.mjs drives headless Chrome against the dev server with a faked backend (8/8 checks).
• Phase 5 — rollout docs + gating: README section; non-managed mode shows no publish affordances (asserted headless).

Test status

• Root: 70 Gleam + 56 vitest green. Server: 99 vitest green.

Remaining before merge (need a sk_live key — none was available locally)

• Phase 0 live deploy: SCOUTOS_API_KEY=sk_live_... smoke/phase0-live-ports/deploy.sh <name>, then curl -X POST https://<name>.scoutos.live/verify, then republish with the printed publishCode.
• One real POST /api/build acceptance of a server-generated tar.gz.
• End-to-end on a PR preview (sign in → save key → build → publish → edit → republish).

🤖 Generated with Claude Code

[hyperio-mc]

Reviewed PR #24 — Publish to scoutos.live. +3035/-107 across 41 files. Approving.

Architecture is clean:

• 5-phase PRD fully implemented with outcomes documented and success criteria checked off
• Credentials stored encrypted (AES-256-GCM via existing keyCrypto), write-only — responses carry presence flags only, tests assert keys never leak into responses/logs
• Packaging uses a hand-rolled ~70-line USTAR+gzip writer (tar.ts) with proper prefix/name splitting for long paths — no new dependency. The generated Dockerfile uses npm install (project file maps carry no lockfile) and numeric USER 1000 (required for runAsNonRoot securityContext)
• scoutlive.ts client mirrors the openrouter.ts injectable pattern — faked in tests, clean error type taxonomy (subdomain_taken, invalid_code, scoutlive_rate_limited + Retry-After)
• Publish flow: first publish prompts for subdomain (pre-validated client-side against naming rules + reserved list before any network call), republish reuses stored subdomain and sends the persisted publishCode

Security:

• Subdomain validated server-side with regex + reserved list; client mirrors for pre-flight feedback
• Content-Length + body size checked against MAX_BODY_BYTES (2MB)
• PublishCode stored encrypted, decrypted only inside the publish handler
• No credentials in responses or logs — verified by tests
• The PUBLISH_DOCKERFILE test asserts no USER root, --privileged, --cap-add, curl|sh patterns — mirrors scout-live validation rules

Client (Gleam):

• New publish actor state machine with modal + toolbar rocket button
• Write-only ScoutOS key field in account panel
• verify-publish-ui.mjs headless Chromium harness — 8/8 checks pass including republish-without-prompt
• Non-managed mode shows zero publish affordances (asserted headless)

DB:

• user_credentials table (clerk_user_id + provider PK, key_enc bytea)
• deployments table (clerk_user_id + project_id, subdomain, publish_code_enc, last_build_id, last_url)
• Migrations split into individual statements (PGlite rejects multi-statement prepared statements)

Smoke (Phase 0):

• smoke/phase0-live-ports/ with deploy.sh, Dockerfile, index.js exercising all 6 data-port ops against hyper-zepto remote adapters
• Wire format verified against scout-live sidecar + data-router sources
• 3 live checks pending a sk_live key

155 client + 99 server tests pass. Solid end-to-end implementation of the full publish pipeline.