diff --git a/CHANGELOG.md b/CHANGELOG.md
index 56310bd..67937ca 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -23,6 +23,45 @@ skip versions are the composition of each intervening adjacent
 release's steps in order — no A-to-B path is pre-computed beyond
 that.
 
+## 0.46.2 — 2026-06-07
+
+**Patch — `SPEC.md` §22.4a contract amendment: entry metadata is
+collection-configured, not type-driven (doc-only).** Reframes the binding
+§22.4a "collection type" contract so a collection's entry **metadata schema**
+is **collection-configured** — a `fields:` schema declared in
+`.collection.yaml` plus per-entry `<slug>.meta.yaml` **sidecars** — rather than
+a frontmatter schema hard-wired to the collection's `type`. Item 3's
+**type-specific surfaces** (release planning for `specification`;
+scenario/coverage views for `bdd`) are **deferred** to a future design; the
+`bdd` coverage capability is recorded there as a future `ref`-field surface
+rendered as hyperlinks (never fusing corpora across collections). What `type`
+still selects is the entry-noun terminology (item 2, shipped v0.45.0) and the
+default `initial_state` / review posture (§22.4b–c).
+
+This is **SLICE-0** of the
+[Configurable Collection Metadata](./docs/design/2026-06-06-configurable-collection-metadata.md)
+design (§7.2) — the contract amendment that unblocks the build slices. It
+supersedes the [per-type-surfaces](./docs/design/2026-06-06-per-type-surfaces.md)
+draft (D11; banner already on that doc).
+
+**No operator action; no schema or behavior change.** Per-type frontmatter
+validation was never implemented — the engine treats every entry as markdown +
+frontmatter regardless of type — so amending the contract changes no runtime
+behavior, no migration, and no deployment config. Sidecar storage, the
+collection `fields:` schema, validation, and the metadata UI arrive in later
+slices (SLICE-1+).
+
+Changed:
+
+- **`SPEC.md` §22.4a** — reframed: `type` selects terminology + default
+  `initial_state`/review posture; entry metadata is collection-configured
+  (`fields:` + `<slug>.meta.yaml` sidecars); type surfaces deferred. The
+  `document`/`specification`/`bdd` bullets updated accordingly; a metadata
+  amendment blockquote records the supersession.
+- **`SPEC.md` §2 and §22 forward-pointers** — the two amendment blockquotes
+  that said "entry frontmatter schema is type-dependent" now read
+  "collection-configured, not type-driven (§22.4a, as amended)".
+
 ## 0.46.1 — 2026-06-06
 
 **Patch — migration 029 hardening for the §22.13 re-stamp aftermath.** Fixes a
diff --git a/SPEC.md b/SPEC.md
index 4679af0..3284f6a 100644
--- a/SPEC.md
+++ b/SPEC.md
@@ -121,9 +121,11 @@ live in the meta repo — they live in the app database (see §5).
 
 > **Three-tier amendment (v0.45.0 — see §22).** Slugs are unique **per
 > collection** (§22.4): `model/intro` and `specs/intro` coexist. The entry
-> frontmatter schema is **type-dependent** on the collection's `type`
-> (§22.4a) — `document` keeps the fields below; `specification` and `bdd`
-> add their type metadata. The §2.3 `RFC-NNNN` `max+1` allocation is
+> **metadata schema is collection-configured** (§22.4a, as amended by
+> v0.46.2) — each collection declares a `fields:` schema in its
+> `.collection.yaml` and stores per-entry values in a `<slug>.meta.yaml`
+> sidecar; the fields below are the `document` baseline, **not**
+> type-driven. The §2.3 `RFC-NNNN` `max+1` allocation is
 > **removed** (the slug is the identity); pre-change `id` values survive as
 > frozen legacy labels. New `active`-entry frontmatter: `unreviewed` (bool)
 > and the `reviewed_at` / `reviewed_by` provenance pair (§22.4c).
@@ -5125,39 +5127,67 @@ never used for routing or lookup. New entries are never assigned one.
 
 ### 22.4a Collection type
 
+> **Metadata amendment (v0.46.2 — Configurable Collection Metadata).** Item 1
+> below originally made the **entry metadata schema type-driven** — a
+> `document`/`specification`/`bdd` frontmatter schema baked into a per-type
+> module. That is **superseded**: entry metadata is **collection-configured**,
+> not type-driven. Each collection declares a `fields:` schema in its
+> `.collection.yaml`, and per-entry values live in a `<slug>.meta.yaml`
+> **sidecar** (the `.md` body stays pure prose; a parser reads the sidecar
+> else legacy top-of-doc frontmatter). See the
+> [Configurable Collection Metadata](./docs/design/2026-06-06-configurable-collection-metadata.md)
+> design, which supersedes the
+> [per-type-surfaces](./docs/design/2026-06-06-per-type-surfaces.md) draft
+> (D11). Item 3's **type-specific surfaces** (release planning for
+> `specification`; scenario/coverage views for `bdd`) are **deferred** to a
+> future design; the `bdd` **coverage** capability is recorded there as a
+> future `ref`-field surface that maps features to the spec entries they
+> verify **as hyperlinks**, honoring the §22 rule against fusing corpora
+> across collections. What `type` still selects is the **terminology** (item 2,
+> the entry noun, shipped v0.45.0) and the **default `initial_state` / review
+> posture** (§22.4b–c).
+
 Every collection declares a `type` in its `.collection.yaml` manifest
 (§22.2), chosen at creation and **immutable**: one of `document`,
 `specification`, or `bdd`. Type does not change the engine — every type uses
 the same content repo (§22.3), the same propose→branch→PR→discuss→graduate
