Merge remote-tracking branch 'origin/main' into claude/issue-14428-driver-update-missing-id

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/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/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/default-agent-canonical-spelling.md

@@ -0,0 +1,72 @@
+---
+"@objectstack/platform-objects": patch
+"@objectstack/lint": patch
+"@objectstack/mcp": patch
+---
+
+fix(ai): author the CANONICAL agent id everywhere the platform teaches one — Studio's pin, the MCP prompt example, and the lint's value roster (#14461)
+
+`skills/objectstack-ai` tells authors that `data_chat` and `metadata_assistant`
+"are **not** vocabulary — always write `ask` / `build`". The platform then
+taught the opposite from every live example it ships. Nothing was broken at
+runtime; what was wrong is what an author copies.
+
+**Studio's pin.** `studio.app.ts` was the repo's ONLY `app.defaultAgent` usage,
+and it spelled the alias:
+
+```
+- defaultAgent: 'metadata_assistant',
++ defaultAgent: 'build',
+```
+
+The triage card left this undecidable — if the cloud plugin registered the
+agent under the legacy id, re-pinning would be a behaviour change in a
+consumer this repo cannot see. Measured instead of assumed, at `cloud`
+`main@3856fbf7`: `service-ai-studio/src/agents/metadata-assistant-agent.ts:12,40`
+ships the record as `name: BUILD_AGENT_NAME` = `'build'`, and `plugin.ts:58`
+registers `metadata_assistant` as a **one-way, resolution-only** legacy alias.
+The canonical id *is* `build`; the old pin reached it by detour.
+
+Nor is the re-pin cosmetic. Alias resolution depends on an in-memory
+`registerAgentAlias` call having run at plugin init, and cloud carries two
+defensive docblocks about that registration silently no-op'ing for real under
+bundle load ordering (`service-ai-studio/src/plugin.ts:44-57`,
+`service-ai/src/agent-runtime.ts:30-41` — "a missed alias must never hide a
+real platform agent like `build`"). The canonical id never touches the alias
+table, so this drops a load-order dependency from the platform's own flagship
+authoring surface. On the UI side nothing moves: `objectui`'s
+`AGENT_ALIAS_GROUPS` is bidirectional and canonical-first, and
+`SURFACE_DEFAULT['studio-build']` was already `'build'`.
+
+**The MCP prompt example.** `mcp-server-runtime.ts`'s `agent_prompt` argument
+described itself as `'Name of the agent to load (e.g. "data_chat",
+"metadata_assistant")'` — two retired aliases, neither canonical id present.
+That string is served to every MCP client asking what to pass, so the one
+surface that suggests a spelling to an LLM suggested the two the catalogue
+forbids. Now `(e.g. "ask", "build")`.
+
+**The lint's value roster.** `validate-ai-agent-authoring`'s `defaultAgent`
+**value** limb reused the four-name `PLATFORM_AGENT_NAMES` set, so it
+deliberately passed `metadata_assistant` — the gate that exists to make
+authoring mistakes loud waved through the exact spelling the catalogue bans,
+which is the silent-tolerance shape ADR-0078 exists to close, committed by the
+gate itself. The two limbs now read different tables, because they ask
+different questions:
+
+- **declaration limb** — unchanged, still all four names. Declaring
+  `metadata_assistant` shadows the `build` record through the alias exactly as
+  declaring `build` does.
+- **value limb** — canonical `ask` / `build` only. A legacy alias gets its own
+  rule id `default-agent-legacy-alias` (exported) and its own wording, because
+  an alias **resolves** (the app gets the agent it meant — a spelling defect)
+  while an unknown name does **not** (the pin is inert). Describing the alias
+  as "no effect" would send an author hunting a bug that is not there.
+
+Both of the #6041 ruling's operative decisions are kept intact: still
+`warning` tier, still no Zod enum narrowing. `defaultAgent: 'metadata_assistant'`
+keeps parsing, building, and resolving — the only change is that authoring it
+now says so.
+
+Not breaking: nothing an author can write was removed, and both aliases stay
+resolvable for old bookmarks and persisted `agent_id`s, which is the only job
+ADR-0063 §2 ever gave them.

.changeset/explain-zero-rows-sentinels.md

@@ -0,0 +1,34 @@
+---
+"@objectstack/spec": patch
+---
+
+docs(spec): the published `explain` payload contract now names BOTH zero-rows sentinels
+
+`ExplainDecision.readFilter` and `ExplainRecordAttribution.rowFilter` are the
+machine artifact behind the explain prose, and their published description
+enumerated the zero-rows vocabulary as a closed two-item list: `null` =
+unrestricted, `{ id: '__deny_all__' }` = zero rows.
+
+That enumeration had grown incomplete. A fail-closed RLS denial — the "no
+active organization" path, which composes plugin-security's `RLS_DENY_FILTER`
+and is guaranteed to return zero rows — is reported with verdict `denies` and
+`allowed: false`, while the payload keeps reporting the predicate that was
+ACTUALLY composed: an `id` equality against `__rls_deny__` plus a colon and a
+UUID-shaped suffix. So a reader of the contract met a zero-rows shape the
+contract did not name.
+
+Both fields now name both shapes, say that the RLS denial is published as
+composed (and can therefore ride inside an `$and` composite on `readFilter`),
+and say which fields are the DECISION — `allowed` and the `rls` layer's
+`verdict` for `readFilter`; `outcome` / `matchesRecord` and the layer's
+`verdict` for `rowFilter` — so a consumer that pattern-matches the payload
+alone to detect "zero rows" is told it must match both.
+
+`readFilter` carried its enumeration in a JSDoc block only, which no generator
+reads: its published description cell and its JSON Schema `description` were
+both EMPTY. It now carries a `.describe()`, so the reference page and the
+emitted JSON Schema publish the vocabulary instead of nothing.
+
+Text only. `readFilter` / `rowFilter` remain `z.unknown()`, no accepted value
+changes, no emitted payload changes, and the two sentinels are not unified —
+the sentinel vocabulary itself is a separate, deployment-facing decision.

.changeset/generate-field-type-vocabulary-totality.md

@@ -0,0 +1,40 @@
+---
+"@objectstack/cli": patch
+---
+
+fix(cli): `os generate` now has an answer for every field type, instead of silently guessing
+
+Three hand-kept vocabularies in `generate.ts` decide what `os generate types`
+and `os generate migration` emit for a field: the TypeScript type, the SQL
+column type, and the knex builder call. None of them was ever checked against
+the `FieldType` enum they describe, and measured against the 49 members on
+`main`, **21 real members had no entry in either lookup table and 24 had no arm
+in the migration switch**.
+
+An unmapped member did not fail — it fell to the default. So a `secret` field
+scaffolded as TypeScript `unknown` and a `TEXT` column, a `location` as
+`unknown` and `TEXT`, and `address` / `composite` / `repeater` / `record` — all
+four stored as JSON on the parent row — as scalar `TEXT` columns. The output
+looked plausible and nothing said otherwise, which is what made this worth
+fixing rather than tidying.
+
+All 49 members now have an entry in all three, and the values are read off the
+platform rather than invented: the spec's ADR-0104 D1 value classes
+(`STRING_VALUE_TYPES`, `NUMERIC_VALUE_TYPES`, `STRUCTURED_JSON_TYPES`, …) decide
+the class, and `driver-sql`'s own DDL emitter — which creates the real columns —
+decides the shape. `location` becomes a JSON column, not a `POINT`: that is what
+the driver does, `POINT` is not portable to SQLite, and the spec's own value
+contract for it is `{lat, lng, altitude?, accuracy?}`. `location` and `address`
+now emit the spec's exported `Data.LocationValue` / `Data.AddressValue` types,
+so the generated interface cannot drift from the value contract.
+
+The gap can no longer reopen quietly. Both lookup tables are
+`satisfies Record<FieldType, string>`, so a field type added to the spec is a
+named compile error here; the switch — whose scrutinee is a plain string off an
+unvalidated config and so cannot carry one — is held by
+`generate-field-type-vocabulary.pin.test.ts`, which walks the real enum and
+names any member left unmapped.
+
+The runtime fallbacks (`|| 'unknown'`, `|| 'TEXT'`, `default:`) are unchanged
+and still reachable: they answer a `type` string that is not a field type at
+all, which the unvalidated authoring door can still deliver.

.changeset/sandbox-hook-input-writeback-key-set.md

@@ -0,0 +1,50 @@
+---
+"@objectstack/runtime": patch
+---
+
+fix(runtime): the sandbox hook write-back carries the keys the body wrote, not every key it could see
+
+A sandboxed `before*` hook body's mutations were written back onto the engine's
+payload with `Object.assign(target, mutatedInput)`, where `mutatedInput` is the
+whole post-run `ctx.input` — every key the body could see, touched or not. That
+target is the engine's flat-input Proxy, and every assignment through it is
+recorded by the hook-write provenance recorder. So the write-back was reporting
+that a body which touched nothing had written every payload key.
+
+The per-row divergence refusal that ends "one hook-mutated payload applied to
+every matched row" on a `multi: true` update reads exactly that recording: per
+row, the key set the hook chain assigned, refusing the batch when two rows
+disagree. All rows share ONE payload, so the noise was order-dependent — with a
+transition stamp bound to `beforeUpdate`, one open row and one already-completed
+row:
+
+- already-done row dispatched first: the windows differ, the batch is refused;
+- open row dispatched first: the already-done row inherits `completed_at` from
+  the transitioning row's write onto the shared payload, the blanket write-back
+  re-asserts it as that row's own write, the windows match — and the refusal
+  abstains, moving a `completed_at` on a record that never transitioned.
+
+The refusal was therefore true for in-process handlers and, in one of two driver
+row orders, silently untrue for shipped hook bodies. The QuickJS runner now arms
+a write recorder on `ctx.input` for hook bodies — the same recorder shape
+`ctx.record` has used since the discarded-record-write report — and the
+write-back re-asserts only the keys the body assigned, defined or deleted.
+
+Nothing else about the channel moves:
+
+- deletion still propagates, unchanged. It was never expressed by the merge:
+  the write-back reads it from the entry snapshot as absence-from-the-dump,
+  before both merges, and a key the body never touched is present in the dump
+  and so is never deleted.
+- a write made THROUGH a value read from the input (`ctx.input.meta.x = 1`)
+  trips no trap on `ctx.input` itself, so it is carried from the dump instead:
+  an object-valued entry key whose dumped value no longer matches the entry
+  snapshot was written through. Primitives need no such leg — a primitive
+  cannot be mutated in place.
+- when the recorder cannot speak — an older runner, a read that failed, a body
+  that replaced `ctx.input` with a non-object — the write-back falls back to
+  the full assign it did before. Narrowing on a key set that is not trustworthy
+  would silently drop a write the body really made. An empty key set is a
+  different answer from an absent one and does narrow.
+
+Hook bodies only; the action path has no input write-back to inform.