Merge origin/main: reconcile with #2556 (keep build lint + boot _diagnostics)

#2556 (view-key collision boot warnings) landed on main while this branch was
open. Reconciled by keeping BOTH: the merged `expandViewContainerWithDiagnostics`
now pushes `collisions[]` (consumed by the new build-time `lint-view-refs`) AND
stamps per-item `_diagnostics` (consumed by the boot loaders) at the same
detection points. view-expand keeps both test suites (17 pass); showcase view/
action conflicts merged; .objectui-sha takes main's pin; api-surface unchanged;
full turbo build 71/71.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Author: os-zhuang

.changeset/adr-0069-last-login-audit.md

@@ -0,0 +1,21 @@
+---
+"@objectstack/platform-objects": minor
+"@objectstack/plugin-auth": minor
+---
+
+feat(auth): last-login audit fields — sys_user.last_login_at / last_login_ip (ADR-0069 D7)
+
+Completes the ADR-0069 D7 identity-field set: `sys_user.last_login_at` and
+`sys_user.last_login_ip` are stamped on every successful `/sign-in/email` by
+`AuthManager.stampLastLogin` (a best-effort after-hook, independent of the
+lockout-accounting path so it runs even when lockout is disabled). The IP is
+taken from the trusted forwarded headers (`x-forwarded-for` →
+`cf-connecting-ip` → `x-real-ip`), the same precedence as the D5 IP allow-list
+middleware, and capped to the 45-char column width. Both fields are
+system-managed, read-only, and land in the Admin group of `sys_user`.
+
+The rest of ADR-0069 P1 (password complexity/history/expiry, HIBP, account
+lockout, enforced MFA) was already implemented; this fills the one missing D7
+field pair. ADR-0069 status updated Proposed → Accepted (P1/P2 implemented)
+with an implementation-status matrix reflecting what is landed vs the remaining
+P2 gaps (per-org IP ranges, shared-store rate limiting).

.changeset/adr-0069-shared-ratelimit-store.md

@@ -0,0 +1,23 @@
+---
+"@objectstack/plugin-auth": minor
+---
+
+feat(auth): shared cross-node rate-limit + session store via the cache service (ADR-0069 D2)
+
+Multi-node deployments previously rate-limited **per process** — better-auth's
+default `rateLimit` store is in-memory, so each node counted independently and
+an attacker could rotate nodes to bypass the limit. `AuthPlugin` now wires the
+kernel `cache` service as better-auth's `secondaryStorage` and flips
+`rateLimit.storage` to `'secondary-storage'`, so rate-limit counters (and the
+session cache) are enforced against **one shared store across every node** —
+shared iff the cache service is (Redis adapter in a cluster; memory single-node,
+where behavior is unchanged). When no cache service is registered the plugin
+logs a warning that a multi-node deployment needs a shared cache (ADR-0069
+honesty — no silent per-process limiting presented as global).
+
+New `cacheSecondaryStorage(cache)` adapter (`ICacheService` → better-auth
+`SecondaryStorage`). Note: the cache has no atomic increment, so under high
+concurrency the get→set counter path can slightly over-count — acceptable for a
+rate limiter and strictly better than independent per-node counters; a future
+cache adapter exposing atomic INCR can add an `increment` method for exact
+counting.

.changeset/adr-0086-two-doors-permission-sets.md

