Merge remote-tracking branch 'origin/main' into claude/issue-4250-test-core-stall

# Conflicts:
#	package.json

Author: claude

.changeset/approvals-engineless-resume-gap.md

@@ -0,0 +1,48 @@
+---
+"@objectstack/plugin-approvals": patch
+---
+
+fix(approvals): an approval decision can no longer strand a flow run silently when no automation engine is attached (#4420)
+
+#4420's fix closed every path by which a decision could be recorded while its
+flow stayed parked — except one, and it is the one where none of the new guards
+could run. Every guard it added (`assertRunResumable`'s pre-flight, the
+`RESUME_TARGET_LOST` refusal, the `RESUME_FAILED` throw) hangs off the
+automation engine. In a process where **no engine is attached**, all of them
+were skipped by the same `typeof this.automation?.resume === 'function'`
+condition that wrapped the resume itself — so the decision was written, the
+mirrored status field advanced, and the call answered HTTP 200 with
+`resumed: false` and **nothing logged at all**. That is #4420's reported
+symptom exactly, reproduced in the one composition its fix could not see.
+
+The composition is reachable the same way the original bug was: a flow parks at
+an `approval` node in a process that has the automation service, and the
+decision arrives in one that does not (the plugin failed to init, or the host
+was recomposed between releases). The request row still carries a
+`flow_run_id` — which is the row's own declaration that a run is parked on this
+decision.
+
+**What changes.** The decision still stands. Rolling it back is not on the
+table (a human really decided, and the row is durable by then), and refusing
+every such call would break the standalone approvals compositions the
+pre-flight deliberately protects — so `finalized` and `resumed` are unchanged
+for every existing caller. What changes is that the gap is no longer silent:
+
+- it is logged at **`error`**, per the durability rule in `AGENTS.md` —
+  persisted state and runtime state disagree while nothing looks broken from
+  the outside, which is the class that rule exists for;
+- the response carries **`resumeError`**, so `resumed: false` arrives with its
+  reason and the stranded run's id instead of leaving the caller to guess
+  whether a resume was even attempted.
+
+It reuses the already-registered `RESUME_FAILED` code and the existing resume
+message shape rather than introducing a new vocabulary — the fact being
+reported (an outcome recorded whose run did not advance) is the same one.
+
+Applied at all five sites that resume a recorded outcome: `decide`, the
+revision-limit auto-rejection, `sendBack`, `resubmit`, and both branches of
+`recall` (whose revise-window path needs `cancelRun` rather than `resume`).
+
+A request that names **no** run is unaffected and stays quiet — there is
+nothing parked on it, and reporting one there would be the mirror-image
+failure that trains operators to skim `error`.

.changeset/auth-admin-audit-hook-bypass-claim-corrected.md

@@ -0,0 +1,12 @@
+---
+---
+
+docs(plugin-auth): the two admin-identity audit comments no longer claim better-auth's writes bypass the ObjectQL lifecycle hooks plugin-audit subscribes to (#4940). `writeAdminAudit` in `admin-user-endpoints.ts` and the run-level insert in `admin-import-users.ts` both justified their explicit `sys_audit_log` row with the same stale mechanism claim #4802 refuted one layer up: *better-auth writes bypass the ObjectQL hooks that plugin-audit subscribes to, so admin identity operations would otherwise leave no compliance trail*.
+
+Re-verified, then **measured** rather than reasoned about: the adapter writes with a plain `dataEngine.insert(...)`, `ObjectQL.insert()` fires `triggerHooks('afterInsert')` inside `executeWithMiddleware()`'s executor, and plugin-audit registers `writeAudit` as a bare `engine.registerHook('afterInsert', …)` with no object filter. Driving the real routes against the showcase stack with `AuditPlugin` installed: `POST /admin/create-user` leaves **two** `action: 'create'` rows on the new `sys_user` (the explicit one and plugin-audit's row snapshot) plus an `update` row for the must-change-password stamp; each imported user likewise gets plugin-audit's own per-row `create` row.
+
+The explicit rows are **kept** — the discipline was right, only the reason was wrong — and the reasons are now the ones that hold. plugin-audit is an **optional** plugin, so without it there is no `sys_audit_log` table at all. `sys_account` **is** in plugin-audit's `SKIP_OBJECTS`, so the credential write behind `/admin/set-user-password` produces **zero** generic rows: that explicit row is the only trail an administrative password reset leaves, and deleting it on the strength of "the hook covers it" would silently destroy it. And the import's run-level row (`action: 'import'`, `record_id: null`) is a shape plugin-audit's `actionFor` cannot emit, answering what no per-row ledger can — who ran which import, and what it did overall.
+
+The stale sentences are **refuted in place rather than deleted**, matching #4802's handling: the claim was copied into cloud's agent-facing docs (cloud#1022), and a reader arriving from a copy needs to see it named and corrected instead of finding silence.
+
+Every measured fact is pinned by a new gate — `packages/qa/dogfood/test/admin-identity-audit-trail.dogfood.test.ts` — so the corrected comment is an assertion the suite enforces rather than a fresh unverified claim. Comments and tests only; no runtime behaviour changes, nothing released.

