tooling(spec): stand up the strict-refusal ledger and ratchet it — option B, scheduled after the strict face that made it premature #8346

Priced by the domain:spec @ objectui seat on #7935. ⛔ Filed unassigned, not claiming.

Blocked-by: #8345

Once the strict face exists (#8345), the programme needs an instrument that makes its redness converge instead of being re-argued. This card turns scripts/measure-strict-authoring-face.mjs from a throwaway into a ledger with a ratchet.

Why this card exists, and why NOT before #8345

#7581's implementing dev left the script's disposition as an open question and recommended keeping it unwired (option A), explicitly rejecting a report-only CI job (option B) with this reasoning, quoted verbatim from os-dev-report 5556504179:

B is capability expansion with no puller: #5250 rules the gate comes after the strict face, so a report-only job today prints numbers nobody is acting on yet

⇒ That objection is exact, and it expires the moment the strict face lands. This card is option B, scheduled after the condition that made it premature is gone. ⛔ It is still not the JSON-fence gate — that is the devx half, and it judges documents; this judges the programme's convergence.

What it does

• A ledger of the current refusal set, keyed by document and component type, checked in.
• A gate that fails when the count goes up, and requires the ledger updated when it goes down. ⛔ Not a gate that fails on the existing 176 / 184 — that would red the repo on day one for debt this card does not own.
• Every repair that lands through the cards that already own it (see below) drains rows.

The numbers it starts from, and their concentration

At origin/main 5505aec1a07c26976d160a39f152a48b088cfbb4: 184 of 2099 nodes refused, 176 of 553 documents refused after the recursion-point redirect. The distribution is what makes this tractable rather than a 184-item sprint:

• form.showSubmit alone is 76 occurrences — one key, 41% of the node refusals, with 40 renderer-source mentions (24 catalog entries fail safeValidateSchema because the Zod mirror names a key its renderer never reads (8 components) #6939-shaped: the renderer reads it, the schema does not declare it).
• The dashboard widgets[] cluster (value 16, icon 15, trend 15, trendValue 15) is one owner.
• 60 of 94 component types seen are strict-CLEAN.
• Seven keys have zero renderer mentions — columnSpan, fullWidth, itemTemplate, rowSpan, summary_field, summary_object, totalItems — which is finding(components): button-group implements no selection, and never wires the per-button onClick / disabled it declares — the catalog authors 29 keys nothing reads #7077-shaped (nothing reads them; retire rather than declare).

⚠️ Renderer-mention counts are a coarse triage hint, not a verdict — a common word hits unrelated code and a computed accessor hits zero. The probe's own controls at this commit: className 13409 (must be positive), zzzFabricatedControlKey 0 (must be zero).

⛔ What this card does NOT own — the repairs already have owners

Filing one big repair card here would duplicate live cards. The ledger's rows point at them:

• 24 catalog entries fail safeValidateSchema because the Zod mirror names a key its renderer never reads (8 components) #6939 — the 8 ruled declaration-repair components (all groups landed; the card stays open on filter-builder declares one operator vocabulary and renders another: the mirror refuses every dropdown id but three, and every id it accepts but three draws a blank trigger #7561's unruled residual).
• finding(types): 39 handler keys a registered renderer READS are declared by no arm — accepted and KEPT by the passthrough, on main today #7804 — 39 handler keys a registered renderer reads that no arm declares, with its own KNOWN_UNDECLARED_READS exemption ledger already draining.
• finding(types): the ChartSchema axis-config object dialect is undeclared and passes through unchecked - liveness read owed before declare-or-retire #7690 (ChartSchema axis config) · types: ObjectKanbanSchema and ObjectCalendarSchema declare no filter (and no sort) — the fourth face of the key #7712 declares everywhere else #8174 (filter / sort on the two object-* schemas) · [finding] NamedListView declares 64 members; the object-view renderer reads 21 names off a named view — all 21 declared, 43 declared-and-unread (figures re-derived with the TypeScript parser) #7924 / Decision: what value type should ObjectViewSchema.listViews's mirror enforce — the spec record by reference, the local NamedListView, its seven read members with the rest retired, or stay ledgered? #7928 (NamedListView) · finding(types): ObjectKanbanSchema requires objectName on both faces while the renderer reads an undeclared inline data ahead of the fetch — the record-source ladder class (#7313) on a fourth view schema #7780 (ObjectKanban inline data) · finding(docs,plugin-calendar): the README's two object-calendar examples author six keys and the renderer reads none of them — object for objectName, startField for startDateField, plus fields / node-level dataSource #7925 (six doc-authored object-calendar keys) · finding(plugin-grid/types): a bare exportOptions array on a directly-authored object-grid node passes the zod mirror unvalidated and silently degrades to the csv/json default #7762 · types: does 'kanban-enhanced' get a declared arm? — its registration reads onColumnToggle / enableVirtualScrolling / virtualScrollThreshold and no schema in @object-ui/types declares the type at all (split from #7742) #8257 · plugin-gantt / types: derive the ten gantt extension keys from GanttConfigSchema.shape now that the spec declares them — retire GANTT_CONFIG_EXTENSION_KEYS and GanttConfigExtensionFields, and the prose that still calls the spec loose (objectstack#15469 follow-up) #7845 · finding(app-shell): the view-level groupBy ObjectView writes into options.kanban is a third lane spelling the spec's KanbanConfigSchema refuses by name #8213 · finding(types,components,docs): page.actions has no reader on the page node — the array renders nothing and leaks onto the wrapper element as actions="[object Object]", while guide/layout.md teaches it in three passages #7926.

Appetite — one dispatched card, one PR

In scope: the ledger file, the ratchet gate, its wiring into the existing lint workflow, and a non-vacuity control (a planted refusal must red the gate; removing it must green it).

⛔ Falls off the back: repairing anything in the ledger; the JSON-fence gate; any change to the strict face itself.

Refs: #5250 · #7935 · #7581 / PR #7916 · #7077 · #6939 · #7804

Generated by Claude Code