Merge commit '00ff228fe' into claude/issue-14348-promote-authenticable-first-user

Author: claude

.changeset/action-governance-registry-rung.md

@@ -0,0 +1,24 @@
+---
+'@objectstack/objectql': patch
+---
+
+Startup `[action-governance]` resolves declarations through the same rungs the router does
+
+The boot inventory built its declaration set from object-embedded `actions[]` plus the
+metadata service's `action` rows. `resolveRouteActionDeclaration` resolves through a third
+source between those two — the engine registry's standalone `action` items,
+`registry.getItem('action', name)`, accepted when the item owns the route. On the in-process
+boot (`new AppPlugin(...)` then `kernel.bootstrap()`), where the metadata plane holds no
+`action` rows at all, every object-less `defineAction` was therefore reported as a
+"registered handler with NO declaration — REFUSED at dispatch (ADR-0110 D3) and there is no
+opt-out" in the same boot in which the router resolved it at that rung and dispatched it.
+Both remedies the message offered were wrong for that shape: the action was already declared
+with `defineAction`, and dropping the registration would have broken a working endpoint under
+a green `pnpm validate`.
+
+The registry rung is now injected into the audit by `ObjectQLPlugin` — the one caller holding
+the engine, because objectql cannot import the router — and judged by the same ownership test
+the router applies. The warning also stops asserting a dispatch outcome it never checked: it
+names the three sources it read, says it did not dispatch, and points an author whose action
+IS declared at the real bug instead of at deleting the registration. The other finding in the
+block, `declared script actions with NO handler`, is unchanged in wording and in population.

.changeset/dashboard-filter-dotted-seam.md

@@ -0,0 +1,41 @@
+---
+'@objectstack/lint': patch
+---
+
+lint: `dashboard-filter-field-unknown` resolves dotted dashboard-filter fields on the object graph, and answers system columns per object
+
+A dashboard-level filter (`dateRange`, or a `globalFilters[]` entry) is ANDed into
+**every** widget's analytics query, so its effective field — after any
+`filterBindings` re-target — has to resolve on each bound widget's dataset object.
+The rule that enforces that shipped with two holes, and this closes both by
+migrating the check onto the shared `resolveFieldPath` / `joinablePrefixes` seam
+the widget's own `filter` keys already use one position over.
+
+- **Dotted paths are no longer skipped.** The branch carried
+  `if (field.includes('.')) continue;`, accurate when nothing in the package could
+  walk relationship hops and false since the object-graph seam landed. A filter
+  re-targeted to `account.signed_at` was unjudged whether or not `account` existed,
+  whether or not `signed_at` existed on it, and whether or not `account` was
+  declared in the dataset's `include`. It is now walked hop by hop, and a miss
+  names **which** hop failed.
+- **System columns are resolved per object, not through the flat union.** The old
+  test was `objectFields.has(field) || SYSTEM_FIELDS.has(field)`, which answers
+  "could this be a system column *anywhere*". On an `ownership: 'none'` object the
+  platform injects no `owner_id`, and on `systemFields: { audit: false }` no
+  `created_at` — both were answered as resolvable and are now reported.
+
+New error id **`dashboard-filter-field-not-included`**: the effective field
+resolves, but its relationship prefix is not declared in the bound dataset's
+`include`, so ADR-0021 compiles no join and the column is out of the broadcast
+query's reach. It mirrors `widget-filter-field-not-included` one level down, and is
+its own id because the fix is a different edit (declare the join, versus point the
+filter at something real).
+
+This **narrows the accept set of a shipped gating rule**. Both new answers are
+error-tier, so like the rule's other errors they fail `os validate` / `os build`
+and the runtime publish gate for `dashboard` writes. Measured over the shipped
+dashboard corpus — the three example apps plus the platform's own
+`system_overview` — the change is 0 findings before and 0 after; the
+`dashboard-filter-field-unprovisioned` warning is unchanged and now travels with
+the verdict, so it answers a dotted path landing on an ADR-0015 `external` object
+too.

