11 — RP Return GO / NO-GO Decision

Decision: RP cleanup = NO-GO (now enforced by a live fail-closed guard)

Decision matrix

#	Question	Answer
1	P1 detector views live?	✅ yes
2	P2 filesystem reconciler live & populated?	✅ yes (287 rows)
3	P6 preflight guard live?	✅ yes (fails closed, exit 3)
4	Backlog triaged?	✅ yes (doc 05; durable ledger)
5	dot-pivot-update classified & quarantined?	✅ STAGED_FILE_ONLY/UNBORN/NOT_VALID_DOT; guard BLOCK
6	Row-level governance bridge visible?	❌ no (P5 out of scope; deferred)
7	OSPA / human approval still blocking?	✅ yes (ospa=0)
8	dot-pivot-update GOVERNED_READY?	❌ no
9	Any unknown critical orphans?	⚠️ now known: 80 unborn + 6 real-missing + 16 fs
10	Can RP cleanup resume?	❌ NO

Why NO-GO

fn_assert_safe_for_dot_action() raises on 4 BLOCK dimensions: birth_orphan_critical_active=80, birth_phantom_real=6, fs_dot_file_no_registry=16, dot_pivot_update_not_governed=1. The difference from before: this is no longer a discretionary hold — it is a deterministic, reproducible gate that any future agent/operator/command hits.

Smallest next actions that would change the decision

RP can resume only when all four BLOCK dimensions reach 0:

1. Onboard dot_iu_command_catalog (register collection + meta + code strategy) → birth its 54 rows.
2. Birth the 27 pivot rows via lawful DOT (dot-pivot-declare/birth path; never manual UPDATE/INSERT).
3. Retire/restore the 6 stranded REAL_MISSING births (COL-171/172/173, SPE-NRC/NRM/NRR) — owner.
4. Register or quarantine the 16 FILE_NO_REGISTRY scripts (incl. dot-pivot-update) via lawful DOT.

Each of these is owner/credential-gated (admin creds for dot-dot-register are absent). None may be done by fabricating rows.

Forbidden-action compliance

RP cleanup NOT continued. dot-pivot-update NOT registered/executed. pivot_definitions NOT mutated. dot_tools NOT cleaned. No birth rows fabricated. No backlog rows deleted/hidden.