Merge remote-tracking branch 'origin/main' into claude/issue-7725-accept-invitation-adopt-membership

Resolved packages/plugins/plugin-auth/src/objectql-adapter.ts: the only
conflict was the import block, where #7825's session-tombstone helpers and
this branch's adoptExistingMembership landed on the same line. Both imports
are kept — the two features hook disjoint adapter methods (adoption on
`create`, tombstoning on `findOne`/`findMany`/`delete`/`deleteMany`), so
neither side may be taken wholesale.

Author: claude

.changeset/action-confirm-one-dialog-identity.md

@@ -0,0 +1,51 @@
+---
+"@objectstack/platform-objects": patch
+---
+
+fix(platform-objects): one decision, one dialog — carry identity confirm questions on `description` (#7309)
+
+The shared console action runner chains confirmation **then** param collection,
+both awaited (objectui `packages/core/src/actions/ActionRunner.ts`). An action
+declaring `confirmText` **and** `params` therefore opened **two** sequential
+dialogs for one click, with nothing sent until the second — while the first
+already read as "the action ran".
+
+The maintainer's 2026-08-10 ruling on #7278 (shipped in PR #7592) is to carry the
+confirm question in the action's top-level `description` (#7367), which the param
+dialog renders under its title, and to drop `confirmText`. #7278 applied it to the
+two `plugin-approvals` actions; this change sweeps the **14** remaining in-repo
+action sites, all in `identity/`:
+
+| object | actions |
+|---|---|
+| `sys_user` | `ban_user`, `delete_my_account`, `disable_two_factor`, `generate_backup_codes` |
+| `sys_oauth_application` | `enable_oauth_application`, `disable_oauth_application`, `rotate_client_secret`, `delete_oauth_application` |
+| `sys_two_factor` | `disable_two_factor`, `regenerate_backup_codes` |
+| `sys_account` | `unlink_account` |
+| `sys_organization` | `change_slug` |
+| `sys_sso_provider` | `delete_sso_provider` |
+| `sys_team_member` | `remove_team_member` |
+
+**No warning was reworded and none was dropped** — each question moves verbatim
+from `confirmText` to `description`, so the user still reads it before committing,
+now in the one dialog that collects the params. `sys_oauth_application.rotate_client_secret`
+went from three dialogs to two: one param dialog (question + `client_id`), then the
+existing post-run `resultDialog` that reveals the new secret. That reveal is output
+shown once *after* the rotation, not a second pre-run decision, so it stays.
+
+**`confirmText` is untouched where it is still correct.** A param-LESS action has
+no param dialog to fold the question into, so the confirm *is* its only dialog —
+`delete_organization`, `leave_organization` and `impersonate_user` keep theirs.
+
+The `en` / `zh-CN` / `ja-JP` / `es-ES` bundles move the same 14 leaves by hand.
+`os i18n extract` treats a renamed key as a new gap and this repo extracts with
+`--fill=default`, which would have seeded English over the curated translations
+in three of the four shipped locales — invisible to `check:i18n`, whose fresh
+extract would agree with the English it just wrote. A carryover test pins each
+locale as translated rather than echoing the English source.
+
+Tests pin the user-visible consequence in both directions: that an action
+carrying params opens one dialog, **and** that its question is still shown.
+Deleting a warning instead of moving it goes red on `ban_user`,
+`delete_my_account` and `rotate_client_secret` — the failure a "no `confirmText`
+anywhere" grep cannot see.

.changeset/adr-0087-wrapped-mention-not-a-label.md

@@ -0,0 +1,35 @@
+---
+"@objectstack/spec": patch
+---
+
+fix(spec-tooling): a hard-wrapped mention no longer reads as a migration label (#7094)
+
+Branch 1 of the ADR-0087 completeness gate decides whether the `FROM`/`TO`
+placeholder is being **used** as a label or merely **mentioned** in a sentence, by
+looking at the one character to its left. Prose in this repo is hard-wrapped at ~80
+columns, so a mention that happens to wrap onto a fresh line has *nothing* to its
+left — its governing word is on the line above — and was read as a declaration.
+That direction hard-blocks an author: all four dispositions close at once and the
+only remaining move is to reword a sentence that was true.
+
+When the placeholder opens its line, the question is now asked of the line above
+instead — and it is a **narrower** question there. Within a line, adjacency is the
+evidence and any attached word governs. A line break is ambiguous by construction, so
+across it only a closed class of determiners, possessives and complement-taking
+prepositions counts: `carry their` continues into the next line, `ends the line here`
+does not. A structural line above (heading, table row, fence marker) does not wrap at
+all, and a blank line above opens a paragraph — both keep their previous reading.
+
+Measured over the whole 1792-changeset stock before and after: 176 hits / 132
+declared-breaking → 174 / 132. The two that leave are `changelog-ships-in-tarball.md`
+(the reported specimen) and `notification-retirement-evidence-corrected.md`, both
+mentions on inspection and **neither declaring a breaking change**. The
+`--audit-stock` worklist is byte-identical — residue 97, `!` candidates 52 — so no
+declared-breaking changeset changed state. The gate's diff-only posture (#6129) is
+untouched, and no ledger entry is added or implied.
+
+The wider version of this fix — reusing the in-line "any letter governs" test across
+the wrap — was written first and rejected by its own positive control, which is
+pinned as an assertion rather than described: it turned every label wrapped under an
+ordinary sentence into a mention. The self-test gains 11 assertions (142 → 153)
+covering both directions.

.changeset/api-key-revoke-product-route.md

@@ -0,0 +1,54 @@
+---
+"@objectstack/platform-objects": patch
+"@objectstack/plugin-auth": patch
+---
+
+fix(platform-objects,plugin-auth): let the API-key revoke/restore actions actually run (#7727)
+
+`sys_api_key` contradicted itself. It declared two row actions —
+`revoke_api_key` / `restore_api_key` — as `PATCH /api/v1/data/sys_api_key/{id}`
+with `bodyExtra: { revoked: true|false }`, while the same object set
+`enable.apiMethods = ['get', 'list']`. The declared PATCH was refused at the
+ADR-0049 method gate with `405 OBJECT_API_METHOD_NOT_ALLOWED` before any
+authorization ran, so **no product route revoked an API key**: the Setup →
+API Keys → Revoke button produced an error toast, the row still read
+`revoked = false`, and the key kept authenticating. A leaked key could only be
+retired by writing the row out of band.
+
+Enforcement of the flag was never the problem — the verifier filters
+`revoked: false` and re-checks the row, so a flipped bit takes effect on the
+very next `x-api-key` call. The missing piece was purely the write path, and it
+had **two** gates, not one:
+
+- **The method gate.** `enable.apiMethods` now carries `update`. `create` and
+  `delete` stay off: minting is `POST /api/v1/keys` (the only path that ever
+  returns the raw secret) and keys are retired by revoking, not deleting.
+- **The affordance reconciler.** ADR-0103's `reconcileManagedApiMethods` strips
+  any write verb a `managedBy` object's resolved affordances do not grant —
+  warning, not failing. So `apiMethods` alone would still have served 405 while
+  the source read correctly. `userActions: { edit: true }` declares the
+  affordance, exactly as `sys_user` does under ADR-0092 D4.
+
+**Opening the method does not open the columns.** `sys_api_key` stays
+`managedBy: 'better-auth'`, so ADR-0092 D2's identity write guard still
+fail-closed rejects user-context writes, and its per-object update whitelist
+remains the only opening. `revoked` is registered there and nothing else is:
+`key` stays unwritable (a rotated hash would mint a credential nobody holds),
+`user_id` stays unwritable (re-owning a key is privilege transfer), and
+`expires_at` stays on the mint path. A PATCH carrying only non-whitelisted
+columns is refused `403 PERMISSION_DENIED` rather than degrading into a
+timestamp touch, and a mixed patch applies `revoked` while stripping the rest.
+The guard itself is unchanged — no general weakening, and every other identity
+table keeps its default-deny.
+
+Per ADR-0092 D4's form-rendering constraint, the columns outside the whitelist
+(`name`, `prefix`, `user_id`, `scopes`, `expires_at`) are now `readonly`, so the
+edit form this affordance turns on cannot offer a write the server refuses —
+the declared-≠-enforced shape that caused the original defect.
+
+Nothing pinned any of this before: the existing tests exercise key *resolution*
+against a pre-revoked row and never call the route the actions declare, which is
+how a declared action and a method gate cancelled out unnoticed. The new
+`api-key-revoke-lifecycle` dogfood suite drives the real PATCH, asserts `200`,
+and then asserts the consequence — the key stops authenticating — because a 200
+that leaves the key working is the defect wearing a success code.

.changeset/bu-tree-share-recompute.md

@@ -0,0 +1,11 @@
+---
+'@objectstack/plugin-sharing': patch
+---
+
+Recompute `unit_and_subordinates` / `business_unit` sharing-rule grants when the business-unit graph changes.
+
+**Security:** read access granted through a business-unit sharing rule is now withdrawn immediately when the business unit is moved out of the shared subtree, deactivated or deleted, or when the membership row is removed — previously it survived until the shared record happened to be written next, which put no bound at all on how long a revoked recipient kept reading the record.
+
+The sharing-rule recompute hooks were registered only on each rule's own object, and nothing was registered on `sys_business_unit` or `sys_business_unit_member`. A rule whose recipient resolves through the business-unit tree therefore never re-materialised its `sys_record_share` grants when the tree or a membership moved. Writes to both tables now drive a recompute: the withdrawal is synchronous and complete before the write returns (scoped by recipient, so it needs no scan of the records the rule matches), and the grant direction — a unit moved *into* a shared subtree — is queued on the existing re-grant queue.
+
+Only recipient kinds that actually read the business-unit graph are recomputed (`business_unit`, `unit_and_subordinates`); `user`, `team`, `position` and `queue` rules are untouched by a business-unit write.

.changeset/console-sha-drift-dev-guard.md

@@ -0,0 +1,33 @@
+---
+"@objectstack/cli": patch
+---
+
+fix(cli): `os dev` refuses to serve a console built from a different objectui SHA than the pin (#7752)
+
+`packages/console/dist` is a gitignored local build that only
+`scripts/build-console.sh` (`pnpm objectui:build`) refreshes — `turbo run
+build` never touches it. Pull a branch that moves `.objectui-sha` and the pin
+advances while the dist stays frozen, so the server keeps serving a Console
+SPA the repo no longer pins.
+
+`pnpm check:console-sha` already fails on exactly this, but it is wired into
+the root `pnpm dev` / `dev:showcase` / `dev:crm` / `dev:todo` scripts only.
+Every other way to boot reaches the server without passing it — `objectstack
+dev` run inside an example dir, an example's own `dev` script (`objectstack
+dev --seed-admin`), a `.claude/launch.json` config driving `pnpm exec
+objectstack dev`. A QA sweep booted that way and spent its run measuring a
+console two days behind the pin; two of its clauses had to be recorded
+`blocked` once the gap was found.
+
+So the guard gets a second seat on the boot path itself. When the dist carries
+an objectui stamp that provably differs from the repo's pin, `os dev` now
+declines to mount `/_console` and prints the rebuild remediation, instead of
+serving the stale bundle under a warning that scrolls past. The API still
+boots, so api/cli work is unaffected, and the banner stops advertising a
+console URL that would have been a lie.
+
+Deliberately narrow: dev only, and only on drift it can prove. A published
+install ships no `.objectui-sha` pin and the sibling-repo dev fallback writes
+no stamp — both keep resolving exactly as before, and no production or cloud
+deployment can reach the refusal. `OS_ALLOW_CONSOLE_DRIFT=1` boots the stale
+bundle anyway when that is what you want.

.changeset/email-template-default-locale.md

@@ -0,0 +1,33 @@
+---
+"@objectstack/plugin-email": patch
+"@objectstack/spec": patch
+---
+
+fix(plugin-email): a `sendTemplate` with no locale renders the documented en-US default, not an arbitrary row (#7731)
+
+With an i18n bundle in `sys_email_template` — `en-US` and `zh-CN` rows under one
+name — a `sendTemplate` call that named no `locale` rendered **zh-CN**, on two
+consecutive fresh boots. Three declarations say en-US is the answer there
+(`SendTemplateInput.locale`, `EmailTemplateDefinitionSchema.locale`, and
+`sys_email_template`'s own object doc); the code asked the driver instead.
+
+Two seams, both now answering from the contract:
+
+- The `sys_email_template` loader moved out of `EmailServicePlugin` into
+  `createSysEmailTemplateLoader`. Its no-locale branch queries
+  `(name, 'en-US')` by name rather than `{ name }` unordered with `limit: 1`,
+  so no driver's row order can change the answer. Every query it issues carries
+  an `orderBy`, so duplicate rows for one locale resolve the same way on every
+  boot too.
+- `EmailService.sendTemplate`'s ladder asks for `DEFAULT_TEMPLATE_LOCALE` when
+  the caller named no locale — the en-US fallback used to run only when a
+  locale *had* been named, so the no-locale path never reached it.
+
+A bundle with no en-US row at all (a single-locale tenant) keeps rendering:
+the lowest locale tag in the bundle is used, ordered rather than arbitrary.
+Explicit locales are unchanged — exact match, then en-US. Language-only prefix
+matching (`zh` → `zh-CN`) is still not performed; no contract declares it.
+
+`SendTemplateInput.locale` (spec, doc-comment only) now spells the whole ladder
+out, including that last rung — behaviour a caller can rely on has to be
+declared where the contract is, not only where it is implemented.

.changeset/external-error-http-status.md

@@ -0,0 +1,46 @@
+---
+"@objectstack/spec": patch
+---
+
+fix(spec): the external-federation error family declares its HTTP status, so a write refusal stops leaking as a bare 500 (#7739)
+
+A write to a read-only federated external object was refused correctly on the
+server — `ExternalWriteForbiddenError` names the datasource, its `schemaMode`,
+and both flags that would be required, and nothing is applied (the gate throws
+before the driver is reached) — but it reached the client as a bare
+**500 INTERNAL_ERROR with no `code`**, indistinguishable from the server
+falling over.
+
+The `code` existed the whole way down: `EXTERNAL_WRITE_FORBIDDEN` is registered
+in the ADR-0112 error-code ledger. What the error did not carry was an HTTP
+**status**, and no HTTP exit can invent one — so the refusal fell past every
+structured branch of the REST boundary, matched no message heuristic, and left
+through the terminal sanitised 500 that drops the `code` with it.
+
+**The whole family now declares its status, in one table.** New export
+`EXTERNAL_ERROR_HTTP_STATUS` (`@objectstack/spec/shared`) maps every
+`EXTERNAL_ERROR_CODES` member to the status it is reported with, and each of
+the three error classes carries the corresponding value as `status`:
+
+| code | status | why |
+| --- | --- | --- |
+| `EXTERNAL_WRITE_FORBIDDEN` | **403** | a policy refusal — the identical body succeeds once `datasource.external.allowWrites` and `object.external.writable` are both on, so 400/422 ("fix your request") would be a lie and 409 promises a retry that cannot help |
+| `EXTERNAL_SCHEMA_MODE_VIOLATION` | **403** | the same sentence about DDL: `schemaMode !== 'managed'` forbids it, and no rewritten request changes that |
+| `EXTERNAL_SCHEMA_MISMATCH` | **503** | not the caller at all — the deployment's metadata and the remote table diverged, only an operator can reconcile them, and it may clear (the reading `ERR_DATASOURCE_UNAVAILABLE` already gets) |
+
+Declared at the **producer** rather than in a REST error map, because every
+HTTP exit in the framework already resolves `status` then `statusCode` —
+`mapDataError`'s `declaredHttpStatus`, `resolveErrorResponse`,
+`HttpDispatcher.errorFromThrown`, `dispatcher-plugin.errorResponseBase`,
+`endpoint-executor`, `domains/actions`, `plugin-hono-server`. One table fixes
+every door at once; a branch in the REST server would have fixed one and left
+the runtime dispatcher, the endpoint executor and the CLI answering 500 for the
+same throw. `satisfies Record<ExternalErrorCode, number>` makes a future gate
+that adds a code without a status a compile error, so the family cannot
+silently re-acquire a member that leaks as a 500.
+
+**What callers see now.** `POST /api/v1/data/<external_object>` against a
+read-only federated object answers `403` with `code:
+"EXTERNAL_WRITE_FORBIDDEN"` and the refusal detail naming both flags to set,
+instead of `500` with no `code`. Behaviour is unchanged — nothing was applied
+before and nothing is applied now; only the envelope was wrong.

.changeset/federated-boot-binding-reconciliation.md

@@ -0,0 +1,49 @@
+---
+"@objectstack/objectql": patch
+"@objectstack/service-datasource": patch
+---
+
+fix(objectql,service-datasource): bind federated objects to their remote tables whatever the boot order, and report the ones that could not be bound (#7737)
+
+`driver.registerExternalObject(obj)` is the only thing that installs an
+ADR-0015 federated object's read metadata — the object -> remote-table mapping
+(`external.remoteName` / `remoteSchema`), the `external.columnMap` translation
+and the coercion maps. An external object that never gets it resolves to a
+table named after the OBJECT rather than the remote table it declares, so every
+read against it fails with `no such table`, or answers from the wrong table.
+
+`ObjectQLPlugin`'s boot schema-sync calls it, but that call runs inside the
+engine plugin's `start()`, while the declared datasource that owns the remote
+database is auto-connected in `AppPlugin.start()` — a later `start()`. So on a
+perfectly healthy boot `getDriverForObject()` answers `undefined` for every
+federated object at that moment and the call is skipped; whether the object ends
+up bound depended on some other component re-driving it afterwards. Two cases
+where nothing did:
+
+- an object routed to the datasource by a **`datasourceMapping` rule** (#4462)
+  rather than an explicit `object.datasource` — `DatasourceConnectionService`
+  re-drove only the explicitly-bound list;
+- any deployment running with **`OS_SKIP_SCHEMA_SYNC`** — that flag is about DDL
+  managed out of band, and this binding is DDL-free, but it took both
+  `syncRegisteredSchemas()` calls (and the only in-plugin binding site) with it.
+
+**What changed**
+
+- `ObjectQLPlugin` now runs a federated-binding reconciliation on
+  `kernel:ready`, after every plugin's `start()` has completed: it re-drives the
+  binding for every registered external object (idempotent) regardless of which
+  plugin connected the datasource, in which slot, or whether DDL was skipped.
+  Boot order no longer decides whether federation works.
+- The same pass **reports** what it could not bind, at `error`, naming the
+  objects, their datasources, the consequence and the fix. Previously the entire
+  diagnosis of a broken federation was one `debug` line reading
+  `No driver available for object, skipping schema sync` — invisible at any
+  normal log level, and emitted on healthy boots too. A boot with nothing to
+  report stays silent.
+- `DatasourceConnectionService.connect()` now re-drives `mappedObjects`
+  alongside `objects` when a datasource comes up, so a mapping-routed federated
+  object is also bound by a **runtime** (UI-created) datasource connect, not
+  only at boot.
+
+No authoring surface changes; a deployment whose federated objects already
+worked behaves identically.