Disposable per-attempt data/DB fork for APR execution (data-side equivalent of worktree-pool.ts)

[JSONbored]

Problem

AMS's existing isolation (packages/loopover-engine/src/miner/worktree-pool.ts) is code/filesystem-level only — a git worktree per attempt. Nothing in this codebase gives an AMS attempt an isolated, disposable copy of a target application's data (a database). For APR specifically (auto-provisioned repos — #7589), AMS's own agent is effectively responsible for the generated app's data-layer correctness the same way Lovable and Bolt.new's agents are for their generated apps, and competitive research found that's exactly where the real-world incidents in this category cluster — not sandbox escapes. Lovable's CVE-2025-48757 (missing/misconfigured Supabase Row-Level-Security policies, ~170 generated apps exposing PII) and the industry's most-cited cautionary tale (Replit's Agent, explicitly told not to touch production, ran destructive commands against a live database and deleted 1,200+ real records) both trace to the agent operating against real, non-disposable data with no structural fallback.

Area

Platform / AMS execution safety — adjacent to but distinct from #7180's compute/network sandboxing, and distinct from the existing worktree-pool.ts code isolation.

Proposal

The industry's converged response to the Replit-class failure (per this research) is architectural, not instructional: give the agent a cheap, disposable, copy-on-write fork of both code and data, so a destructive action against the fork is reversible/discardable rather than relying on the agent correctly following an instruction not to touch production. loopover already does this for code (worktree-pool.ts); this issue is the data-side equivalent for APR, where loopover controls the provisioned database and can practically implement it (Postgres — see #7180's Neon+Hyperdrive decision — supports branch/fork-style copy-on-write natively via some providers, worth checking against the specific provider chosen).

Scope this to APR specifically for now — BYOR's target database (if any) belongs to the customer, not loopover, and forking a customer's own production data is a different, much larger consent/access problem not in scope here.

Deliverables

• A written decision: what "disposable fork" means concretely for the chosen Postgres provider (branch-per-attempt, snapshot/restore, or another mechanism), and when it gets created/discarded relative to an AMS attempt's lifecycle.

Resources

• packages/loopover-engine/src/miner/worktree-pool.ts (the existing code-side precedent this mirrors)
• Provisioning core: create/destroy a tenant's Container + Postgres DB #7180 (Postgres provider decision this depends on)
• Epic: dual-path repo provisioning — BYOR + APR #7589 (BYOR+APR epic — this is APR-specific)
• Research citations: Replit's "Snapshot Engine" (manifest-based copy-on-write for both filesystem and a forked Postgres instance, built directly in response to the production-deletion incident); Lovable CVE-2025-48757 (the data-layer-correctness risk category this doesn't directly prevent but is adjacent to)

Boundaries

Design decision only — no reward/pricing figures, no implementation of the actual fork mechanism (downstream of this decision and #7180's provider choice).

maintainer-only — data-safety architecture decision, not a build task.

[linear-code]

JSO-5403

[JSONbored]

Postgres-provider blocker cleared 2026-07-20 — Neon + Cloudflare Hyperdrive, decided on #7180. Linking the blocked-by edge for traceability; the remaining blocker is #7180's real driver existing at all, not the provider choice.

[JSONbored]

APR tenant-identity anchor resolved (2026-07-21): now that repo creation uses the submitting customer's own OAuth session (see corrected #7590/#7637), the customer's own GitHub login/user ID from that session is the natural per-customer key — no synthetic ID needed. This gives #4920's quota model and #4889's per-tenant admin concept a real anchor for APR, parallel to how BYOR already uses installations.id.

[JSONbored]

Decision (ratified 2026-07-21): use Neon branch-per-attempt as the disposable data fork mechanism. #7653 already fixed Neon + Cloudflare Hyperdrive as the Postgres provider for the hosted control-plane, and Neon's native copy-on-write branching (the same primitive Neon's own docs recommend for exactly this kind of ephemeral-fork use case) is a better fit than building a separate snapshot/restore pipeline against the same provider.

Lifecycle (concrete shape): create a Neon branch off the tenant's APR database at the start of an AMS attempt (mirroring worktree-pool.ts's per-attempt code checkout), point that attempt's DB connection (via Hyperdrive) at the branch instead of the tenant's primary database, and discard the branch when the attempt concludes (merged or abandoned) rather than merging branch data back automatically — matching the code-side worktree behavior of "reversible/discardable, not auto-applied."

This closes this issue's decision deliverable. Implementation is split out to a new issue rather than blocking this one open.

[JSONbored]

Decision recorded above and ratified. Implementation split out to #7858.