Merge remote-tracking branch 'origin/main' into claude/issue-14439-multi-package-build

# Conflicts:
#	scripts/check-stack-collection-maps.mjs

Author: claude

.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/declaration-boot-guard-boundaries.md

@@ -0,0 +1,12 @@
+---
+"@objectstack/cli": patch
+---
+
+fix(cli): close the declaration-boot write guard's two named boundaries — engine-held drivers and immediate DDL (#14126)
+
+`os migrate plan` / `os migrate apply` boot host plugins for their declarations behind a guard that refuses the contract's row writes and, since #13332 / #14053, prints "a plan writes nothing" only when that held. Two boundaries were left open and named in the guard's own census; both are now covered, under ONE outcome-line rule:
+
+- **Engine-held drivers.** Only the default datasource is published as `driver.*`; every other driver reaches the engine through `engine.registerDriver` alone (`DatasourceConnectionService.connect()`, `AppPlugin`'s `drivers.register`, `ObjectQL.create`), so a hook writing to an object bound to a second datasource landed during a plan. The guard now shadows `registerDriver` on the engine instance the kernel publishes (`objectql` / `data`) for the length of the boot, arms each driver instance in place as it is registered — forwarding the SAME instance, never a wrapper, never a second registration under a held name — reaches drivers the engine already held through its public accessors, and restores the engine on `disarm()`. Such a write is now refused and reported as `via engine.<datasource>`.
+- **Immediate DDL.** `dropTable()` / `rotateShards()` are not held back by the schema deferral and execute immediately. They are still not refused (refusing DDL an operator's own hook asked for is out of this guard's scope) — but they now get `execute()`'s treatment: forwarded, counted per driver/method/object, warned once per driver on stderr, named in the notes, and the run no longer claims "a plan writes nothing".
+
+The rule, decided once: the claim prints only when it held across everything the guard can see — every write refused, nothing forwarded (raw `execute()`, immediate DDL), and no instance that refused the override (a frozen driver, an engine that could not be shadowed). Each of those is named in the notes and withholds the line. An embedder with no data plane, and read/log-only hooks, are untouched: a quiet boot still renders byte-identically.

.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/email-sender-validated-at-configuration-time.md

@@ -0,0 +1,55 @@
+---
+"@objectstack/plugin-email": patch
+---
+
+fix(plugin-email): judge the default sender where it is configured, and record a send rejected before delivery (#14318)
+
+Measured on a local rig with `OS_EMAIL_FROM="ObjectOS Local <noreply@localhost>"`,
+`OS_EMAIL_PROVIDER=log` and `OS_AUTH_REQUIRE_EMAIL_VERIFICATION=true`: the server
+booted clean, the first sign-up answered `200`, the UI said a verification email
+had been sent, and nothing had been. `EMAIL_REGEX` requires a dotted domain and
+correctly refuses `noreply@localhost` — but it refused it inside
+`normalizeMessage`, on the **first send**, which for a fresh deployment is the
+first user's sign-up. better-auth runs `sendVerificationEmail` through
+`runInBackgroundOrAwait`, which logs `Failed to run background task` and returns
+normally, so the account was created and the user was parked on a verify screen
+whose Resend repeated the whole sequence. `sys_email` held no row for any of it:
+the throw happened *before* the row insert, and every other failure shape in the
+service is a row at `status:'failed'`.
+
+Two changes, one per half.
+
+**The address is judged where it is configured.** `EmailServicePlugin.init()`
+now refuses a declared `defaultFrom` that no message could ever be sent from, so
+a deployment that names an unsendable sender fails its boot instead of failing
+every send — the same trade `resolveTransport` already makes for an SMTP
+provider with no host, and the error names the consequence and the fix
+(`OS_EMAIL_FROM` / `config.email.defaultFrom`). An **absent** sender is still
+accepted: callers that always pass `input.from` are a complete configuration,
+and `normalizeMessage` already refuses a send that has neither.
+
+The `mail` settings channel takes that method's opposite, stated trade — a save
+must not kill a running server — so an unsendable saved From address is
+**refused, the previous sender kept**, and the consequence stated at `error`.
+`error` and not `warn` because nothing looks broken afterwards: the save
+succeeds and the settings page shows the address the operator typed.
+
+**A send rejected before delivery now leaves a `sys_email` row.** The
+`normalizeMessage` window was the one path on which a send produced no record at
+all. It now writes `status:'failed'` with the reason, prefixed
+`rejected before delivery:` so the column distinguishes a message that never
+reached a transport from one an SMTP host refused. The envelope columns carry
+what the caller actually passed (never re-canonicalised — canonicalisation is
+what threw), `(none)` where the input named nothing, since `from_address` /
+`to_addresses` / `subject` are required. The row is safe by construction: both
+re-delivery paths — the `afterInsert` outbox drain hook and the boot outbox
+sweep — gate on `status === 'queued'`, so a rejection record can never be
+mistaken for an outbox entry. Persisting it is best-effort and never replaces
+the caller's error.
+
+Unchanged: `formatAddress`, `EMAIL_REGEX` and `normalizeMessage` keep their
+exact verdicts (the new `isSendableAddress` predicate shares the one regex, so a
+boot cannot pass a check the send path then fails), `send()` still throws on
+validation failure rather than answering `failed`, and the auth layer's
+propagation is as it was — `sendVerificationEmail` already rejects on both a
+throw and a returned `status:'failed'`, which is now pinned by a test.

.changeset/filesystem-loader-keyed-items.md

@@ -0,0 +1,29 @@
+---
+'@objectstack/metadata': patch
+---
+
+`FilesystemLoader` now implements `loadManyKeyed()`, so a metadata file whose
+body has no top-level `name` is no longer invisible to `MetadataManager.list()`.
+`loadMany()` globbed files and pushed bodies, discarding the path it had just
+read; the manager then fell back to keying by `body.name`, which drops every
+nameless body — an aggregated `defineView` container has none by design. That is
+the #14205 defect, unrepaired for this loader until now.
+
+The key is this loader's own name-to-path derivation — the basename minus
+extension, the same one `list()` reports — but only where that derivation is a
+bijection for the file: it sits directly under `ROOT/TYPE/` and carries an
+extension `findFile()` tries, so `findFile(type, key)` resolves back to that same
+file. Every other shape (a nested path, an extension-less file) keeps the
+previous behaviour verbatim: keyed by `body.name` when it has one, dropped when
+it has none. `list()` and `findFile()` disagree outside the flat shape — `list()`
+reports the bare basename for a nested file and `findFile()` cannot resolve it —
+so keying those by the basename would mint names `get()` and `exists()` cannot
+open, and two directories holding one basename would collide silently. Repairing
+the derivation itself is tracked separately.
+
+One deliberate consequence: a flat file whose `body.name` disagrees with its
+basename is now keyed by the basename. That is #14205's rule (identity is the
+key the store holds an item under, not `body.name`) applied to this loader, and
+it aligns `list()` with `listNames()` for that shape. `loadMany()`'s own
+signature and answer are unchanged; both methods now share one file walk so
+their bodies cannot drift.

.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/hook-provenance-sibling-seams.md

@@ -0,0 +1,50 @@
+---
+"@objectstack/objectql": patch
+---
+
+fix(objectql): decide the insert-side runtime-owned strip by hook-write PROVENANCE, not `Object.is` (#14259)
+
+#14088 replaced `Object.is(payload[k], supplied[k])` inside `stripReadonlyFields`
+with a recording of the keys the before-phase hook chain actually assigned
+(`recordHookPayloadWrites`). Its argument was never about `null`: value equality
+cannot separate *the hook deliberately wrote the value the caller also sent* from
+*the hook never touched the key*, and those two demand opposite verdicts.
+
+`stripRuntimeOwnedFields` — the INSERT-side twin — was left on the comparison
+that argument retired, and #6339's own prose is the finding: it argued a key SET
+made the contract true "only BY ACCIDENT" and moved to values, which is
+accidental in the identical way. A `beforeInsert` hook that re-issues or
+normalises a record number therefore still lost its write to any caller that
+submitted the same value — the caller who omitted the key kept the hook's number,
+the caller who echoed it got the sequence value, and the two differed in nothing
+else.
+
+`engine.insert` now arms one recording **per row** at hook-context construction
+and seals each immediately after that row's `beforeInsert` chain, and
+`stripRuntimeOwnedFields` consults the sealed record before the value test. Per
+row, never per call, so a hook stamping one row of a batch confers nothing on the
+next.
+
+⛔ **Not a relaxation of #5503, and the accept set for callers does not move.** A
+caller-seeded record number that no hook assigned is still stripped, still warns
+with the same text, and still reports through `onFieldsDropped` /
+`strictReadonlyWrites`; `isSystem` and `preserveAudit` are untouched. What
+changed is only the EVIDENCE for the hook-write exemption that already existed —
+a record of which keys were assigned, instead of an inference from the values
+afterwards.
+
+The forgery boundary is inherited verbatim: a caller-supplied value must never
+become hook-owned. The new insert-side recording is armed after the caller's
+payload has arrived and been snapshotted, sealed before any engine-owned pass
+touches the row, and records that an assignment ran rather than anything about
+the payload's contents — a caller cannot execute an assignment, so no key it
+sends can enter the record. A hook that REPLACES the payload object leaves no
+attributable record and falls back to the pre-existing value test, which
+over-strips: keeping the old bug is the only safe direction, because reading a
+replacement's keys as hook-owned would launder a caller's forgery.
+
+The `readonlyWhen` sibling seam #14259 also names (`isCallerSuppliedValue`,
+behind `stripReadonlyWhenFields` / `stripReadonlyWhenFieldsMulti`) is **not**
+included: threading the record there was measured to let a caller's value survive
+a TRUE `readonlyWhen` predicate, which is a maintainer decision rather than a
+mechanical follow-through. Nothing about that seam's behaviour changes here.

.changeset/idatadriver-update-declares-null.md

@@ -0,0 +1,11 @@
+---
+'@objectstack/spec': minor
+---
+
+feat(spec): `IDataDriver.update()` declares its not-found arm (#13878)
+
+**BREAKING** for TypeScript consumers, shipped as `minor` under the repo's launch-window convention for breaking changes (maintainer ruling 2026-09-01, option A). `IDataDriver.update()`'s return type is now `Promise<Record<string, unknown> | null>` — the shape `findOne()` already carries and the not-found vocabulary `delete()` already uses (`false`) — and its docblock says when `null` is returned: no record with that id exists, on a driver not configured to throw on missing records. The Zod mirror `DriverInterfaceSchema.update` carries the same `.nullable()` output and the same sentence. This declares the behaviour four of the six shipped drivers have always had, which the previous declaration forbade.
+
+What breaks: a caller that read fields straight off an `update()` result compiled before only because the arm was undeclared; it now narrows the `null` arm first — a compile-time obligation at the call site in place of a silent runtime hazard. No metadata key, no runtime behaviour and no wire shape moves.
+
+<!-- adr-0087: not-required (no-migration-prescription) A declared return type gains the not-found arm the implementations already answer: no metadata key is removed, renamed or re-shaped, so there is no tombstone and nothing for `objectstack migrate meta`, `spec-changes.json` or the upgrade guide to rewrite; the obligation is a TypeScript narrowing at the consumer's own call site, and the compiler is the channel that reaches every affected consumer. -->