.changeset/auth-database-hooks-middleware-claim-corrected.md

@@ -0,0 +1,12 @@
+---
+---
+
+docs(plugin-auth): the `databaseHooks` doc comment no longer claims better-auth's adapter bypasses the ObjectQL middleware chain (#4802). The option's JSDoc in `auth-manager.ts` (and its two sibling copies — the wiring comment beside `composeDatabaseHooks`, and `AuthPluginOptions.databaseHooks` in `auth-plugin.ts`) justified "use `databaseHooks`, not an ObjectQL middleware" with a mechanism claim that no longer holds: *better-auth's adapter goes through `dataEngine` directly, bypassing the `ql.registerMiddleware` chain*.
+
+Re-verified hop by hop against `main`: `ObjectQLPlugin` registers **one** engine instance under both service names (`registerService('objectql', this.ql)` and `registerService('data', this.ql)`, and nothing else in the repo registers `data`); `AuthPlugin` passes exactly that instance to `createObjectQLAdapterFactory`; the adapter writes with a plain `dataEngine.insert(objectName, …)` — there is no bypass or skip-middleware option to pass; and `ObjectQL.insert()` wraps its body in `executeWithMiddleware()`, whose only filter is the object name. So `ql.registerMiddleware(fn, { object: 'sys_user' })` **does** fire for better-auth's writes, and so do the engine's `beforeInsert`/`afterInsert` hooks — the SCIM identity-source stamp in `auth-plugin.ts` is built on precisely that.
+
+The **rule is unchanged** — user-lifecycle invariants still belong in `user.create.after`, not in a `sys_user` middleware — but the reason is now the one that is actually true: **ADR-0093 D2**, one owner for the invariant on the one seam every creation path already flows through (self-signup, admin create-user, import, SSO JIT). The narrower fact that survives is written down instead of the false one: adapter writes carry `context.isSystem: true` (`withSystemContext`, pinned by `objectql-adapter.test.ts`), so every *authorization* middleware — security, sharing, the ADR-0092 identity write guard — early-returns by design; a middleware that gates on `isSystem` sees nothing, one that does not, runs.
+
+The stale sentence is **refuted in place rather than deleted**, because it had been copied into cloud's agent-facing docs and had already killed the middleware option in two rounds of design work there (cloud#1012, handed over as cloud#1022). A reader arriving from one of those copies needs to see the claim named and corrected; a silent deletion would leave them assuming the framework comment is the stale one.
+
+Comments only — no runtime behaviour changes, nothing released.

.changeset/brace-expansion-advisory-5-0-9.md

