Prepare local-with-cloud mode
Keep the proven local profile intact while preparing an explicit, least-privilege cloud activation.
Outcome
You can distinguish the deterministic Slice-0 environment from a later local-with-cloud profile and activate cloud services only after their owning adapters, credentials, and recovery checks exist.
Slice 0 runs the workbench and API on your computer, PostgreSQL in the repository's pinned Docker
service, and immutable artifact bytes on the local filesystem. It does not provide an active hybrid or
hosted profile. The cloud-oriented names in .env.example document intended ownership boundaries;
their presence does not make the corresponding provider path operational.
Prerequisites
Complete local setup and the first research story. Review the generated configuration reference before relying on an environment name: only settings present there are consumed by the current typed process configuration.
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
- Keep
pnpm bootstrapandpnpm devas the baseline. These scripts deliberately force the local database and artifact root, even when the ignored environment file contains cloud values. - Wait for the owning vertical slice to add a named, validated cloud profile and its provider contract tests. Slice 0 has no cloud activation command or supported environment switch.
- Activate one boundary at a time: canonical database and authentication, durable workflow service, immutable object storage, isolated compute, then model or connector providers. Do not create a partially hosted profile by pointing the development bearer token or local migration role at a public service.
- 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.
- 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.
- 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
For the current Slice-0 path, run pnpm check, then confirm the deterministic story succeeds without
cloud credentials. Confirm that pnpm dev binds the API and workbench to loopback and uses the pinned
Compose database plus .lumen-data/artifacts.
For a later cloud profile, verification is complete only when its documented profile command selects the intended adapters, startup rejects missing role-specific configuration, unconfigured UI is clear, 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 later profile fails before performing external work, stop it and return to the documented local 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.