Merge origin/main into claude/issue-14685-ratchet-cross-file-move

Two conflicts, both against main commits that landed after this branch's
merge base 5ff5f95:

- .claude/skills/pm-dispatch/references/lanes/services.md: main's
  365141f (#14856) edited the very bullet this branch deletes (the
  bullet moved to references/platform-readings.md). Settled to OUR side:
  the bullet stays deleted and the move stands. The FACT main corrected in
  that bullet (the i18n gates answer PREREQUISITE NOT MET with exit 3, not
  1) is carried into the moved text by the follow-up commit, so this merge
  commit's non-conflict content stays a pure merge of the two parents.

- scripts/check-ratchet-remedy-authority.mjs: main's a610775 (#14896)
  added the self-test battery roster and floor at the spot where this
  branch's section (21) sits. Settled by keeping BOTH: section (21) opens
  with battery('(21) ...'), is declared in SELF_TEST_BATTERIES at its case
  count (2), and sits before the floor-evaluation block; the roster's own
  size pin SELF_TEST_BATTERY_FLOOR moves 20 -> 21 by the header's own
  convention (the roster size is pinned at the declared count). The
  exception phrase stays assembled, never spelled, in author-facing text,
  and the gate's run line is byte-identical to main's.

scripts/pm/check-skill-line-ratchet.mjs auto-merged with main's c47a5ac
(#14853) verdict handshake; the two run-path verdict lines this branch adds
are outside that handshake, which covers selfTest()'s sentinel return only.

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

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/autonumber-default-unique.md

@@ -0,0 +1,73 @@
+---
+"@objectstack/spec": minor
+---
+
+feat(spec): an `autonumber` field is `unique: 'organization'` by default; explicit `unique: false` opts out (#13894)
+
+**BREAKING** emitted-shape change on `FieldSchema` (the accept set is unchanged),
+shipped as `minor` under the repo's launch-window convention for breaking changes.
+
+An auto-number is a business identifier — a contract number, a quote number, a
+case number — and an identifier that may repeat is not one. Yet the platform
+only ever materialized a unique index where the author had written `unique`
+by hand: of hotcrm's nine auto-numbered identifiers, exactly one
+(`crm_case.case_number`, `unique: true`) carried the tenant-composite unique
+index, and the other eight could mint the same number twice (measured:
+objectstack#12394 re-issued `ACC-000009`). Maintainer ruling 2026-08-31
+(hotcrm#1301): the default flips.
+
+- An `autonumber` field that **omits** `unique` now parses to
+  `unique: 'organization'` — one holder per organization, materialized by the
+  drivers exactly as `case_number`'s hand-written declaration was: the NULL-safe
+  tenant-composite index `(COALESCE(organization_id, '__global__'), <field>)` on an
+  organization-scoped object, a plain unique index on an object with no
+  organization key.
+- Every **other** field type keeps `unique: false` as its default, at the same
+  key position — parse output for non-autonumber fields is byte-identical.
+- Every **authored** spelling (`true`, `'organization'`, `'global'`, `false`)
+  parses exactly as before, on every type.
+- The default is materialized at parse time (the `.overwrite()` tail of
+  `FieldSchema`, the type-conditional precedent `deleteBehavior` set), because
+  the drivers read the parsed `unique` value-only; the published JSON Schema
+  therefore no longer carries `default: false` on `Field.unique` — the
+  description states the rule, and the authorable-defaults ratchet records the
+  move as `data/Field:unique = false → (none)`.
+
+**Opting out.** Write `unique: false` explicitly on the autonumber field. That
+is the whole opt-out surface — no second key. It is legitimate only for a
+display-only sequence that nothing uses to identify the record; note that the
+platform's duplicate scan (`os migrate duplicates`) keeps treating every
+autonumber field as an identifier regardless.
+
+**Migration — what an operator with existing duplicates sees.** A table that
+already holds duplicate auto-numbers cannot take the index. On SQLite/Postgres/
+MySQL the SQL driver does not fail the boot and does not skip silently: it logs
+on the `error` channel —
+
+```
+[sql-driver] cannot create NULL-safe unique index 'uniq_crm_quote_organization_id_quote_number' on "crm_quote" — existing rows violate it (duplicates the previous NULL-distinct index admitted, #5030). The constraint 'organization_id, quote_number' is NOT enforced until the data is deduplicated: run "os migrate plan" for the conflicting rows (ADR-0120 D4).
+```
+
+— and the same boot's drift pass names the conflicting key groups with their
+row counts:
+
+```
+[schema-drift] crm_quote: cannot create 'uniq_crm_quote_organization_id_quote_number' as UNIQUE (COALESCE(organization_id, '__global__'), quote_number) — existing rows already violate the NULL-safe unique constraint (duplicates the old index wrongly admitted, #5030): (organization_id="__global__", quote_number="QUO-00009") × 2 rows; (organization_id="org_x", quote_number="QUO-00010") × 2 rows. The op is BLOCKED: apply re-probes and refuses, and the existing index stays in place (ADR-0120 D4). Deduplicate the listed rows, then re-run "os migrate plan".
+```
+
+`os migrate plan` reports the same blocked `create_index` with the same groups
+until the rows are deduplicated; `os migrate duplicates` lists the holder row
+ids of any value minted across organization partitions (the seed/API split).
+Deduplicate — which duplicate keeps its number is a business decision — then
+re-run `os migrate plan` / restart, and the index materializes. An object with
+`tenancy.enabled: false` takes a plain unique index instead, and there the
+driver raises the database's own unique-violation error at boot (it names the
+index, not the rows) — run `os migrate duplicates` / a `GROUP BY <field> HAVING
+COUNT(*) > 1` to find them.
+
+Two landed defects change shape on purpose under the default: a counter that
+re-issues a number after a burned reservation (#12394) and two counters minting
+for one object (#8686) used to produce a *silent* duplicate; they now produce a
+loud unique-violation refusal at the write.
+
+<!-- adr-0087: registered autonumber-default-unique-organization -->

.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.