Ledger convergence: registration home + one store implementation + permission-set convergence (ADR-0126 §4/§8, maintainer-ruled bundle)

[os-support-ai]

Part of #12150 (Epic: ADR-0126 implementation, v17 line — 17.x minor, maintainer-ruled).
Maintainer ruling, 2026-08-26, live PM chat, verbatim: 「同意」 — to the three-part package presented with four-axis analysis (full ruling record: #12359 comment 5419050253): #12359 option B, #12350, and this card's original L8 scope are one card, one PR, one verification pass. This card is that card; its PR closes #12159, #12350 and #12359.
Dispatch: coordinated under the #12150 program — ⛔ not from the general queue (maintainer anti-preemption instruction, 2026-08-25, PM session session_01KWRU3s15AJz7PGW7a7wdCh). Contract: ADR-0126 §4 walls + §8 items 2–3, ADR-0029 D7 (object ownership), ADR-0068 D2 (write authority unchanged).

Part 1 — registration home (#12359, ruled: option B)

sys_metadata_activation registration moves from the automation service's manifest (registerRunObject, beside sys_automation_run/sys_flow_dispatch) to PlatformObjectsPlugin — where the object is declared, beside SysMigration/SysMigrationJournal/SysSecret. Move, not add: single owner, no double registration. Consequence: every composition carrying platform-objects has the ledger, so packaged-action disable works without the automation service, and every future Regime C consumer inherits it.

• The Packaged-action disable is unavailable without the automation service — sys_metadata_activation has only one registrant #12359 measured 503 (actions-and-no-automation boot, bootStack(showcaseStack) + flip → SERVICE_UNAVAILABLE) becomes this part's positive test: same boot, flip succeeds, disable consulted at dispatch.
• A composition with automation must be measured too: boot order, metadata:reloaded re-attach (both the flow and the action projections hydrate), no ownership-diagnostic regression (ADR-0029 D7).

Part 2 — one store implementation (#12350)

One metadata_type-parameterized store replaces the two copies of the §4 row contract (ObjectStoreFlowActivationStore in service-automation, ObjectStoreActionActivationStore in objectql). Home: a package BOTH may depend on — @objectstack/core is the leading candidate (#12350's own analysis); ⛔ platform-objects as code home would invert the tiering for objectql (orthogonal to Part 1's registration move, which is composition-level). Both consumers move onto it; the row semantics stay byte-equivalent: install-level rows only, org-carrying rows skipped on read, driver 0 read as false, read-then-write, no engine-slice delete.

• Both existing pin suites (flow-activation-ledger.test.ts, action-activation.test.ts) stay green unchanged — they pin the contract, so they are the proof the consolidation lost nothing.

Part 3 — permission-set convergence (original L8, ADR-0126 §8 item 3)

Decide and implement how sys_permission_set.active (the #11513 row-state door, permission-set-projection.ts #4669 carve-out) relates to the generic ledger — projection (column stays, ledger reads through) vs migration (rows move, column retired). §4 walls inherited: no definitions in the ledger, no linkage columns.

• A short decision note on this card before code (which route, and the measurement that grounds it); ⛔ if the choice has customer-visible consequences, stop-and-report to the maintainer instead of choosing.
• Landed Studio save of a package-declared permission set forks it into a silent, undiscoverable overlay #11513 behavior unchanged from the customer's seat (lock message, clone action, deactivate semantics); existing sys_permission_set.active values preserved whichever route.

Acceptance

• One PR, Closes #12159, Closes #12350, Closes #12359; three parts verifiable independently in the diff.
• Actions-only boot: flip works end-to-end (Part 1 positive test); automation boot: flows + actions both keep working.
• Both activation pin suites green unchanged; Studio save of a package-declared permission set forks it into a silent, undiscoverable overlay #11513 suites green unchanged.
• No packages/spec surface; smooth upgrade (the table already exists in live databases — moving its registrar must be a no-op for existing data).

Refs: #12359 (ruling) · #12350 · ADR-0126 §4/§8 · ADR-0029 D7 · #11513/#4669 · permission-set-projection.ts:1128-1145

[os-support-ai]

Claiming — dispatched under the #12150 program (standing autonomy ruling, maintainer, 2026-08-25, verbatim: 「继续自主完成所有开发」; bundle ruling 2026-08-26, verbatim: 「同意」).

• Session: session_01KWRU3s15AJz7PGW7a7wdCh (PM session; implementation delegated to an os-dev agent under this session)
• Branch: claude/issue-12159-ledger-convergence
• Unlock condition satisfied: original Blocked-by L1: sys_metadata_activation platform object — the activation ledger (ADR-0126 §4) #12155 merged long since (428f9b24); both store copies this card consolidates are merged (feat(automation): durable packaged-flow disable — activation ledger, execute() consult, operator gate #12296 15249270, feat(actions): durable packaged-action disable — same activation ledger, dispatch-time consult #12348 e5ce2ed0).

---

Generated by Claude Code

[os-support-ai]

Part 3 — decision note, and a STOP

Posted before any Part 3 code, as the card requires. Verdict: stop-and-report. The measurement says the choice has customer-visible consequences either way, which is the card's own trigger for not choosing on the maintainer's behalf. Parts 1 and 2 are implemented and delivered; Part 3 carries no code.

All numbers below are from a real boot — bootStack(showcaseStack), rows read through the engine under a system context — not from reading source.

What is actually in sys_permission_set

total = 17    managed_by = { platform: 8, package: 9 }
              with package_id = 9      (so 8 of 17 carry NONE)
              inactive = 0             org-carrying = 0
indexes    = [ {name, unique:'organization'}, {active}, {package_id} ]
listViews filtering on `active` = [ 'active', 'inactive' ]
sys_position   rows = 16, with package_id = 0
sys_capability rows = 10, with package_id = 2
sys_metadata_activation: package_id required = true
                         indexes = [ {metadata_type,name, unique:'organization'} ]

And the #11513 remedy path, driven end-to-end through the real data door:

POST /api/v1/data/sys_permission_set  (clone)      -> 201
  row = { managed_by:'admin', package_id:null, active:true, organization_id:null }
PATCH /api/v1/data/sys_permission_set/{id} {active:false}  -> 200

Route A — migration (rows move, column retired)

Customer-visible, and unsound on two independent axes:

1. Subject mismatch. 8 of 17 rows on a stock boot carry no package_id, and every clone — the exact remedy the packaged-set lock names — adds another (managed_by:'admin', package_id:null, measured above). The ledger's package_id is required: true and its subject is packaged artifacts (ADR-0126 §4). Migration would have to relax a required column or invent package ids for artifacts nobody packaged.
2. Row-identity mismatch. sys_permission_set is unique:'organization' on name, so two organizations may each hold sales_readonly with different active values (Five more instances of the #8323 class: admin- and user-authored names on tenant-scoped objects still carry installation-wide unique indexes #8554 measured exactly that pair live). The ledger's organization_id is RESERVED and unwritten (§5), and the store SKIPS org-carrying rows on read. Collapsing per-org sets onto one install-level row is the Decide whether POST /api/v1/automation/:name/toggle belongs in the manage_metadata write set — it mutates flow enablement with no authoring capability #10243 cross-tenant leak the ledger exists to retire, arriving from the other direction.
3. Surfaces bound to the column, each customer-facing: a declared index {fields:['active']}; two Setup list views filtering on it (active / inactive) and a third displaying it; activate_permission_set / deactivate_permission_set PATCHing /api/v1/data/sys_permission_set/{id} with bodyExtra:{active}; clone_permission_set sending active:true on create; the explain panel's deactivated verdict (The explain engine has no contributor state for a DEACTIVATED permission set — it just vanishes, where an expired grant says "held until … — expired" #8714).
4. Read-path cost. active is read as a COLUMN off rows resolveAuthzContext has already fetched, via the shared isRowActive predicate — zero extra reads on the hot authorization path. A ledger-backed answer inserts a second store into authorization.

Route B — projection (column stays, ledger reads through)

Splits into two halves, and neither is the convergence §8 item 3 asks for:

• Read-through only (a metadata_type:'permission' adapter over the column) changes nothing a customer can see — and delivers nothing: it adds a second way to ask one question. That is the "one operation, two implementations" shape ADR-0126 §4 and Two implementations of the ADR-0126 §4 activation-ledger row contract (flow + action) — consolidate onto one #12350 exist to remove, so it is convergence spelled backwards.
• Write-through (making the ledger's setActive a real door for 'permission') is customer-visible: it becomes a second write path to sys_permission_set.active that bypasses the permission-set backfill (ADR-0094 D4) 现在 100% 失败：行里的 active 存储列喂进了 #4001 之后严格化的 permission spec #4669 row-state carve-out ordering and the Studio save of a package-declared permission set forks it into a silent, undiscoverable overlay #11513 packaged-set lock pre-pass in permission-set-projection.ts. The card requires landed Studio save of a package-declared permission set forks it into a silent, undiscoverable overlay #11513 behaviour to be unchanged from the customer's seat; this changes it.

The family the card does not mention

sys_position.active (16 rows, 0 packaged) and sys_capability.active (10 rows, 2 packaged) are the same ADR-0049 switch, judged by the same isRowActive predicate. Converging only the permission member splits a three-member family — and the other two are less packaged than this one, so whatever answer fits here has to be argued for all three.

Four-axis reading

• Real business need — no measured pull. Zero inactive permission-set rows on a stock boot; the active switch that IS exercised is the Studio save of a package-declared permission set forks it into a silent, undiscoverable overlay #11513 clone/deactivate loop, which works today and is unrelated to packaged-artifact activation.
• Long-term soundness — the ledger's declared row identity (install-level, packaged, (metadata_type,name)) and this column's (per-org, mostly unpackaged, per-record) are different contracts. Route A bends the ledger's; route B duplicates a question. Neither is contract-first.
• AI-written-code safety — a second write door for the same bit (route B's write half) is precisely where an AI-authored admin app would flip a set without passing the packaged-set lock. Today there is one door.
• Startup scope discipline — this is an unpulled convergence over a landed, working surface, on a three-member family the card scopes to one member.

What I recommend the maintainer decide

Three options, in the order I would rank them:

1. Decline the convergence and record why (recommended). Amend ADR-0126 §8 item 3 to say the row-state door stays where permission-set backfill (ADR-0094 D4) 现在 100% 失败：行里的 active 存储列喂进了 #4001 之后严格化的 permission spec #4669 put it, with the measurement above as the ground: the ledger is for packaged artifacts at install scope, and sys_permission_set.active is neither. Costs nothing, closes an open item honestly.
2. Re-scope it to the family — one card covering permission / position / capability together, starting from "what is active FOR on a catalogue row", and only then asking whether any of it belongs in the ledger.
3. Route A anyway, accepting a data migration for unpackaged rows, a per-org dimension the ledger has not chartered (§5), and changes to the Setup views and the two lifecycle actions. I do not recommend it on any of the four axes.

Parts 1 and 2 are in the PR; Part 3 is stopped-reported there and needs no rework to land whichever way this goes.

---

Generated by Claude Code