@@ -0,0 +1,16 @@
+---
+"@objectstack/spec": patch
+---
+
+`liveness/rest_api.json` — `RestApiConfigSchema` (the `api` sub-object of `RestServerConfig`) is now a governed liveness type. Every key it declares carries a status, the evidence that settles it and the producer that populates it: 12 `live`, 14 `dead` across 26 classified properties (#14640).
+
+The ledgers ship inside this package (`files[]` includes `liveness`), so this is one new file in the tarball plus two changed ones — `liveness/README.md`'s index row and heading, and the generated `liveness/state-counts.md`. Nothing else moves: no schema accepts or refuses anything it did not before, no export changes, no runtime behaviour changes, and no CLI author warning is added (no entry is marked `authorWarn` — a `RestServerConfig` is not part of a stack, so the lint that emits those warnings could never reach one).
+
+- **Why it was ungoverned, and why that reason has expired.** #14369 enrolled four of the five `RestServerConfig` sub-objects and deliberately left this one out: the `api` block's consumption seam was then still validate-only, so a census would have recorded a half that was about to move. That half has moved — `RestServer.normalizeConfig` now builds the `api` block from `parseDeclaredApiConfig`'s output rather than discarding it, and the change is released, not in flight. The fence was re-tested before anything here was written; it no longer holds, so the sub-object is measured on the settled seam. The stale sentence is corrected in the gate source and in the four README rows that repeated it.
+- **The ledger is `rest_api.json`, never `api.json`.** That name was already taken, by a different `api`: `ApiEndpointSchema`, the registered `api` metadata type, with real consumers in the matcher, executor, policy chain and mapping layer. One spelling, two unrelated meanings inside this package — filing here would have published one file's measurement under the other's name. The gate's own override paragraph now carries that fence too.
+- **Twelve keys are `live`.** `version`, `basePath` and `apiPath` become the prefix of every route the server mounts, through `getApiBasePath` — read via a whole-block destructure rather than a property access, which is why the census for the dead keys swept destructuring shapes with their own control instead of relying on a property-access pattern. The eight `enable*` switches each gate a mount, and most of them also the discovery document's capability block, so mount and advertisement move together. `projectResolution` decides whether the unscoped legacy routes mount alongside the scoped ones.
+- **Fourteen are `dead`**: the `requireAuth` tombstone, and the two declared containers `documentation` and `responseFormat`, which `normalizeConfig` copies into `this.config.api` and nothing reads back. So `api.responseFormat.envelope: false` unwraps no response, and `api.documentation.title` retitles no served OpenAPI document — that document's `info` block is written by this package's own `build-openapi.ts` and passed through untouched by the REST layer.
+- **`documentation` is drilled**, including its nested `contact` and `license` objects, so the change adds no row to the undrilled-container baseline. Those five leaf verdicts rest on a structural argument rather than a spelling sweep, which is stated in each row: `name` / `url` / `email` are too generic to grep, but the container that holds them is unreachable from outside `RestServer` — the field is `private` and `NormalizedRestServerConfig` is module-local with no `export` — so nothing can read a member of an object nothing reads.
+- **The two dead containers deliberately do not share one verdict.** This file records status; it decides nothing. The enforce-or-remove call per key (ADR-0049) is a follow-up on the human floor, and the two differ: `documentation`'s members are OpenAPI `info` fields whose enforce route collides with a recorded ownership decision, while `responseFormat`'s enforce route would mean making the response envelope configurable — a larger claim.
+
+For an embedder, the practical read: every key that changes what this server mounts or advertises is marked `live` and evidenced; `documentation` and `responseFormat` are accepted, validated and normalized, and change nothing.
@@ -0,0 +1,12 @@
+---
+"@objectstack/spec": patch
+---
+
+`src/migrations/entries/README.md` — the ADR-0087 entry authoring rules now record that an entry's prose is scanned as source **twice**, and that the rule is never to spell a shape a live textual ratchet matches (#15130).
+
+This file ships inside the package (`files[]` carries `README.md`, which matches at every depth — measured with `npm pack --dry-run`: 277 files, this one among them), so the rules an entry author reads are these.
+
+- **The mechanism is the counter-intuitive part.** Every string an entry declares — `surface`, `replacement`, `reason`, `acceptanceCriteria` — is concatenated verbatim into the generated `src/migrations/registry.ts`, which is ordinary `.ts`. A repo-wide textual scan therefore reads the same sentence once in the entry file and once in the registry. The tree's one code/prose separator masks **comments** and leaves **string literals** intact by design, so a quoted example is code to every scan built on it, and prose in this package can turn **another package's** test red.
+- **The rule is the broad one, and the parenthesis is its instance.** A rule worded as "quote a retired call site without its parentheses" would make counter-examples of entries that spell a parenthesised call and are green — they go unmatched only because no live ratchet enumerates *those* methods, which is a fact about today's ratchets rather than a licence. What an author controls is not spelling a shape some ratchet matches; the guidance is to name the surface rather than spell a call of it.
+
+No schema, no export and no authorable key moves; the three existing rules in that section are unchanged and no entry was edited.
@@ -0,0 +1,15 @@
+---
+"@objectstack/plugin-dev": patch
+---
+
+`DevPlugin`'s boot posture on a malformed stack is now written down: dev boot tolerates and reports; refusing belongs to the production doors, which are not uniform about it (#15292).
+
+Clause-②: no
+
+No behaviour changes. `DevPlugin` already degraded a stack the platform would reject, and the posture — ruled, not invented here — is that it should: the contract refuses at the production door, while the developer's inner loop tolerates incomplete input and never hides it. Metadata that is incomplete halfway through an edit is the normal state of a project under active development, so refusing at dev boot would charge the cost to the only user group this plugin exists for, for a consistency the production doors already provide. What was missing was the written posture and one load-bearing correction to it.
+
+- **The two branches are not one defect handled two ways.** `new AppPlugin(stack)` reads `manifest.id` / `manifest.name` and nothing else, so a malformed `packages[]` passes the constructor untouched and is refused one branch later: `AppPlugin.init()`'s LAST statement hands the bundle to the `manifest` service, whose `register()` calls `resolveArtifactPackageOrder` unguarded, and `DevPlugin`'s child-`init()` loop degrades that refusal to an `error` line. The lazy `collections` getter is not on that path at all — it is not read during `init()`, and its first read is in `AppPlugin.start()`, where it reaches the same refusal on the same bytes. Both in-file comments that named the constructor as the stack's parse door (*"a malformed stack throws HERE"*, and §3b's *"twenty lines above, `new AppPlugin(...)` parses the SAME object"*) overclaim for that reason, and both are corrected in this PR.
+- **The two malformations are exact complements, measured with a lit control.** An app payload with no `manifest.id` / `manifest.name` throws from the constructor (a bare `Error`, no ADR-0112 `code` / `status`) and is invisible to the package-list parse; a `packages[]` entry that is not a package entry (ADR-0130 D4) is invisible to the constructor and refused by the parse as `INVALID_ARTIFACT_PACKAGE_ENTRY` / `422`. A stack carrying neither is silent on both. So a clean boot past one branch is no evidence about the other — which is why the division is now documented rather than left to be re-derived.
+- **Tolerating is not hiding.** The posture's second half is that a boot which skipped something is never byte-identical to a healthy one: a silent degrade lets an author, or a coding agent, read "it started" as "I wrote it correctly".
+- **The production doors are not uniform, and every carrier now says so.** A malformed `packages[]` fails `ObjectStackDefinitionSchema` — `packages: z.array(ArtifactPackageSchema)`, the SAME entry schema the runtime parse uses — and both `os validate` and `os build` parse the lowered stack against it and exit 1 (`validate.ts` step 2; `compile.ts` step 3). `lowerCallables` passes a non-`{ manifest: object }` entry through untouched, so the verdict transfers to what the CLI actually parses. An app payload with no `manifest.id` parses green at BOTH: `os validate` reports it only as the structural advisory *"Missing manifest.id — required for deployment"*, which fails only under `--strict` (both exit faces read one `warnings` list — the `--json` ternary and the text face's `if (flags.strict)` block), and `os compile` "never computes them at all" in its own words, so `os build` is silent on it. The flat "`os validate` / build / publish refuse" overstated BOTH doors for that half, and `publish` is simply not a door this card measured, so it is no longer claimed.
+- **What ships**: the `DevPlugin` docblock (which reaches the published `dist/*.d.ts`), the two in-file comments named above, and `content/docs/plugins/packages.mdx`, plus a test pinning the posture, its division and the init-time path the refusal actually takes. The wording of the malformed-metadata diagnostic itself is deliberately not pinned — that text is a sibling change.
@@ -0,0 +1,26 @@
+---
+'@objectstack/spec': minor
+---
+
+`IMetadataService` declares `loadManyKeyed?` — the keyed plural loader read now sits on the contract beside its two declared siblings `loadMany?` and `loadDiagnosed?` (#15385).
+
+Clause-②: yes
+
+A verb family lives whole on the contract. `MetadataManager.loadManyKeyed(type)` shipped as a public member with no declaration on the interface its siblings are declared on, so the one cross-package caller — the ObjectQL governance audit — narrowed the service slot with a **local structural type** written beside the call site. That local type is deleted in the same change and the call site reads the contract.
+
+The vocabulary is not new: `loadManyKeyed`, and the `{ name, data }` item shape it answers with, are already published on `MetadataLoader`, which declares the same member as optional over its own loader-local options type. What this adds is the member's place on `IMetadataService`.
+
+```ts
+loadManyKeyed?<T = unknown>(
+    type: string,
+    options?: Record<string, unknown>,
+): Promise<Array<{ name: string; data: T }>>;
+```
+
+**What it is for.** The key is a fact about the **store** — `register()`'s own `name` argument — and it travels *beside* `data`, never folded into it, so `data` stays byte-identical to what the unkeyed plural read would return and no consumer ever sees a synthesised `name`. An item whose stored body has no top-level `name` is legal and deliberate (an org customization container's identity is the object it targets), and such an item has no identity at all in a plural read keyed by `data.name` — it is dropped, silently. That is why this is a second member rather than a widened return type on the existing one.
+
+**What moves for consumers.** Nothing breaks. The member is **optional**, like `loadMany?` and `loadDiagnosed?` beside it, so every existing `IMetadataService` implementation still satisfies the contract unchanged and the `typeof … === 'function'` probe stays the way a caller asks for it. What changes is that a caller no longer has to declare the shape itself to stay typed: intersecting the slot with a hand-written structural type was the only way to reach the member without erasing the lookup to `any`, and that workaround is now unnecessary. `MetadataManager`, which already implements the member, needs no edit.
+
+This is the position `loadDiagnosed` was in before #4127 batch 4 declared it, and it is resolved the same way. Ruled in decision batch #123 item 5 (2026-09-12), maintainer verbatim: 「同意」.
+
+`content/docs/kernel/contracts/metadata-service.mdx` gains the member in the same change.
@@ -0,0 +1,98 @@
+---
+'@objectstack/spec': minor
+---
+
+feat(spec)!: retire the plugin-security scan-result surface — zero consumers after the scanner retirement (#15932)
+
+**BREAKING** — the plugin-security scan-result family is removed. ADR-0049
+enforce-or-remove; maintainer ruling 2026-09-07 (director seat, decision batch
+#65), adopted verbatim 「同意」.
+
+This is the second half of the scanner retirement — issue 14919, a number since
+deleted from the board, landed as PR #15930. That change retired `PluginSecurityScanner`,
+the `@objectstack/core` class that shipped as a security control and returned
+`status: "passed"` for every plugin it was ever handed. The **schemas** it fed
+survived it — and that scanner's type-only import was their only importer of any
+kind, so the family went from one type-only importer to **zero consumers** while
+staying fully published: 27 authorable rows on `authorable-surface/kernel.json`,
+six `api-surface` exports, two authorable defaults and two json-schema manifest
+keys, with no `.parse` or `.safeParse` site against either schema anywhere. An
+author could write any of it, be accepted, and get nothing. That is the
+declared-not-enforced shape, one layer out from the class removed for the same
+reason. "Declare an owner to enforce" was refused by name: it would rebuild the
+scanner just retired.
+
+### FROM → TO
+
+| removed | what to write instead |
+| --- | --- |
+| `KernelSecurityScanResult`, `KernelSecurityScanResultParsed`, `KernelSecurityScanResultSchema` (exports) | nothing — delete the import. No replacement type exists. |
+| `KernelSecurityVulnerability`, `KernelSecurityVulnerabilityParsed`, `KernelSecurityVulnerabilitySchema` (exports) | nothing — delete the import. No replacement type exists. |
+| `PluginSecurityManifest.scanResults` | delete the key |
+| `PluginSecurityManifest.vulnerabilities` | delete the key |
+| `PluginQualityMetrics.securityScan` | delete the key |
+
+**The one-line fix: delete the keys and every import of the two types.** Plugin
+security scanning is not a platform capability and there is no replacement
+schema. What the platform does still enforce is unchanged: `permissions` and
+`sandbox` on the same `PluginSecurityManifest`, and artifact provenance through
+`verifyPluginArtifactIntegrity` and the plugin signature verifier — which tell
+you an artifact is the one its publisher signed, and never that it is safe. For
+dependency vulnerabilities use the tools built for it against your own project
+(`npm audit` / `pnpm audit`, Dependabot, the GitHub Advisory Database, OSV), and
+treat an unaudited third-party plugin as untrusted code. A publisher who used
+`scanResults` to advertise diligence keeps the surviving `securityContact` and
+`vulnerabilityDisclosure` blocks, which are contact terms rather than a verdict.
+
+⚠️ Runtime behaviour is deliberately **unchanged**. Nothing ever read any of
+these keys, so deleting one removes no check that was running. A consumer that
+gated on `securityScan.passed === true` was gating on nothing — the remediation
+is to audit with a real tool, not to find a replacement key.
+
+### The retirement kit
+
+- The two **defs** leave the build whole — `RETIRED_DEFS_BY_MAJOR[18]`
+  (`kernel/KernelSecurityScanResult`, `kernel/KernelSecurityVulnerability`) —
+  because nothing parses them, so there is no author a tombstone could reach.
+- The three **authorable keys** are `retiredKey()` tombstones registered in
+  `RETIRED_KEYS_BY_MAJOR[18]`. Neither carrying shape is `.strict()`, so a bare
+  deletion would strip an authored key in silence (ADR-0104): the tombstone is
+  audible in both channels — `tsc` (input type `never`) and the parse, which
+  raises the prescription itself.
+- **No D2 conversion.** A plugin security manifest and a plugin registry entry
+  are package artifacts a publisher ships, never stack collection members and
+  never stored `sys_metadata` rows, so the chain has no seam that would see one
+  — the disposition the sibling `kernel-plugin-security-durations-unit-in-key`
+  entry already records for this same manifest. The D3 semantic entry
+  `plugin-security-scan-result-surface-retired` carries the judgement.
+- `PluginSecurityManifest.vulnerabilities` is a **forced consequence**, not one
+  of the four names the ruling listed: it was the last authorable referent of
+  `KernelSecurityVulnerability` and could not outlive the def.
+- **No deprecation window** (maintainer 2026-08-27: 「项目在创业阶段，用户也很少，短期不考虑渐进」).
+
+⚠️ **The out-of-repo consumer population is NOT MEASURED.** `@objectstack/spec`
+is published, so this is breaking for consumers no download, dependent or source
+telemetry was consulted for — exactly as that retirement's own changeset says of its
+three exports. That was an input to the ruling, not a reason to soften the removal.
+
+⛔ **Untouched, and not checked:** the marketplace `'scanning'` status
+(`marketplace.zod.ts`). The ruling made it conditional on a producer grep of
+`objectstack-ai/cloud`, and that repository was not reachable from the session
+that executed this card, so it stays exactly as it is and its absence from this
+diff is not evidence about it.
+
+⚠️ **The two members the ruling paired with it were ALREADY GONE** — measured on
+this tree, not assumed. The incident `'malware'` type was a member of
+`system/IncidentCategory`, and the whole incident-response family was retired by
+#15513 (maintainer ruling 2026-09-05 — two days *before* the 2026-09-07 ruling
+that made it conditional). `marketplace-admin.zod.ts` was deleted outright with
+the cloud subpath (#16526). Both files return zero tree entries here, against a
+lit control where `'scanning'` still returns a live declaration. So the
+conditional question is **one** enum member wide, not three.
+
+`Clause-②: yes (narrowing)` — a published surface is removed: six exports leave
+the built `.d.ts` and three authorable keys stop being writable, so the accept
+set a consumer writes against narrows. Nothing is widened and nothing is
+renamed. Contract-review tier.
+
+<!-- adr-0087: registered plugin-security-scan-result-surface-retired -->