Merge remote-tracking branch 'origin/main' into claude/issue-14685-ratchet-cross-file-move

Author: claude

.changeset/auth-bindings-off-registerroutes.md

@@ -0,0 +1,42 @@
+---
+"@objectstack/plugin-auth": patch
+---
+
+fix(plugin-auth): the mail transport, brand and locale bindings no longer depend on `registerRoutes`
+
+`AuthPlugin` bound five things to the live kernel on `kernel:ready` — the
+outbound mail transport (`setEmailService`), the SMS transport
+(`setSmsService`), the deployment email locale (`setDefaultEmailLocale`), the
+brand name (`setAppName`) and the SMS locale (`setDefaultSmsLocale`) — from
+inside the same hook that mounts `/api/v1/auth/*`, and that hook was gated on
+`registerRoutes`.
+
+`registerRoutes` answers a transport-mounting question: should this plugin put
+its own routes on the kernel's `http-server`. The bindings are service
+composition, and they are true of an embedding regardless of who serves the
+routes. So an embedding that serves auth routes itself — the whole point of
+`registerRoutes: false` — came up with no mail transport, no locale on either
+channel and no brand binding. Silently: the `logger.info` lines that report the
+wiring were inside the same skipped block, and the `localization` settings
+namespace was not even read. One visible consequence was that the workspace
+language could not reach auth mail on such a host at all, and
+`/api/v1/auth/config` answered `requireEmailVerification: false` because
+`resolveRequireEmailVerification()` saw no transport.
+
+The composition block now registers as its own unconditional
+`ctx.hook('kernel:ready', …)` — the shape the sibling diagnosis and dev-seed
+hooks in this plugin already use — placed before the route hook so a routing
+host keeps the ordering the single combined hook gave it.
+
+Route registration itself stays gated: a `registerRoutes: false` kernel still
+mounts no auth routes.
+
+**Behaviour change for `registerRoutes: false` embeddings.** They now resolve
+the `email`, `sms`, `i18n` and `settings` services at `kernel:ready`, apply
+`branding.workspace_name` and `localization.locale` (subscribing to both), seed
+the built-in auth SMS templates when phone sign-in is enabled, and emit the
+four wiring `info` lines. Hosts that had compensated by wiring these by hand
+should expect the plugin's own binding to run as well; both paths are
+idempotent setters, and an explicit workspace setting keeps outranking a
+manifest default exactly as it does on a routing host. Nothing changes for a
+host that leaves `registerRoutes` at its default.

.changeset/try-catch-failing-catch-step-record.md

