05 — P5 bad-input oracle + P6 false-PASS firewall (rows 12-23; A9-A13, A16)

P5 exact-oracle (sql/p5-bad-input-harness.sql)

c1_run(case_no, phase, label, exp_code, exp_state, query):

• EXECUTE q succeeds (bad input accepted) → INSERT outcome='accepted', pass=false (p5:26-29). Accepted invalid input is always a FAIL (A9 refuted).
• exception path → GET STACKED DIAGNOSTICS; rc := split_part(ms,' |',1); ok := (exp_code IS NOT NULL AND rc=exp_code) OR (exp_state IS NOT NULL AND st=exp_state) (p5:31-35). pass=true only on exact reject_code OR SQLSTATE match; an unexpected/unrelated exception → no match → pass=false (A10 refuted).
• The 9 cases map 1:1 to the reject codes raised by P3's c1_validate_operation (p3:29-38): missing code (C1_REJ_MISSING_CODE), dup (SQLSTATE 23505), empty title, invalid group, missing required_inputs, bad expected_outputs, unknown mode, case 8 = INSERT into official dot_tools expecting 42P01 (isolation proof), production_ready forbidden. The RAISE format CODE | detail makes split_part(ms,' |',1) return exactly CODE.
• FATAL gate p5:57-69 (DO block, ON_ERROR_STOP=1 → psql exit 3): requires total=9 AND accepted=0 AND failed=0 AND passed=9 AND residue (canonical_operation) = 3. Any violation aborts psql → the bin never prints P5_DONE (A16/A11 upstream). Per-case failed INSERTs roll back to the block savepoint, so residue stays 3 (row 23).

A13 — official table write hidden in SQL? NO

Case 8's INSERT INTO dot_tools(code) VALUES ('nope') runs inside the sandbox DB where dot_tools does not exist → 42P01. PostgreSQL cannot perform cross-database writes, so this can never reach the official directus.dot_tools. It is an isolation proof, not a write. No SQL file targets directus; all bins call psql with db = $SBX or postgres (maintenance, for CREATE/DROP DATABASE + pg_database reads only).

P6 false-PASS firewall (sql/p6-evidence-readback.sql)

1. Txn A (p6:22-39): define c1_digest(), register it, COMMIT — no verdict emitted.
2. Txn B (p6:43-87): LOCK TABLE canonical_operation, c1_test_results IN SHARE MODE, then a FATAL DO gate requiring: P3/P4/P5 ledger evidence present; nops=3; nvalid=3 validated; bad-matrix total=9/passed=9/failed=0/accepted=0; isolation proof = case 8 rejected with SQLSTATE 42P01; zero orphan public objects (tables relkind='r', functions, non-internal triggers). On any RAISE, ON_ERROR_STOP aborts psql at the DO block → no COMMIT, no digest persisted, no verdict (A11/A16).
3. Only if the gate passes: INSERT ledger row whose detail holds c1_digest() computed over the SAME SHARE-locked snapshot (p6:84-86), then COMMIT. Digest spans both vocab (vops, vocab_md5) AND the P5 harness rows (vharness, harness_md5) + combined_md5 (p6:26-36) → A12 refuted.
4. SELECT 'C1_STAGING_FAST_DRY_RUN_PASS' (p6:97) is unreachable if the gate raised (psql already exited), and the bin echoes P6_DONE only on psql exit 0.

Cross-stage consistency

P3 loads exactly 3 ops (status 'staged'); P4 marks them 'validated' (p4:15, gate nvalid=3 p4:36); P6 requires nvalid=3. P5 runs after P4 and only performs rejected (rolled-back) inserts, so canonical_operation stays at exactly 3 validated rows for P6. Fully consistent.