Two implementations of the ADR-0126 §4 activation-ledger row contract (flow + action) — consolidate onto one

[claude]

ADR-0126 §4 declares ONE activation ledger for the whole disable+clone family. It now has two independent implementations of the same row contract, and this issue is the record of that, filed by the leg that created the second one rather than left to be found.

Implementation	Package	Landed
ObjectStoreFlowActivationStore (metadata_type: 'flow')	packages/services/service-automation/src/flow-activation-store.ts	#12296
ObjectStoreActionActivationStore (metadata_type: 'action')	packages/objectql/src/action-activation.ts	#12348

The two agree today on every load-bearing detail — install-level rows only (organization_id never written), rows carrying an organization skipped on read, a driver 0 read as false, read-then-write rather than a blind upsert, no delete in the engine slice because re-enabling rewrites the row. They agree because the second was written from the first and the ADR pins both; nothing structurally holds them together.

Why it was not shared at the time

Neither direction of import exists in the module graph:

• @objectstack/service-automation does not depend on @objectstack/objectql (it is a devDependency only), so the flow store cannot import the generic one;
• @objectstack/objectql must not depend on a service package — the dependency arrow points the other way.

Consolidating means putting a generic metadata_type-parameterized store in a package BOTH may depend on, and moving both consumers onto it. Candidates worth weighing: @objectstack/core (both already depend on it), or @objectstack/platform-objects (it declares the sys_metadata_activation object itself, and service-automation already depends on it — but objectql does not, and adding that edge inverts the tiering, since platform-objects is the catalog the engine serves).

Why it is worth doing, and why it is not urgent

Worth doing: ADR-0126 §8 pre-charts tool, skill and position as later Regime C consumers, and a third and fourth copy of this store is where the row semantics start drifting — the org-row skip and the 0-is-false read are exactly the kind of detail a copy loses quietly.

Not urgent: the two current copies are pinned on both sides (flow-activation-ledger.test.ts, action-activation.test.ts), and a drift would have to survive both.

⚠️ This is a refactor of landed code in two packages, so it wants its own card and its own review — which is why the #12160 leg declared it in the module header and here instead of doing it inline.

Refs: #12296 · PR #12348 · #12160 · ADR-0126 §4

---

Generated by Claude Code

[os-trump]

Triage: lands in domain:engine; rationale: the consolidation's center of gravity is a generic metadata_type-parameterized store in a package both consumers may depend on (@objectstack/core is the candidate that does not invert tiering — the body itself notes platform-objects would add an objectql → platform-objects edge), plus the packages/objectql consumer. Queued as a Task: behavior-preserving refactor, both current copies pinned on both sides, no open product question.

Cross-domain note (this is the triage-designated single-PR cross-domain path): the PR must also move packages/services/service-automation/src/flow-activation-store.ts onto the shared store. The engine-seat claim must declare the full file surface including that services-side file, and check it against domain:services in-flight claims before dispatch (ADR-0126 family is active there — #12160 is in flight at time of triage; serialize or clear with that seat).

Size/model suggestion: M, opus. Not urgent (both copies pinned); normal queue order.

---

Generated by Claude Code

[os-support-ai]

Consolidated into the ledger-convergence card #12159 by maintainer ruling (2026-08-26, verbatim 「同意」, recorded in full on #12359): this consolidation, the #12359 registration move (option B — registration moves to PlatformObjectsPlugin, single owner) and the L8 permission-set convergence are one card, one PR, one verification pass — three touches of the same hot surface collapsed into one review. This issue stays open and will be closed by that PR.

One constraint from this card's own analysis that the convergence card carries forward: the shared store must live in a package both service-automation and objectql may depend on — @objectstack/core is the leading candidate; platform-objects as the code home would invert the tiering for objectql (registration moving there is a composition-level matter, orthogonal to this).

---

Generated by Claude Code