Merge origin/main into claude/issue-14556-list-view-grouping-contract

Takes main's deletion of skills/objectstack-ui/contracts/react-blocks.contract.json
(the react-blocks generator now emits one artifact, references/react-blocks.md);
the regenerated artifacts follow in the next commit, after the merge is committed.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H2oQebDDxYKfWZusyd8GXk

Author: os-justin

.changeset/bulk-data-event-organization-id.md

@@ -0,0 +1,48 @@
+---
+"@objectstack/spec": minor
+---
+
+feat(spec): `BulkDataEvent` names the one organization a predicate write's affected records belong to
+
+The realtime `BulkDataEvent` payload (`@objectstack/spec/api`, the body of every
+`data.records.updated` / `data.records.deleted` event) gains an optional
+`organizationId`: the organization every record the predicate write affected
+belongs to — one organization for the whole batch, never per-row and never a
+list. It takes the same spelling, the same position beside the match term
+`object`, and the same refusal of the empty string as `DataEvent`'s
+`organizationId`, so a tenant-scoped consumer discriminates both event families
+on one key with one comparison — never a partition of the batch.
+
+Why one organization can be honest on a batch that names no rows: a predicate
+write reaches the driver with the security layer's tenant wall AND-composed
+onto the caller's filter first (under `isolated` an equality on the caller's
+active organization; under `group` membership in the caller's organization
+set), and nothing in business RLS or sharing can widen it. When that wall names
+exactly one organization, every affected row belongs to it, and the producer
+can state so from what it already holds.
+
+What a consumer may assume — and where this deliberately diverges from
+`DataEvent`:
+
+- **Present** — every record the write affected belongs to exactly that
+  organization. Never fabricated, and never the caller's active organization
+  standing in for the rows'.
+- **Absent** — the producer did not assert one organization for the batch: every
+  event on a `single`-posture deployment; a system, environment-wide or
+  cross-membership predicate write; any write whose affected rows are not known
+  to belong to one organization. A bulk event names no rows, so absence is a
+  statement about the producer's knowledge, not about the rows. It is NOT
+  `DataEvent`'s reading "belongs to no organization, not behind any wall". A
+  tenant-scoped consumer (a per-organization webhook subscription, a
+  per-organization realtime subscriber) must treat an absent key as not
+  attributable to its organization and must not deliver the event inside an
+  organization wall; a deployment-wide consumer may use it.
+
+Declared = enforced: the key is optional and nothing else. No default
+fabricates a tenant; `null` and the empty string are refused with a located
+issue, so "not asserted" has exactly one spelling — the key is absent.
+
+Additive and shape-preserving: every bulk event that parsed before parses
+identically, and no producer emits the key yet — the ObjectQL engine's bulk
+publish site is a separate change that follows this contract. `DataEvent` and
+`MetadataEvent` are unchanged.

.changeset/data-event-record-organization.md

@@ -0,0 +1,45 @@
+---
+"@objectstack/objectql": patch
+---
+
+fix(objectql): a published `DataEvent` now names the organization the RECORD belongs to
+
+`DataEventSchema.organizationId` has been declared and published since the spec
+half landed, and its TSDoc states the obligation on the producer's side: *"a
+producer that omits the key on an organization-stamped row publishes a
+cross-tenant event, which is fixed at the publish site — never by a
+consumer-side lookup."* The engine populated it on no event at all. Every
+`data.record.created` / `updated` / `deleted` went out with the key absent,
+which a consumer is required to read as *"this record is behind no organization
+wall"* — so an organization-stamped row was published as an unwalled one, and a
+tenant-scoped fan-out had nothing to discriminate on.
+
+`publishDataEvent` now resolves the organization from the row itself and spreads
+the key in when there is one. The row is already in hand at all three call
+sites — the written record on `created`, the post-state on `updated`, and the
+pre-image on `deleted` (the by-id branch reads it unconditionally for its
+existence gate) — so this buys **no** per-event read: the key exists precisely
+to keep a per-event lookup off the fan-out path.
+
+Three properties are deliberate:
+
+- **The RECORD's organization, never the caller's.** The row's own tenant column
+  is the only source consulted. `ExecutionContext.tenantId` is the caller's
+  *active* organization; the two coincide on an ordinary tenant write and
+  diverge on a system or unscoped one, where substituting it would mislabel an
+  administrator's write into another organization as belonging to the
+  administrator's.
+- **Absence has exactly one spelling: the key is omitted.** An object that is
+  not tenant-scoped, a row whose column is empty, and a value no id can be read
+  off all publish the key absent rather than `null`, `''` or an explicit
+  `undefined`. The schema refuses the empty string outright, so producing one
+  would have thrown at the publish site and dropped the event entirely.
+- **The column is resolved the way the write path resolves it** — the
+  `tenancy.enabled: false` opt-out, then a declared `tenancy.tenantField`, then
+  the injected `organization_id` — so the event cannot name an organization for
+  a column the engine does not actually scope by. Note the two spellings differ:
+  the column is `organization_id`, the published key is `organizationId`.
+
+No schema, no accepted shape and no public export moves: the key was already
+declared, already validated and already part of what consumers parse. Only the
+implementation changed, from omitting a declared key to populating it.