@@ -0,0 +1,36 @@
+---
+"@objectstack/metadata-protocol": minor
+"@objectstack/plugin-security": minor
+---
+
+feat(security): two-doors separation for permission sets (ADR-0086 P2)
+
+Splits who may change a permission set into two non-overlapping doors, enforced
+at the data layer instead of by convention:
+
+**块1 — the package door (publish-time materialization).**
+`ObjectStackProtocolImplementation` gains a generic publish-time materializer
+registry (`registerPublishMaterializer(type, fn)`). When a draft of a registered
+type is published, its body is projected into a data-plane row and the result is
+surfaced on the publish response as `materializeApplied` (best-effort, never
+thrown — same contract as `seedApplied`). `promoteDraft` now returns the draft's
+`packageId` so the materializer can stamp the owning package. `plugin-security`
+registers a `permission` materializer that upserts the published set into
+`sys_permission_set` with `managed_by:'package'` + `package_id` — so a set
+authored through the studio package door (saved as a `permission` draft, then
+published) lands in the admin surface with the exact provenance the boot seeder
+already stamps, now on the runtime publish path too. The single-set upsert is
+shared with `bootstrapDeclaredPermissions` (`upsertPackagePermissionSet`), so
+both paths apply the same own-row / foreign-package / env-authored rules.
+
+**块2 — the admin door (data-layer write gate).**
+The security middleware now refuses any admin-door write
+(`update`/`delete`/`transfer`/`restore`/`purge`) to a `sys_permission_set` row
+with `managed_by:'package'`, and refuses an `insert` that forges
+`managed_by:'package'`. The gate fails closed regardless of the caller's grants
+(a platform admin with `modifyAllRecords` is blocked just the same), so it is a
+real data-layer boundary rather than a UI hint. System/boot writes carry
+`isSystem` and bypass the whole middleware, so the boot seeder and the publish
+materializer are unaffected. Env-authored sets (`managed_by` `user`/`platform`
+or absent) stay freely editable through the admin door — the two doors never
+overwrite each other.

.changeset/automation-bind-flows-cold-boot.md

@@ -0,0 +1,30 @@
+---
+"@objectstack/service-automation": patch
+---
+
+fix(automation): bind flow triggers on a cold boot, not just after an HMR reload
+
+Record-triggered (and other trigger-typed) flows silently never fired on a
+fresh process start — in dev and in production. The automation service's
+boot-time flow pull reads `ql.registry.listItems('flow')`, which is **empty for
+flows defined inline in an app manifest** — `registry.registerApp()` stores the
+app under type `'app'` and never promotes its inline flows to standalone
+registry `'flow'` items. The re-sync that *could* see them only ran on the
+`metadata:reloaded` hook, which never fires on a cold boot (`os dev` restarts
+the process on recompile rather than firing it, and production never reloads).
+
+Net effect: after any real restart, **no flow bound its trigger**, so
+record-change automations did not fire at all.
+
+Fix: bind flows at `kernel:ready` from `protocol.getMetaItems({ type: 'flow' })`
+— the canonical flattened flow view that `GET /meta/flow` serves and that does
+surface inline app flows — once every plugin has finished `init()`/`start()`
+(so the app, hence its flows, is registered). `registerFlow` is idempotent, so
+re-binding a flow the boot pull already registered is harmless.
+
+Verified end-to-end on a clean instance: before the fix, updating a record
+fired **0** flows (0 bound at boot); after, a cold boot binds all flows and a
+single record update fires every matching record-triggered flow. Regression
+test boots a kernel with an inline-app record-triggered flow served only via
+`protocol.getMetaItems` and asserts it is bound after `bootstrap()` alone with
+no `metadata:reloaded` fired — it fails on the pre-fix code.

.changeset/automation-publish-rebind-flows.md

@@ -0,0 +1,39 @@
+---
+"@objectstack/service-automation": patch
+"@objectstack/runtime": patch
+---
+
+fix(automation): bind a flow published while the server runs, without a restart
+
+Follow-up to #2560 (cold-boot flow binding). A flow **published while the server
+is running** — the Studio online-authoring journey: author a record-triggered
+automation, publish it, immediately update a matching record — did **not** fire.
+Its trigger only bound on the next process restart.
+
+Two gaps, both fixed:
+
+1. **The publish path fired no rebind signal.** `POST /packages/:id/publish-drafts`
+   → `protocol.publishPackageDrafts` promotes the drafts to active but emitted no
+   event the automation service listens to. The runtime dispatcher now announces
+   `metadata:reloaded` after a successful publish — the same signal a dev artifact
+   reload fires (`MetadataPlugin._reloadAndAnnounce`) — so boot-cached consumers
+   re-sync without a restart.
+
+2. **The runtime re-sync read the wrong source.** The automation service's
+   `metadata:reloaded` re-sync pulled `metadata.list('flow')`, which returns 0 in a
+   real running server (it does not surface inline app flows), so even when the
+   hook fired it bound nothing. It now reads `protocol.getMetaItems({ type: 'flow' })`
+   — the same flattened flow view #2560's cold-boot bind and `GET /meta/flow` use —
+   while keeping the teardown of flows removed from the artifact. A failed or
+   unavailable protocol read is a no-op and never tears down live flows.
+
+Production is largely unaffected (a deploy reboots the process, so #2560's
+cold-boot bind covers it); this closes the gap for dev and single-instance
+Studio authoring.
+
+Verified end-to-end on a clean instance: authored a record-triggered flow in a
+package, published it via `POST /packages/:id/publish-drafts` **without
+restarting**, then updated a matching record and observed the flow fire (before
+the fix it did not). New regression tests boot a kernel whose protocol serves a
+flow only after boot and assert `metadata:reloaded` binds it — and that the
+re-sync reads the protocol, not `metadata.list` — both failing on the pre-fix code.

