09 — Registries-Pivot Future Design Patch Plan

Branch I. This is a PLAN, not a patch. No canonical design doc is modified by this mission. Targets are the live-verified filenames under knowledge/dev/design/registries-pivot-os-agency/ (14 docs, confirmed 2026-06-01). The mission's assumed names are corrected here.

9.1 Filename reconciliation (verified)

Mission assumed	Live actual	Action
00-overview-control.md	00-master-design-v0.1.md	patch real file
04-dynamic-drilldown-layer-model.md	04-dynamic-drilldown-layer-model.md ✓	patch
07-label-grouping-policy.md	07-label-grouping-policy.md ✓	patch
new 08-pin-phantom-pivot-coverage-governance.md	08-pin-ghim-policy.md already exists	renumber → new 14-governance-coverage-and-anarchy-detection.md
10-ui-contract-os-agency.md	10-ui-contract-os-agency.md ✓	patch
12-implementation-readiness-gate.md	12-implementation-readiness-gate.md ✓	patch
13-next-macro-prompts.md	13-next-macro-prompts.md ✓	patch

These will be content-only, no-version-bump editorial patches in the future patch phase (doc 10 phase 2), each adding a One-Roof section referencing this pack. No version increment, no status change.

9.2 Per-doc patch specifications

P-09.1 → 00-master-design-v0.1.md

• Section to add: §0.X One-Roof Governance Statement (near the control/scope block).
• Content: Registries-Pivot is governed under the central roof; it owns no local governance. Policy → GOV-COUNCIL, health/coverage → GOV-SIV, DOT → GOV-DOT, render → GOV-MOUT. Add the One-Roof verdict (doc 00 §0.4) and a pointer to this pack.
• Purpose: make non-islanding the first architectural constraint, before any surface decision.
• Dependency: doc 01.
• Acceptance: the master design names the four owners and states "no local governance island" as a binding constraint; a reviewer can trace every RP governed object to an owner.

P-09.2 → 04-dynamic-drilldown-layer-model.md

• Section to add: §X Grouping/layer is a governance-covered object.
• Content: every drill-down layer and grouping rule is a governed object (class grouping_policy); the layer model must resolve an owner (GOV-COUNCIL) and approval path; ungrouped-ceiling (≤50) is a governed threshold, not a code literal. Drill-down from coverage summary (L5) → orphan exemplars (L4) → object (L3) → DB substrate reuses the existing recursive contract.
• Purpose: prevent grouping from becoming a local policy island.
• Dependency: doc 02, doc 04, doc 08 §8.4.
• Acceptance: layer model references owner_gov_code + APR for any grouping rule; no grouping literal in the drill-down spec.

P-09.3 → 07-label-grouping-policy.md

• Section to add: §X Grouping policy governed by central framework.
• Content: grouping/classification/threshold policy owned by GOV-COUNCIL, sourced from Điều 24 faceted SSOT (taxonomy_facets/label_rules/entity_labels), changed only via APR; max_ungrouped is a ceiling CHECK ≤50 in a governed PG table. Forbid a standalone registry_grouping_policy/display_policy without owner_gov_code.
• Purpose: bind the existing 50-ceiling design to central ownership.
• Dependency: doc 08 §8.4.
• Acceptance: the policy section names GOV-COUNCIL owner + APR + PG ceiling; CI rule F-ISLAND-3 referenced.

P-09.4 → NEW 14-governance-coverage-and-anarchy-detection.md

