05 — Objective D: DOT / Handler Simulation Boundary

Verdict: REHEARSAL PASS (3/3) rollback-only. Registration is rehearsable + reversible on clone; actual DOT execution is OUT-OF-DB → BLOCKED (precise blocker below). SQL: sql/D_dot_register_rehearsal_rollback_only_clone.sql

DOT surface (verified live on clone)

• DOT tables: dot_config, dot_coverage_required, dot_domain_rules, dot_domains, dot_iu_command_catalog, dot_iu_command_run, dot_iu_runtime_lease, dot_operations, dot_tools, dot_tools_domain_backup, law_dot_enforcement (+ views). dot_tools=309.
• dot_tools carries 13 triggers. An INSERT fans out to:
  • BEFORE: gen_code_dot_tools (auto-code), fn_birth_gate, fn_validate_dot_origin, fn_normalize_dot_filepath, fn_description_birth_guard.
  • AFTER: fn_birth_registry_auto('code') (fired twice → writes birth_registry), fn_auto_label_provenance, fn_auto_label_assignment, refresh_registry_count, fn_refresh_dot_count, trg_fn_refresh_orphan_dot.
  • AFTER INSERT/UPDATE OF status,tier: trg_context_pack_dot_register → fn_context_pack_on_dot_register.
• fn_birth_gate runs 5 fn_pre_birth_check checks; mode = current_setting('app.birth_gate_mode') defaulting to warning (non-blocking) — a failed check WARNs, does not abort.
• fn_context_pack_on_dot_register calls pg_notify('context_pack_event', …) iff status='active' AND tier ∈ ["A","B","C"] (live watch config). pg_notify is delivered only on COMMIT; a ROLLBACK discards it.
• dot_coverage_required = 11 rows (domain, operation, tier, description) — the DOT-side coverage-requirement registry, distinct from governance object ownership.
• Execution ledger: dot_iu_command_run=55, dot_iu_command_catalog=54, dot_iu_runtime_lease=0 (nothing executing).

Rehearsal (rollback-only) — 3/3 PASS

Registered a dry coverage-scanner DOT with status='published' (not active, so the NOTIFY branch is never taken), tier=NULL, whitelisted _dot_origin='DIRECTUS':

#	check	result
D1	dry registration accepted (gate WARNed on code format, did not block)	PASS
D2	dot_tools 309 → 310 inside txn	PASS
D3	birth_registry side-effect observed (1,090,053 → 1,090,058 inside txn)	PASS

Post-rollback: dot_tools=309, dot_iu_runtime_lease=0 — fully restored. The birth gate emitted WARNING: Code "DOT-CLONE-TEST-COVSCAN" sai format (warning mode) and proceeded — confirming registration is non-blocking but not side-effect-free (5 birth_registry rows were written in-txn).

Boundary determination

operation	on clone	on production
Register a DOT (INSERT dot_tools)	rehearsable rollback-only; real birth_registry writes + (conditional) pg_notify — contained by rollback	NO-GO (writes birth_registry, may emit pg_notify; governed)
Run a DOT (execute script_path)	BLOCKED — not a DB operation	FORBIDDEN

Precise blocker for "run a dry DOT scanner"

There is no SQL mechanism to execute a DOT. Execution means an external runner (a) acquires a dot_iu_runtime_lease, (b) executes the tool's script_path on the host filesystem (shared container, NOT isolated to the clone DB), and (c) records a dot_iu_command_run. Step (b) is a genuine external side effect outside Postgres isolation; running it "on the clone" would still execute host-level code. Therefore no DOT was executed, on clone or production.

Recommendation

Do not model the governance coverage scanner as an executable dot_tools row. The coverage scan is correctly implemented as the SQL scanner already proven (prior Steps A–E + this macro's regression suite): idempotent, bounded, side-effect-free, and requiring no external runner, no lease, no birth_registry write, and no pg_notify. If a DOT registration is ever wanted for catalog/discovery purposes, register it with a non-active status (no NOTIFY) and accept the birth_registry append as governed provenance — but keep scanning in SQL.