docs: vibecode persistence plan (proposal, no code)

[rafavalls]

What

A proposal/plan for the output half of vibecoding without GitHub. PR #3361 covered the input side (plain cloneUrl → sandbox boots from a template); this proposal covers persistence so user edits survive sandbox idle/restart, with no GitHub remote required.

No code in this PR — just the markdown plan at VIBECODE_PERSISTENCE.md. Intended as a spec for review/handoff before implementation starts.

TL;DR of the proposal

• On idle, the sandbox daemon makes a git bundle of the workspace and streams it through mesh to a blob store.
• On VM_START, mesh checks the store; if a bundle exists, it's staged inside the pod at /tmp/snapshot.bundle and fed to the existing setup orchestrator as the cloneUrl. The orchestrator's existing clone/install/start machinery handles it unchanged.
• Two store backends behind one interface: LocalFsStore (writes under <DATA_DIR>/vibecode/... for local dev) and S3Store (SigV4/IRSA, reusing the STS-refresh pattern proven out by configmap-s3-sync.yaml).
• Selection by env var (VIBECODE_BUCKET), so the save/restore code is identical in local and prod.

Why bundle, not tar

• .gitignore from the template already excludes node_modules / .next etc. — no hand-maintained exclude list.
• Smaller payload (packed git objects, not the working tree).
• Free history → "undo last vibecode" is git reset --hard HEAD~1 on restore.
• Future "promote to GitHub" is git remote add gh && git push gh — zero rework.

Key reused pieces (no changes needed)

• packages/sandbox/daemon/setup/orchestrator.ts — clone-from-bundle works because git clone /tmp/snapshot.bundle . is a standard git operation.
• packages/sandbox/daemon/git/git-sync.ts — gitSync() helper for the commit/bundle commands.
• packages/sandbox/server/daemon-client.ts postConfig() — delivers the modified config (with bundle path as cloneUrl) to the daemon.
• The IRSA STS-refresh logic in deploy/helm/studio/templates/configmap-s3-sync.yaml:29-58 — ported to TS for S3Store.

Open questions for the dev who picks this up

Listed at the bottom of VIBECODE_PERSISTENCE.md:

1. Single bucket per env, prefix-multitenant — or one per org?
2. Idle threshold of 60s before first save, poll every 30s — feel right?
3. 500MB hard cap on bundle size — OK?
4. Save-on-shutdown sweep on every running sandbox, even ones with no recent activity — OK?

Suggested commit boundaries

VibecodeStore interface + LocalFsStore → daemon snapshot routes → restore step in VM_START (local-only) → mesh idle poller → S3Store adapter → Helm values + IRSA policy. Each step ships independently; full prod path lights up at step 5.

Test plan

See "Verification" section in the doc. End-to-end is: click "Build landing page", edit a file, wait for idle, kill the pod, restart, confirm edits restored — runnable both locally (host runner + LocalFsStore) and on a kind cluster (agent-sandbox + S3Store).

🤖 Generated with Claude Code

---

Summary by cubic

Proposal for bundle-based persistence so vibecoded sandboxes (from plain cloneUrl, per #3361) keep user edits across idle/restarts without GitHub. No code; VIBECODE_PERSISTENCE.md outlines git bundle save/restore, a small VibecodeStore (local FS or S3 via IRSA, selected by VIBECODE_BUCKET), new daemon snapshot routes, a mesh idle saver, and a VM_START restore that reuses the existing setup orchestrator.

^{Written for commit a8df0da. Summary will update on new commits. Review in cubic}

[cubic-dev-ai]

No issues found across 1 file

_{Re-trigger cubic}