Merge branch 'main' into claude/issue-14299-skills-platform-optimization

Nine sibling skills flights landed on main after this branch's base. Both
conflicts fell inside the BEGIN/END GENERATED: skills region of the two mixed
generated files (skills/README.md, content/docs/ai/skills-reference.mdx);
resolved by clearing the markers in place — preserving main's text-merged prose
outside the region — and regenerating both wholesale with
`pnpm --filter @objectstack/spec gen:skill-docs` on the merged tree.
scripts/check-skills-token-ratchet.mjs auto-merged (each flight edited its own
package's ceiling rows). No behaviour or content change to the platform package.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01489YWhZEoHT9oXshiyywQy

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/address-location-value-strict.md

@@ -0,0 +1,74 @@
+---
+"@objectstack/spec": minor
+---
+
+feat(spec): refuse undeclared keys on `address` and `location` values — `AddressSchema` / `LocationValueSchema` are strict (#13802)
+
+<!-- adr-0087: registered address-location-value-unknown-keys-refused -->
+
+**BREAKING** accept-set narrowing on two ADR-0104 D1 value contracts, shipped
+as `minor` under the repo's launch-window convention for breaking changes; the
+migration prescription is registered under protocol major 18. Maintainer
+ruling 2026-09-01 on #13802 (director decision batch #26, verbatim 「同意」):
+option A.
+
+`LocationValueSchema` and `AddressSchema` (`AddressValueSchema` is the same
+schema) were all-optional **stripping** `z.object`s. Every member being
+optional meant a value with a completely wrong key set still parsed green,
+and the wrong keys vanished from the parse output — the showcase seed wrote
+`postal_code`, the platform accepted it, dropped it, and rendered an empty ZIP
+box (#13388), while a stored-value scan over either class could only ever
+report a clean count it had no way to earn. Both are now `strictObject`s.
+`FileValueSchema` stays `z.looseObject` — the one deliberate loose site,
+untouched.
+
+**What is refused:** any key the shape does not declare, with a prescriptive
+message naming the surface, the key, and a rename where one is known
+(`postal_code` / `zipCode` / `zip` / `postcode` → `postalCode`;
+`latitude` → `lat`, `longitude` → `lng`). The zod issue is
+`unrecognized_keys` and its `keys` name the offending spellings.
+
+**What stays accepted:** every declared key byte-identically —
+`street`, `city`, `state`, `postalCode`, `country`, `countryCode`, `formatted`
+on an address; `lat`, `lng`, `altitude`, `accuracy` on a location.
+
+**Where the refusal bites — and where it deliberately does not** (the
+ADR-0104 posture is unchanged; this changeset narrows the contract, not the
+write path's evidence gate):
+
+- **Authoring, hard reject, unconditional:** a `location` / `address` field's
+  literal `defaultValue` (`FieldSchema`, #7127) and an action param of those
+  types (`validateActionParams`, strict by default since 17.0).
+- **Record writes, per deployment:** objectql's `validateRecord` rejects the
+  value (`400 VALIDATION_FAILED`, field code `invalid_type`, message naming
+  the key) **only** on a deployment that has attested `adr-0104-value-shapes`
+  or set `OS_DATA_VALUE_SHAPE_STRICT_ENABLED=1` (`OS_ALLOW_LAX_VALUE_SHAPES=1`
+  re-opens). Everywhere else the write is **admitted** warn-first, logged once
+  per field, and reported to the admitted-violation sink — exactly as before.
+- **`os migrate value-shapes`** now counts an undeclared key as a violation,
+  so a deployment holding such values cannot attest until they are cleaned at
+  the producer. That scan is what keeps the strict flip from stranding stored
+  data.
+- **Read paths: none.** No consumer parses these shapes on read; a stored
+  `{ …, postal_code }` reads back as it was written. No read path was
+  narrowed, and no consumer-side alias is introduced — `postal_code` is
+  refused, never read.
+
+## FROM → TO
+
+```ts
+// before — parsed green; `postal_code` silently gone from the parsed output
+valueSchemaFor({ type: 'address' }, 'stored').safeParse(
+  { street: '1 Main St', city: 'Seattle', state: 'WA', postal_code: '98101', country: 'US' })
+// => { success: true, data: { street, city, state, country } }
+
+// after — refused, naming the key and the declared spelling
+// => { success: false, error: { issues: [{ code: 'unrecognized_keys', keys: ['postal_code'],
+//      message: 'Unrecognized key(s) on this address value: `postal_code`. Did you mean `postal_code` → `postalCode`? …' }] } }
+```
+
+Fix: spell the key as the contract declares it — `postal_code` → `postalCode`
+in the producer (seed, importer, geocoder adapter, widget). For a location,
+`latitude` / `longitude` → `lat` / `lng`; drop device extras such as
+`heading` / `speed` or model them as fields of their own. Run
+`os migrate value-shapes` to find stored values that carry undeclared keys.

.changeset/adr-0130-install-gate-co-ownership.md

@@ -0,0 +1,47 @@
+---
+"@objectstack/objectql": minor
+"@objectstack/runtime": patch
+---
+
+feat(objectql): admit same-artifact co-owners at the namespace gate, and refuse two of them defining one object name (#14163)
+
+ADR-0130 **D1 + D3**, landed as the single change D3 specifies as a machine
+constraint. Neither half may ship alone, in either order.
+
+- **D1 — the gate's question is corrected.** `SchemaRegistry.installPackage`'s
+  ADR-0048 namespace gate asked *"is this the same package id?"*; it now asks
+  *"are these co-owners within one artifact?"*. Everything inside one release
+  artifact is built, versioned, downloaded and installed as one atomic act by
+  one publisher, and ADR-0130 D1 makes that joint delivery the ownership proof.
+  `RESERVED_NAMESPACES` / `isShareableNamespace` are unchanged, and two packages
+  from **different** artifacts sharing a namespace are still refused with the
+  existing `NamespaceConflictError`.
+- **D3 — the guarantee the gate was silently carrying is now checked directly.**
+  Namespace exclusivity has been proxying for *"no two packages define the same
+  object name"* (ADR-0048 §3.2 grounds it on exactly that). So `installPackage`
+  now refuses, **at install time and ahead of any DDL**, a package whose object
+  name is already owned by a co-owner from the same artifact —
+  `ArtifactObjectNameConflictError`, an ADR-0112 envelope (`code:
+  'DUPLICATE_ARTIFACT_OBJECT_NAME'`, `status: 422`) naming both packages and the
+  object. Without it, two co-owning packages defining `crm_account` would reach
+  the DB as a duplicate `CREATE TABLE` or — driver-dependent — one silently
+  overwriting the other's table definition.
+
+**How the gate learns "same artifact".** An optional third argument on
+`installPackage` (`ArtifactInstallScope`, the artifact's own package-id list),
+threaded from the ADR-0130 D4/D5 load path through `ObjectQL.registerApp`. ⛔ No
+owner/publisher field on the manifest — ADR-0130 D8 defers that deliberately,
+and nothing is persisted, so a co-ownership claim cannot outlive or drift from
+the artifact that IS the claim.
+
+**Not a compatibility break** (#14122 §6.2): the new refusal can only reject a
+configuration that would have failed at the DB anyway, and it rejects it earlier
+and more legibly. Every caller that installs one package —
+`protocol.installPackage`, `POST /packages`, a bare `registerApp` — passes no
+scope, so both halves are structurally no-ops there; a single-`manifest`
+artifact passes a one-element scope whose only member is the installing package,
+which the gate excludes anyway (D7's bit-identity pin covers it).
+
+`@objectstack/runtime` carries the classification row for the new error code in
+the dispatcher error-code vocabulary (verdict `boot-refusal`: the refusal cannot
+be raised by either HTTP install site, which pass no artifact scope).

.changeset/approval-escalation-calendar-clock.md

@@ -0,0 +1,16 @@
+---
+"@objectstack/spec": patch
+---
+
+docs(spec): `ApprovalEscalation.timeoutHours` names its clock — calendar (wall-clock) hours
+
+The `timeoutHours` describe text now states that the hours are calendar
+(wall-clock) hours: nights, weekends and holidays count, because the platform
+ships no business-hours calendar, so a request opened at 17:00 on a Friday with
+`timeoutHours: 4` escalates at 21:00 that same Friday. The sentence is published
+contract text — it is what `gen:schema` emits to the JSON schema `description`
+and what the reference page carries — so the unit is part of the declaration an
+author reads at authoring time rather than prose beside it. No key is added,
+renamed or defaulted differently; the approvals service's arithmetic is
+unchanged and is now pinned by a wall-clock test (Friday 17:00 + 4 h, a 168-hour
+deadline across a weekend, a DST transition).

.changeset/approval-override-recall-pending-only.md

@@ -0,0 +1,47 @@
+---
+"@objectstack/plugin-approvals": patch
+---
+
+fix(approvals): the #3424 override reaches a `pending` request only — override-recall of a `returned` request is now refused (#12775)
+
+**Behaviour change, declared explicitly (maintainer ruling 2026-09-02) so that
+one revert of this changeset's PR restores the previous behaviour.**
+
+`ApprovalService.recall` admits two callers: the submitter, and a platform or
+tenant admin releasing a stuck request (the #3424 privileged override). Recall
+is also valid on the LATEST `returned` request of a run — the ADR-0044 revise
+window, where the submitter abandons the revision instead of resubmitting.
+Those two rules met above the state check: the override short-circuit carried
+no status test of its own, so an override actor could recall a `returned`
+request too. Nothing else on the platform said so — `isOverrideActor`'s doc
+block names a PENDING request, `attachViewers` computes
+`viewer.can_override` as `status === 'pending' && isOverrideActor(...)`, and
+the `approval_recall` action's override arm reads that flag — so the reach was
+API-only, never offered by any UI, and pinned by nothing.
+
+What changes:
+
+- **Override-recall of a `returned` request is refused.** The override
+  short-circuit in `recall` now applies only while the request is `pending`,
+  spelled exactly as the viewer flag is computed. On `returned` an override
+  actor is judged exactly as any other non-submitter and receives the existing
+  refusal: `403 FORBIDDEN` over REST, with the operation catalog's
+  `approval_recall_not_submitter` sentence. No new error code, no new envelope.
+- **Only `pending` requests are override-recallable** — the same scope as the
+  other three override levers (approve / reject / reassign are pending-only at
+  their endpoints), and the same scope the viewer flag has always declared.
+
+What does not change:
+
+- The submitter's own recall of a `returned` request (the ADR-0044 revise
+  window) is untouched; so is the submitter's recall of a `pending` one.
+- The override actor's recall of a `pending` request — the #3424 rescue of a
+  request routed to an unstaffed position — is untouched, lock release and all.
+- The refusal's message, wire code and developer log line keep their shape; the
+  log line now also names the request status it refused on.
+
+Why: the gate now agrees with the viewer flag and the documented contract at
+one point instead of disagreeing with both. If a real operator workflow
+depended on override-recalling a `returned` request, this is the change to
+revert; the `returned` record lock is already released, so the stuck-record
+rescue motive that justifies the override does not apply on that status.

.changeset/artifact-boot-single-security-registrar.md

@@ -0,0 +1,38 @@
+---
+"@objectstack/runtime": minor
+---
+
+fix(runtime): one registrar for the artifact boot's security collections — the artifact door, not `AppPlugin` (#12892 step 2)
+
+On an artifact boot (`createStandaloneStack`: `os serve` / `os dev` / `os start` /
+`os migrate` booting from `dist/objectstack.json`) the stack-declared
+`positions` / `permissions` / `capabilities` / `sharingRules` used to reach the
+metadata service through TWO registrars over the same bytes: the artifact door
+(`MetadataPlugin`, which forward-converts, strict-parses and stamps ADR-0010
+provenance) and `AppPlugin`'s ADR-0057 block (which does none of that). Because
+`AppPlugin` started last its copy won, so a consumer of
+`metadata.list('sharing_rule')` read a sharing rule whose `condition` was a bare
+STRING where the door's copy carries `{ dialect, source }` (reading
+`.condition.source` gave `undefined`), and a capability with no `scope` default
+and no `_packageVersion` / `_provenance`. Which shape a reader saw depended on
+plugin start order.
+
+Maintainer ruling on #12892 (2026-08-29): the door owns the route. Now:
+
+- `AppPlugin` takes `securityMetadataRegistrar: 'app-plugin' | 'artifact-door'`
+  (constructor `opts`, default `'app-plugin'`). Under `'artifact-door'` the
+  ADR-0057 block registers nothing and logs a `debug` line naming the
+  collections left to the door; an unknown value is refused loudly.
+- `createStandaloneStack` — the one composition that runs the door over the
+  same artifact — declares `'artifact-door'` on the `AppPlugin` it composes. On
+  that boot the metadata service holds exactly ONE copy of every security item:
+  the door's, parsed, defaulted and provenance-stamped, in either start order.
+- Every door-less composition (`new AppPlugin(config)` over a `defineStack()`
+  module in `os serve` / `os migrate`, `DevPlugin`, `@objectstack/verify`'s
+  `bootStack`, embedders) is unchanged: the default keeps registering all four
+  collections exactly as before.
+
+`minor` rather than `patch`: a public constructor option is added, and what the
+metadata service serves for these four kinds on an artifact boot changes shape
+(door copy instead of raw copy) — a fix, but one a reader of `GET /meta/<kind>`
+or `metadata.list(<kind>)` on an artifact boot can observe.

.changeset/artifact-load-topological.md

@@ -0,0 +1,9 @@
+---
+'@objectstack/objectql': minor
+---
+
+Load a release artifact's packages in dependency-topological order (ADR-0130 D5).
+
+The `manifest` service now reads both artifact shapes ADR-0130 D4 declares — `packages: [...]` when present, and the singular `manifest` treated as a one-element list when absent — and registers the packages inside one artifact in dependency-topological order, resolved by `resolvePluginOrder`, the platform's single topological sorter (ADR-0116). A package that extends another package's object therefore registers after the package it extends, whatever slot the artifact's array put it in.
+
+An existing single-`manifest` artifact takes the second branch, by reference and unrewritten, and its registration state is unchanged (ADR-0130 D7). New: `resolveArtifactPackageOrder` is exported so every other door that grows an artifact-loading seam reads both shapes and orders them the same way.

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