@@ -60,7 +60,7 @@
           "status": "dead",
           "verifiedAt": "2026-10-19",
           "evidenceScope": "cross-repo",
-          "note": "REMOVED 2026-10-19 (#24640, ADR-0049 enforce-or-remove; maintainer ruling C, record 6278975049, pulled into 18.0 by record 6279033298) — tombstoned at the schema (retiredKey carries the prescription; authoring it is a tsc error and a parse error at every list-view door built from the shape: ListViewSchema, ObjectListViewSchema, the flattened overlay arm and a page list-view node's properties; a react page's props are an opaque source string no door parses against the shape, a stated boundary) and dropped from stored rows and sources by the protocol-18 view-list-filterable-fields-removed conversion, which never rewrites it to userFilters.fields. The entry stays because retiredKey keeps the key in the walked shape (the rls.priority precedent); for a curated end-user filter bar declare `userFilters`, and the Filter panel offers every field the user may read (field read security decides; a field the object marks `hidden: true` is not offered) — no per-view whitelist replaces it. The prior `live` verdict (audit L15) named the wrong reader for the declared meaning: the spec described the key as the `userFilters.fields` shorthand, and UserFilters never read it. RE-MEASURED 2026-10-19 before removal, at objectui's pinned sha 4016370a: the one reader was packages/plugin-list/src/ListView.tsx (the `filterFields` memo), which used it as the Filter panel's field WHITELIST (the fields Add filter offers, a hidden field included when named), fed by packages/app-shell/src/views/ObjectView.tsx (`filterableFields: viewDef.filterableFields ?? listSchema.filterableFields`) and packages/plugin-view/src/ObjectView.tsx; a page list-view node withheld it (packages/plugin-list/src/index.tsx). The ruling is that the platform carries no per-view Filter-panel whitelist, so that reader is unreachable from authored metadata once this lands and leaves in objectui's own follow-up; objectui's types mirror declares the key locally (types/src/objectql.ts) and its zod twin reads the spec shape's member by reference, so the tombstone flows in on the pin bump. In this repo: zero authorings in examples/, packages/apps, packages/platform-objects, packages/create-objectstack or packages/qa — CONTROL on the same instrument: `userFilters` 7 hits in examples/, `searchableFields` 2. The Studio view form's input left with the key."
+          "note": "REMOVED 2026-10-19 (#24640, ADR-0049 enforce-or-remove; maintainer ruling C, record 6278975049, pulled into 18.0 by record 6279033298) — tombstoned at the schema (retiredKey carries the prescription; authoring it is a tsc error and a parse error at every list-view door built from the shape: ListViewSchema, ObjectListViewSchema, the flattened overlay arm and a page list-view node's properties; a react page's props are an opaque source string no door parses against the shape, a stated boundary) and dropped from stored rows and sources by the protocol-18 view-list-filterable-fields-removed conversion, which never rewrites it to userFilters.fields. The entry stays because retiredKey keeps the key in the walked shape (the rls.priority precedent); for a curated end-user filter bar declare `userFilters`, and the Filter panel offers every field the user may read (field read security decides; a field the object marks `hidden: true` is not offered) — no per-view whitelist replaces it. The prior `live` verdict (audit L15) named the wrong reader for the declared meaning: the spec described the key as the `userFilters.fields` shorthand, and UserFilters never read it. RE-MEASURED 2026-10-19 before removal, at objectui's pinned sha 4016370a and re-read 2026-10-20 at the moved pin 12dc7b47 (same readers, same lines within a few): the one reader was packages/plugin-list/src/ListView.tsx (the `filterFields` memo), which used it as the Filter panel's field WHITELIST (the fields Add filter offers, a hidden field included when named), fed by packages/app-shell/src/views/ObjectView.tsx (`filterableFields: viewDef.filterableFields ?? listSchema.filterableFields`) and packages/plugin-view/src/ObjectView.tsx; a page list-view node withheld it (packages/plugin-list/src/index.tsx). The ruling is that the platform carries no per-view Filter-panel whitelist, so that reader is unreachable from authored metadata once this lands and leaves in objectui's own follow-up; objectui's types mirror declares the key locally (types/src/objectql.ts) and its zod twin reads the spec shape's member by reference, so the tombstone flows in on the pin bump. In this repo: zero authorings in examples/, packages/apps, packages/platform-objects, packages/create-objectstack or packages/qa — CONTROL on the same instrument: `userFilters` 7 hits in examples/, `searchableFields` 2. The Studio view form's input left with the key."
         },
         "resizable": {
           "status": "live",
 
@@ -11,7 +11,8 @@
  * "Field names available for filtering", while its one renderer — objectui's
  * `ListView` (the `filterFields` memo), fed by the app shell's object view —
  * read it as the Filter panel's field WHITELIST. Measured at objectui's pinned
- * sha `4016370a`, with the reader named on the ledger row
+ * sha `4016370a` and re-read at the moved pin `12dc7b47`, with the reader named
+ * on the ledger row
  * (`liveness/view.json`, `/props/list/children/filterableFields`). The ruling is
  * that the platform carries no per-view Filter-panel whitelist, so the key
  * retires and NO key replaces it.