06 — Fix or Reconcile Plan

Recommended path: DOCUMENTATION RECONCILIATION

This audit (reports 00–07) is the documentation reconciliation. No additional code, migration, DML, rollback, or reapply is required for NVSZ Macro A to be considered governance-complete.

What this audit reconciles

Concern raised	Resolution
Macro A wrote Birth Execution Plan retrospectively	Acknowledged in [[feedback-birth-execution-plan-hard-gate-precedes-apply]]; binding for Macro B forward; NVSZ Macro A retained as PARTIAL_WITH_EXACT_GAP per the macro report
SUSPECT: prefix on COL-IUS-001/002	Triaged in report 05 as accepted historical pattern; no defect; soft annotation only
Whether NVSZ violated QT-001/QT-002	Classified in report 04 as Case 3 (Catalog Auto-Birth) — neither QT-001 nor QT-002; the canonical path the system uses for catalog rows
Auto-birth verification	Confirmed live in report 02: 28 triggers inventoried, fn_birth_registry_auto source retrieved, idempotent and correct
Per-object birth state	Documented in report 03; no orphan, no half-born
Whether birth pipeline needs a fix	Report 04 §10: NO for NVSZ. Optional independent improvement TD-411 (dot_origin_whitelist table) — beneficial but not blocking

What is explicitly NOT being done in this audit

• ❌ No new collection.
• ❌ No migration.
• ❌ No rollback of NVSZ substrate.
• ❌ No modification of NVSZ catalog rows, birth records, sidecar policy, or staging table data.
• ❌ No fix to birth triggers, fn_validate_dot_origin, fn_birth_gate, or tac_birth_gate_config.
• ❌ No Qdrant write, no vector indexing change.
• ❌ No MARK or CUT.
• ❌ No registration of D36-Macro-A in dot_tools (would clear SUSPECT prefix but is out of scope).

Optional future fix phases (each independent, each user-approved separately)

Option A — Minimal SUSPECT cleanup (≈ 5-line apply, ≤ 1 minute)

Trade-off: clears the visible audit annotation on NVSZ catalog and birth records, but leaves the underlying root cause (no whitelist for macro labels) for the next macro to hit again.

Steps inside one transaction, run as workflow_admin over pg_hba trust socket:

BEGIN;
-- 1. Register macro label in dot_tools (schema verification required first)
--    INSERT INTO dot_tools (code, name, ...) VALUES ('D36-Macro-A', 'D36 NVSZ Macro A', ...);
-- 2. Clear SUSPECT prefix on collection_registry rows
UPDATE collection_registry
   SET _dot_origin = 'D36-Macro-A'
 WHERE _dot_origin = 'SUSPECT:D36-Macro-A';   -- 2 rows
-- 3. Clear SUSPECT prefix on birth_registry rows
UPDATE birth_registry
   SET dot_origin = 'D36-Macro-A'
 WHERE dot_origin = 'SUSPECT:D36-Macro-A';    -- 2 rows
-- 4. Verify
SELECT entity_code, dot_origin FROM birth_registry
 WHERE entity_code IN ('COL-IUS-001','COL-IUS-002');
COMMIT;

Risks to consider before approving:

• dot_tools schema must be inspected first (category, lifecycle, name, etc.).
• UPDATE OF _dot_origin on collection_registry re-fires trg_validate_dot_origin_collection_registry; the dot_tools row must already exist or the UPDATE will re-prefix to SUSPECT.
• trg_birth_auto_certify and trg_birth_change_flag_matrix fire on the birth_registry UPDATE; these are designed for normal lifecycle and should not cause issues.

Option B — Macro-label family (≈ 10-line apply)

Same as Option A but generalized to all macro labels (D36-Macro-A/B/C, D37-Macro-A, …). Add a macro-label category in dot_tools and register the existing macro labels in bulk. Future macros pass the validator natively. Cleanup the SUSPECT prefix on the catalog rows + birth records the same way.

Option C — TD-411 (dot_origin_whitelist table)

The canonical fix. Move fn_validate_dot_origin's hardcoded whitelist into a dot_origin_whitelist table with rows like (origin_pattern, kind, rationale). Refactor the function to query it. This benefits all macros, not just D36. Requires a new mini-migration (1 table + function update + 1 DOT to register patterns). Pair with Option B to seed the whitelist with macro labels.

Option D — Bind Birth Execution Plan gate in CI/CD

Codify [[feedback-birth-execution-plan-hard-gate-precedes-apply]] as a pre-apply check in the macro tooling: a Macro is allowed to run substrate apply ONLY if a 01-birth-execution-plan.md already exists in its KB folder AND has all 9 required sections AND was authored before the substrate timestamp. Prevents the order violation from happening again. Independent of A/B/C.

What to do right now

Nothing in production. Accept the audit. Optionally:

1. Mark NVSZ Macro A as classification-resolved in the macro index.
2. Add Option D (CI pre-apply check) to the carry-forward backlog.
3. Schedule Options B+C for a later cleanup macro after Macro B finishes its primary scope.

STOP/route condition

This audit completes within the prompt's scope. The next action is GPT/User review of the verdict and a decision on:

(a) accept verdict as-is (recommended), or (b) approve Option A (small SUSPECT cleanup, NVSZ-only), or (c) approve Option B/C/D scheduling.