@@ -0,0 +1,26 @@
+---
+---
+
+ci(deps): lift the `brace-expansion` pin to 5.0.9 so `Validate Package Dependencies` stops failing on every PR (#4945)
+
+`GHSA-rgw5-rvv9-x895` (7.5 high) affects `brace-expansion` 5.0.8 — which is
+exactly the version the previous pin (`brace-expansion@>=5.0.0 <5.0.8: ^5.0.8`,
+added for `GHSA-mh99-v99m-4gvg`) had settled on. The OSV-Scanner step in
+`.github/workflows/validate-deps.yml` reads `pnpm-lock.yaml` directly and exits
+non-zero on any match, so the job was red on `main` itself and attached that red
+to every PR that touched a manifest or the lockfile, whatever the PR contained
+(observed on #4944, which never touched `pnpm-lock.yaml`).
+
+The `pnpm-workspace.yaml` override bound moves to `<5.0.9` / `^5.0.9`. It stays a
+transitive-only pin — nothing declares `brace-expansion` directly; it arrives via
+`minimatch` (ts-morph, eslint, `@typescript-eslint`, glob, `@vscode/vsce`,
+archiver), so no published manifest changes and `check-override-consistency`
+still has nothing to reconcile. 5.0.8 disappears from the lockfile entirely; the
+three `minimatch` snapshots that referenced it now resolve 5.0.9.
+
+The reason to fix this on its own rather than let it ride along with the next
+dependency PR is the one the issue names: a permanently red required check
+trains everyone to scroll past it, and the next real advisory will look exactly
+like this one in the PR list.
+
+Lockfile and override metadata only; releases nothing.

.changeset/bulk-action-option-passthrough.md

@@ -0,0 +1,33 @@
+---
+"@objectstack/spec": minor
+---
+
+fix(spec): stop silently stripping widget config off a bulk-action param option (#4001)
+
+`BulkActionParamSchema`'s `options[]` entry is now `.passthrough()`, matching its
+parent. **Behaviour change, loosening only**: keys other than `label` / `value` on
+an option used to be *removed at parse* and are now preserved. Nothing that parsed
+before stops parsing, and no key changes meaning — an authored option simply keeps
+what it was written with.
+
+Concretely, this used to happen without a warning:
+
+```ts
+// authored
+options: [{ label: 'In Review', value: 'in_review', color: '#8B5CF6', icon: 'eye' }]
+// parsed, BEFORE
+options: [{ label: 'In Review', value: 'in_review' }]
+```
+
+`color` and `icon` are not decoration the renderer ignores. objectui's
+`bulkParamToField` spreads every option entry into the field metadata
+(`packages/plugin-grid/src/components/bulkParamToField.ts:131`), where the widget
+vocabulary is `SelectOptionMetadata` (`packages/types/src/field-types.ts:288`) —
+`color`, `icon`, `disabled` and `visibleWhen` beyond the declared pair, and read
+(`option?.color`, `packages/fields/src/index.tsx:1089`). So the strip deleted
+config that would otherwise have rendered, on the authoring side, invisibly.
+
+Nothing to migrate. If you dropped option colors/icons because "the spec ate them",
+they work now. The strictness ledger's prose already described this level as
+deliberately open while only the parent schema said so in code; the code now says
+it too, which is the part a machine can check.

.changeset/cli-banner-tenancy-posture.md

@@ -0,0 +1,53 @@
+---
+"@objectstack/cli": patch
+---
+
+fix(cli): the boot banner's `Tenancy:` row now reports the resolved posture, not the superseded boolean (#4801)
+
+`printServerReady` printed `Tenancy: multi-tenant | single-tenant` from a boolean
+`multiTenant` that `serve` filled with `resolveMultiOrgEnabled()` — i.e. from
+`OS_MULTI_ORG_ENABLED`. [ADR-0105 D1] replaced that knob with
+`OS_TENANCY_POSTURE`, keeping the boolean only as the fallback
+`resolveTenancyPosture()` consults when the posture is unset, and **the runtime
+wiring in `serve` already keys off the posture**. So the banner and the server it
+describes read two different sources for one fact, and they drifted exactly where
+it hurts: booting with `OS_TENANCY_POSTURE=isolated` and `OS_MULTI_ORG_ENABLED`
+unset printed
+
+```
+  Tenancy: single-tenant
+  Plugins: 40 loaded
+           …, Organizations, …
+```
+
+— the banner claiming single-org one line above the plugin table that proves the
+organization wall is up (observed on a real boot in cloud#1020, where the lie was
+only caught by hand-comparing the plugin list).
+
+This is not cosmetic. It is the "declared ≠ enforced" class (ADR-0049) landing on
+the **diagnostic** surface, which is the worst place for it: a banner that can be
+wrong costs every later investigation an extra lap proving whether it is.
+
+**What changes for users.** The row now prints the posture verbatim — `Tenancy:
+single`, `Tenancy: group`, `Tenancy: isolated` — sourced from the same
+`resolveTenancyPosture()` call the runtime wiring uses. The old `multi-tenant` /
+`single-tenant` vocabulary is gone. That vocabulary was itself part of the defect:
+tenancy has been a three-valued spectrum since ADR-0105, and a boolean has no
+spelling for `group` at all, so a `group` deployment could only ever be
+misreported.
+
+**The internal `multiTenant` option is removed, not deprecated.** With the posture
+authoritative, a retained boolean could only ever be a field the printer ignores —
+and a field that exists but cannot be believed is precisely how this bug was
+authored in the first place. `ServerReadyOptions.tenancyPosture` is typed as
+`TenancyPosture`, so re-wiring the banner to the legacy boolean now fails to
+compile (`resolveMultiOrgEnabled()` returns `boolean`) instead of producing a
+plausible-looking wrong line. The interface is package-internal — `format.ts` is
+not re-exported from `@objectstack/cli`'s entry point — so no consumer code needs
+a change.
+
+Regression-pinned in `packages/cli/src/utils/format.tenancy.test.ts`, which asserts
+the printed token **is** `resolveTenancyPosture()`'s answer across the cases that
+made the old code wrong: posture set with the boolean unset, posture unset with the
+boolean true, both set and contradicting (either direction), the legacy `multi`
+spelling, and `group`.

.changeset/connector-rate-limit-config-removed.md

@@ -0,0 +1,64 @@
+---
+"@objectstack/spec": major
+---
+
+refactor(spec)!: remove `connector.rateLimitConfig` and the whole outbound rate-limit shape — the engine never existed (#4911, ADR-0049)
+
+`ConnectorSchema.rateLimitConfig` let an author declare an outbound throttle for
+their connector — `strategy`, `maxRequests`, `windowSeconds`, `burstCapacity`,
+`respectUpstreamLimits`, `rateLimitHeaders` — and nothing anywhere applied it.
+This is not the ordinary declared-but-unread case; it is a step worse:
+**there is no outbound rate-limiting engine to wire it to.** The only token
+bucket the platform owns is `packages/runtime/src/security/rate-limit.ts`, and it
+is INBOUND — the dispatcher calls `consume(key)` on a request fingerprint and
+answers 429. No connector provider (`connector-rest`, `connector-openapi`,
+`connector-mcp`, `connector-slack`) reads the key, and no seam exists that could.
+
+So a well-formed, schema-validated block told the author they had capped their
+call rate against a third party's quota, and capped nothing — the false-compliance
+class ADR-0049 exists for. With no implementation and no committed roadmap,
+`experimental` would be a promise nobody made; **absent** is the honest
+disposition. The vocabulary comes back *with* the engine, in one change
+(implementation-first — the #4834 / PR #4878 ruling for the plugin-runtime family).
+
+FROM → TO:
+
+| Removed | Replacement |
+| :--- | :--- |
+| `connector.rateLimitConfig` (key) | **none** — delete it; throttle at the connector provider or upstream gateway |
+| `ConnectorRateLimitConfigSchema` / `ConnectorRateLimitConfig` | **none** — importing either is TS2305 in v17 |
+| `RateLimitStrategySchema` / `RateLimitStrategy` | **none** — the enum had no other consumer |
+
+**Do NOT substitute `shared`'s `RateLimitConfig`.** That is the INBOUND limiter
+(`enabled` / `windowMs` / `maxRequests`) and caps the calls others make to *us* —
+the opposite direction. #4684 split the two names for exactly this confusion; the
+conversion deliberately does not rewrite one into the other, because that would
+silently change behaviour rather than losing a no-op.
+
+The retirement kit:
+
+- **Tombstone.** `ConnectorSchema` is not `.strict()`, so a plain delete would be
+  a silent strip (ADR-0104). `retiredKey()` makes the removal audible in the two
+  channels an upgrading author hits — `tsc` (the key types `never`) and the parse
+  (the prescription itself). It reaches `stack.connectors[]` and
+  `DeclarativeConnectorEntry`, which is `ConnectorSchema.superRefine(…)`.
+- **ADR-0087 D2 conversion + D3 chain step** (`connector-rate-limit-config-removed`,
+  `retiredFromLoadPath`): `os migrate meta --from 16` deletes the key from author
+  sources and stored rows replay clean. A lossless delete — the block never had an
+  effect to lose.
+- **The shape goes with the key.** `ConnectorRateLimitConfigSchema` and the
+  `RateLimitStrategySchema` enum it embedded had no other consumer, and an
+  exported schema with no consumer reads as a capability to whoever finds it
+  (#3950).
+- **#4684's rename is absorbed.** `integration/RateLimitConfig` →
+  `integration/ConnectorRateLimitConfig` and this retirement landed in the same
+  unreleased major; composed they are a plain delete, so the `RENAMED_DEFS` entry
+  is removed rather than pointing at a def this build no longer emits.
+- Baselines updated deliberately: `json-schema.manifest.json` (−2 defs),
+  `authorable-surface.json` (−6 def lines; `Connector` /
+  `DeclarativeConnectorEntry` gain `… [RETIRED]`), `api-surface.json` (−4
+  exports). `api-surface-signatures.json` is unchanged by construction — it hashes
+  each `defineX` parameter as TypeScript *prints* it, a reference
+  (`z.input<typeof ConnectorSchema >`), so key-level narrowing never reaches it.
+
+No runtime behaviour changes — that impossibility is the reason for the removal.