Merge remote-tracking branch 'origin/main' into claude/plugin-boot-logs-visibility-12kkwh

# Conflicts:
#	scripts/check-wildcard-fallthrough.mjs

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/discovery-metadata-slot-computed.md

@@ -0,0 +1,18 @@
+---
+'@objectstack/metadata-protocol': patch
+'@objectstack/runtime': patch
+---
+
+Both discovery builders now compute the `metadata` service entry from the implementation that fills the slot, instead of hardcoding opposite verdicts for it (#4089).
+
+`metadata` sat in a "kernel-provided (always available)" block above the loop that reads `__serviceInfo`, hardcoded separately in each builder — and the two disagreed about the same slot:
+
+- `@objectstack/runtime`'s dispatcher declared it permanently `status: 'degraded'` with `message: 'In-memory registry; DB persistence pending'`, so a stack with `MetadataPlugin` and a real `sys_metadata` table was still reported as having no persistence.
+- `@objectstack/metadata-protocol` declared the same slot permanently `status: 'available'`, so the kernel's in-memory fallback (`createMemoryMetadata`, auto-registered when no metadata plugin is present) read exactly like a persisted registry — the `__serviceInfo` marker #4058 gave it went unread here.
+
+Both now read the registered service's `__serviceInfo` (via `readServiceSelfInfo`) and report what it declares:
+
+- kernel in-memory fallback, or plugin-dev's dev registry → `status: 'degraded'` plus that implementation's own `message`, which names what is missing and what to install.
+- `MetadataPlugin` (or any implementation carrying no marker) → `status: 'available'` with no message.
+
+`handlerReady: true` is now stated unconditionally on both sides: it answers "is `/api/v1/meta` mounted?", and that route is served by the protocol whichever implementation occupies the slot — a degraded service in it does not unmount the route. Nothing about routing, gating, or dispatch changes; consumers that treat `status` as a capability claim (AI agents, the console) simply stop being told two different things by two hosts.

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

.changeset/serve-boots-without-artifact.md

@@ -0,0 +1,65 @@
+---
+'@objectstack/cli': patch
+'@objectstack/core': patch
+'@objectstack/metadata': patch
+'@objectstack/runtime': patch
+---
+
+fix(cli,core,metadata,runtime): `os serve` boots with no compiled artifact — the platform does not need an application to start (#4085)
+
+The artifact (`dist/objectstack.json`) defines an **application**. ObjectStack is
+a development platform, so it has to start without one — but `os serve
+objectstack.config.ts` died during boot whenever the artifact was absent:
+
+```
+  Loading objectstack.config.ts...
+[StandaloneStack] artifact read FAILED: path='…/dist/objectstack.json' error=ENOENT…
+
+  ✗ Service 'manifest' is async - use await
+```
+
+Exit 1 — on a **known-good app** (`examples/app-todo` fails the same way with
+only its `dist/objectstack.json` moved aside), and on every freshly authored
+project between `os init` and its first `os compile`. The message named neither
+the missing artifact nor a fix, so it read as an internal kernel fault.
+
+Three separate faults, each of which alone was enough to refuse the boot:
+
+- **`serve` registered the config-derived `AppPlugin` before the stack's own
+  `plugins[]`.** Registration order *is* the kernel's init/start order, and that
+  slot sits ahead of `ObjectQLPlugin` (which registers `manifest`/`objectql`) and
+  `DefaultDatasourcePlugin` (which connects the database the app seeds through).
+  The wrap is now **appended** to `plugins[]`, the same slot
+  `createStandaloneStack` gives its artifact-derived `AppPlugin` — so config-boot
+  and artifact-boot share one plugin order. The artifact path never hit this,
+  which is exactly what made a plugin-**order** bug look artifact-related.
+
+- **`ctx.getService()` reported a never-registered service as "is async".**
+  `PluginLoader.getService` is an `async` method, so its return value is *always*
+  a Promise and its internal "not found" rejection can never surface
+  synchronously — the kernel read the answer off that Promise and told every
+  caller to `await` a service that did not exist, while the `not found` branch
+  below it was unreachable. It now decides from the registry: absent ⇒
+  `[Kernel] Service 'x' not found`, registered-but-uninstantiated ⇒ the unchanged
+  `Service 'x' is async - use await`. The same crash now reads
+  `[Kernel] Service 'manifest' not found`, which points at the layer that is
+  actually wrong.
+
+- **`MetadataPlugin` treated an absent `local-file` artifact as fatal.**
+  `createStandaloneStack` always points it at `dist/objectstack.json`, so a stack
+  with no app at all could not boot. A **missing** local artifact is now "nothing
+  compiled yet": it logs, starts empty, and leaves the artifact watcher armed, so
+  a later `os compile` hydrates the running server. The tolerance is
+  ENOENT-only — a malformed or unreadable artifact stays fatal — and
+  `bootstrap: 'artifact-only'` (sealed runtime, where the artifact *is* the
+  deployment) keeps failing loudly rather than silently serving an empty runtime.
+
+`[StandaloneStack] artifact read FAILED … ENOENT` is likewise no longer shouted
+at callers for whom "no artifact" is a healthy state; a present-but-unusable
+artifact keeps the loud warning.
+
+Pinned by an e2e pair that drives the real `os serve` with **no `os compile`
+anywhere**: an app defined only by `objectstack.config.ts` (asserting its object
+is in the started plugin set, not merely that boot survived) and a bare
+`export default {}` platform. The #4012 fixture drops the `os compile` this bug
+had forced on it.

content/docs/api/client-sdk.mdx

@@ -40,7 +40,11 @@ async function main() {
 
   // 2. Check available services
   console.log('Services:', discovery.services);
-  // → { metadata: { enabled: true, status: 'degraded' }, data: { enabled: true, status: 'available' }, auth: { enabled: false, ... } }
+  // → { metadata: { enabled: true, status: 'degraded', message: 'In-memory metadata registry — …' },
+  //     data: { enabled: true, status: 'available' }, auth: { enabled: false, ... } }
+  // `metadata` reports the implementation actually behind it: `degraded` plus a
+  // message naming what is missing while the kernel's in-memory fallback fills
+  // the slot, `available` once MetadataPlugin provides a persisted registry.
 
   // 3. Query data
   const tasks = await client.data.find('todo_task', {

content/docs/api/index.mdx

@@ -132,6 +132,8 @@ Returns the full discovery manifest.
 
 Disabled/uninstalled route keys (e.g. `auth`, `analytics`, `workflow`) are omitted from `routes` entirely rather than set to `null`; check `services` to tell "not installed" apart from "installed but not yet mounted here." The sample above shows a minimal install: `analytics` reports `unavailable` and advertises no route until `@objectstack/service-analytics` registers the engine — the dispatcher then also mounts `/api/v1/analytics/*` (the routes are capability-conditional; an uninstalled capability answers 404 for every method).
 
+`metadata` is reported from whatever implementation fills its slot, so the sample's `available` is the `MetadataPlugin` case (a persisted `sys_metadata` registry). A stack running the kernel's in-memory fallback instead reports `status: "degraded"` with a `message` naming what is missing and what to install. `handlerReady` is `true` either way: `/api/v1/meta` is served by the protocol, so the route is mounted whichever registry sits behind it.
+
 ### `GET /.well-known/objectstack`
 
 Served by the runtime dispatcher (`@objectstack/runtime`), not `@objectstack/rest` — its body is wrapped as `{ "data": { ... } }` and includes fields (`name`, `environment`, `features`, `locale`) that the `@objectstack/rest`-served `/api/v1` response above does not. The client SDK's `connect()` tries `/api/v1/discovery` first and falls back to this endpoint, unwrapping either `body.data` or the bare `body`.

content/docs/kernel/services-checklist.mdx

@@ -113,15 +113,19 @@ The metadata service is a **framework** — it works with an in-memory `SchemaRe
 
 ### Discovery: Per-Service Status
 
-The discovery endpoint returns a `services` map so clients know what is available:
+The discovery endpoint returns a `services` map so clients know what is available.
+The `metadata` entry is **computed from the implementation that fills the slot**, not
+fixed (#4089): a stack running the kernel's in-memory fallback reports `degraded` with
+that fallback's own message, while a stack with `MetadataPlugin` reports `available` and
+no message. Below is the former — the fallback case:
 
 ```json
 {
   "services": {
     "metadata": {
-      "enabled": true, "status": "degraded",
+      "enabled": true, "status": "degraded", "handlerReady": true,
       "route": "/api/v1/meta", "provider": "kernel",
-      "message": "In-memory registry; DB persistence pending"
+      "message": "In-memory metadata registry — real reads and writes, no persistence (lost on restart). Register MetadataPlugin for a persisted registry."
     },
     "data": {
       "enabled": true, "status": "available",

content/docs/releases/implementation-status.mdx

@@ -468,7 +468,7 @@ Implementation spans every layer of the platform. Core infrastructure, data mode
 | **Query Engine** | ⚠️ | Partial (depends on driver) |
 | **REST API** | ✅ | Yes |
 | **Client SDKs** | ✅ | Yes |
-| **Metadata System** | ⚠️ | Partial (in-memory only, DB persistence pending) |
+| **Metadata System** | ⚠️ | Partial (`sys_metadata` persistence via `MetadataPlugin`; without it the kernel's in-memory fallback fills the slot and discovery reports it `degraded`) |
 | **HTTP Caching** | ✅ | Yes |
 | **Testing Tools** | ✅ | Yes |
 | **UI Rendering** | ❌ | No |

docs/adr/0076-objectql-core-tiering.md

@@ -134,7 +134,7 @@ Decision: each capability plugin registers its routes as a **normalized handler*
 **Inventory of current fakes / mis-reports:**
 - `plugin-dev` registers ~8 dev stubs — `storage` / `search` / `automation` / `graphql` / `analytics` / `realtime` / `notification` / `ai` (they already carry a `_dev: true` marker that nothing respects). *(Update #4000: the `analytics` one is **gone** — after the fallback's retirement (#3891/#3989) it was the last thing refilling that slot, and refilling it re-created the retired shape in dev: the dispatcher gated on service presence, so the stub was called like an engine and answered 200 with fabricated rows. The remaining stubs are unchanged, and the class-wide question they raise is tracked separately — see conclusion 3 below.)* *(Update #4058 step 1: the blanket `_dev: true` is **gone** too. Every dev implementation now carries the standard `__serviceInfo`, classified in one reviewable table (`DEV_STUB_SELF_INFO`) by what it actually is — `degraded` for the ones that really work with reduced capability (`file-storage` / `search` / `metadata` / `workflow` / `realtime`, plus the wrapped kernel fallbacks), `stub` for the ones whose answer is fabricated (`ai` / `automation` / `notification` / `data` / `auth` / `security.*`). The single marker made those two indistinguishable and declared the working ones fake, which is why "adopt the dispatcher gate everywhere?" could not be answered. The gates themselves are untouched — that is #4058 step 2.)*
 - `ObjectQLPlugin` registers a ~66-line `analytics` **fallback** (the D10 note — deliberate, but it reports as fully available).
-- `http-dispatcher.ts` `svcAvailable` — the hardcode above.
+- `http-dispatcher.ts` `svcAvailable` — the hardcode above. *(Update #4089: `svcAvailable` respects the marker, but two entries never went through it at all — a "kernel-provided (always available)" block above the loop, hardcoded per builder and **contradicting itself across them**: the dispatcher declared `metadata` permanently `degraded` with "In-memory registry; DB persistence pending", while metadata-protocol declared the same slot permanently `available`. So one host called a `sys_metadata`-backed registry degraded and the other called the in-memory fallback fully real — the marker #4058 had just added to `createMemoryMetadata` went unread on both sides, because neither side read anything. Both now compute the slot from the registered implementation's `__serviceInfo` and agree; `handlerReady: true` stays unconditional on both, since `/api/v1/meta` is served by the protocol whichever implementation occupies the slot. `data` keeps its hardcode: ObjectQL is the only producer that ever fills it, and `ObjectQLPlugin` — which plugin-dev always loads as a child — registers the real engine, so plugin-dev's `data` stub is unreachable in a stack that has a discovery builder at all.)*
 - *(Added by #4058: the **kernel's own** fallbacks — `createMemoryCache` / `Queue` / `Job` / `I18n` / `Metadata`, auto-registered by ObjectKernel — were missing from this inventory and were the worst case in it: they carried `_fallback: true`, a marker **no** reader recognized (not even `readServiceSelfInfo`), so both discovery builders reported them as fully `available`. They now self-describe as `degraded` with `handlerReady: false` where no HTTP surface exists (`cache` / `queue` / `job`). The lone duck-typed consumer of `_fallback`/`_dev` — an i18n diagnostic in `app-plugin.ts` — reads `readServiceSelfInfo` instead.)*
 
 **Decision — honest capabilities:**