05 — Technical Addendum SCAFFOLD: SB-1 Governance APR Action-Types

This is a SCAFFOLD, not a technical design. It frames the future T3 design. It contains no SQL, no DDL, no DOT code, no handler code. Anyone writing the detailed design adds it as a new doc in this package and links it here.

Purpose

Frame the future design of the governance APR action-types that the apply/remediation path needs (to propose an owner edge or a governed exception) — without designing or building them yet.

Controlling inputs

• Concept canon doc 03 (SB-1 statement) and doc 01 (governed-object, responsibility-scope, governed-exception).
• Round-4 law-hardening doc 02 (closure ledger, C-2) + doc 08 (live apr_action_types=6, *=unimplemented).
• This package doc 03 §3.1 (SB-1) and §3.2 (C-2); doc 04 (T3).
• House law prompt-muc-tieu-mo-for-claude-code.md (Design-Only Macro Mode, no-hardcode).

Current blocker status

OPEN. Live apr_action_types lacks assign_governance_owner / grant_governance_exception / delegate_authority / assign_axis_owner. C-2 (council bundle decision) is unresolved. No action-type may be registered live until council rules and the human enact path runs.

Exact scope of the future design (T3)

• Specify the 4 action-types as data rows (name, description, handler_ref, approval routing, council-review requirement) — the recommended C-2 default is assign_governance_owner with a real handler and the other three routed to council-review.
• Define the interim governed-exception store = admin_fallback_log (C-2 default) pending a permanent store.
• Define the apply-readiness gate: what must be true before any of these is registered/used.
• Provide uncommitted rehearsal evidence (read-only / BEGIN..ROLLBACK) that registration is additive and reversible.

Dependencies

• Pairs with C-2 (council action-type bundle decision).
• Feeds T6 (scanner's propose/apply DOTs use these action-types).
• Interacts with SB-6/H-1 (no governance approval exists yet → live use is COMMIT_FORBIDDEN until the human phase).

Known constraints

• amend_law/enact_nrm handlers are unimplemented (SB-5) — do not assume an enact handler exists.
• No-hardcode: action-types are data, routed via registry, never hardcoded into a code branch.
• Reuse the existing APR / approval spine; do not invent a parallel approval mechanism (no local island).

Forbidden implementation shortcuts

• ❌ Registering the action-types live "just to test."
• ❌ Hardcoding action-type names into a handler switch.
• ❌ Granting an exception without the 11-field governed-exception contract.
• ❌ Treating a council default as a council ruling.

Acceptance criteria for the future detailed design

4 action-types fully specified as additive data; handler vs council-review routing defined; interim exception store named; apply-readiness gate stated; rollback + read-only rehearsal log; no committed mutation; no-hardcode attestation.

Where future detailed docs must be added

In this package (e.g. 05a-sb1-apr-action-types-design.md). Add a pointer line here when created.

What old docs must NOT be used as controlling input

• Round 1/2/3 wording about action-types (SUPERSEDED_BY_ROUND4).
• Any Registries-Pivot ship report's APR usage (TECHNICAL_REFERENCE_ONLY — those are S178 DOT-repair, out of governance scope).