15 — Next Paste-Ready Prompts

Eight paste-ready macros for the next steps. Each is standalone, names its read sources, and restates the forbidden list. Pick by the doc-14 verdict: prompts 1–2 if you want one more review pass; 3–5 are the GO-track design patches; 6 is content-only law cleanup; 7 is CI; 8 is the RP UI correction. All remain read/design only unless a prompt explicitly enters a ratified build phase.

---

Prompt 1 — One more adversarial review (if you want a third pass before patching)

MISSION: ONE_ROOF_HARDENING_REVISION_ADVERSARIAL_RECHECK
Effort xhigh. Read-only. No mutation, no enactment, no version bump, no approval, no canonical patch.
Read: knowledge/dev/reports/architecture/one-roof-governance-hardening-revision-all-domains-all-axes-2026-06-01/ (all 17 docs).
Task: adversarially attack the FOLDED model. Specifically try to break:
- M-DEF-8/9 open-axis model: find an axis-bearing surface the Axis Registry reconciliation would miss.
- M-DEF-7 grain: construct an inheritance case where a child authority gap still hides.
- doc 11 anti-spam vs doc 09 anti-hiding seam (§11.7): find a case that is both over-aggregated AND a real gap.
- the CONDITIONAL GO: argue whether any of the 4 🟧 scenarios is actually an uncaught critical (not just remediation-pending).
- IU: find an IU operation/axis not covered by the 17 classes in doc 03.
Output a standalone critique doc: confirmed-holes / false-alarms / verdict (upgrade or hold CONDITIONAL GO).
Do NOT patch the package; produce a separate review doc.

Prompt 2 — Cowork / Claude Desktop critique of the hardened law model

Please critique this hardened One-Roof Governance law/design model for a multi-agent OS.
Context docs (KB): one-roof-governance-hardening-revision-all-domains-all-axes-2026-06-01/ docs 02 (open axis), 03 (IU), 05 (Đ37 hub), 06 (classes), 09 (invariant), 13 (clauses), 14 (go/no-go).
Questions:
1. Is "axis as a governed object + Axis Registry + shared-truth predicate" a sound way to avoid hardcoding axes, or does it just move the hardcode into the registry schema?
2. Is "one accountable owner per (object × scope)" the right reconciliation of federation with a one-owner constitution clause?
3. Is the CONDITIONAL GO defensible — concept docs GO, apply docs wait on one substrate delta — or should the whole thing hold?
4. Does folding IU as a domain (not dissolving its microcosm) create a hidden second governance system?
Give a frank critique with the 3 weakest points and whether you'd patch canonical design now.

Prompt 3 — Canonical design patch (GO track; concept docs only)

MISSION: ONE_ROOF_CANONICAL_DESIGN_PATCH_CONCEPT_DOCS
Effort xhigh. Patch CANONICAL DESIGN DOCS ONLY (not law). No law enactment, no version bump, no normative_registry/law_catalog touch, no approval, no PG/Directus/Qdrant/Nuxt mutation, no route/table/UI.
Read: the hardening-revision package (all 17 docs), esp. doc 13 (clauses) + doc 14 §14.2 (GO scope).
Also read: knowledge/dev/design/registries-pivot-os-agency/ (the canonical design package).
Task: fold doc 13's M-DEF-1..9 + Đ37 §4.15/§4.15-bis/-ter/-quater/§4.16/§4.17/§4.18/§5.4-EXT + §0-GOV hook into the canonical design docs for: One-Roof principle, governed-object contract, anarchy definition, OPEN-AXIS MODEL + Axis Registry, IU coverage concept (NOT owner-binding), coverage invariant v2, detection obligations, Đ37 hub.
HARD CONSTRAINT: every patched doc must (a) carry the hardened definitions verbatim, (b) explicitly flag T1-6 (object/axis edge + 4 APR action-types) as a substrate prerequisite gating the apply surfaces, (c) flag OP-B (IU owner) as a council decision gating IU surface docs.
Do NOT patch apply/remediation-binding docs or IU surface docs (NO-GO scope, doc 14 §14.3).
Output: patched canonical design docs + a patch-log doc listing exactly what changed and what was deferred.

Prompt 4 — Technical design for the governance-coverage scanner / DOT (GO track)

MISSION: GOVERNANCE_COVERAGE_SCANNER_DOT_TECHNICAL_DESIGN
Effort xhigh. DESIGN ONLY. No PG/Directus mutation, no DDL, no DOT registration, no enactment, no approval.
Read: hardening-revision docs 09 (invariant v2), 10 (detection obligations), 11 (noise control), 06 (profiles), 02 (axis registry).
Task: design (NOT build) the GOV-SIV coverage scanner + GOV-DOT coverage-DOT lifecycle as an EXTENSION of the existing Đ31 orphan/integrity pattern (reuse, do not island):
- the 6 detection layers (doc 10 §10.3) as views/functions (design only);
- L0 ground-truth inventory set incl. route inventory (nginx+Nuxt derived) + Axis Registry;
- the coverage identity + closure check (doc 09 §9.2) as a view;
- the coverage-DOT lifecycle DETECT→PROPOSE→APPROVE→APPLY→VERIFY→CLOSE with SoD + seed attestation;
- anti-spam (coalesce keys, grain aggregation, emit ceiling) per doc 11.
EXPLICITLY mark the two-mode apply: Mode 1 (agency→law, works today) vs Mode 2 (object/axis edge, BLOCKED until §5.4-EXT). Design the §5.4-EXT table + the 4 APR action-types as a SEPARATE prerequisite spec.
Output: a technical-design package (no code executed), with BEGIN..ROLLBACK rehearsal SQL authored but NOT run.

