Merge remote-tracking branch 'origin/main' into claude/issue-15229-verify-option-b-readers

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/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/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/standalone-stack-stamps-env-local.md

@@ -0,0 +1,47 @@
+---
+"@objectstack/runtime": patch
+"@objectstack/metadata": patch
+---
+
+fix(runtime,metadata): the default local environment id is `env_local`, not `proj_local` (#13366)
+
+The v5.0 `project` to `environment` rename changed the default local environment
+id and shipped that change on the surfaces most people meet: `packages/cli`'s
+`CHANGELOG.md` records "Default local env id: `proj_local` -> `env_local`", the
+`os dev` / `os start` / `os serve` commands emit `env_local`, and
+`content/docs/deployment/cli.mdx` documents `env_local` as the default. Two
+sites never received it and kept stamping `proj_local`.
+
+FROM: `createStandaloneStack()` — with no `environmentId` in its config and no
+`OS_ENVIRONMENT_ID` in the environment — stamped `proj_local` on the kernel it
+composed, and `MetadataPlugin` used `proj_local` to fill the environment-artifact
+validation envelope for a bare definition.
+
+TO: both stamp `env_local`.
+
+WHO SEES IT. Two audiences, both on the DEFAULT path — no `environmentId` in
+the config and no `OS_ENVIRONMENT_ID` in the environment:
+
+1. a host that calls `createStandaloneStack` / `createDefaultHostConfig`
+   **directly**;
+2. a **bare `os serve`** — one not spawned by `os dev` / `os start`. Those two
+   commands export `OS_ENVIRONMENT_ID=env_local` into the child process, which
+   the fallback yields to, so a boot they start never reached the changed line.
+   `os serve` sets no such variable for its own boot: it only READS one to name
+   the runtime state file. So a bare `os serve` used to run a kernel stamped
+   `proj_local` while publishing `runtime.env_local.json` beside it; the two now
+   agree.
+
+Where the id is observable — row scoping in `ObjectQLPlugin`, the
+`X-Environment-Id` header, `sys_metadata.environment_id` — such an embedder now
+sees `env_local` where it saw `proj_local`, so an install with rows already
+written under the old id should set `environmentId: 'proj_local'` (or
+`OS_ENVIRONMENT_ID=proj_local`) explicitly to keep them addressed. That escape
+hatch is unchanged and still wins over the default.
+
+NOT CHANGED, deliberately: `@objectstack/cloud-connection` still treats BOTH
+spellings as the local sentinel, so a persisted `OS_ENVIRONMENT_ID=proj_local`
+config keeps being recognised as local rather than presented to the control
+plane as a cloud environment id; and `package-state-store`'s separate `'default'`
+fallback keeps its own spelling, because renaming it would re-key persisted
+package-disable state files.