.changeset/execution-step-branch-key.md

@@ -0,0 +1,63 @@
+---
+"@objectstack/spec": minor
+---
+
+feat(spec)!: `ExecutionStepLog.iteration` is single-valued — the enclosing loop iteration — and the parallel branch index moves to a new optional `branch` key (#14414)
+
+<!-- adr-0087: registered execution-step-iteration-single-valued -->
+
+**BREAKING** for any consumer that read `iteration` as the parallel branch index
+on a `regionKind: 'parallel-branch'` step record: that number now means the
+enclosing `loop`'s iteration, and the branch index lives on `branch`. Shipped as
+`minor` under the repo's launch-window convention for breaking changes; the
+hand-migration prescription is registered under protocol major 18. Maintainer
+ruling 2026-09-03 on #14414 (director decision batch #15, verbatim 「同意」):
+option A.
+
+`ExecutionStepLogSchema.iteration` was declared as "zero-based loop iteration
+OR parallel branch index of the enclosing region" — one field, two meanings,
+told apart only by reading `regionKind` first. For `loop { body: [ parallel {
+branches } ] }` the engine tagged each branch step with the branch index and no
+step of that branch with the loop iteration, so a per-row failure inside a
+branch was attributable to a branch, never to the row. The sibling `try_catch`
+rule (a try/catch region has no index of its own, so it carries the loop
+iteration) had deliberately left `parallel` open, because a parallel region
+DOES have an index of its own.
+
+**What changes on the record shape** (`packages/spec/src/automation/execution.zod.ts`):
+
+- `iteration` — single-valued: the zero-based iteration of the enclosing
+  `loop`, carried through any nesting (`try` / `catch` already carried it;
+  `parallel-branch` now does too). The try/catch sentence is unchanged.
+- `branch` — **new**, optional, `integer >= 0`: the zero-based index of the
+  enclosing `parallel` branch, present only on a step inside a parallel
+  branch. A branch step of a parallel node inside a loop body carries both.
+- `regionKind` — unchanged vocabulary; its describe now points the
+  `parallel-branch` index at `branch`.
+
+**What does NOT change in this PR:** the engine tagger in
+`@objectstack/service-automation` still writes the innermost region only —
+today it writes the branch index into `iteration` on `parallel-branch` steps
+and never writes `branch`. The tagger change is a follow-on card in the same
+lane, blocked by this one (three-surface rule: spec first, no engine-only patch
+in between). A step record written by an engine that predates that follow-on
+therefore carries no `branch` key, and its `iteration` under `parallel-branch`
+still holds the legacy branch index.
+
+## FROM → TO
+
+```ts
+// before — one key, two meanings; the loop iteration of a branch step is lost
+const step = { regionKind: 'parallel-branch', iteration: 1 }; // 1 = branch index
+const branchIndex = step.regionKind === 'parallel-branch' ? step.iteration : undefined;
+
+// after — one meaning per key; a branch step inside a loop body carries both
+const step = { regionKind: 'parallel-branch', iteration: 3, branch: 1 };
+const branchIndex = step.branch;   // 1 — the branch
+const rowIteration = step.iteration; // 3 — the enclosing loop's row
+```
+
+Fix: where a consumer groups or labels `parallel-branch` steps by `iteration`
+(the objectui `FlowRunsPanel` grouping key is the one measured reader), read
+`branch` for the branch index and keep `iteration` for the row. Reads of
+`iteration` on `loop-body`, `try` and `catch` steps need no change.

.changeset/liveness-realtime-subscription-surface.md

@@ -0,0 +1,59 @@
+---
+"@objectstack/spec": patch
+---
+
+chore(spec): govern the realtime `SubscriptionSchema` surface in the liveness ledger (#14446)
+
+The `liveness/` ledgers ship inside this package's npm tarball (they are named in
+`files`), so this is a published-data change even though no runtime behaviour moves,
+no schema key changes spelling, and `packages/spec/src/api/realtime.zod.ts` is not
+edited at all.
+
+A new ledger file — `realtime_subscription.json` — classifies all six authorable
+properties of `SubscriptionSchema`, what a client declares to open a realtime
+subscription: the item type of `RealtimeConfigSchema.subscriptions` and the
+`Subscription` the generated API reference publishes. It is enrolled through the
+gate's `SPEC_ONLY_SCHEMAS` override, the route `query` / `qa` / `manifest` and the
+four `RestServerConfig` sub-objects already take. A transport-protocol surface is
+neither a metadata item nor stored metadata nor a manifest, so no registry has ever
+held it and no ratchet rooted in one could ask who reads it — and
+`RealtimeConfigSchema` is `.passthrough()`, so nothing downstream even refuses an
+unknown key.
+
+All six are `dead`, and the container is the finding: nothing outside
+`packages/spec` imports `SubscriptionSchema`, `SubscriptionEventSchema` or
+`RealtimeConfigSchema` at all, so no key beneath them can be read. The two the
+census filed with this card measured are the sharp ones. `events[].type` accepts
+`RealtimeEventType`, whose four members (`record.created` / `record.updated` /
+`record.deleted` / `field.changed`) are disjoint from what the engine publishes —
+`DataEventType`'s `data.record.*`, with a live emitter in `service-knowledge` — so
+an author who writes the enum's own `record.created` gets a subscription that
+silently never fires, and the enum is what the API reference shows them.
+`events[].filters` is `z.unknown().optional()`: an authorable key with no shape and
+no consumer, failing in the permissive direction, since the only payload matching
+the platform performs compares object name and event type.
+
+What this records, and what it deliberately does not. The enum's direction is
+settled and the row carries the 2026-09-02 triage ruling verbatim so the next reader
+does not re-open it: if the verdict is enforce it means repointing the enum, never
+changing what the runtime publishes, which would break a live event contract to
+satisfy a member nothing has ever used. `field.changed` is the same spelling the
+sibling `DataEventType` removed in 17.0.0 under ADR-0049 (#4673, PR #4685) for
+having no producer; it survives here only because this enum was never in a ratchet's
+denominator. No key is removed, enforced, deprecated or re-described here — the
+enforce-or-remove call per dead key is a follow-up on the human floor.
+
+Rooted on `SubscriptionSchema` rather than on `RealtimeConfigSchema`, which is
+measurement rather than taste: the ledger walk drills exactly one level, so with the
+config as the root `subscriptions` would be the drilled level and `events[].type` /
+`events[].filters` would have no row of their own, inheriting a container verdict —
+the same reasoning that rooted the four `RestServerConfig` sub-objects separately.
+`RealtimeConfigSchema`'s own three keys are not enrolled: whether enabling realtime
+does anything is a different question with no census behind it yet.
+
+One correction the ledger records because the next reader will hit it too. The card
+and its triage both name the two keys on `SubscriptionSchema`; they are declared on
+`SubscriptionEventSchema` (`realtime.zod.ts:46-50`), reached from this root as
+`events[].type` and `events[].filters`. The cited lines and quoted shapes are exact;
+only the owning symbol was misattributed, and this package's own authorable-surface
+census (`authorable-surface/api.json`) already spells the two schemas apart.

.changeset/packages-domain-protocol-handle-typed.md

@@ -0,0 +1,26 @@
+---
+"@objectstack/runtime": patch
+---
+
+fix(runtime): the packages domain reaches the `protocol` service through a typed handle (#13598)
+
+`deps.resolveService(context, 'protocol')` answers `any` — `protocol` is
+deliberately left unmapped in `ServiceSlotContracts` — so every request literal
+downstream of that seam compiled against nothing. Twelve sites in
+`domains/packages.ts` held that `any` (two of them on the variable declaration
+rather than the call), and an undeclared or misspelt key in the ADR-0045
+publish-visibility flip's `getMetaItems` / `saveMetaItem` literals compiled
+silently. Measured on the base tree: injecting `bogusUndeclaredKey: true` into
+the `saveMetaItem` literal gave `tsc --noEmit` exit 0 and zero diagnostics.
+
+The slot is now narrowed once, at one helper, to a handle `Pick`ed from the
+DECLARED contracts — `MetadataProtocol` / `PackageProtocol` from
+`@objectstack/spec`, plus the producer's own exported `DeletePackageRequest` —
+so the same injection is now `error TS2353`. Every member is OPTIONAL and every
+`typeof protocol.<verb> === 'function'` capability probe is unchanged: a host
+may occupy the slot with a partial object, and the type answers "is this key
+declared?" while the probe still answers "did this host bring the verb?".
+
+Compile-layer signal only — no request is newly accepted or refused, no
+response shape moves, and the eight verbs no contract declares keep an explicit
+`any` request rather than a private restatement nothing verifies.

.changeset/service-automation-test-tsc-program.md

@@ -0,0 +1,62 @@
+---
+"@objectstack/service-automation": patch
+---
+
+fix(service-automation): put the test layer in front of tsc, and repair the TS2341 x3 it was hiding (#15048)
+
+`packages/services/service-automation` had **no `typecheck` script at all** —
+its scripts were `build` and `test` — so no tsc program anywhere read this
+package (`turbo run typecheck` selects only packages that declare the task, so
+it skipped this one silently). `tsup` transpiles with esbuild and `vitest`
+runs through esbuild type-**stripping**; neither type-checks. The package's
+own `tsconfig.json` does include the tests and always did, so the program that
+would have read them already existed and was simply never invoked. This is
+the `packages/services/**` sibling of `@objectstack/service-cluster`'s same
+graduation (#14181 / PR #15032), reached by the same road in.
+
+What that hid was three `TS2341`s, all in
+`src/nested-region-parity.test.ts` (lines 95/151/180):
+
+```
+error TS2341: Property 'flows' is private and only accessible within class 'AutomationEngine'.
+```
+
+Three tests dot-read the private `AutomationEngine#flows` map directly
+instead of going through the class's own public accessor,
+`await engine.getFlow(name)` — already the idiom every other test file in
+this package uses. The fix replaces the three private reads with that
+existing public call (making the two synchronous test bodies `async` where
+they were not already); no source signature was widened, no cast was added.
+
+Wired by the route the `packages/plugins/**` family settled on in #14062 and
+`service-cluster` carried into `packages/services/**` in #14181: a sibling
+`tsconfig.test.json` that changes **module semantics only** (`esnext` /
+`bundler` / `lib: ES2022`, matching how vitest actually executes these files)
+with **strictness inherited and untouched**, named by a new `typecheck`
+script through the shared `check:test-typecheck` gate. Measured before the
+repair: 3 errors under build semantics (`tsc -p tsconfig.json`, which already
+included the tests), 3 under the new config — the two readings agree, so this
+package carried no config-tier pile, and all 3 were genuinely code-tier from
+the start. After: 0 and 0, across a 555-file program covering all 103 of its
+`src/**/*.test.ts`.
+
+No `test-typecheck-debt.json` is added, and its **absence is the zero**: the
+gate reads a missing ledger as `{ entries: {} }`, under which any error in any
+file here is red immediately. The package's `DEBT` entry in
+`scripts/check-type-check-coverage.mjs` (`errors: 3`) is deleted in this PR
+rather than lowered — that is the graduation the ratchet's own invariant
+requires, and it is why the errors were fixed rather than ledgered.
+
+`scripts/check-type-source-resolution.mjs` also gains a registry entry for
+this package: onboarding `tsconfig.test.json` moved the package's tsc program
+set (per that gate's documented onboarding-limb terms), exposing 9 workspace
+deps whose types resolve through `dist/` with no pre-existing program for them
+to have been laundered through. `paths` was measured and rejected as the
+alternative — it takes this package's test layer from 0 errors to 648, nearly
+all billed to other packages' source.
+
+No runtime code changes: `src/**` (excluding the one edited test file, whose
+own assertions are unchanged — only how it reaches the flow moved) is
+otherwise byte-identical, so no shipped behaviour moves. The `patch` level
+reflects the published `package.json` gaining `typecheck` /
+`check:test-typecheck` scripts and a `tsx` devDependency.

.changeset/spec-text-content-exclusion-recorded.md

@@ -0,0 +1,13 @@
+---
+"@objectstack/spec": patch
+---
+
+docs(spec): `PageTranslation.components` now says why `element:text`'s `content` is not one of its keys (#14412)
+
+The per-component translation face names its deliberate exclusions with reasons — `help` because no component in the model declares it, `subtitle` because `page:header` is already addressed by page name. `content` was neither named nor excluded. An author looking for a bundle key for the one string `element:text` renders therefore found an absence, and an absence reads exactly like an oversight.
+
+It is not one, and the schema comment now records that beside the other two. `element:text` declares `content: I18nLabelSchema` (`ui/component.zod.ts`), so the string is localizable at its own authoring site as an inline `{ en, 'zh-CN' }` locale map — the route `sys-user.page.ts` itself uses. Adding it to the bundle face would be the face widening the `submitLabel` retirement declined for the identical shape (#10926, ADR-0049).
+
+No key was added and no behaviour changed: the bundle face is still `title` / `description` / `label` / `placeholder` / `emptyText`, and `translatePage` resolves exactly what it resolved before. Bundles, extractor output and existing page definitions are unaffected.
+
+Known and tracked separately: inline locale maps are invisible to `os i18n extract` and `check:i18n-coverage`, so page prose written this way is not counted by coverage tooling. That is true of every inline `I18nLabel` field rather than this component alone, and is carried as #14749.