# Offline Runtime Entrypoints

This directory contains environment adapters and supporting runtime modules.
It is not the formal release runbook.

## Current Staging authority

Formal Staging is serviceified D3. Its public controller is
`.github/workflows/deploy-staging-blue-green-environment.yml`, and its runtime
operator is `scripts/run_serviceification_d3_staging.py`.

The current contract is:

1. the workflow accepts one exact signed resolved-BOM digest;
2. the BOM independently selects L0 Engine, signed L1 AppRelease, and the exact
   L2 metadata commit;
3. preflight verifies those immutable artifacts before the optional database
   reset or target mutation;
4. live nginx state identifies the current slot and its two-slot successor;
5. Staging preserves the selected standby database unless the same dispatch
   explicitly authorizes its conditional Prod-clone reset predecessor;
6. the target converges from the verified BOM and must pass complete D3 and
   public ingress readiness before nginx changes;
7. a successful run uploads immutable `serviceification-d3-staging-<run-id>`
   evidence for the separate D3 Tag emitter.

The successful deployment conclusion is the Tag eligibility boundary. Formal
Staging does not publish a release Tag inline.

## Retired Candidate boundary

`deploy_staging_env.py`, `candidate_deployment.py`, and the Classic
release-manifest vocabulary are retained implementation or migration
references. The D3 Staging workflow does not invoke them as release authority.

Candidate sealing, Candidate S3 upload, `prod_release_eligible`, Classic
`staging-release-*` Tag publication, and Candidate promotion to Prod are
retired. The Classic Tag emitter, manifest renderer, Candidate checkpoint,
Tag-target verifier, release authority, and S3 artifact-store helpers have been
deleted. References to the remaining helpers in the Seed Catalog preserve
reviewed mutation ownership until their code is removed; they do not create an
operator entrypoint. Repository history is the authority for the deleted
Classic release procedure.

## Patch Bundle boundary

Patch Bundle is a manifest-backed migration input selected only by Staging.
The successful Staging dispatch records its nullable path/digest, the D3 Tag
copies that identity, and Prod replays it from the exact Tag-selected L2 tree.
Prod exposes no independent patch input.

`common.load_patch_bundle_definition()` and
`common.resolve_patch_sql_files()` are the canonical patch manifest and file
ordering contract. `deployment_patch_replay.py` owns idempotency validation,
bounded transient-connection retry, assertions, and replay evidence. Its deep
`execute_patch_bundle()` interface is shared by deployment adapters and the
independent `scripts/run_patch_bundle.py` CLI. The CLI requires an exact source
commit, one clean tracked bundle under `docs/migration/patch-bundles`, an explicit
target runtime env, a unique operation ID, and a new evidence directory.

The CLI is execution mechanism, not environment authorization. A production
migration through that standalone CLI still requires separate authority,
fencing, recovery, and readback; ordinary D3 Tag and Prod release surfaces do
not invoke the standalone CLI.

## Other environment adapters

- `deploy_offline_env.py` and `deploy_staging_env.py` retain shared D3
  initialization, credential, and quiescence helpers. Their Classic CLI
  entrypoints are retired and fail before performing any operation.
- The Classic CI workflow/adapter and monolithic backend launch helpers are
  deleted. Local application verification uses the D3 Compose operator.
- `test_slot_runtime.py` owns fixed Test slot identity and Test reset behavior;
  Remote Test full deployment runs through the exact manually selected
  controller ref and one signed BOM. That same canonical workflow also owns
  production-to-Test database refresh and selected-ref exact-digest SFCRM
  diagnostics; neither diagnostic is a release deployment or a second
  environment adapter.
- `deployment_runtime_state.py` owns environment-neutral offline runtime layout
  and runtime-env updates used by retained adapters.

## Shared operational rules

1. durable environment policy lives in `deployments/deployment-config.json`;
   host-local `runtime.env` files are rendered snapshots only;
2. deployment adapters resolve refs through the shared authority helpers rather
   than reimplementing per-environment ref policy;
3. nginx configuration is written atomically and changes only after target
   readiness;
4. deploy-owned Seed mutations enter through the canonical Seed Dispatcher and
   the reviewed Catalog profiles;
5. stable environment prerequisites belong in
   `seeds/deploy-baseline.seed.yaml`; run-specific fixtures stay outside deploy
   profiles;
6. secrets never belong in tracked Seed sources or release evidence;
7. case-specific Salesforce file repair and inspection workflows remain
   independent of release admission;
8. retained host-local copies of a removed stack must fail closed before
   mutating shared runtime roots.

## Monolithic launch retirement

The former Classic CI workflow and adapter, EXP/Staging CLI orchestration,
backend-runner generators, and monolithic start/install helpers are removed.
The shared offline and staging modules remain importable for current D3
initialization, credentials, database maintenance, and predecessor quiescence.
Their old direct CLIs fail with a retirement message before reading environment
files or performing host operations. Existing predecessor state is retained for
D3 handoff and inspection; removing source does not delete remote host state.

The Seed Catalog drops callsites and invocations owned solely by the removed
orchestration. Current D3 app-shell, Staging baseline/credential, and Test
reference-data calls retain their existing owners. CI now has no deploy Seed
invocations. Canonical dataset sources and manual adapter implementations stay
under their existing ownership; retirement does not authorize replaying them.