# Sensitive post-action read-only preflight

Use after a user has manually completed a sensitive queued action and before beginning the next implementation or release phase.

## Fail-fast verification

1. Open the productive SQLite database with URI `mode=ro`; set `PRAGMA query_only=ON` and `PRAGMA trusted_schema=OFF`.
2. Require exactly one candidate at the commissioned business timestamp and exactly one same-day logical event.
3. Compare every required structured field. Use decimal equivalence for numeric quantities and only narrowly documented canonical formatting for composite values; never normalize enough to hide a unit or strength mismatch.
4. Bind audit records using their real identity contract. For the Health capture queue, `capture_action_log.entry_id` points to the opaque `capture_entries` row, not to `medication_administrations.id`; bind the medication projection through `medication_administrations.business_revision == capture_action_log.action_hash`, and separately require one active capture entry.
5. Count pending, processing, and failed queue markers independently. Do not count receipt subdirectories as pending work.
6. Verify latest one-shot worker result/exit status plus watcher state.
7. Run read-only integrity and foreign-key checks.
8. Only after all prerequisites pass, verify every requested API/browser projection. On any duplicate, queue residue, or contract inconsistency, stop before UI checks, implementation, regeneration, backup, commit, or deployment.

## Privacy-safe failure report

Report only aggregate technical evidence: exact-record count, duplicate status, queue counts, worker status, integrity/FK result, and number of structured fields that differ. Do not print sensitive values, record names, timestamps, notes, paths, filenames, or internal identifiers. Explicitly state that no mutation or later phase started.

## Pitfalls

- Comparing unrelated row IDs creates a false missing-audit finding.
- Empty queues and a successful worker do not prove the projected business contract is correct.
- One exact timestamp match does not prove absence of a same-day duplicate.