.changeset/automation-run-history.md

@@ -0,0 +1,37 @@
+---
+"@objectstack/service-automation": minor
+---
+
+feat(automation): durable run history — every terminal run leaves a queryable record with its failure reason
+
+Automation runs were observable **only in memory**: the engine kept the last N
+`ExecutionLogEntry` records in a ring buffer, so "did this flow run, and why did
+it fail?" could not be answered after a process restart (or once the buffer
+evicted the entry), and a failed run surfaced no reason at all. This was the
+biggest silent-trust gap for anyone authoring automations — a flow could stop
+firing or start failing with nothing durable to inspect.
+
+`sys_automation_run` — previously the ADR-0019 store for *live suspended* runs
+only — becomes a durable **run-history** table. On every terminal run the engine
+mirrors a row through the `SuspendedRunStore` (`recordTerminal`): `status`
+(`completed` / `failed`), `finished_at`, `duration_ms`, and, for a failure, the
+`error` message a designer needs to fix it. `listRuns()` merges this durable
+history with the in-memory buffer (in-memory wins on id, newest-first) so the
+Studio "Runs" surface shows runs that predate the current process.
+
+The design is **safe and additive**. Terminal history rows use a `run_`-prefixed
+id, disjoint from live suspended runs (which key on the raw `runId` with
+`status: 'paused'`), so the suspend save/load/delete/list path is untouched and
+resume sweeps (`list()` filters `status: 'paused'`) never see history rows.
+Persisting is **best-effort and fire-and-forget** — a history-write failure is
+logged and swallowed, never breaking the run that produced it. New object fields
+(`finished_at`, `duration_ms`, `error`) are all optional and the `status` enum
+gains `running` / `completed` / `failed` alongside the existing `paused`.
+
+Verified end-to-end on a clean showcase instance: a schedule-triggered flow and
+seven task-completion flows each left durable `completed` rows; a genuinely
+failing flow (`showcase_resilient_sync`) left a `failed` row carrying its
+`try_catch` failure reason; a live `paused` suspended run coexisted without
+collision; and after a full process restart the `failed` row — reason intact —
+was still queryable via `/api/v1/data/sys_automation_run`. New `run-history.test.ts`
+covers completed/failed persistence, read-across-restart, and best-effort isolation.

.changeset/destructive-ops-rbac-mapping.md

