04 — DOT Cleanup: Execution / Blocker

Decision: HELD — zero production mutation

The mission permits persistent prod mutation only through a verified Đ26/DOT path for safe RP classification cleanup, and explicitly allows the outcome "safe cleanup executed or correctly held" (Completion criterion 5; PARTIAL).

Applying the gate to each candidate:

Cond.	A (comp fix ×3)	B (domain ×12)	C (RP-local ×14)	D (retire ×2)
DOT path verified	❌ none exists	❌ none exists	n/a	✅ DOT-314
Bounded	—	—	✅	✅
Reversible	—	—	✅	⚠️ no un-retire DOT
No manual UPDATE	✅ (we issue none)	✅	✅	✅
No L2 dependency	✅	✅	✅	✅
No event/system_issues	✅	✅	✅	✅
No ambiguous naming	✅	❌ needs council	✅	✅
Executable now?	NO (no tool)	NO (no tool + council)	N/A (done)	NO-OP (already inactive)

Why each is held

• Action A (PIV-001/016/021 composition fixes): No DOT can perform a targeted field UPDATE. dot-pivot-declare is INSERT-only; the matrix DOTs only touch matrix_spec/is_active. A manual UPDATE is forbidden (Đ26 §II-QUINQUIES) and would fire the 3 triggers uncontrolled. Blocker: missing governed tool → author dot-pivot-update (doc 08, sql/05_*).

• Action B (12 domain assignments): double-blocked — same missing tool, plus the FAC-02 target for each is a genuinely semantic decision the council must ratify (doc 05). Not auto-ratified (forbidden).

• Action C (14 RP-local rows): complete by design. The values are correct as RP-local pivot-shape / drill metadata; the live view's derived columns (registry_group_kind, pivot_kind, composition_status='drill_overload') are the fix. No data change is needed or wanted.

• Action D (PIV-020, MTX-TEST): already inactive. dot-matrix-retire early-exits on is_active='f' and writes nothing. There is no mutation to make. (PIV-020's NULL superseded_by is cosmetic and unreachable via DOT-314.)

What was NOT done (forbidden / unsafe), and why

• ❌ Manual UPDATE pivot_definitions — Đ26 §II-QUINQUIES; would fire 3 triggers.
• ❌ Retire+recreate workaround — duplicate-guard self-blocks + identity-breaking (doc 03 R4).
• ❌ Registering/executing dot-pivot-update — it is unregistered and untested; DOT execution requires a verified, registered tool + explicit owner-go.
• ❌ Applying the optional health view — outside "RP classification cleanup via DOT"; this macro keeps prod byte-identical (held, paste-ready in sql/02_*).

Net effect on production

Zero mutations. pivot_definitions fingerprint unchanged (md5=4eb00c8fe4d0937325278d7e5e12b7a3, entry==exit). L2 gate unchanged (ospa 0 / own 0 / gap 210 / emit 0). The only live RP-classification object remains the mapping view applied by the prior macro.

The corrected blocker statement

RP L1 classification cleanup is blocked not by L2 governance, but by a tooling gap: the pivot domain lacks an update-capable, governed DOT. Unblock = author + register dot-pivot-update (one engineering task, owner-operated), then Action A executes deterministically and Action B executes after council naming ratification. Neither requires L2 rollout (ospa≥1).