# Read-only preflight and schema-capacity stop gate

Use this pattern for sensitive-domain releases where a requested UI/workflow depends on durable corrections, provenance, or state transitions and the user forbids unapproved migrations.

## Read-only preflight

Before edits, verify repository/remote/runtime identity, clean status, protected fallback hash, service/listener state, read-only database integrity/foreign keys, queue emptiness, and worker health. Use authenticated private UI probes only when authorized.

A synthetic action smoke may open/close forms and navigate dependent views, but must not submit. Bracket it with business-table row-count and action-queue sentinels. Report aggregate evidence only; do not expose patient-, finance-, or record-level values.

For SPAs, distinguish a failed session bootstrap from a request cancelled because a later view navigation superseded it. Require successful session readiness, working protected endpoints, zero visible console/page errors, and unchanged sentinels before treating the latter as harness noise.

## Inventory semantic capacity

Do not inventory only row counts and visible UI labels. Compare every requested state and relationship with the active schema and worker contract:

- distinct business entities and statuses;
- immutable correction lineage and required correction reason;
- original versus replacement/effective state;
- planned versus actual values;
- source/provenance and timestamps;
- deterministic action identity, preview revision/digest, and replay behavior;
- optional structured fields that must remain queryable and safely projected.

A UI that displays headings such as planned/actual/missed/corrected does not prove that those states can be persisted safely.

## Mandatory stop condition

If durable semantics require fields or relations absent from the active schema, do not:

- pack structured state into a generic notes field;
- create browser-only correction state;
- infer missing values from labels or elapsed time;
- silently broaden status allowlists;
- run a migration when the governing sprint requires stop-and-report first.

Stop before repository edits, productive queue actions, commit, or deployment. Report:

1. green read-only preflight evidence;
2. sanitized aggregate inventory;
3. exact missing schema/worker capabilities;
4. why existing columns or generic action logs are insufficient;
5. minimal additive and backward-compatible proposal;
6. copy-first backup, migration-on-copy, idempotence, integrity/FK, logical-preservation, and restore-proof gates;
7. the precise approval required to continue.

## Additive design principles

Prefer extending established canonical tables and audit logs over introducing an unrelated parallel database. Preserve legacy values byte-for-byte and add canonical fields beside them. The mutation worker must assert the migrated schema and never create or alter it in the action path. Replays must resolve to the original result rather than create duplicate events.

After approval, begin with synthetic failing tests for state separation, immutable correction lineage, stale preview rejection, conflict detection, and replay idempotence. Test migration and restore on an independent database copy before any productive change.