.changeset/dev-admin-seed-credential-gate.md

@@ -0,0 +1,36 @@
+---
+'@objectstack/plugin-auth': minor
+'@objectstack/cli': patch
+---
+
+Fix: `objectstack dev` now seeds its dev admin on a database that has PEOPLE but no LOGIN
+
+An app that declares `sys_user` rows in `defineStack({ data })` used to lose the
+`objectstack dev` login permanently. The declarative seed is awaited inside
+`AppPlugin.start()`, so it always landed before the dev-admin seed's own
+`kernel:ready` hook; the seed's gate asked "does any human `sys_user` row
+exist?" and skipped — on that boot and on every later one, because the rows
+survive. The deployment ended up with no loginable account at all: people rows
+present, `sys_account` empty, `POST /auth/sign-in/email` returning 401.
+
+A seeded person is a directory row with no credential. It is not a login, and
+the gate now says so: the seed acts while no account holds the configured seed
+address and no local password login (`sys_account.provider_id = 'credential'`)
+exists anywhere. "Never overwrites an existing account" is unchanged and now
+covers federated accounts on that address too. A credential store that cannot be
+read is its own verdict — the seed declines and says so, rather than minting a
+known-credential admin into an environment it could not see.
+
+The seed's own provisioning call is now admitted as what it is — the
+deployment's own boot command provisioning its admin — instead of riding on the
+audience gate's zero-human bootstrap bypass, which the app's people seed also
+answers "populated". The public self-registration door is unchanged: nothing
+outside the process can stage that declaration, it names one address, and it is
+cleared as soon as the call returns.
+
+`GET /api/v1/auth/bootstrap-status` now answers with the same bootstrap-window
+question the admission gate asks, instead of counting `sys_user` rows with no
+filter. On a database still carrying the legacy `usr_system` service row it used
+to report `hasOwner: true` while the admission gate and plugin-security's
+first-user detection both stood ready to admit and promote the first human — so
+the console withheld a first-run setup flow the platform would have accepted.

.changeset/driver-memory-update-upsert-honest-types.md