@@ -0,0 +1,37 @@
+---
+"@objectstack/service-automation": patch
+---
+
+fix(automation): a `try_catch` whose `catch` region itself fails now keeps the step record of both regions
+
+`try_catch` returns a failure from three sites. #13803 taught the engine to fold
+a dying container's carried steps off the THROW channel, #14184 taught its
+returned-failure branch (`if (!result.success)`) to do the same, and #14184 also
+taught the first producer — a `try_catch` with no `catch` region — to supply
+them. The second producer was left unfolded: when a `catch` region is present
+and the handler itself fails, the return dropped `childSteps` entirely.
+
+That is the same defect one path over, and the worst of the three for an
+operator, because TWO regions ran. The try region may have written rows before
+it failed; the handler may have written more before IT failed; the run log kept
+a step for neither, so the run summary folded over that log reported `acted: 0`
+over writes that had genuinely landed. `acted: 0` on a failed run reads as
+"nothing happened, safe to re-run", which for a non-idempotent region invites
+double-execution.
+
+Closing it needed the half that was genuinely missing rather than the available
+one: the failed try attempts were already in scope, but the catch region ran
+without a `partialSteps` sink, so when the handler threw, the handler's own
+completed steps unwound with the stack. The catch region now receives the same
+sink the try region already had (`runRegion`'s fifth argument), and the failing
+return carries `[...failedTryAttempts, ...catchAttempts]` — failed try attempts
+first, because they happened first, which is the ordering the successful-catch
+return has always used. `runRegion`'s existing tagger supplies `regionKind:
+'try'` / `'catch'` and `parentNodeId` on its failure path as well as its
+success path, so the two halves stay distinguishable in the log.
+
+Additive to the RECORD only. This return already reported failure with the same
+error text, already produced a `NODE_FAILURE` step, already set `$error` and was
+already routable by a `fault` edge; none of that moves, and neither does the
+successful-catch path or the retry/throw semantics. No engine change was needed
+— the fold that reads these steps has been in place since #14184.

content/docs/permissions/system-context.mdx

@@ -97,7 +97,7 @@ that silently does not happen.
 | 8 | `explain()` may target a principal other than the caller | plugin-security | Get: no `manage_users` / delegated-admin check | `security-plugin.ts:3857` |
 | 9 | Anonymous-deny treats the caller as authenticated | core | Get: passes the 401 seam with no `userId` | `anonymous-deny.ts:154` |
 | 10 | Permission-set projection middleware skipped | plugin-security | Lose: projection of permission-set-derived columns | `permission-set-projection.ts:1015` |
-| 11 | Session-resolution middleware skipped | plugin-auth | Get: no session lookup attempted | `auth-plugin.ts:1353` |
+| 11 | Session-resolution middleware skipped | plugin-auth | Get: no session lookup attempted | `auth-plugin.ts:1380` |
 | 12 | Per-request performance timings disclosed | observability | Get: timing headers a normal caller cannot pull | `perf-timing.ts:474` |
 | 13 | Permission-set **overlay discard** skips the tenant-admin assertion | plugin-security | Get: an overlay can be discarded with no authenticated tenant administrator | `permission-set-overlay-discard.ts:142` |
 | 14 | MCP stdio bridge skips the object API-exposure gate | mcp | Get: the bridge reaches objects whose `apiEnabled` / `apiMethods` would refuse an external caller | `stdio-data-bridge.ts:246` |
@@ -198,7 +198,7 @@ assuming `isSystem` covers it is a documented source of bugs.
 | "It skips validation rules" | **No.** Field shape, `format`, `script` and the rest still run. The `readonly` strip runs *before* validation precisely so a discarded value is not judged | `objectql/src/engine.ts:10007`–`10024` |
 | "It preserves a supplied `updated_at` / `updated_by`" | **No.** That is `preserveAudit`, a separate opt-in — and an UPDATE-path exemption only | `field.zod.ts:1516` (#3493 / #6640) |
 | "It stamps `created_by`" | **No.** Audit stamping reads `userId` from the context. A user-less system write stamps nothing — that is today's behaviour, not an error | `runtime-identity.ts:280`–`281` |
-| "It bypasses every guard" | **No.** The last-admin guard applies to **every** context, `isSystem` included — the deprovision path that actually locks an org out is the system one | `last-admin-guard.ts:286` |
+| "It bypasses every guard" | **No.** The last-admin guard applies to **every** context, `isSystem` included — the deprovision path that actually locks an org out is the system one | `last-admin-guard.ts:299` |
 | "A client can request it" | **No.** Never settable from inbound HTTP or from an action body | `rest-server.ts:1522`, `:1551`; `domains/actions.ts:404` |
 
 ---

packages/plugins/plugin-auth/src/auth-manager.ts

@@ -5135,7 +5135,7 @@ export class AuthManager {
    * generated docs and the #13816 refusal all asserted the ban.
    *
    * This method restores declared = enforced by routing the state to the
-   * platform's OWN ban write (`admin-ban-endpoints.ts`):
+   * platform's OWN ban write (`user-ban-write.ts`):
    *
    *  - `active: false` on a row that is not banned ⇒ `applyUserBan` with
    *    `SCIM_DEACTIVATION_BAN_REASON` and no expiry. The vendor's
@@ -5164,8 +5164,14 @@ export class AuthManager {
    * A consequence worth stating: on 1.7.2 a SCIM `DELETE /Users/{id}` no
    * longer deletes the better-auth user (the vendor tombstones the source);
    * it leaves the user with no active source, so this callback disables the
-   * account. Re-provisioning through the tombstone re-links the same user,
-   * the state turns active, and the SCIM ban is lifted by the second bullet.
+   * account — by the SAME branch as `active: false`, including over an
+   * administrator's timed ban, whose `banExpires` a DELETE therefore clears
+   * too: a deprovision cannot be outlived by an expiry the administrator set.
+   * For the same reason a DELETE is judged by the `beforeUpdate` guard below
+   * and never by any `beforeDelete` — deleting the last administrator through
+   * SCIM is refused exactly as deactivating them is. Re-provisioning through
+   * the tombstone re-links the same user, the state turns active, and the
+   * SCIM ban is lifted by the second bullet.
    *
    * The break-glass last-administrator guard (ADR-0024 D5.2, #5892) is an
    * ENGINE `beforeUpdate` hook on `sys_user`, so it judges this write exactly