Prepare local-with-cloud mode

Outcome

You can compose the implemented Supabase, Temporal Cloud, R2, and Daytona boundaries without giving one process or sandbox more authority than it needs. Provider adapters are selected by validated settings; there is no broad environment switch and no silent fallback to a paid provider.

Prerequisites

Complete local setup and the first research story. Review the generated configuration reference; only names in Settings, WorkerSettings, and MigrationSettings are consumed.

Use an isolated development project and synthetic data for every activation check. Obtain credentials through the approved secret manager for the specific environment and role. Do not copy an owner-only environment file, production data, or administrative credentials into a checkout or sandbox.

Steps

1. Keep pnpm bootstrap and pnpm dev as the deterministic baseline. Those scripts select local PostgreSQL, filesystem artifacts, development authentication, and unconfigured paid providers.
2. Activate one boundary at a time: Supabase authentication and role-specific PostgreSQL URLs, Temporal Cloud for the worker, R2 with separate staging/read/worker credentials, and then Daytona with a digest-pinned runtime image and deployment-proven block_all egress.
3. Give migration, app, and worker processes separate least-privilege credentials. Static browser configuration may contain only publishable values and public origins. A sandbox receives only short-lived attempt- and generation-scoped product capabilities.
4. Keep app-side R2 staging/read credentials distinct, use a separate worker finalization credential, and keep the staging and canonical buckets distinct. Inactive R2 or Daytona settings are rejected.
5. For each activated provider, run its deterministic contract suite first, then the named live smoke with synthetic data. Record the exact environment, role, region or endpoint, deployed commit, and remaining activation gate without recording secret values.
6. Keep the local fake implementation available as the test profile. It proves the product contract; it is not a silent fallback for a failed paid request.

Verify

Run pnpm check, then confirm the deterministic story succeeds without cloud credentials. For each cloud boundary, verification is complete only when the intended adapter appears in redacted readiness, startup rejects incomplete or inactive configuration, unconfigured UI remains explicit, and normal, denied, timeout, ambiguous-provider, restart, and rollback paths pass at the real boundary. An environment variable being present is not proof that the process uses it safely.

Recover

If a cloud adapter fails before performing external work, disable that explicit adapter and keep the deterministic test profile; do not weaken validation or reuse an administrative credential. If a provider may have accepted a request, preserve its request identity and reconcile the remote state before retrying.

If a credential may have crossed into a browser, sandbox, log, artifact, or repository history, revoke and rotate it before resuming. Keep the deterministic local story available while the provider path is disabled, and record the live smoke as an activation gate rather than implying success.

Next task

Review configuration ownership.