Merge remote-tracking branch 'origin/main' into claude/os-serve-artifact-startup-cgy5aq

Author: claude

.changeset/adapter-hono-auth-wildcard-yields.md

@@ -0,0 +1,28 @@
+---
+"@objectstack/adapter-hono": patch
+---
+
+fix(adapters/hono): the auth wildcard yields paths the auth service does not own (#4117)
+
+`app.all('${prefix}/auth/*')` claimed a whole namespace and was **terminal**: it
+returned the auth service's response unconditionally, including better-auth's 404
+for a path it does not implement, and the legacy `handleAuth` bridge's own
+`handled: false` 404. That is the #4088 shape, found by #4116's enumeration after
+manual greps had missed it.
+
+A 404 from better-auth, or `handled: false` from the dispatcher, now means "not
+this mount's path" and the handler yields. The predicate is the dispatcher's own
+`handled` flag wherever one exists — an explicit ownership answer beats inferring
+one from a status; only the better-auth hand-off lacks such a flag, and there the
+404 is the signal, as in #4092.
+
+**What changes on the wire.** An unowned path under `${prefix}/auth/*` used to get
+a 404 built by this mount. It now continues to the `${prefix}/*` dispatcher
+catch-all and gets a real, gate-carrying `dispatch()` attempt, so a domain handler
+registered for such a path becomes reachable — this adapter's actual extension
+mechanism. When nothing anywhere claims the path the reply is still the same
+enveloped `{ success: false, error: { message: 'Not Found', code: 404 } }`. Paths
+the auth service does own are untouched, and a 401/403 from it is never treated as
+a disclaimer of ownership.
+
+No configuration changes and no new routes.

.changeset/dev-plugin-security-stubs-and-prod-guard.md

@@ -0,0 +1,16 @@
+---
+'@objectstack/plugin-dev': minor
+'@objectstack/plugin-hono-server': patch
+---
+
+Retire the three `security.*` dev stubs, and refuse to load `plugin-dev` under `NODE_ENV=production` (#4093).
+
+**The security stubs are gone.** When `@objectstack/plugin-security` was not installed, `plugin-dev` filled its three slots with fakes that inverted the decision each stood in for: `security.permissions.checkObjectPermission()` returned `true` for everything, `security.rls.compileFilter()` returned `null` so no row-level predicate was applied, and `security.fieldMasker.maskResults()` returned rows unmasked. ADR-0076 D12's rule — learned from the analytics shim it retired in #3891 — is that a fallback may degrade features, **never security semantics**; `packages/spec/src/contracts/security-service.ts` says the same from the other side (these three are plugin-security's internals, and access-narrowing answers must fail CLOSED). Since `plugin-dev` loads SecurityPlugin through the same optional dynamic import as everything else, the package merely being absent was enough to swap real RBAC/RLS/masking for allow-all behind a single `warn` line.
+
+The slots now stay empty — which is what production has without SecurityPlugin, and what every consumer already handles — and the boot log states plainly that RBAC, row-level security and field masking are not being enforced.
+
+**`plugin-dev` now refuses to initialize under `NODE_ENV=production`.** It is a published package that registers development fakes for every unclaimed core service slot, including ones that report success for work they never did, and it had no environment check of its own: an `objectstack.config.ts` carrying `new DevPlugin()` into a production deploy got the whole fake slate with only a boot log to say so. `init()` now throws there. Set `OS_ALLOW_DEV_PLUGIN=1` if you deliberately want the dev slate under a production `NODE_ENV` (a staging box mimicking prod, a smoke test that pins the variable).
+
+FROM → TO: a stack that relied on the dev security stubs was not being protected by them — it was being told everything was allowed. Install `@objectstack/plugin-security` to enforce RBAC/RLS/masking, or accept the empty slots (unchanged behaviour on every path that already handled an absent SecurityPlugin). A production process that loaded `plugin-dev` must now either drop it and install the real services, or opt in explicitly with `OS_ALLOW_DEV_PLUGIN=1`.
+
+Also: `plugin-hono-server`'s `/auth/me/permissions` resolves `security.permissions` and `metadata` through the same guarded lookup its three sibling lookups already used. An unregistered slot makes `getService` throw, which previously landed in the outer catch — the same fail-open response body, but logged as "/auth/me/permissions failed" on every console navigation instead of taking the deliberate `!evaluator` branch.

.changeset/discovery-data-slot-computed.md

@@ -0,0 +1,15 @@
+---
+'@objectstack/metadata-protocol': patch
+'@objectstack/runtime': patch
+---
+
+Both discovery builders now derive the `data` service entry from the implementation in the slot, closing the hardcoded "kernel-provided" block (#4130).
+
+#4089 computed `metadata`; `data` was the last entry that judged itself, reporting `status: 'available'` and `handlerReady: true` unconditionally. That was true — but by a convention in a different package, not by anything either builder checked: ObjectQL is the slot's only producer, and plugin-dev always loads `ObjectQLPlugin` as a child, so plugin-dev's `data` stub (`find()` returns `[]`, `insert()` mints an id and stores nothing) never reaches the slot. A second producer, or a trimmed dev config, and the hardcode starts lying about the platform's most load-bearing capability.
+
+Both builders now read the registered service's `__serviceInfo`:
+
+- a real engine carries no marker ⇒ `available` + `handlerReady: true`, byte-identical to the hardcode it replaces (verified on a real kernel boot);
+- a self-declared stub ⇒ its own `status` and `message`, with `handlerReady: false` (the default for `stub`), so a consumer that gates on `handlerReady` stops treating an empty query engine as a real one.
+
+`handlerReady` is derived here rather than pinned `true` as it is for `metadata`, because the two routes differ: `/meta` answers from the protocol whatever fills the metadata slot, while `/data` needs the `protocol` or an objectql-shaped service and 503s without them — and the only stack where a stub occupies the `data` slot is one where ObjectQL never registered. No routing, gating or dispatch behavior changes: the `data` domain resolves its engine directly and never consulted this slot.

.changeset/docs-audit-changelog-non-exclusion.md

@@ -0,0 +1,18 @@
+---
+---
+
+Docs only — no package changes, nothing to release.
+
+Records why `packages/*/CHANGELOG.md` is **not** added to the docs-drift mapper's test-file
+exclusion (#4091). It reads as the obvious next narrowing and is a provable no-op:
+
+- `chore: version packages` is the only PR class that mass-touches those files, and it runs
+  no GitHub Actions — `changesets/action` opens it with the repo `GITHUB_TOKEN`, which by
+  design triggers no workflow runs. Measured on #3910: one check run, Vercel's own app.
+  The version bump is still verified, just post-merge (`ci.yml` / `lint.yml` on `push: main`,
+  and `release.yml` gates publish on a green build).
+- `changeset version` writes `package.json` beside every `CHANGELOG.md` it appends to
+  (45 vs 46 on page 1 of #3910's diff), so excluding the CHANGELOGs would leave the derived
+  package-root set bit-identical anyway.
+
+Written down so the next reader does not spend a PR rediscovering it as a gap.

.changeset/i18n-view-coverage.md

@@ -0,0 +1,37 @@
+---
+"@objectstack/cli": patch
+"@objectstack/spec": patch
+---
+
+fix(cli,spec): i18n coverage actually gates view labels — the `defineView()` container is no longer skipped (#4123)
+
+`i18n/missing-view` had **zero producers**. `collectExpectedEntries` recognized
+two view shapes and the compiled config is neither:
+
+1. **Object-nested `listViews`** — objects do not carry `listViews` once
+   compiled (0 across every example).
+2. **Top-level named views** — guarded by `if (!view?.name) continue`.
+
+`defineView()` emits the aggregated View **container**, `{ list, listViews,
+formViews }`, which per spec (`view.zod.ts`) has **no top-level `name`**: it is
+keyed implicitly by its target object at `list.data.object`, exactly as
+objectql's `resolveMetadataItemName` resolves it. So the guard rejected the
+spec's own container shape, and with it every view in every example — 64 view
+strings that the ratchet reported as fully covered.
+
+The walker now handles the container, emitting under the same
+`objects.<object>._views.<view>.*` convention the runtime resolver reads
+(`viewLabel` in `@object-ui/i18n`) and the shipped platform bundles already
+carry. An unnamed default `list` resolves under `_views.list`, matching the
+console's `primary.name || 'list'`. `formViews` stays uncovered — form views
+have no counterpart in that resolver convention, so keys for them would expect
+translations nothing reads.
+
+`StrictObjectTranslation` gains the `_views` slot that
+`ObjectTranslationDataSchema` already permits. Without it, `satisfies
+StrictObjectTranslation<…>` rejects the very translations the gate now asks
+for.
+
+The newly surfaced strings are **translated, not ratcheted** (the precedent set
+when the object-less action landed): `check-i18n-coverage` stays at 665 with
+none new.

.changeset/inline-action-schema.md

@@ -0,0 +1,69 @@
+---
+"@objectstack/spec": minor
+---
+
+feat(spec): `element:button` declares the action it executes — `InlineActionSchema` (objectui#2997)
+
+`element:button`'s renderer reads `properties.action` and dispatches it through
+the `ActionRunner`; that prop is the only thing making a standalone-page button
+interactive. `ElementButtonPropsSchema` declared `label`, `variant`, `size`,
+`icon`, `iconPosition`, `disabled`, `aria` — and no `action`.
+
+It is being authored anyway. cloud's `service-tenant` pages carry five
+declaration sites across the billing and pricing funnel (`pricing`, `welcome`,
+`billing-cancel` ×2, `billing-success`), each `{ type: 'navigation', to: … }`,
+each cast `as any` to get past the type system.
+
+**An undeclared prop is stripped, not ignored.**
+`ElementButtonPropsSchema.safeParse({ label, action })` returned `success: true`
+with no `action` in `data` — a non-strict `z.object` drops unknown keys. That is
+harmless only because page block `properties` are still
+`z.record(z.string(), z.unknown())`, so this schema never runs on a real page
+save. The moment anyone tightens `properties` to validate against
+`ComponentPropsMap` — an obvious hardening — every one of those buttons loses its
+action at save, with a green parse. Declaring the prop is what defuses it.
+
+**`InlineActionSchema` is derived, not a new dialect.** `ActionSchema` is
+`z.object(…).refine(…).refine(…)`, so `.pick()` is unavailable on the exported
+schema — the object half is now a factory both schemas build from, which keeps
+`lazySchema`'s deferral (the fields are constructed on first use of whichever
+schema is touched, not at module load). The inline schema `.pick()`s the twelve
+fields `element:button` actually forwards to the runner, so their `describe()`
+text, the `ActionType` vocabulary and the `target`-required refinement are shared
+rather than restated.
+
+`name` and `label` are optional, which is the substantive difference:
+`ActionSchema` requires both because a registry entry needs an identity and a
+menu label, and an inline action has neither — the button already has its own
+`label`, and requiring `action.label` too would mean writing it twice. Everything
+that only means something for a registered action — `objectName`, `locations`,
+`order`, `ai`, `requiredPermissions`, `visible`/`disabled`, `resultDialog` — is
+excluded, as are `icon`/`variant` (the button has its own) and `body` (a page
+button running an inline sandboxed script is a separate decision). A declared
+field no renderer reads is the failure this schema exists to stop, so widen it
+when a renderer widens, not before.
+
+**`navigation` and `to` become normalizing aliases, not new members.**
+`normalizeInlineAction` folds `type: 'navigation'` → `'url'` and `to` → `target`
+on parse, the `VIEW_FILTER_OPERATOR_ALIASES` pattern. So cloud's existing pages
+keep validating unchanged while parse output is always canonical, and the aliases
+get a `retiredKey` tombstone once the producers are migrated. `url` is also the
+*better* target: the runner's `url` path has `${param.X}` / `${ctx.X}`
+interpolation, `apiBase` promotion for `/api/…` paths and popup-blocker-safe
+`openIn`, none of which its `navigation` path has.
+
+Deliberately **not** done: promoting `navigation` into `ActionType` as a bare
+member, which was considered and declined in #4070. It would name the type while
+leaving the prop undeclared and `to` homeless — half a fix, and a permanent
+synonym in a vocabulary whose members cannot be removed later.
+
+Nothing is narrowed. `ui/InlineAction` and `ui/ElementButtonProps:action` are
+additions to every generated surface; no accepted value stops being accepted, so
+no stored page metadata changes meaning.
+
+Verified: 16 new tests — the derivation is asserted from both directions
+(the inline field set is exactly the documented twelve; every one of them
+round-trips through `ActionSchema`; every registry-only concern is absent; every
+`ActionType` member is inline-authorable), and the fold is pinned against the
+literal shape cloud writes. Full `@objectstack/spec` suite **7038 tests across
+271 files**, `tsc --noEmit`, and all twelve `check:*` gates, clean.

.changeset/metadata-form-zod-reconciliation.md

@@ -0,0 +1,79 @@
+---
+"@objectstack/spec": minor
+"@objectstack/rest": patch
+"@objectstack/platform-objects": patch
+---
+
+fix(spec,rest): the metadata forms save what they show — form ↔ Zod reconciliation (#3786)
+
+Every entry in `METADATA_FORM_REGISTRY` is a hand-written `defineForm` layout
+that names keys of a Zod schema it never imports: two descriptions of one key
+set, a comment asking the next author to keep them in step, and nothing that
+fails when they don't. #3786 asked for a sweep of that shape across the repo.
+**Four of the seventeen forms had already drifted, every one of them silently.**
+
+The silence is the point. `ObjectSchema` / `FieldSchema` are deliberately not
+`.strict()`, so a key the schema does not declare parses clean and is stripped
+on the way to storage — the same ADR-0104 failure class the `field.zod.ts`
+prune tombstone already describes in prose. An admin toggled a switch in
+Studio, got no error, and the value never landed.
+
+**What was broken, from an author's seat:**
+
+- **Object → Capabilities.** The block bound to `capabilities`; the
+  `ObjectSchema` key is `enable`. All seven toggles (Track history, Searchable,
+  API enabled, Files, Feeds, Activities, Clone) saved nothing.
+- **Object → Fields.** The inline column grid offered 16 keys `FieldSchema` has
+  never declared. `PII`, `Encrypted`, `Indexed`, `Immutable`, `Filterable`,
+  `Placeholder`, `Validation`/`Error message` and `Starting number` were
+  controls with no storage behind them at all; the rest named keys the schema
+  had **renamed** and the form never followed:
+  `referenceFilter` → `lookupFilters`, `cascadeDelete` → `deleteBehavior`
+  (a three-way enum, not a boolean), `formula` → `expression`,
+  `displayFormat` → `autonumberFormat`, and the flat `summaryType` /
+  `summaryField` pair → the single `summaryOperations` object, which also
+  restores the `object` key the flat pair had no slot for. Roll-ups authored in
+  that grid saved nothing.
+- **Report → Advanced.** `aria` and `performance` were pruned from
+  `ReportSchema` by #3496; the form kept rendering both.
+- **Hook / Action → Body.** `memoryMb` was unauthorable — named in
+  `hook.form.ts`'s own doc comment, absent from the list beneath it.
+- **Page → Interface.** `interfaceConfig.sort` was unauthorable, so a page's
+  default sort order could not be set in Studio at all.
+
+**No authored metadata changes and nothing you can write is removed.** These
+were UI controls that never persisted; every corrected key is one `FieldSchema`
+/ `ObjectSchema` already accepted. Metadata authored in YAML/TS was always
+validated against the real schema and is unaffected. If you had been filling
+those Studio controls expecting them to stick, they now either work (the
+renamed five) or are gone rather than lying to you.
+
+The metadata-form translation bundles are derived from the registry, so all
+four locales are regenerated. Worth naming what they contained: translated
+labels, in four languages, for switches that saved nothing — the drift had
+propagated into a generated artifact and been dutifully translated there.
+
+**The mechanism.** `metadata-form-zod-reconciliation.test.ts` walks every
+registered form and reconciles it against `getMetadataTypeSchema()`. The two
+directions are deliberately asymmetric: **form-only** (a control whose value is
+discarded) is always a defect and cannot be excused, because no design wants
+one; **zod-only** is ledgerable with a reason, for a deprecated key held back
+from new authoring or a curated quick-add subset that defers to a fuller
+editor. Ledger entries are checked for non-vacuity and for still resolving on
+both sides, per the #4045 / #4040 discipline. Verified by mutation — re-adding
+a stripped key, dropping a covered key, and offering a ledgered omission each
+turn the gate red.
+
+**New export: `TRANSLATABLE_METADATA_TYPES`** (`@objectstack/spec/system`), the
+set of metadata types whose labels `translateMetadataDocument` localizes,
+derived from its dispatch table rather than restated. `@objectstack/rest` had
+been carrying a hand-copied literal set under a "keep in sync with the type
+dispatch" comment; it now reads this instead. Registering a translator in spec
+reaches the REST boundary with nothing else to remember — the second list is
+deleted rather than checked, which is the better half of derive-or-gate.
+
+Also corrected: `ActionAiCategorySchema`'s comment claimed it mirrored
+`ToolCategorySchema` in `ai/tool.zod` and told the next author to update both
+sides — but #3896 deleted `ToolCategorySchema` along with the inert
+`tool.category` key it typed. The instruction had been pointing at a source
+that no longer exists. The enum is canonical now and says so.

content/docs/plugins/packages.mdx

@@ -344,10 +344,10 @@ All services implement contracts from `@objectstack/spec/contracts` and are kern
 
 ### @objectstack/plugin-dev
 
-**Developer Tools Plugin** — Development-time utilities.
+**Local Development Plugin** — one-line local stack: wires ObjectQL, the in-memory driver, auth, security, the HTTP server, REST and the dispatcher, then fills any still-unclaimed core service slot with an in-memory dev implementation.
 
-- **Features**: Metadata validation, schema introspection, debugging tools
-- **When to use**: Development and debugging
+- **Features**: Composes the real plugins above; registers dev implementations for unclaimed slots, each declaring what kind of fake it is (`__serviceInfo` — `degraded` when it really does the work in memory, `stub` when it fabricates). Slots that would fabricate an answer over HTTP get no implementation at all: `analytics` and the three `security.*` handles stay empty on purpose.
+- **When to use**: Local development only. **`init()` throws under `NODE_ENV=production`** — set `OS_ALLOW_DEV_PLUGIN=1` only if you deliberately want the dev slate under a production `NODE_ENV`.
 - **README**: [View README](https://github.com/objectstack-ai/objectstack/blob/main/packages/plugins/plugin-dev/README.md)
 
 ### @objectstack/plugin-approvals