• Why new + why #14: 08 is taken (08-pin-ghim-policy.md); coverage/anarchy detection is a distinct concern spanning pin + phantom + pivot-coverage, so it gets its own doc appended after 13.
• Content: import doc 03 (orphan/anarchic/island), doc 04 (coverage invariant + GOVERNANCE_COVERAGE_PASS), doc 05 (6-layer detection), doc 07 (#14 pivot_coverage_unowned, the phantom-definition gap, pin-policy ownership). Define how RP displays coverage (pivot-backed) and how pin/phantom/pivot-coverage are governed objects, superseding the scattered treatment in 06-orphan-phantom-unmanaged-policy.md and 08-pin-ghim-policy.md by adding the governance lens (not rewriting them).
• Purpose: give RP one canonical home for governance-coverage detection.
• Dependency: docs 03–07.
• Acceptance: doc exists; defines orphan/anarchic/island for RP; defines the coverage invariant + gate; cross-links 06 and 08 without duplicating them (Điều 37 §4.12 SSOT).

P-09.5 → 10-ui-contract-os-agency.md

• Section to add: §X UI displays governance state; does not decide it.
• Content: RP UI renders v_governance_coverage_summary + pivot results via a registered design_template; no governance/count/grouping computation in Nuxt (Điều 28 NT-D1). Retire the live anti-patterns: health.get.ts:123 totalGap=reduce(+Math.abs(gap)), index.vue hardcoded CAT-017/orphan_count:hd.totalGap. Coverage tiles are drill-down dimensions, not hardcoded strings.
• Purpose: enforce render-shell discipline for the governance display.
• Dependency: doc 05 §5.3, doc 07 §7.6, doc 08 §8.6.
• Acceptance: UI contract states "display-only, pivot-backed"; lists the exact files/lines to retire; Test-4 (100% Nuxt=PG) applies to coverage tiles.

P-09.6 → 12-implementation-readiness-gate.md

• Section to add: §X GOVERNANCE_COVERAGE_PASS gate (alongside RG1…RG9 / REUSE-EXTEND-WRAP-RECONCILE-DEFER-NEW).
• Content: add the gate predicate (doc 04 §4.6): a feature ships only if governance_orphans(feature)=0 (or approved exception), evidence-based (no blind PASS, Điều 30 §V). Classify each RP governed object (display_policy, registry_pin, pivot coverage, Direct-PG adapter, DOTs) as REUSE/EXTEND/NEW + its owner + its current gap.
• Purpose: make governance coverage a hard ship gate for RP.
• Dependency: doc 04, doc 06.
• Acceptance: gate is in the readiness checklist; each RP object has an owner + classification + coverage status row.

P-09.7 → 13-next-macro-prompts.md

• Section to add: update the macro roadmap so every future RP macro requires GOVERNANCE_COVERAGE_PASS as a precondition and references the One-Roof DOT lifecycle (doc 06) before any PG/UI work.
• Content: insert the governance-coverage view-rehearsal and scanner-DOT-design macros ahead of the existing F1/F2/F3 surface macros; gate F-series on coverage pass.
• Purpose: sequence governance coverage before surface build (GPT direction: "governance alignment macro, not a UI patch").
• Dependency: doc 10, doc 12.
• Acceptance: roadmap shows coverage macros before surface macros; each macro lists the coverage precondition.

9.3 What this plan deliberately does NOT do

• Does not add owner_gov_code columns to RP tables (ownership stays relational, doc 02 §2.2).
• Does not create display_policy/registry_pin as standalone tables — they are governed objects pending owner + APR (doc 08 §8.4).
• Does not rewrite 06-orphan-phantom-unmanaged-policy.md or 08-pin-ghim-policy.md — it adds a governance lens via the new doc 14, preserving SSOT.
• Does not patch anything in this mission — execution is doc 10 phase 2, after council review (doc 10 phase 1).

9.4 Patch ordering & dependency

P-09.1 (master)  ─┐
P-09.4 (new 14)  ─┼─→ P-09.2 (drilldown) ─→ P-09.3 (grouping) ─→ P-09.5 (UI) ─→ P-09.6 (gate) ─→ P-09.7 (roadmap)
                  └ (define concepts first, then apply to each surface doc)

All seven are content-only, no-version-bump patches executed together in doc 10 phase 2, each carrying a header note "supplemental One-Roof alignment; no version change."

Cross-refs: doc 10 (when these patches run), doc 12 (the paste-ready patch prompt).