@@ -0,0 +1,11 @@
+---
+'@objectstack/driver-memory': minor
+---
+
+feat(driver-memory): `update()` and `upsert()` publish their honest types (#13878)
+
+**BREAKING** for TypeScript consumers — a published TYPE-surface narrowing, the shape ADR-0087's 2026-08-30 addendum names (a published SDK method whose declared return moves off `any` onto the contract it always answered) — shipped as `minor` under the launch-window convention. The emitted `.d.ts` read `Promise<any>` for both doors: the return types were inferred through the backing store's `any[]` rows, so the union collapsed and no caller was asked to narrow. They are now declared as the contract declares them — `update()` returns `Promise<Record<string, unknown> | null>` (the `null` arm is the non-`strictMode` miss the driver has always answered with), `upsert()` returns `Promise<Record<string, unknown>>`. A caller that read fields off `update()`'s result through the `any` now narrows the `null` arm first; a caller that leaned on `any` to read undeclared members of either result now types them.
+
+`upsert()` now asserts — throws on — the `null` arm of `update()` on a path it cannot reach (the row it updates was found in the same table a moment earlier, with nothing yielding in between), instead of widening its own declared return to carry an arm it can never produce. No reachable runtime behaviour changes.
+
+<!-- adr-0087: not-required (no-migration-prescription) A published return type moves off `any` onto the contract's own shape: no metadata key is removed, renamed or re-shaped and nothing exists for `objectstack migrate meta` to rewrite; the obligation is a TypeScript narrowing at the consumer's call site, delivered by the compiler. `type-surface-only` is not claimable here because the same diff touches `packages/spec/**` (the contract declaration itself). -->

.changeset/eighty-pumas-shave.md

@@ -0,0 +1,20 @@
+---
+'@objectstack/lint': patch
+---
+
+Walk object-nested `list` / `listViews.*` through the view completeness rules.
+
+`validateFunctionalCompleteness` walked only the top-level `views[]` containers, so
+a `timeline` / `gantt` / `map` / `tree` view authored on the object itself — the
+ADR-0017 "Object has-many View" spelling that `objects[].list` and
+`objects[].listViews.*` carry — never reached `checkViewCompleteness`. Both doors
+register the same expanded view items and reach the same renderer, so `os validate`
+and `os build` were silent on exactly the half of the stack the sibling rules
+(`lint-view-refs`, `validate-list-view-field-refs`) already walk.
+
+Both authorable object spellings (array-form and name-keyed map) are covered, and a
+list view's own `data.object` retarget (ADR-0047) resolves the bound object the same
+way it does on the top-level door — so `view/layout-without-binding` and
+`view/tree-without-parent-field` now reach the nested door by construction rather
+than by a second wiring step. Findings report as
+`object "<name>" › listViews.<key>` / `objects[<i>].listViews.<key>.<block>`.

.changeset/element-number-filter-rule-array.md

@@ -0,0 +1,46 @@
+---
+"@objectstack/spec": minor
+---
+
+feat(spec): `ComponentPropsMap['element:number'].filter` converges onto the `ViewFilterRule` array form (#12039, objectui#6206 Option B)
+
+<!-- adr-0087: registered element-number-filter-rule-array -->
+
+**BREAKING** accept-set change on one props-map entry, shipped as `minor` under
+the repo's launch-window convention for breaking changes; the migration
+prescription is registered under protocol major 18.
+
+One filter orthography platform-wide (maintainer batch adjudication
+2026-08-25, verbatim 「同意」, Option B): `element:number`'s `filter` was the
+one `filter` input in `ComponentPropsMap` declared as the MongoDB-style record
+(`FilterConditionSchema`) while every sibling (`record:related_list` and its
+Add-affordance picker) declared `z.array(ViewFilterRuleSchema)` — so the
+filter a list view stores and renders was refused by the KPI element beside
+it. The entry now declares the same array form its siblings do.
+
+Sequenced consumer-first (the 2026-08-25 Option-A ordering ruling):
+objectui#6828 made `ObjectStackAdapter.aggregate()` lower a rule array through
+the same `translateFilterArray` its `find()` path runs before the analytics
+wire; the objectui pin carrying it (`d8ec8d6d`) was re-measured before this
+declaration moved, and the end-to-end chain is authored array → adapter
+lowering → filter AST → accepted by `lowerAnalyticsWhere` (which still refuses
+a RAW rule-object array — by design, and unchanged here).
+
+Migration — FROM → TO, one rule per key (several keys AND):
+
+```ts
+// before (refused now — `invalid_type` at `filter`, expected array)
+filter: { status: 'won' }
+filter: { amount: { $gt: 100 } }
+// after
+filter: [{ field: 'status', operator: 'equals', value: 'won' }]
+filter: [{ field: 'amount', operator: 'greater_than', value: 100 }]
+```
+
+The ruled migration check ran with the change: the sweep of first-party
+corpora (examples/, skills/, create-objectstack, content/docs/, packages/apps/,
+spec fixtures) found one `element:number` author writing a record-form
+`filter` — a spec test fixture, rewritten to the array form here — and zero
+outside the spec package. `ElementNumberPropsParsed` is declared
+(ADR-0122: the parsed state now differs on `filter`, whose `operator` is
+normalized on parse). `element:record_picker.filter` is not changed here.

.changeset/flow-run-summary-contained-failure-visibility.md

@@ -0,0 +1,45 @@
+---
+'@objectstack/spec': minor
+---
+
+feat(spec): a contained per-iteration failure is visible in the flow run contract — run-level `failed`, loop iteration through `try` / `catch`, row identity on `$error` (#13681, spec half)
+
+The ruled containment spelling for a per-iteration failure that must not end
+the sweep is `loop { body: [ try_catch { try, catch } ] }` — ⛔ no
+`loop.config.onIterationError` key (maintainer 2026-08-31, verbatim
+「其他同意」; branch B selected by measurement: 5/5 iterations processed, the
+run completes). The ruling's rider is that such a caught failure is invisible
+at run level, and this change declares the three contract surfaces that close
+that gap. Additive only: nothing narrows, no existing key moves, no
+`BREAKING`.
+
+- **`FlowRunSummary.failed`** — total node executions that failed, a fold of
+  the existing per-node counter (`failed = Σ nodes[].failures`; that counter
+  already exists and already counts a caught try-region attempt, so there is
+  no second per-node key). On a run that completed, every one of them was
+  contained — caught by a `try_catch` or routed down a `fault` edge — and the
+  run went on. **Absent is not zero**, exactly as `unmeasured`: a run
+  recorded before the field existed did not track it, and a parse leaves the
+  key absent rather than defaulting it to `0`. It reads BESIDE the
+  broken-sweep filter (`selected > 0 AND acted = 0 AND unmeasured = 0`), not
+  inside it: `acted = 0` with `failed > 0` is a sweep whose writes were
+  attempted and failed, not one that silently stopped.
+- **`ExecutionStepLog.iteration` through `try` / `catch`** — a step executed
+  inside a try/catch region that is itself inside a loop body carries the
+  ENCLOSING LOOP's `iteration` (a try/catch region has no index of its own)
+  while `regionKind` stays `try` / `catch`. The schema already declared both
+  keys; the contract now states how they combine, and pins it.
+- **`TryCatchErrorValueSchema`** (`@objectstack/spec/automation`, beside
+  `TryCatchConfigSchema`, with `TryCatchErrorValue` /
+  `TryCatchErrorValueParsed`) — the value a `try_catch` binds to
+  `errorVariable` (default `$error`) was assembled by the engine and typed
+  nowhere. It is now declared: `nodeId`, `message`, and — only when the
+  failure happened inside a loop body — `iteration` (the enclosing loop's)
+  and `item` (the loop item being processed, `unknown`). A plain object
+  closed by convention: a value the engine assembles, not an authoring
+  surface.
+
+The engine half — populating `failed` in `summarizeRun`, propagating the loop
+iteration through `try_catch` → `runRegion`, binding `$error.iteration` /
+`$error.item`, and printing `failed=` on the run summary line when present —
+is the `domain:services` card that follows this contract.

.changeset/formula-receiver-call-prescription.md

@@ -0,0 +1,55 @@
+---
+"@objectstack/formula": patch
+---
+
+fix(formula): a stdlib function written as a method gets the bare call shape, not the dialect (#14203)
+
+`validateExpression` refused `record.name.upper()` correctly and then handed the
+author the generic dialect trailer — "`predicate`s are bare CEL (e.g.
+`record.rating >= 4`)" — advice that cannot succeed on a source that already IS
+bare CEL and parses fine. The third instance of the same defect family as the
+`bounds` class (#7073) and the unknown-name class (#13821), and the one neither
+of them could cover: #13821's arm fires only when the name is ABSENT from
+`CEL_STDLIB_FUNCTIONS`, and `upper` is present, so this class had no
+prescription at all. The name is right; the call SHAPE is wrong.
+
+It is a high-frequency AI-author mistake, not an exotic one: method-call syntax
+is what almost every other language uses for string operations, so a generator
+that knows `upper` exists reaches for `record.name.upper()` before
+`upper(record.name)`. The remedy is one sentence and it is mechanical — the
+correct spelling is derivable from the fault itself:
+
+```
+invalid CEL predicate: found no matching overload for 'dyn.upper()'
+
+>    1 | record.name.upper()
+         ^ — `upper` is callable bare, not as a method — a CALL-SHAPE fault, not
+a dialect mistake, so re-spelling the expression will not fix it. Write
+`upper(record.name)` instead. The callable names this platform advertises for
+authoring (the `functions` list `introspectScope` returns,
+`CEL_STDLIB_FUNCTIONS`) take their subject as an argument; only cel-js's own
+receiver methods (`record.name.split(',')`) are written after a dot.
+```
+
+The spelling is assembled from the SOURCE, because cel-js's message names the
+receiver's TYPE (`dyn.upper()`) and never the author's expression. When the
+receiver is not a plain dotted chain (`record.tags[0].upper()`,
+`(a + b).upper()`, `'lit'.upper()`) the message names the call shape —
+`upper(…)` with the receiver as its first argument — rather than inventing a
+spelling it cannot derive.
+
+The arm is keyed on membership of the bare-callable catalog plus the
+environment's own record of the receiver form, never on the call shape alone.
+Two classes therefore keep exactly the behaviour they had:
+
+- the 33 receiver-only names cel-js registers (`split`, `map`, `getFullYear`)
+  are correct ONLY after a dot — `record.name.split(',')` type-checks and never
+  reaches this arm;
+- the seven advertised names registered BOTH ways (`contains`, `endsWith`,
+  `matches`, `size`, `startsWith`, `string`, `trim`) keep the existing trailer
+  when a receiver call of them faults, because the fault there is the arguments
+  (`record.name.contains()`), and a bare rewrite would fault just as hard.
+
+No change to `CEL_STDLIB_FUNCTIONS`, to the registered environment, or to what
+`validateExpression` accepts: the receiver call was refused before this change
+and is refused after it. Only the sentence the author is told to act on changes.

.changeset/generate-flow-scaffold-validates.md

@@ -0,0 +1,48 @@
+---
+"@objectstack/cli": patch
+---
+
+fix(cli): `os generate flow` scaffolds a flow `os validate` accepts (#14087)
+
+The `flow` scaffold could not survive its own toolchain. Measured on 17.2.0,
+`os g flow my_flow` followed by `os validate` produced four refusals in one
+parse:
+
+```
+flows[0].nodes[0].label  expected string, received undefined
+flows[0].nodes[0]        unrecognized key(s): `name`, `next`
+flows[0].edges           expected array, received undefined
+flows[0]                 unrecognized key(s): `trigger`
+```
+
+`FlowSchema` is `.strict()` and has never declared a top-level `trigger` on
+protocol 17. A record-change flow binds on the START node's `config` —
+`{ objectName, triggerType, condition }` — which is where
+`AutomationEngine.resolveTriggerBinding` reads it from. The scaffold also wrote
+an `events: ['after_insert', 'after_update']` vocabulary that exists nowhere on
+the current surface, and named a single node it then pointed at a node it never
+emitted.
+
+So the first flow anybody scaffolded was a file their own `os validate`
+rejected — against a `.strict()` error enumerating what is allowed rather than
+saying where the trigger had moved to.
+
+The template now emits the shape the schema accepts and the engine binds:
+`type: 'record_change'`, a labelled START node carrying
+`config: { objectName, triggerType: 'record-after-write' }`, a labelled END
+node, and the `edges` array joining them. `status` stays `'draft'` — the arming
+decision is the author's, and `os validate` says so.
+
+`generate-scaffold-validates.test.ts` puts every generator's output through the
+two steps `os validate` runs on an authored stack (schema parse, then the
+author-time rule registry), loaded through the same `bundle-require` path
+`loadConfig` uses, so the generator and the schema cannot drift apart again
+silently. Both layers are needed: a flow node's `config` is an open slot
+(ADR-0018), so the schema cannot judge the trigger vocabulary at all — the
+`record-*` grammar is held by `validate-flow-trigger-readiness` one layer
+later.
+
+No other generator's output changed. Four of them (`object`, `view`, `action`,
+`app`) are refused for unrelated reasons of their own; the new test records
+them in a shrink-only ledger that fails when one is repaired and its entry is
+left behind.