Prompt 5 — IU governance-coverage design (split out; needs OP-B first)

MISSION: IU_GOVERNANCE_COVERAGE_DESIGN
Effort xhigh. DESIGN ONLY. No mutation, no DOT registration, no enactment, no approval.
PRECONDITION: confirm the council has resolved OP-B (IU family owner_agency_code) and OQ-IU-OWNER (review_decision as governed approval-adapter exception, or migrate to Đ32). If unresolved, STOP and produce an OP-B decision packet for the council instead.
Read: hardening-revision doc 03 (IU coverage), doc 02 (axis registry), doc 06 (Class 11 IU-OP), doc 08 (exception model); knowledge/dev/laws/dieu44-trien-khai/ (IU design family); the dot_iu_command_catalog (54) + dot_tools (Đ35 SSOT).
Task: design the de-islanding of IU:
- map the 54 dot_iu_command_catalog tools into dot_tools (Đ35) with paired_dot tiers (design only);
- register IU axes (A/B/C + composition/species/relation/label/vector/lifecycle/workflow + future) into the Axis Registry (design rows, not inserted);
- wire IU issues/events into the central GOV-SIV detector + the new governance/integrity event domain;
- record the IU reconstruction + vector invariants as non-exemptable (doc 03 §3.4);
- assign owners per scope (doc 03 §3.5).
Output: an IU-coverage design package + the exact APR proposals needed (NOT filed).

Prompt 6 — Law clause content-only correction (resolve doc-drift before any law patch)

MISSION: GOVERNANCE_LAW_CONTENT_ONLY_CORRECTION
Effort high. CONTENT-ONLY corrections to law DOCS; no enactment, no version bump, no status change, no normative_registry/law_catalog row change, no approval, no PG mutation.
Read: hardening-revision doc 04 §4.4 + doc 14 §14.3 (doc-drift list).
Task (owner GOV-NRM-SYS, content-only): resolve the authoritative-status ambiguities WITHOUT enacting:
- Đ45 `ban_hanh=false` leftover — determine + document the correct enacted text;
- Đ36 v4.0 vs v5.0 — determine the authoritative version;
- enacted Đ37 v3.3 capability JSON vs live columns — document the drift + the correct text;
- the stale governance_docs UI index.
Output: a content-correction report stating, per item, the authoritative text and the drift — for the human ratification phase to act on. Do NOT change any registry row.

Prompt 7 — No-local-governance CI prompt

MISSION: NO_LOCAL_GOVERNANCE_ISLAND_CI_DESIGN
Effort high. DESIGN the CI checks; do not wire them into a live pipeline without approval.
Read: hardening-revision doc 10 (detection), doc 06 (classes), doc 02 (axes), doc 05 (§0-GOV hook).
Task: design CI checks (F-ISLAND-*) that fail a build/deploy when:
- a mutating routine is outside dot_tools / has no paired_dot (Class 5);
- a route in nginx/Nuxt is not owner-mapped (Class 6);
- UI/Nitro server/api computes governance/count/grouping truth or hardcodes an axis list (Đ28 NT-D1-ext);
- a policy/threshold literal appears in code instead of a governed row (Class 4);
- a new law/design doc lacks a §0-GOV hook (Class 8);
- an axis-bearing surface is absent from the Axis Registry (Class 3).
Each check: detection method, severity, which gate phase (G-DESIGN/IMPL/ROUTE/PROD), and the issue_type emitted.
Output: a CI-design doc + sample (non-wired) check scripts.

Prompt 8 — Registries-Pivot UI correction after governance coverage

MISSION: REGISTRIES_PIVOT_UI_GOVERNANCE_COVERAGE_CORRECTION
Effort high. DESIGN + (only after RG-ratification) implement. Until ratified: design only, no route/UI/PG mutation.
Read: hardening-revision doc 02 §2.8 (axis display), doc 10 §10.5 (detection→display), doc 14; prior RP ship memory (registries-pivot route LIVE).
Task: design the Registries-Pivot surface so it:
- lists every registered axis (Axis Registry) with its 9 attributes + coverage state, pivotable by family/owner/scope/lifecycle;
- shows governance-orphan / island / axis_unregistered / exception rows alongside object orphans (NO separate page);
- computes NO governance/count/axis truth in Nuxt or Nitro server/api (reads L5/pivot/coverage views only) — retire the known violations (health.get.ts:123 totalGap reduce; index.vue CAT-017/orphan_count:hd.totalGap);
- removes any hardcoded axis list from the UI (Class 3 / red-team #37).
Output: a UI-correction design doc; implement ONLY after the human ratifies the governance-coverage views (RG-style sign-off) — re-verify os_proposal_approvals before any commit.

Recommended order

1. Prompt 3 (concept design patch) — the GO-track next macro.
2. Prompt 6 (content-only law cleanup) in parallel — unblocks later law patch.
3. Prompt 4 (scanner/DOT technical design) — includes the §5.4-EXT + action-type prerequisite spec (clears T1-6 on paper).
4. Prompt 5 (IU design) once council resolves OP-B (use Prompt 5's OP-B decision packet path if not).
5. Prompts 7/8 (CI + UI) after the scanner design.
6. Prompts 1/2 anytime you want an independent adversarial/Cowork pass before patching.