@@ -0,0 +1,16 @@
+---
+"@objectstack/plugin-security": minor
+"@objectstack/spec": patch
+---
+
+feat(security): pre-map `transfer`/`restore`/`purge` to their RBAC bits (#1883)
+
+The permission evaluator now maps the destructive record-lifecycle operations
+to their spec permission bits (`transfer` → `allowTransfer`, `restore` →
+`allowRestore`, `purge` → `allowPurge`) and extends the `modifyAllRecords`
+super-user bypass to cover them. The ObjectQL operations themselves are still
+roadmap M2 — but the gate now exists ahead of them: the moment such an
+operation is dispatched through the security middleware it is denied unless a
+resolved permission set grants the matching bit. Unmapped destructive
+operations continue to fail closed (ADR-0049). Spec descriptions updated from
+`[EXPERIMENTAL — not enforced]` to `[RBAC-gated; operation pending M2]`.

.changeset/permission-package-provenance.md

@@ -0,0 +1,26 @@
+---
+"@objectstack/spec": minor
+"@objectstack/plugin-security": minor
+---
+
+feat(security): permission-set package provenance + declared-permission seeding (ADR-0086 P1)
+
+Packages now ship working default access for their own objects, with a
+machine-checkable metadata↔config boundary:
+
+- **Spec (ADR-0086 D3)**: `PermissionSetSchema.packageId` (owning package for
+  a package-shipped set; absent = env-authored) and per-record provenance
+  `managedBy: 'package' | 'platform' | 'user'` on the existing
+  metadata-persistence axis. Persisted on `sys_permission_set` as
+  `package_id` / `managed_by` (new columns + `package_id` index).
+- **Seeding (ADR-0086 D5)**: new `bootstrapDeclaredPermissions` — the sibling
+  of `bootstrapDeclaredRoles` — materializes `stack.permissions` into
+  `sys_permission_set` at boot with `managed_by:'package'` + `package_id`.
+  Idempotent and upgrade-aware: rows the seeder owns are re-seeded to the
+  shipped declaration on every boot; rows owned by a different package are
+  refused loudly; env-authored `platform`/`user`/legacy rows are never
+  clobbered. Closes the ADR-0078 inert-metadata violation for
+  `stack.permissions` (declared sets were runtime-enforced but never
+  materialized — invisible to the admin surface, uninstall undefined).
+- Conformance matrix row `declarative-permission-seeding` (ADR-0056 D10) +
+  dogfood proof pin the behavior so it cannot regress to inert.

.changeset/permset-resolve-observability.md

@@ -0,0 +1,13 @@
+---
+"@objectstack/plugin-security": patch
+---
+
+fix(security): surface swallowed permission-set resolution failures (#2565)
+
+`PermissionEvaluator.resolvePermissionSets` swallowed metadata `list()` and
+`sys_permission_set` dbLoader failures silently — fail-closed (unresolvable
+sets grant nothing), but a transient DB error made custom permission sets
+vanish with no trace, leaving the resulting 403s undiagnosable. The evaluator
+now accepts an optional `{ logger }` and emits one `warn` per failed source,
+naming the unresolved permission sets and the error. SecurityPlugin wires its
+plugin logger into both call sites. Resolution behavior is byte-identical.

.changeset/require-auth-secure-by-default.md

@@ -0,0 +1,45 @@
+---
+"@objectstack/spec": major
+"@objectstack/rest": major
+"@objectstack/verify": patch
+"@objectstack/cli": patch
+---
+
+feat(security)!: `api.requireAuth` now defaults to `true` — anonymous access to the data API is denied by default (ADR-0056 D2 flip)
+
+**BREAKING.** The global `requireAuth` default flipped FROM `false` TO `true`
+(`RestApiConfigSchema.requireAuth` in `@objectstack/spec`, mirrored by
+`RestServer.normalizeConfig` in `@objectstack/rest`). Anonymous requests to
+the `/data/*` CRUD + batch endpoints are now rejected with HTTP 401 unless the
+deployment explicitly opts out. (Scope note: this gate covers the REST
+`/data/*` surface — the metadata read/write endpoints and the dispatcher
+GraphQL route have their own pre-existing anonymous posture, tracked
+separately; this flip does not change them.)
+
+**Migration (one line):** a deployment that intentionally serves data publicly
+(demo / playground / kiosk) sets the flag on the stack config — now a declared
+`ObjectStackDefinitionSchema.api` field, so it survives `defineStack` strict
+parsing (previously an undeclared top-level `api` key was silently stripped):
+
+```ts
+export default defineStack({
+  // …
+  api: { requireAuth: false },
+});
+```
+
+The REST plugin logs a boot warning for the explicit opt-out so a fail-open
+posture is always visible. A misplaced `api.requireAuth` at the plugin level
+(one nesting short) is now also called out with a boot warning instead of
+being silently ignored.
+
+**What keeps working with no action:**
+
+- **Share links** — validate their token, then read under a system context.
+- **Public forms** — self-authorizing via the declaration-derived
+  `publicFormGrant` (create + read-back on the declared target object only);
+  no `guest_portal` profile needed.
+- **Control plane** — `/auth`, `/health`, `/discovery` are exempt.
+- **`objectstack serve` with an auth-less stack** — the CLI passes an explicit
+  `requireAuth: false` for stacks whose tier set has no `auth` (nothing could
+  authenticate against them), with the boot warning.