Merge branch 'main' into claude/issue-11958-vitest-inner-pool-bound

Author: yinlianghui

.changeset/admin-remove-user-gate-ordering.md

@@ -0,0 +1,40 @@
+---
+"@objectstack/plugin-auth": patch
+---
+
+fix(auth): authorize before the break-glass guard on `POST /api/v1/auth/admin/remove-user` (#11477)
+
+The break-glass last-local-credential guard is registered as a global better-auth
+`hooks.before`, which runs ahead of an endpoint's own middleware. On
+`/admin/remove-user` — served directly by better-auth's router, whose
+`adminMiddleware` establishes only a session, with the role decision landing
+later inside the vendor's handler — that ordering let the guard's lookup and its
+distinctive refusal be reached by any **authenticated** caller before either
+authorization layer had run. Because that refusal is target-dependent, the
+refusal itself carried a per-record fact about a user the caller was not
+entitled to ask about.
+
+`/admin/ban-user` already ran the same guard **after** authorization: #9652
+shades that path with an ObjectStack raw mount whose platform-admin gate fires
+first. One guard, two routes, opposite orders, and nothing asserting either.
+
+`/admin/remove-user` now carries the same shading, converging the whole
+`/admin/*` family on **authorization before the guard**. The mount reuses the
+landed #9652 / #9653 pattern and introduces no new mechanism.
+
+What changes is **when** the guard decides, never **what** it decides:
+
+- an anonymous caller still gets `401 UNAUTHENTICATED`;
+- an authenticated non-admin now gets `403 PERMISSION_DENIED` for every target,
+  so the guard is unreachable before authorization and its answer no longer
+  varies with the named user;
+- a platform admin is unaffected in every respect — the mount **delegates** into
+  better-auth rather than re-implementing removal, so the path-keyed hook still
+  fires and the guard still refuses the removal of the last local password
+  login, and admission remains the vendor's own decision (#9969).
+
+An ordering pin ships with the fix so the sequence is mechanically checkable
+rather than re-argued: it asserts that one authenticated non-admin naming two
+different targets receives **indistinguishable** responses, and — so the pin
+cannot be satisfied by deleting the guard — that an admitted platform admin
+still hits the guard's refusal, and still succeeds on an ordinary user.

.changeset/build-json-failure-payload-warnings.md

@@ -0,0 +1,79 @@
+---
+"@objectstack/cli": minor
+---
+
+feat(cli): `os build --json` carries the computed advisory lists on every failure exit, not the success payload alone (#11772)
+
+**Machine-contract widening on the `--json` failure payloads.** A consumer that
+today branches on `warnings` being ABSENT from an `os build --json` failure
+payload sees a different shape after this change.
+
+## What was wrong
+
+The text face prints its advisory blocks before the gates that can stop the
+run — the #11529 author-time advisories at step 3b, the #3786 undeclared
+authoring-key findings at 3d — and both end in `— re-run with --json for the
+full list`. But `warnings` lived on the TERMINAL SUCCESS payload only (plus,
+for `ruleAdvisories` alone, the author-time-rules failure). On a tree with 60
+undeclared authoring keys *and* a package-docs error:
+
+```
+os build         Undeclared authoring keys (60) … 50 rows …
+                 … and 10 more … — re-run with --json for the full list
+os build --json  {"success":false,"error":"docs validation failed","issues":[…]}
+                                                        ^ the 60 keys nowhere
+```
+
+The remedy the notice named returned a payload that did not contain the list,
+and the author could not reach the withheld entries by any route until an
+unrelated later failure was fixed — the "the remedy named is unreachable"
+shape of #11643 and #11391.
+
+## Which exits gain the field
+
+All nine failure exits of `os build --json`. Six already had a payload of their
+own; three more were found while enumerating (the filing card's table listed
+six). `warnings` is now present on every one, alongside each exit's existing
+keys, which are unchanged:
+
+| exit (step) | existing keys | `warnings` before | after |
+| --- | --- | --- | --- |
+| `strict-body: missing body` (2b) | `issues` | absent | `[]` |
+| protocol parse failure (3) | `errors` | absent | `[]` |
+| `author-time rules failed` (3b) | `issues` | `ruleAdvisories` | unchanged |
+| `capability provider preflight failed` (3c) | `issues` | absent | rule + capability |
+| `access matrix drift` (3e) | `changes` | absent | rule + key + capability |
+| `docs validation failed` (3f) | `issues` | absent | all four lists |
+| `--no-runtime-bundle` refusal (4b) | `error` | absent | all four lists |
+| `runtime bundle failed` (4b) | `error` | absent | all four lists |
+| thrown / caught (bottom) | `error` | absent | what the run had computed |
+
+The success payload is unchanged in content: its
+`[...ruleAdvisories, ...docWarnings, ...unknownKeyWarnings, ...capProviderWarnings]`
+spread — `os validate --json`'s order minus its trailing `structuralWarnings`
+— moved to a single `warningsSoFar()` site that every exit now reads, so the
+member order cannot drift between exits.
+
+## What a consumer keying off its absence should do instead
+
+⛔ `warnings` is no longer a signal of which exit produced the payload. Read
+`success` (and `error` / `errors`) for that; a consumer that inferred "this is
+a failure payload" from a missing `warnings` must switch to `success === false`.
+
+⛔ `warnings: []` on a failure payload does NOT mean "this tree raises no
+advisories". It means **this run stopped before those advisories were
+computed** — the two early exits above (`strict-body`, protocol parse) run
+before any advisory step, so their list is empty by construction. A consumer
+that needs the full advisory set for a tree must read it from a run that
+reaches at least the gate that computes it, or from `os validate --json`.
+
+✅ `warnings` is always an array on every `os build --json` payload, success or
+failure, so it can be read unconditionally — that shape constancy is the point
+of the change (maintainer ruling 2026-08-25, option 1 of three; option 2,
+"carry them only where the text face printed them", was rejected as the hardest
+contract to declare).
+
+Advisories stay CARRIED, never recomputed: each list is still computed at
+exactly the step that owns it, so an exit upstream of a step legitimately
+reports that list empty and no failure path pays for a computation it did not
+already do.

.changeset/client-unannotated-return-erasure.md

@@ -0,0 +1,52 @@
+---
+"@objectstack/client": minor
+---
+
+fix(client): bind the three verifiable methods of the unannotated return-type erasure population to their spec contracts (#11925)
+
+**Return-type narrowing on a published SDK.** No runtime change — the value each
+method resolves to is byte-identical before and after. Only the DECLARED type
+moved, off `any`, which is precisely why a runtime test cannot observe it and
+the pins for it are type-level.
+
+`any` is assignable to everything and admits every property read, so for each
+method below a consumer's code could stop compiling where it previously did
+not: assigning the result to an unrelated annotation, reading a property the
+bound type does not declare, or forwarding the value to a differently-typed
+parameter.
+
+## What changed, per family
+
+**`client.packages.list` → `{ packages: InstalledPackage[]; total: number }`**
+(was `{ packages: any[]; total: number }`). A consumer stops compiling if it
+reads any key off a row that `InstalledPackage` does not declare. Note in
+particular `source` (`'database' | 'registry' | 'both'`): the REST surface
+spreads it onto each row, the dispatcher surface does not, and it is therefore
+deliberately NOT declared — code reading `pkg.source` off this result compiles
+today and will not after. `total` and the array envelope are unchanged.
+
+**`client.packages.update` → `InstalledPackage`** (was `any`). This method
+declared no envelope before, so nothing about the shape claim changed; a
+consumer stops compiling if it reads an undeclared key off the returned row, or
+assigns the result somewhere `InstalledPackage` does not fit.
+
+**`ScopedProjectClient.packages.get` → `{ package: InstalledPackage }`** (was
+`{ package: any }`). The `{ package }` envelope is unchanged; only the member
+narrowed. A consumer stops compiling if it reads a key off `.package` that
+`InstalledPackage` does not declare — again including `source`, which this
+route does send and which stays undeclared for consistency with its already
+bound `list` sibling.
+
+## What deliberately did NOT change
+
+The other 36 methods in the measured population keep their erased `any`, each
+with a docblock stating why and pointing at the issue that carries it:
+`meta.*` history/diagnostics (9) and eight `packages.*` routes have no published
+response contract to bind to (#12038); `client.packages.get` has two mounted
+surfaces that emit different envelopes and `install`/`enable`/`disable` declare
+an envelope no surface emits (#12034); the 15 cloud `projects.*` methods call a
+control plane that speaks snake_case while the `@objectstack/spec/cloud` rows are
+camelCase, so binding to them would compile and be false (#12036).
+
+No consumer loses anything by those staying `any` — they are exactly as
+permissive as before.

.changeset/engine-findone-predicate-guard.md

@@ -0,0 +1,40 @@
+---
+"@objectstack/metadata-core": minor
+"@objectstack/objectql": minor
+---
+
+feat(metadata-core,objectql): publish `assertEngineFindOnePredicate` — the read-side member of the engine-double contract family (#11957)
+
+`ObjectQL.findOne` applies `limit: 1`, so a query naming no particular record
+would return an ARBITRARY row. `requireFindOnePredicate` (#4419) REFUSES that
+call. Every in-memory test double in the repo instead read an absent filter as
+"match everything" and answered happily, so a production call site that violates
+#4419 read as *working* under every unit suite and only failed on a real engine.
+
+That is measured, not hypothetical. `AuthManager.isBootstrapCreation` probed the
+bootstrap population with `findOne({ where: [] })` inside a `try/catch`; on a
+real engine that throws, the `catch` read the refusal as "users exist", and the
+declared first-run bypass became permanently inert on real deployments — while a
+641-line unit matrix over the double stayed green, including a case named
+"bootstrap: the very first signup is admitted" (#11767).
+
+New public API, mirroring the two write-side dispatch predicates
+(`assertEngineDeleteDispatch`, `assertEngineUpdateDispatch`) exactly — the
+implementation lives in `@objectstack/metadata-core` so that packages
+`@objectstack/objectql` itself depends on can reach it, and `@objectstack/objectql`
+re-exports every symbol:
+
+- `assertEngineFindOnePredicate(object, query)` — the line a fake engine's
+  `findOne` opens with; throws the engine's own message, object name included.
+- `resolveEngineFindOnePredicate(object, query)` — the same decision without the
+  throw, for a double that wants to classify.
+- `engineFindOnePredicateRefusalMessage(object)` — the refusal text, so an
+  assertion pins the producer's wording rather than a paraphrase.
+- `ENGINE_FINDONE_PREDICATE_CASES` — the shared conformance case-set, driven
+  against the REAL engine by
+  `packages/objectql/src/engine-findone-predicate.test.ts`, so the predicate
+  cannot drift from `engine.ts` unnoticed.
+
+Nothing is removed and no existing behaviour changes: the engine's own guard is
+untouched, and this publishes the decision it already makes so a double can
+import it instead of re-deriving it.

.changeset/skill-catalog-projected-issue-ids.md

@@ -0,0 +1,32 @@
+---
+"@objectstack/spec": patch
+---
+
+docs(spec): strip the internal issue-id references that were projected into the published skill catalog
+
+The 2026-08-23 ruling stripped internal `#NNNN` citations from the published
+skill corpus, but 14 of them were not authored in `skills/**` at all — they were
+projected there from `.describe()` / TSDoc text in `packages/spec/src/**` by
+`gen:skill-refs` and `gen:react-blocks`, so a hand-edit of the corpus could not
+reach them and a regeneration would have put them straight back.
+
+Six source sites are rewritten to say the same thing without the citation, and
+the artifacts are regenerated: the module summaries of `data/driver/common`,
+`data/driver/config-registry`, `data/driver/turso`, `shared/retry-policy` and
+`system/translation`, plus the `ListView.objectName` / `ListView.viewType`
+deprecation notes and the `<Block>` summary in `ui/react-blocks`. The teaching in
+each is kept, per the standing ruling of 2026-08-12, verbatim and untranslated:
+「处理 issue 时犯的错应该总结成经验,保留 issue id没有意义」.
+
+Customer-facing text changes in three places from the one source edit: the
+published catalog (`skills/*/references/_index.md`,
+`skills/objectstack-ui/references/react-blocks.md` and its sibling
+`contracts/react-blocks.contract.json`), and the docs site
+(`content/docs/references/data/driver-common.mdx`, `driver-turso.mdx`). No
+schema shape, no `.describe()` used for validation, and no accept/reject
+behaviour changes — the edits are comment and documentation text only.
+
+The doc-authoring gate's path exemption for the generated artifacts is removed
+in the same change: it existed only because those files still carried projected
+ids, and an exemption over a surface that no longer needs one is where the next
+regeneration would smuggle one back in.

.changeset/sqlite-rebuild-applied-honesty.md

@@ -0,0 +1,17 @@
+---
+"@objectstack/driver-sql": patch
+---
+
+**Fix:** on SQLite, `applyMigrationEntries` no longer reports an op as **applied** just because a table rebuild ran (#11722).
+
+`SqlDriver.applyMigrationEntries` splits by dialect, and the two arms disagreed about what `applied` means. The in-place arm (Postgres / MySQL) asks per entry and believes the answer — `applyDriftOpInPlace` returns `false` for an op its dialect cannot perform, and the entry goes to `skipped`. The SQLite arm did not ask at all: it called `rebuildSqliteTablePatched(table, ents)` and then `applied.push(...ents)`, every entry, unconditionally. But that rebuild honours exactly four op types — `relax_not_null`, `tighten_not_null`, `drop_column`, `drop_column_default` — and silently ignores everything else; its own docblock already said so for the varchar ops. An ignored op was still reported applied.
+
+**The failure mode is a false green, not an error.** Nothing throws and nothing is skipped, so every consumer announces work that never happened: `reconcileAndWarnDrift` logs `auto-reconciled <op> on <table>`, and the artifact boot gate prints `↪ migrated <op>`. The finding is still physically present, so the next boot detects it again, reports drift again, and "migrates" it again — a loop with no failing signal anywhere in it.
+
+**What changes.** `rebuildSqliteTablePatched` now returns the entries it actually acted on, built in the same pass that fills the four column sets it already partitioned into — deliberately not a second list of op types to keep in sync, so the returned set cannot drift from the work done. The caller reports those as `applied` and routes the remainder to `skipped`, logging it in the **same sentence** the in-place arm uses for an op its dialect cannot do (`<op> on <table>.<column> is unsupported on dialect 'sqlite' — skipped`), so one greppable line covers all three dialects. `@objectstack/driver-sqlite-wasm` and `@objectstack/driver-turso` extend `SqlDriver` without overriding either method, so both inherit the correction.
+
+**What deliberately does not change.** No op does anything different — this moves only what is *reported*. In particular the rebuild still runs for the whole table even when it honours nothing: it re-materializes every kept column's default (#11321, #4560) and the full declared index set from metadata (#3696), so it is not a no-op, and suppressing it would change what the reconciler DOES rather than what it says it did. `applied`/`skipped` remains a reported partition consumed by log lines and CLI counts; it is not an accept/reject door, and no public surface widens.
+
+**Latent when found, and fixed anyway.** The gap was unreachable at the time of the fix, held closed from two independent directions neither of which knew it was holding it: `enforcesVarcharLength` excludes SQLite, so the differ never emits `widen_varchar`/`narrow_varchar` there, and `multiValueColumnTypeIsLoadBearing` excludes SQLite for an unrelated measured reason, so #11535's `manual_column_type_change` is never emitted there either. The next column op that is not SQLite-rebuildable would have opened it silently. `manual_column_type_change`'s own docblock states that `applyMigrationEntries` reports it "skipped, never applied" — measured on Postgres and MySQL; that sentence is now also true on SQLite, and the docblock says so.
+
+Pinned by `packages/drivers/driver-sql/src/sql-driver-11722-sqlite-rebuild-applied-honesty.test.ts`, which constructs the reachability rather than waiting for it — it substitutes only the differ's dialect guard, handing entries straight to the public `applyMigrationEntries` seam that `os migrate apply` and the artifact boot gate both call, with a real driver, dialect and database throughout. All five cases fail on the pre-fix tree, including the consumer-level one that catches `auto-reconciled` being logged for an op that never happened.

.changeset/stale-fill-i18n-leaf-repair.md

@@ -0,0 +1,31 @@
+---
+"@objectstack/platform-objects": patch
+"@objectstack/plugin-webhooks": patch
+"@objectstack/service-messaging": patch
+---
+
+fix(i18n): re-translate the five leaves that served a superseded source revision (#12065)
+
+`os i18n extract` merges gaps only, so a revised source string leaves the previous
+revision standing in every translated locale — in sync by key, green under
+`check:i18n` and counted as translated by `check:i18n-coverage`. The five leaves
+`check:i18n-stale-fill` froze in its baseline are re-translated here from the
+**current** `en` source, and the baseline is ratcheted to empty in the same change.
+
+User-visible admin/Setup help text changes in `es-ES`, `ja-JP` and `zh-CN`:
+
+- `dataset.fields.measures.helpText` (metadata forms) — all three locales promised a
+  `"certified"` governance flag that was removed from the declaration in 16.0.
+- `sys_webhook.fields.method.help` — all three locales served the pre-revision method
+  enumeration after the source became a prose description.
+- `sys_webhook.pluralLabel` — `ja-JP` was an untranslated Latin fill and is now
+  Japanese; `zh-CN` keeps `Webhook`, which is the term this bundle's own Chinese prose
+  uses and which carries no plural inflection.
+- `sys_http_delivery.fields.attempts.help` — `es-ES` / `ja-JP` held an English fill and
+  `zh-CN` a translation of the same superseded source; all three now carry the
+  PARKED / terminal-row clause the source documents.
+- `sys_notification_subscription.fields.principal.help` — the selector list was missing
+  the `owner_of:object:id` and bare-email forms in all three locales.
+
+No schema, export or runtime behaviour changes: translated-locale leaf values only,
+plus the shrink-only ratchet baseline.