Merge branch 'main' into claude/issue-7309-confirmtext-params

Author: os-zhuang

.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.

.changeset/normalized-filter-member-union-strict.md

@@ -0,0 +1,53 @@
+---
+"@objectstack/spec": minor
+---
+
+fix(spec): `NormalizedFilterSchema` judges its members instead of catching them all (#7711)
+
+Each `$and` / `$or` member and the `$not` operand was
+`z.union([z.record(z.string(), FieldOperatorsSchema), NormalizedFilterSchema])`,
+and the second branch was a NON-strict `z.object({ $and, $or, $not })` with every
+key optional. "All three of my optional keys are absent" is true of any object
+whatsoever, so that branch was a catch-all: whenever the record branch **rejected**
+a field condition, the group branch accepted the very same value. The whole-filter
+face validated the logical skeleton and nothing else — no comparand shape it
+declared could ever make it fail.
+
+Measured before the change, every one of these parsed green while
+`FieldOperatorsSchema` — the copy this schema is documented as validating
+against — refused the identical operator map:
+
+```
+{ $and: [{ c: { $null: 'not-a-boolean' } }] }
+{ $and: [{ c: { $between: [1, 2, 3] } }] }
+{ $and: [{ hello: 'world' }] }
+```
+
+The green was also lossy: an admitted member came back parsed to `{}`, so the
+accepted output no longer carried the condition it was asked about — a whole
+`{ $not: … }` subtree parsed as a field named `$not` and returned empty.
+
+Now the group branch is `.strict()` and the field-condition branch rules out
+`$`-prefixed keys, so a member the operator map refuses has nowhere to land. The
+refusal names the offending keys and both valid member shapes:
+
+```
+Not a valid $and member — got an object with key(s) "c". A $and member is either
+a FIELD CONDITION ({ "field": { "$op": value } }, whose keys are field names and
+whose operator map must satisfy FieldOperatorsSchema — comparand shapes
+included), or a nested LOGICAL GROUP carrying only $and / $or / $not and nothing
+else. Ruled on #7711: declared = enforced (ADR-0049).
+```
+
+Graded a narrowing of the accepted surface, so `minor` rather than `patch` — but
+the blast radius is measured at zero: nothing in the repo called `.parse` /
+`.safeParse` on `NormalizedFilterSchema` outside this package's own tests
+(swept with `FilterConditionSchema`'s 20-plus call sites as the positive
+control), no driver or evaluator references the normalized AST at all, and the
+exported `NormalizedFilter` TYPE is unchanged — every shape that stops parsing
+was already outside it. Nothing is removed from the declared surface, which is
+what separates this from the ADR-0087 removal grade.
+
+`FilterConditionSchema`, the AUTHORING face every driver, `read-scope-sql` and
+`cel-to-filter` actually consume, is untouched and still admits sugar by design,
+so no request path's row set can move with this.

.changeset/pageheader-title-optional.md

@@ -0,0 +1,31 @@
+---
+"@objectstack/spec": minor
+---
+
+fix(spec): `PageHeaderProps.title` is optional — matches the platform's own synthesized header (#7702)
+
+`PageHeaderProps.title` was declared **required**, but the platform's own
+synthesizer (objectui `buildDefaultHeader`) emits every seeded `page:header`
+with **no `title` at all** — `{ type: 'page:header', recordChrome, …actions }`.
+`PageHeaderRenderer` (`containers.tsx`) reads
+`schema?.title ?? schema?.properties?.title` and, finding neither, falls
+through to the record chip's own record-derived heading: a static authored
+title would be wrong on every record but one. `PageHeaderProps.safeParse`
+therefore rejected the platform's own canonical output with `title: Invalid
+input` — invisible on the write path today (`PageComponent.properties` is an
+opaque `z.record`), but a standing contradiction that surfaces the moment any
+props-level validation runs against a header node (`validateComponentProps`,
+#5068, is exactly that consumer).
+
+Maintainer ruling 2026-08-11 (accepting the spec lane's A/B recommendation,
+rejecting a sentinel-value option C): `title` becomes optional, and its
+describe states the sanctioned spelling — **title omitted ⇒ the renderer
+derives the heading from the record**. Authors still set it explicitly on
+non-record pages (dashboards, landing pages) where there is no record to
+derive a heading from.
+
+This is a widening change: every payload that validated before (with `title`)
+still validates identically, and `title`, when present, still parses as
+`I18nLabelSchema` exactly as before. The only newly-accepted shape is a
+`page:header` with `title` omitted — the platform's own default. Minor, not
+patch, because the accepted-input surface grows.

.changeset/sys-api-key-no-batch-route.md

@@ -0,0 +1,34 @@
+---
+"@objectstack/spec": patch
+"@objectstack/platform-objects": patch
+---
+
+fix(spec,platform-objects): put `sys_api_key`'s missing batch route on the record (#7802)
+
+`@objectstack/spec`'s `apiMethods` conformance scan was failing on `main` — and,
+because the scan lives in `spec` while the object it judges lives in
+`platform-objects`, failing for every PR that touched `spec` and no others.
+#7769 had added `update` to `sys_api_key`'s `enable.apiMethods` so the Setup
+UI's Revoke button had a working route, which tripped the rule "a whitelist that
+grants single-record writes must also grant `bulk`".
+
+Resolved as the rule's second documented outcome — a registered exemption, not a
+widened object. `sys_api_key` now carries the monorepo's only
+`SINGLE_RECORD_WRITE_ONLY` entry, with the evidence behind it:
+
+- **No batch surface exists to deny.** The console renders no checkbox column on
+  any of the object's list views: multi-select is auto-enabled only when a bulk
+  action exists, the sole implicit one is bulk-delete, and this object grants no
+  delete affordance (`managedBy: 'better-auth'` denies by default, `userActions`
+  opens `edit` alone, `delete` is not in `apiMethods`).
+- **A future multi-select revoke would not need `bulk` either.** `revoke_api_key`
+  / `restore_api_key` are `list_item` actions; promoting one into a view's
+  `bulkActions` resolves it to a `custom` def that the grid executor fans out
+  through the action runner as N single-record PATCHes — never `/batch`.
+
+So `POST /api/v1/data/sys_api_key/batch` and the `*Many` routes keep answering
+405 for API keys, deliberately: the object's authorable surface is the single
+`revoked` boolean that ADR-0092 D2's identity write guard admits, and nothing
+asks to write it in bulk. #7769's `update` grant is untouched — the Revoke
+button keeps working. Adding `bulk` later requires retiring the exemption in the
+same commit; the conformance suite's stale-entry check refuses to let both stand.

content/docs/references/ui/component.mdx

@@ -241,7 +241,7 @@ const result = AIChatWindowProps.parse(data);
 
 | Property | Type | Required | Description |
 | :--- | :--- | :--- | :--- |
-| **title** | `string \| Record<string, string>` | ✅ | Page title |
+| **title** | `string \| Record<string, string>` | optional | Page title. Omit to let the renderer derive the heading from the record (the default for record pages) — set explicitly on non-record pages (dashboard, landing) with no record to derive from. |
 | **subtitle** | `string \| Record<string, string>` | optional | Page subtitle |
 | **icon** | `never` | optional | [REMOVED] `page:header` property `icon` was removed in @objectstack/spec 17.0.0 (#6946, ADR-0087 D2) — no renderer ever read it: objectui resolves `icon` only per header action (`action.icon`), never off the header's own props bag, and the component registry never published it as an input, so an authored value was accepted and dropped. Delete the key. The header's own identity is drawn by the record chrome (`recordChrome`, on by default) and each action carries its own `icon`. Run `os migrate meta --from 16` to rewrite existing sources automatically. |
 | **breadcrumb** | `boolean` | ✅ | Show breadcrumb |

docs/audits/2026-07-unknown-key-strictness-ledger.counts.md

@@ -22,7 +22,7 @@ regenerate.
 |---|---|
 | Triaged directories | 5 |
 | Object sites in them | 438 |
-| Still-open (strip) sites | 181 |
+| Still-open (strip) sites | 180 |
 | Files carrying at least one | 27 |
 
 Remaining strip sites by class:
@@ -31,7 +31,7 @@ Remaining strip sites by class:
 |---|---|
 | authorable — the ruling's forced scope | 40 |
 | unresolved — needs a per-schema verdict | 34 |
-| wire / open — out of forced scope | 105 |
+| wire / open — out of forced scope | 104 |
 | no door — no carrier, ADR-0049 territory | 1 |
 | no gate — carrier live, no parse | 0 |
 | covered — no carrier, no parse, guarded at every consumer | 1 |
@@ -45,11 +45,11 @@ The `strict` column is the one the campaign schedules against; it counts both th
 | Dir | Sites | strict | passthrough | catchall | strip |
 |---|---|---|---|---|---|
 | `ui/` | 161 | 119 | 5 | 0 | 37 |
-| `data/` | 165 | 56 | 1 | 0 | 108 |
+| `data/` | 165 | 57 | 1 | 0 | 107 |
 | `automation/` | 65 | 42 | 0 | 0 | 23 |
 | `security/` | 20 | 7 | 0 | 0 | 13 |
 | `studio/` | 27 | 27 | 0 | 0 | 0 |
-| **total** | **438** | **251** | **6** | **0** | **181** |
+| **total** | **438** | **252** | **6** | **0** | **180** |
 
 ## File-level triage — site counts
 
@@ -179,7 +179,7 @@ over it is here.
 
 ### `data/` — open
 
-**108 strip of 165**, in 16 file(s).
+**107 strip of 165**, in 16 file(s).
 
 | File | Strip | Sites |
 |---|---|---|
@@ -194,18 +194,18 @@ over it is here.
 | `external-lookup.zod.ts` | 12 | 12 |
 | `field-value.zod.ts` | 2 | 3 |
 | `field.zod.ts` | 2 | 10 |
-| `filter.zod.ts` | 11 | 11 |
+| `filter.zod.ts` | 10 | 11 |
 | `hook.zod.ts` | 5 | 7 |
 | `object.zod.ts` | 1 | 20 |
 | `query.zod.ts` | 4 | 5 |
 | `seed-loader.zod.ts` | 12 | 12 |
-| **total** | **108** | **165** |
+| **total** | **107** | **165** |
 
 | Bucket | Sites |
 |---|---|
 | authorable — the ruling's forced scope | 8 |
 | unresolved — needs a per-schema verdict | 34 |
-| wire / open — out of forced scope | 66 |
+| wire / open — out of forced scope | 65 |
 | no door — no carrier, ADR-0049 territory | 0 |
 | no gate — carrier live, no parse | 0 |
 | covered — no carrier, no parse, guarded at every consumer | 0 |