# Release runway, schema freeze, and generated-runtime freshness

## Why this exists
Large bounded sprints can consume the execution budget during implementation and leave the explicitly authorized terminal steps (commit, push, deploy, smoke, hashes) undone. A technically green working tree is not a completed release.

## Reserve a release runway
Before the final implementation loop, reserve one uninterrupted closeout sequence:

1. focused final tests and static checks;
2. consume all delegated release-gating reviews;
3. final staged diff/privacy/medical review;
4. copy-first migration proof on the final schema;
5. commit and clean-tree verification;
6. push and remote-SHA verification;
7. atomic private deploy + unit reload/restart;
8. controlled pipeline run;
9. read-only runtime smoke;
10. runtime hashes, protected fallback hash, and final status.

Batch independent reads/checks, avoid repeatedly regenerating the same fixture, and stop nonessential exploration before it threatens this runway. If the execution environment announces an iteration/tool limit, treat the remaining budget as a release resource, not as room for more feature polishing.

## Schema freeze rule
- Run copy migration experiments while developing, but do not apply the private production migration until schema, worker payloads, CHECK constraints, and tests are frozen.
- If production was migrated before freeze and the schema then changes, the release candidate is not migration-complete. Add an idempotent in-place upgrade for already-created intermediate tables (new nullable columns, constraint-compatible table rebuilds), take a new owner-only backup, and rerun copy-first/idempotency/integrity/FK/restore gates.
- Never assume `CREATE TABLE IF NOT EXISTS` upgrades an existing table. Explicitly inspect columns and stored `sqlite_master.sql` constraints.
- Preserve legacy row counts/digests across rebuilds; migration-marker presence alone is insufficient.

## Generated runtime freshness
Browser evidence is valid only for assets generated from the current tree.

After any renderer, JS, CSS, feature-flag, or fixture change:
1. rebuild the synthetic DB if schema/data contracts changed;
2. regenerate HTML with the exact production feature profile;
3. recopy runtime assets to the isolated temp server;
4. restart the isolated server;
5. rerun only the affected browser group.

An API returning the new contract while the test server serves an older copied JS/CSS file is a stale-runtime failure, not a product-contract failure. Inspect the served asset, not only the source tree.

## Final-report honesty
If a hard execution limit interrupts the runway, report exactly which terminal actions did and did not occur. Do not describe a staged tree or successful private migration as committed, pushed, or deployed. Resume from the staged diff and revalidate any gate invalidated by subsequent edits.