Merge remote-tracking branch 'origin/main' into claude/issue-13937-stranded-run-operator-verb

Author: claude

.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/cli-option-b-config-load-boundaries.md

@@ -0,0 +1,45 @@
+---
+"@objectstack/cli": patch
+---
+
+fix(cli): `os serve` / `os dev` / `os build` / `os migrate` resolve `packages[]` when a stack carries no flattened top level
+
+The CLI holds four independent config-load boundaries, and every read of a
+package-owned collection behind them was an inline expression against the
+FLATTENED top level. A multi-package stack that carries each definition once
+under `packages[]` — the shape ADR-0130 D4's option B produces — reached those
+expressions with the key simply absent, and nothing threw:
+
+- `os serve` / `os dev` auto-register the ObjectQL engine and the storage driver
+  when the stack declares objects. Both gates read `config.objects`, so the app
+  booted with **no query engine and no storage driver** and reported healthy.
+  Nothing between the artifact and the gate could notice: the standalone stack
+  omits the `objects` key entirely when the array is absent rather than setting
+  `[]`, and the boot-config merge is a plain spread.
+- `os serve` auto-registers the i18n service plugin when the stack carries
+  translations. `translations` is package-owned while `i18n` is an envelope key a
+  translations-only stack never sets, so the REST i18n routes silently did not
+  exist.
+- `os dev` diffs the artifact's object inventory across recompiles to name a
+  newly added `*.object.ts`. It went permanently empty, so every recompile read
+  as all-green.
+- `os build` runs the author-time rule table twice — once over the union, once
+  per package. The per-package run already read `packages[]`; the union run,
+  which is the only one of the two that can see a finding spanning packages,
+  judged an empty stack and published green.
+
+All of them now resolve through one seam, in the dependency-topological order
+`resolveArtifactPackageOrder` gives. Each answer starts from the expression it
+replaced, so every stack that boots or builds today takes the identical branch —
+including a stack declaring an empty `objects: []`, which stays a stack that gets
+an engine — and `packages[]` is consulted only where the old read returned
+nothing. A malformed `packages` list is refused with its ADR-0112 envelope on
+that leg instead of resolving to the silent empty.
+
+The predicate `os serve` and `os migrate` each carried their own copy of — "does
+this config carry app metadata that needs an `AppPlugin` wrap" — is now one
+function. Measured, it does not lose under the new shape; it is folded in because
+it is the master gate for everything `AppPlugin` then reads.
+
+No command emits anything different: the compiled artifact still carries both
+copies, and the folded stack is a rule INPUT that reaches no writer.

.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/plugin-security-default-profile-packages-reader.md

@@ -0,0 +1,50 @@
+---
+"@objectstack/plugin-security": patch
+---
+
+fix(plugin-security): the app default permission set resolves from `packages[]`, not only the flattened top level (#15007)
+
+`appSecurityPluginOptions(config)` read `config.permissions` and nothing else.
+For a multi-package artifact under the ADR-0130 D4 option-B shape — where
+`packages[]` carries each definition exactly once and the flattened top-level
+copy is gone — that read returns `undefined`, the reader concludes "this app
+declared no default profile", and the boot continues. Nothing throws and
+nothing logs.
+
+That silence has a security posture attached. The name this resolves becomes
+the `SecurityPlugin`'s `fallbackPermissionSet`, i.e. the app's half of every
+authenticated human principal's additive baseline
+(`composeHumanBaselinePermissionSets`, ADR-0090 D5). Losing it does not deny
+anyone the boot — the deployment simply runs on the platform floor alone, and
+every member of a multi-package app quietly holds less access than the app
+declared for them. #7555 measured what that looks like from the outside: nav
+entries served, 403 behind them.
+
+The resolution now reads the flattened top level FIRST and then each package
+body, in the order `resolveArtifactPackageOrder` (`@objectstack/core`,
+ADR-0130 D4+D5) registers them:
+
+- **Every artifact the platform emits today answers bit-identically.** The
+  flattened level still answers first, so the `packages[]` pass can only supply
+  a set where the top level had none. This is the reader half of the ruled
+  order (readers first, emitter last, artifact stays additive throughout), so
+  it lands with no change to what any command emits.
+- **Order is the platform's one package order, not the array's.**
+  `appDefaultPermissionSetName` resolves the FIRST `isDefault` set, so with two
+  packages declaring one, "first" has to mean here what it means at every other
+  artifact reader: dependency-topological, so a package that extends another is
+  read after it whichever array slot it occupies.
+- **The singular `manifest` is still not consulted** (#7001 — the harness must
+  not honour a declaration `serve.ts` ignores). That is not a special case: an
+  artifact carrying no `packages` key makes `resolveArtifactPackageOrder`
+  return the caller's own object as the single package body, so that branch
+  reads `permissions` from exactly where the old code read it.
+- **A malformed `packages` is refused, not skipped.** A non-array `packages`,
+  an entry inlined instead of wrapped under `manifest:`, or a duplicate package
+  id raises the same ADR-0112 envelope (`code` + `status: 422`) the manifest
+  service raises when it registers that artifact. Catching it would resolve a
+  permission surface out of an artifact the loader refuses to load.
+
+Every boot path that already funnelled through this one function picks the fix
+up unchanged: `objectstack serve`'s artifact and from-source paths, and
+`@objectstack/verify`'s `bootStack` / RLS harness.