# NEW SESSION PROMPT — Mobile Command Center rebuild (paste this to start)

Steve — I want the mobile version of my Command Center brought up to the same bar as the desktop chat we just rebuilt on 2026-07-24. Run this A→Z; I want it to feel like a real app I can drive from my phone anywhere, with the same reliability the desktop now has.

## What already exists (don't rebuild — extend)
- `~/projects/command-center-v1` is a Next.js 15 app on Vercel (cc.thomasdigital.com), already a **PWA**: `public/manifest.json` (standalone), apple-mobile-web-app meta tags + `viewportFit: cover` + safe-area padding in `app/layout.tsx` / `app/globals.css`, a bottom **mobile tab bar + accordion sheet** nav in `app/components/AppShell.tsx`, and **web-push infra** (`app/components/PushSubscribeButton.tsx`, `app/api/push/subscribe`, `app/api/push/test`, VAPID keys, `sw.js` push handler).
- The chat transport + reliability layer we just built on desktop is the foundation to reuse: `app/lib/steve-socket-transport.ts` (turn registry, **resume from a frame cursor**, reconnect, visibilitychange re-attach), `app/lib/fallback-transport.ts` (media→relay), and the Mac-side `~/projects/steve-ws/steve_ws.py` (per-turn frame buffer + `{action:"resume", from_idx}` + heartbeats + WS keepalive). The server ALREADY keeps a resumable per-turn buffer — mobile just needs to use it correctly.

## The real gaps to fix (verified 2026-07-24)
1. **The chat surface has ZERO mobile handling.** `ThreadView.tsx` / `ChatRail.tsx` have no `visualViewport`, no `dvh`, no keyboard-aware composer. The whole app uses `100vh` (breaks under the mobile keyboard/URL bar).
2. **None of the desktop reliability work has a mobile counterpart** — and mobile's hard problems are worse: the OS suspends the app when backgrounded, screen-lock kills the socket, and cellular↔wifi handoff drops the connection mid-answer.
3. **Push exists but isn't wired to chat** — it should wake you when a long answer finishes while the app is backgrounded.
4. The desktop **artifact split-pane** won't work on a phone (needs a full-screen sheet).

## Frontier reference (from research, 2026)
- **OpenClaw shipped official native iOS/Android apps on 2026-06-29** — thin client, WebSocket to the Gateway, Tailscale `wss://` for remote, QR pairing, **action-approval cards** on mobile, **push for job/workflow completions**, a **Canvas** surface the agent pushes dashboards to, and **offline message queuing**. Mirror these patterns; we already have most of the backend.
- **Reliability pattern:** transport-recovery ≠ session-recovery. The fix is SSE/WS + a **cursor (Last-Event-ID / from_idx)** replaying from a **bounded server-side turn buffer** — which steve-ws already implements. Add push-to-wake + reconnect-on-resume(foreground/network-change).
- **Mobile UX patterns to adopt:** conversation **drawer** (swipe), **long-press the send button** for the model picker (per-send, no modal), **full-screen sheet** for artifacts/canvas on phone, paperclip→camera/gallery upload, thumb-reachable primary actions, keyboard-aware composer via `visualViewport` + `100dvh`.
- **The #1 mobile use case is approvals + a kill switch** (per the research): the highest-value phone interaction is interrupt-driven — the agent pauses on something sensitive, the phone buzzes, you tap allow/deny (sub-second), and it continues; plus a one-tap "stop everything." Build this early, not last. The official OpenClaw app shipped rough (v0.9, Android 2.2★) and community PWAs (ClawBridge over a Cloudflare tunnel — the same tunnel setup we run) fill the gaps — so a polished version is a real edge, not a rebuild of theirs.

## The one strategic decision I want you to make and justify
**PWA-only vs Capacitor wrapper vs native.** Research leans PWA-first, but because I specifically want **reliable background push and a native feel from anywhere**, weigh whether wrapping the existing Next.js build in **Capacitor** (thin native shell, reuses the entire codebase, real background push + camera + no iOS install friction) is the better call for a single-user control surface I depend on. Pick one, justify it against my requirements (reliable push, native feel, reuse the codebase, speed), and state the reversible migration path.

## How to run it
Run this as a `/d4` disciplined build. Diagnose the current mobile state on a real phone viewport, decide the build path, then implement in a worktree, deploy to a preview, and **test on an actual mobile viewport** (parallel chats, a long answer while backgrounded, screen-lock, an image upload from the camera roll, the keyboard-aware composer). Prove each on the preview before calling it done. Hard rule: the desktop chat must keep working — mobile changes ride behind responsive breakpoints / feature detection, reversible. Give me a verified public preview link at the end.

## Success criteria
- Chat composer stays above the keyboard on iOS + Android (no `100vh`; `dvh` + `visualViewport`).
- A long answer survives app-background, screen-lock, and a wifi↔cellular switch, and resumes on foreground.
- Push wakes me when a backgrounded answer completes.
- Conversation drawer, per-send model picker, full-screen artifact sheet, camera/gallery upload all work by thumb.
- Desktop chat unchanged. Verified public preview link delivered.