-lifecycle (§§9–13), the same threads, flags, and chat. Type selects exactly
-three things:
+lifecycle (§§9–13), the same threads, flags, and chat. Type selects:
 
-1. the **entry frontmatter schema** the collection validates entries against (§2);
-2. the **terminology** the chrome uses for an entry (the §8.1 noun, catalog labels);
-3. the set of **type-specific surfaces** layered on top of the shared §7 catalog.
+1. the **terminology** the chrome uses for an entry (the §8.1 noun, catalog
+   labels) — the entry noun, shipped v0.45.0;
+2. the **default `initial_state`** a new entry lands in, and its review
+   posture (§22.4b, §22.4c).
 
-Type-specific behavior is implemented as a per-type module the framework
-selects on `collection.type`; the engine itself treats every entry as
-markdown + frontmatter regardless of type. `type` is an **open set** in shape
-— a future type is a new module plus a new allowed enum value, no schema
-rebuild. The type names and their behavior are framework concepts (like role
-names), not deployment content: a deployment picks which type each collection
-is, but does not define or rename types.
+Entry **metadata** is **not** selected by type — it is **collection-configured**
+(a `.collection.yaml` `fields:` schema + per-entry `<slug>.meta.yaml`
+sidecars; see the amendment above, the Configurable Collection Metadata
+design, and the §2 baseline). **Type-specific surfaces** layered on the shared
+§7 catalog are **deferred** to a future design.
+
+Type-specific behavior, where it exists, is implemented as a per-type module
+the framework selects on `collection.type`; the engine itself treats every
+entry as markdown + a metadata sidecar regardless of type. `type` is an
+**open set** in shape — a future type is a new module plus a new allowed enum
+value, no schema rebuild. The type names and their behavior are framework
+concepts (like role names), not deployment content: a deployment picks which
+type each collection is, but does not define or rename types.
 
 - **`document`** — long-form normative prose (OHM: a model of principles and
-  definitions). Frontmatter is the §2 baseline. No type-specific surfaces. The
-  §22.13 generated default collection is a `document` collection, so the N=1
-  case is unchanged.
+  definitions). Metadata is the §2 baseline; no collection-configured `fields:`
+  are required. The §22.13 generated default collection is a `document`
+  collection with no `fields:`, so the N=1 case is unchanged.
 - **`specification`** — a versioned technical specification (this framework's
-  own `SPEC.md` is the archetype). Frontmatter adds spec metadata (`version`,
-  lifecycle `status` of draft/active/superseded, `supersedes`). Type-specific
-  surface — **release planning:** group entries/changes into versioned
-  releases with a changelog + §20-style upgrade-steps per release.
+  own `SPEC.md` is the archetype). A deployment that wants spec metadata
+  (`version`, lifecycle `status` of draft/active/superseded, `supersedes`)
+  declares those as collection `fields:`. **Release planning** — grouping
+  entries into versioned releases with a changelog + §20-style upgrade-steps —
+  is a **deferred** type surface.
 - **`bdd`** — behavior-driven feature specs: each entry states a feature as
-  Given/When/Then scenarios with acceptance criteria. Frontmatter adds feature
-  metadata and an optional link to the `specification` entries a feature
-  verifies. Type-specific surface: a scenario/acceptance view and a coverage
-  view mapping features to the spec sections they exercise.
+  Given/When/Then scenarios with acceptance criteria. Feature metadata is
+  declared as collection `fields:`. The **scenario/acceptance view** and a
+  **coverage view** (mapping features to the spec entries they verify via a
+  future `ref` field, rendered as hyperlinks — never fusing corpora across
+  collections) are **deferred** type surfaces.
 
 ### 22.4b Initial state of a new entry
 
@@ -5400,10 +5430,12 @@ The single-corpus sections defer to §22; the load-bearing reinterpretations:
   a project's repo (§22.3). The bot and app-owned-authorization paragraphs are
   unchanged and now read org-wide.
 - **§2 Schema / §2.3 IDs.** Slugs are unique **per collection**; the entry
-  frontmatter schema is **type-dependent** (§22.4a). The `RFC-NNNN` `max+1`
-  allocation is **removed** — the slug is the identity (§22.4). New
-  `active`-entry fields: `unreviewed` (bool) and the `reviewed_at`/
-  `reviewed_by` provenance pair (§22.4c).
+  **metadata schema is collection-configured**, not type-driven (§22.4a, as
+  amended by v0.46.2) — a `.collection.yaml` `fields:` schema + per-entry
+  `<slug>.meta.yaml` sidecars. The `RFC-NNNN` `max+1` allocation is
+  **removed** — the slug is the identity (§22.4). New `active`-entry fields:
+  `unreviewed` (bool) and the `reviewed_at`/`reviewed_by` provenance pair
+  (§22.4c).
 - **§2.4 State machine.** The `(no entry) ─[idea-PR merged]→` transition
   targets the collection's `initial_state` (§22.4b); a new `active
   ─[mark-reviewed, Owner]→ active` self-transition clears the `unreviewed`
diff --git a/VERSION b/VERSION
index 620104d..43c125a 100644
--- a/VERSION
+++ b/VERSION
@@ -1 +1 @@
-0.46.1
+0.46.2
diff --git a/frontend/package.json b/frontend/package.json
index 47ec95a..4e1cc36 100644
--- a/frontend/package.json
+++ b/frontend/package.json
@@ -1,7 +1,7 @@
 {
   "name": "rfc-app-frontend",
   "private": true,
-  "version": "0.46.1",
+  "version": "0.46.2",
   "type": "module",
   "scripts": {
     "dev": "vite",