Merge remote-tracking branch 'origin/main' into claude/issue-14637-share-link-probe-policy-gate

# Conflicts:
#	content/docs/permissions/system-context.mdx

Author: claude

.changeset/auth-no-sign-in-account-boot-report.md

@@ -0,0 +1,28 @@
+---
+'@objectstack/plugin-auth': patch
+---
+
+Report the zero-account boot dead end at `kernel:ready` (#14353)
+
+A deployment holding human `sys_user` rows and zero `sys_account` rows cannot
+be recovered from inside, and until now it booted silently. Nobody can sign in;
+the first-account bootstrap carve-out counts humans, and humans exist, so it
+does not open; the default `invite_only` audience posture refuses
+self-registration; and no administrator exists who could send an invitation.
+The only symptom was a 401 on credentials nobody holds.
+
+That state is now reported at `kernel:ready` at `error` level, under the name
+`no_sign_in_account_at_boot`, naming both the consequence (the deployment will
+keep looking healthy and cannot be recovered from inside) and the remedy
+(provision an account out of band, or open the audience posture).
+
+⛔ No admission semantics change. Whether the carve-out should count humans or
+logins was ruled on 2026-09-02 (option A — the door does not move); this only
+reports.
+
+The check extends the existing `kernel:ready` walled-owner reporter rather than
+opening a parallel one: it shares that hook, and the bounded human-population
+page is read ONCE per boot and handed to `probeWalledOwnerAccountState`, so no
+deployment pages `sys_user` twice. At most one report is emitted per boot — a
+deployment matching both shapes gets this error, and the walled-owner warning
+is suppressed rather than stacked on top of it.

.changeset/bu-tenant-screen-relanding.md

@@ -0,0 +1,11 @@
+---
+'@objectstack/plugin-sharing': patch
+---
+
+Fix: a sharing rule with a business-unit recipient granted nothing when the unit came from seed data — and tenant-screen the member reads that widening exposes.
+
+`BusinessUnitGraphService.orgScope` screened `sys_business_unit` with a strict `organization_id` equality, while the platform's own read-side chokepoint (`SqlDriver.applyTenantScope`) is null-inclusive: `(organization_id = ? OR organization_id IS NULL)`, because a NULL organization marks a platform/seeded row every tenant may see. A sharing rule always carries the caller's organization, but a business unit written by seed data carries none — a seed cannot know the id the runtime mints at boot — so the two never matched. The seed check read the unit as "does not exist", both recipient widths (`business_unit` and `unit_and_subordinates`) expanded to zero users, and the rule stayed active having materialised no `sys_record_share` row and logged nothing. `orgScope` now applies the platform's null-inclusive screen, the same predicate `plugin-approvals` already applies to these very rows and `SharingRuleService.adminOrgScope` applies to the rule table.
+
+The member reads are now tenant-screened, which they were not before. Both `expandUnitMembers` and `expandUsers` queried `sys_business_unit_member` with no organization predicate at all, under a system context that carries no tenant either, so the strict unit screen was the only thing keeping an org-stamped rule away from that unscoped query. Widening the unit screen alone would have turned a silent under-grant into a silent cross-tenant over-grant, since a seeded unit id exists identically in every tenant. The member screen is strict rather than null-inclusive on purpose: seed replay and elevated system writes both leave `sys_business_unit_member.organization_id` NULL, so a NULL there means unknown tenancy rather than platform-global, and an org-scoped rule does not grant to it. The sibling recipient widths already read their membership rows this way.
+
+An active business-unit rule that expands to no recipients now warns once per rule per process, naming the rule, the object, the recipient kind, the unit and the organization. That case — a rule whose unit and membership rows were both seeded — is the one combination that still grants nobody, and it is no longer silent.

.changeset/cli-action-dedup-global-key-constant.md

@@ -0,0 +1,22 @@
+---
+"@objectstack/cli": patch
+---
+
+refactor(cli): spell the action-dedup object-less key as `GLOBAL_ACTION_OBJECT_KEY` (#14669)
+
+`os lint` dedups action declarations on the engine's composite registration key
+(`<objectName>:<name>`), and the object half of that key terminated on a bare
+`'global'` string literal in `lintConfig`'s `PREFIXED_TYPES` table. The engine's
+own writers stopped spelling the literal: PR #14667 converged
+`ObjectQLPlugin.actionObjectKey` onto the shared `GLOBAL_ACTION_OBJECT_KEY`
+constant for exactly this reason — a copy that agrees by value today is the one
+that parts from the writer in silence the day the constant moves, with no test
+in the repo able to see it. This reader now imports the constant from
+`@objectstack/objectql`, which `@objectstack/cli` already depends on.
+
+**No behaviour moves.** `GLOBAL_ACTION_OBJECT_KEY` is `'global'`, so every key
+this table builds is byte-identical to the one it built before; the #5510 dedup
+suite (`lint-namespace-prefix.test.ts`, 15 declarations over 5 objects) passes
+unchanged. Only `objectName` is read, exactly as before — the `object`/`entity`
+aliases are still rejected upstream by `ActionSchema`'s strict shape and are
+deliberately not admitted here.

.changeset/cli-test-typecheck-wiring.md

@@ -0,0 +1,52 @@
+---
+"@objectstack/cli": patch
+---
+
+fix(cli): wire `packages/cli`'s test layer into `check:test-typecheck`, so its 115 test files are type-checked at all (#14710)
+
+`packages/cli/tsconfig.json` declares `include: ["src"]` and no `exclude` at
+all, and the package's `typecheck` script was a bare `tsc --noEmit` against that
+very config — so the 115 test files in the sibling `test/` tree were read by no
+tsc program anywhere. This is the shape AGENTS.md already forbids, reached by
+the OTHER spelling: not an `exclude` naming the test globs, but an `include`
+that never reaches them.
+
+Measured at `5a5336b399` with the workspace closure built first, rather than
+read off the config: `tsc --noEmit --listFiles -p tsconfig.json` puts 1009 files
+in the program and **0** of the 115 among them, while 119 of 119 non-test
+`src/**` files and all 121 `src/**` test files ARE there — so the zero is the
+`include` line, not a probe that sees nothing. The directional control is
+`packages/drivers/driver-memory`, whose tsconfig carries no test exclusion: the
+same probe puts 40 of its 40 test files in the program. Under the new
+`tsconfig.test.json` the count is **115 of 115**, plus the three package-root
+harness modules (`vitest.config.ts`, `vitest-tiers.ts`,
+`vitest-tiers.fixtures.ts`) and `test/helpers/serve-process.ts`.
+
+Onboarded by *wiring* to the shared mechanism (`scripts/check-test-typecheck.mts`)
+the way `objectql`, `rest`, `lint`, the fourteen `packages/plugins/**` and
+`runtime` are wired, never by copying it: a sibling `tsconfig.test.json`
+matching vitest's real module semantics (`module: esnext`,
+`moduleResolution: bundler`), named by `typecheck` via
+`check:test-typecheck --project`. Strictness is untouched and inherited; not one
+`any` and not one `@ts-expect-error` was added to any test file to open the
+gate. `rootDir` IS widened to `../..`, the way `packages/client`'s test config
+already does it — this package's tests sit outside the build config's
+`rootDir: "src"`, and three of them import fixtures from
+`examples/app-showcase/src/**`.
+
+**Seeded, not repaired, per this card's triage ruling.** The layer reports 28
+errors across 3 files and they are recorded EXACT and shrink-only in the new
+`test-typecheck-debt.json`. Every one is pre-existing: no test file is edited
+here. The other 112 files carry no entry, so any error they gain is red on
+arrival.
+
+This is a CONVERSION rather than a new debt-opening decision. The same
+population under the build config's inherited NodeNext reports 144 — exactly the
+number `scripts/check-type-check-coverage.mjs` already held for this package in
+its per-PACKAGE `TEST_DEBT` ledger, class for class — and that entry graduates
+here, as the pairing forces. The 144 → 28 step is attributed in both directions
+with no remainder: −120 config-tier diagnostics that dissolve under vitest's
+module semantics (TS2835 ×56, the TS7006 ×59 cascading above them, TS2307 ×3,
+TS18046 ×2) and +4 that collapsing the cascade exposed (TS18048 ×4 in
+`test/i18n-extract-action-description.test.ts`, previously masked by an `any`
+from two unresolved imports). The 24 TS2339 survive unchanged, file for file.

.changeset/compose-stacks-action-key-collision.md

@@ -0,0 +1,17 @@
+---
+'@objectstack/spec': minor
+---
+
+`composeStacks` now refuses two input stacks whose action declarations resolve to one scope-qualified runtime key — **BREAKING** accept-set narrowing, shipped as `minor` under the repo's launch-window convention for breaking changes.
+
+**The refused shape:** two (or more) input stacks that each declare an action resolving to one runtime key — `objectName:name`, or `global:name` for an object-less action. The canonical case is two packages, each legal on its own, each declaring a global action named `shared_refresh`: `composeStacks([a, b])` used to accept the pair and emit `["global:shared_refresh", "global:shared_refresh"]`, and the runtime — which registers and dispatches every action under that one exact-string key — collapsed both handlers to one registration: whichever registered second won, and the other package's action stayed a live, declared, permission-gated button whose handler was unreachable. `defineStack` refuses exactly this collision within one stack (#14686); composition was the second door in the same file that let it through.
+
+The refusal carries `composeStacks`' conflict prefix and `defineStack`'s envelope shape — `composeStacks conflict: cross-stack action key collision (N issue(s)):`, one `✗` line per colliding key — and every line names the key, **both source stacks by manifest id** (`'com.example.a' (stack #0)`; a manifest-less input is named by position), and where each declaration sits (`stack.actions[i]`, or `objects['OBJECT'].actions[j]` for an embedded one). The fix is the one the message names: rename one of the colliding actions within its scope, bind one of them to a different object, or remove the duplicate from one of the stacks. ⛔ There is no `actionConflict` option and none is coming: `composeStacks` does not pick a winner for actions (maintainer ruling, 2026-09-03).
+
+What the check judges is what composition **carries**: standalone actions from every stack (they concatenate), and each composed object's embedded actions attributed to the one stack whose object `objectConflict` handed the `actions` array to. So an embedded action that `'override'` or `'merge'` did not carry into the composed object cannot collide — that loss is the object strategy's own semantics — while a standalone action bound to an object from one stack does collide with an embedded action of the same name the composed object carries from another. Only a key declared by two or more **distinct** stacks is reported: a key an input repeats within itself is `defineStack`'s door (`strict: false` opts out there by choice), and an input built by `defineStack` legitimately carries each bound standalone action twice — as the copy the build appended to its object — which is never a collision with itself.
+
+Deliberately unchanged, as in `defineStack`: one global and one object-bound action may share a name across stacks (two keys), and one name bound to two different objects is two keys. The shipped composer, `examples/app-multi-package`, declares no colliding key and composes unchanged; no `composeStacks` caller exists in objectui or hotcrm.
+
+**Migration.** A composition refused by the new check must resolve the collision in one of the two packages — rename the action within its scope, bind it to a different object, or drop the duplicate. Which package keeps the name is an authoring decision the metadata cannot make for you.
+
+<!-- adr-0087: not-required (no-migration-prescription) a validity narrowing over existing declarations: no key is removed, renamed or re-shaped and no export moves, so the ledger has no rewrite to carry; the refusal itself names the remedy at the composition site, and choosing which of two packages keeps the action name is an authoring decision no migration entry can perform on an upgrader's behalf. -->

.changeset/converge-runtime-global-action-key-literals.md

@@ -0,0 +1,47 @@
+---
+"@objectstack/runtime": patch
+---
+
+refactor(runtime): spell the object-less action key as `GLOBAL_ACTION_OBJECT_KEY` in `action-execution.ts` (#14678)
+
+`GLOBAL_ACTION_OBJECT_KEY` exists so the object-less action-registration key is
+written once. #14422 converged the owner-key LADDER and the ObjectQL plugin's
+copy of it; three bare `'global'` spellings elsewhere in
+`packages/runtime/src/action-execution.ts` were never in that card's path,
+because the runtime fence it built was a re-export plus a delegating alias.
+This converges those three. The constant was already imported in the file.
+
+No behaviour moves — the constant is `'global'`, so every site is equal in
+value before and after. That equality is the entire defect: it is what made the
+three invisible to every test in the repo, and what would have let them part
+from the constant in silence the day its value changes.
+
+- `seedFlowActionParams` — a live comparison (`objectName !== 'global'`) that
+  decides whether an object-derived `<object>Id` param key is seeded. The one
+  site where a drifted literal would change what an action body receives.
+- `enforceActionParams` — the warn-once dedup key, which is also interpolated
+  into the operator-facing `[action-params] <key>: …` line. Converged rather
+  than left: the argument for a literal here is that a log key must never fail
+  to render, and that argument does not survive contact with the fact that
+  `GLOBAL_ACTION_OBJECT_KEY` is a module-scope `const string` already imported
+  into this file — it cannot fail to render either. What a drift there would
+  actually cost is an operator grepping logs by the key the engine now uses and
+  silently missing these lines.
+- `collectActionDeclarations`'s docblock, which carried a second defect
+  independent of the literal: it called the key "the `'global'` wildcard",
+  contradicting `action-governance.ts` ("an exact-string `Map` lookup with no
+  wildcard semantics"). It is now the phrasing the sibling docblock 48 lines
+  below it already used — "the object-less `GLOBAL_ACTION_OBJECT_KEY`" — so the
+  correction is copied from the file's own converged prose rather than invented.
+
+`patch`, not `skip-changeset`: `packages/runtime` publishes `dist`, which is
+built from this source, so the emitted bytes move even though the behaviour
+does not. Nothing reaches the published entry — `action-execution.ts` is not
+re-exported from `packages/runtime/src/index.ts` and no export, signature or
+type changed here — which is what keeps it below `minor`.
+
+The docblock that promised the lockstep is joined by a weld that enforces it:
+`action-owner-key-single-source.test.ts` gains a half C that reads
+`action-execution.ts` and fails if any quote spelling of the key is written out
+by hand again. The forbidden spelling is DERIVED from the constant rather than
+hard-coded, so the guard is not itself a fourth copy of the literal it forbids.

.changeset/create-record-duplicate-code.md

@@ -0,0 +1,25 @@
+---
+"@objectstack/service-automation": patch
+---
+
+fix(automation): `create_record` now surfaces the engine's `DUPLICATE_RECORD` code, so a `try_catch` / `fault` edge can finally tell "already there" from "the store is down" (#14419)
+
+`engine.insert` (#14095) already raises `DuplicateRecordError` — `code: 'DUPLICATE_RECORD'` (ADR-0112) — for a unique-constraint violation, driver-independent. The `create_record` node executor threw that away: every failure, from a duplicate key to a downed connection, collapsed into one opaque string (`create_record(<object>) failed: <message>`). A flow's only two error-handling primitives, `try_catch` and a `fault` edge, saw the same shape either way — the only expressible reading of "swallow the duplicate" was "swallow everything".
+
+`NodeExecutionResult` gains an optional `code?: string` field, beside the existing `errorClass`, set when the caught error carries the platform's classified `DUPLICATE_RECORD` code. `AutomationEngine` now copies it onto the `$error` run variable alongside `message` (both the direct `fault`-edge path and the `try_catch` catch-region binding, which previously reconstructed `errorVariable` from the caught exception's message alone and silently dropped it), so a flow can actually branch on `{$error.code}`:
+
+```
+try:   create_record(lead, { email })
+catch: { $error.code === 'DUPLICATE_RECORD' } → swallow, continue
+       else                                   → re-raise / route the fault edge
+```
+
+Additive only — no existing field, message text or routing behaviour changes; an executor that never sets `code` (every one except `create_record` today) is unaffected. Deliberately scoped to `create_record` alone: `update_record` / `delete_record` collapse the same way, but `engine.update` still leaks the raw driver error (#14390, not yet fixed), so those node results have nothing structured to surface yet. `create_record` itself forwards `code` only when it equals `DUPLICATE_RECORD` — narrowly, on purpose, matching the ADR-0112 vocabulary member this repair was actually scoped to surface, not any code an as-yet-unaudited driver error might someday carry.
+
+**Patch round 1 (tier contract review):** `try_catch`'s catch region reads `code` off the run-wide `$error`, but the engine only rewrites `$error` when a failing node *returns* a failure, or *throws* through a node with its own `fault` edge — and a node inside a `try_catch`'s `try` region never has one (the region's synthetic sub-flow carries only the region's own edges). A node that fails by throwing (a `timeoutMs` firing, a dying nested container) therefore used to leave `$error` exactly as an *earlier, unrelated* failure left it — its `code` included. An identity guard (`$error` must have *changed*, not merely still be present, since this attempt started) closes that; two flows now pin it: a `loop` sweeping two rows where row 1 is a genuine duplicate and row 2 times out, and a plain flow where an earlier fault-routed duplicate must not leak into a later, unrelated `try_catch`.
+
+A custom `IDataEngine` implementation whose thrown error already carries `code: 'DUPLICATE_RECORD'` (without being an instance of `@objectstack/objectql`'s `DuplicateRecordError`) is treated as a duplicate too — correct under ADR-0112, since `code` is the classified envelope's public contract, not the concrete class.
+
+**Known gap, filed rather than fixed here (out of this lane's scope):** `packages/spec`'s `TryCatchErrorValueSchema` — the ONE declared shape for the `errorVariable` binding shared by author, engine and run log — does not declare `code` yet, and strips it on a strict parse. `packages/spec` is single-owner (`domain:spec`); tracked as #14954.
+
+<!-- adr-0087: not-required (no-migration-prescription) additive optional field; no authorable key, export removal or rename for an upgrader to migrate -->