-
Notifications
You must be signed in to change notification settings - Fork 0
Draft Rubric Integrated Loop
Status: CANDIDATE, not in force. This is the B arm of a vibe test against the current loop (Reviewer Brief + Critic Rules). Do not point a cron at it. If it wins, it replaces STEP 2 of the brief and a handful of critic rules move to the rubric.
The critic has grown its own opinions about component quality — ossification, effects, DOM ownership, perf tests. The Component Audit Rubric already owns most of that, better and in more detail: C1 justifies every effect, C13 wants stable hook returns, C6/C7 cover observers, P38 covers escape hatches, P10 says converge rather than diverge.
Two sources of truth for the same judgement is the problem. The split this arm proposes:
| owns | |
|---|---|
| The rubric | what good CODE is. True with no reviewer in the room. |
| The critic | what good REVIEW is. Meaningless outside a review. |
"A theme target ossifies the system" is rubric. "Approve summaries are ≤30 words" is critic. The test: could a contributor read it before writing the PR? Then it belongs in the rubric, where they and the nightly auditor can find it.
frame → RUBRIC selects the checks → run them → draft → CRITIC grades the draft
The rubric is private to the reviewer. Nothing from it reaches the comment: no check ids, no grades, no tiers, no severities. R12c stands — every finding is translated into what it costs a real person.
Straight from the rubric's own "Reviewing a change". Never the whole checklist.
| Change | The bar |
|---|---|
| Bug fix | Evidence it was broken and is fixed — red→green test, or before/after frames. Plus a code-smell pass. Evidence real, fix clean ⇒ approve and move on. |
| New feature | Every automatable check, then judgment on what the change touches. |
| New component → core | Full audit, visual evidence. |
| New component → lab | Deliberately lax. Flag for the promotion gate rather than blocking. |
(a) Syntactic triggers — the rubric's existing table. What the diff literally
touches: themeProps → §2 · aria-* → §1 · useEffect → §7 · a physical CSS
property → §9. Use it as written.
(b) Semantic triggers — NEW, and the reason this arm exists. What the change means, which is not always visible in what it touches:
| The change's nature | Also run |
|---|---|
| Behavior changes | §1 accessibility — AT dispatch, focus order, keyboard path · §7 code health · §4 state coverage |
| API surface changes | §3 · §8 docs and changeset · §2 if the prop is style-driving |
| A theme target is added | §2 · §5b screenshots · §3 — a target is public surface |
| Anything rendered moves | §5b · §9 RTL · §10 responsive · §1 contrast |
| O(N) work on a hot flow | §6 evidence · §7 · a perf test |
Why this table is the point. #5018
changed dismissal behavior. Its real defect was an accessibility one — a screen
reader dispatches a bare click with no pointerdown, and the guard swallowed
it. Nothing in the diff said "aria"; the syntactic table fired §1 only because
six unrelated lines happened to match. A behavior change should reach §1 by
design, not by luck.
Findings the current critic carries that have no rubric home. If this arm wins, they move — as rubric checks with ids, not critic prose.
| Gap | Nearest existing | Why it does not reach |
|---|---|---|
| New surface must solve a CLASS of problems, not one case | P38 | P38 asks for "a demonstrated use case" — one callsite. The bar is the class, because a single-case addition becomes the precedent for the next one and the surface ratchets shut. |
| A new theme target is permanent surface | §2's 5/5 anchor | The anchor says "justified by a named consumer need", but it is prose in a grading anchor, so nothing can cite it. Targets look free — no runtime behavior — so nobody counts them. |
| O(N) work on a hot flow needs a perf test | §6 | §6 has no perf row at all. The repo already has the convention: *-perf.test.tsx, colocated, build-excluded, asserting render counts, never milliseconds — a wall-clock budget is flaky on CI and gets deleted within a month. |
The cost of adding them: each is a new FIX/BLOCK-capable check, so under the rubric's versioning rule that is a minor bump and existing §2, §3 and §6 scores stop being comparable. The semantic trigger table is routing only — a patch, no re-audits.
Everything about the review as an artifact: length caps, voice, the presentation slots, staleness (R14d), anchor verification (R14e), attribution, recording (R17), contributor policy (R1g), order of consequence (R1b).
What it loses: R1g-surface, R18, R18b, R18c — the component-quality rules — which become rubric checks the reviewer cites privately.
Same PR, both arms, blind. A wins if the split costs nothing; B wins if routing through the rubric finds what A missed.
| A — current | B — this draft | |
|---|---|---|
| reads | Brief + Critic | Brief + Critic + Rubric with both trigger tables |
| judged on | did it find the real defect · did it invent one · did the presentation survive |