Component Taste and Review Gates

Modules 1 and 2 made the system legible: tokens that carry intent, and a DESIGN.md the agent loads at the start of every session. The result is that producing a plausible component now takes minutes. This module is about the consequence of that speed: the bottleneck moves from production to judgment, and if the team does not decide deliberately where judgment sits, components enter the system on momentum rather than on merit.

Frame the module around one division of labour. Some review work is mechanical — token usage, type safety, contrast, state coverage — and an agent can check its own output against it before a human ever looks. Some review work is taste — density, hierarchy, restraint, voice — and that has to stay with people, but it gets dramatically cheaper when the mechanical layer is already clean and the evidence is laid out in front of the reviewer.

Set expectations on scope. This module covers the gate for individual component changes and the intake pipeline for new component proposals. It does not cover system-wide audits or drift detection — that is Module 4 — and it does not cover the fully scheduled maintenance loop, which is Module 6. The gate built here is the unit those later modules reuse.

The word taste does a lot of work in design system conversations and most of it is unhelpful, because it gets used to mean both I have a standard I have not written down and I prefer it the other way. Operationally, taste in component review reduces to a handful of nameable dimensions. Density: agents trained on the public web default to airy, marketing-grade spacing, and a work tool usually wants the opposite. Hierarchy: whether the component's internal order matches the user's task order, which no linter can verify. Restraint: the strong default of generative tools is to add — another prop, another variant, another visual flourish — and the system's job is mostly to refuse. Voice: copy inside components drifts towards generic template language unless someone holds it to the product's register.

The reason to name the dimensions is not philosophical tidiness. A finding that says this feels off cannot be acted on by an agent, cannot be checked by the next reviewer, and cannot ever become a rule. A finding that says the summary row is denser than anything else in the system, reduce it to one line of metadata can be acted on, and after the second occurrence it can be written into DESIGN.md.

Be honest that the dimensions are judged, not measured. Two competent reviewers can disagree on density for a specific component. That is fine — the gate later in this module routes those disagreements to a named decision-maker rather than pretending a rule can settle them.

This table is the module's first learning objective in one view. The left column is everything that can be expressed as a checkable rule: every colour resolves to a token, every prop is typed, contrast meets AA, the required interaction states exist, the name follows the system's pattern. These checks are cheap to run, they run identically on every proposal, and an agent can run them on its own output before a human ever sees the work. The right column is the judgment work from the previous slide, plus the largest judgment of all: whether the component should exist in the system at all.

The two failure modes at the bottom deserve attention because they are the ones teams actually hit. On the mechanical side, the rules go stale — the token file moves, a new state becomes required — and the checks keep passing while the standard quietly drops. On the taste side, the failure is a reviewer enforcing personal preference as if it were a system standard, which erodes contributor trust faster than any backlog does. The cure for the first is owning the checks like code. The cure for the second is requiring that taste findings cite a dimension and, where one exists, the line of DESIGN.md they rest on.

The highlight line is the operating principle: humans should not spend review time catching hardcoded hex values, and scripts should not be allowed to block work on grounds they cannot actually evaluate.

This list is the concrete content of the left-hand column from the previous slide, and it doubles as a starting checklist participants can lift directly. The token audit is usually the highest-value single check for design systems: in the traced runs behind this course's articles, hardcoded values are the most common defect in unconstrained agent output, and they are also the defect a script catches with essentially no false positives. Type check, lint, and build catch the invented prop and the broken import — boring failures that waste reviewer goodwill when they reach a human.

State coverage is the check teams most often forget to make explicit. An agent asked for a card builds the happy path; the empty, loading, and error states only appear when something demands them. Making their existence a mechanical requirement — they must exist and render, even though their quality is still judged at taste review — moves a whole class of back-and-forth out of human review. The accessibility pass at this stage is the automatable layer: contrast, focus visibility, labels, target sizes. It is a floor, not a substitute for the deeper accessibility judgment that belongs to the system's standards.

The closing point matters for trust: the agent should report what it ran and what it fixed. A proposal that arrives saying token audit clean, axe clean, one contrast failure found and fixed on muted text reads very differently from one that arrives silent — and that self-report becomes part of the evidence the next gate consumes.

The evidence packet is the hinge of the whole gate, and it is also the part agents are genuinely good at producing. Capturing screenshots at fixed widths, enumerating states, listing the tokens consumed and the props exposed — this is mechanical assembly work that used to be the reason component reviews arrived half-documented. When the contributor is an agent, there is no excuse for a thin packet, because assembling it costs the agent minutes.

The overlap statement deserves emphasis because it is the cheapest component decision available: the one you do not build. Requiring every proposal to name the nearest existing components, and say specifically why they fall short, forces the comparison to happen before review rather than during it. In the contribution intake workflow this course draws on, overlap analysis is its own stage run by a dedicated agent, and the most common outcome across real backlogs is a redirect to an existing composition rather than a new component.

Fixed widths matter more than they look. Reviewing whatever viewport the contributor happened to capture makes findings impossible to compare across proposals; reviewing the same three widths every time makes density and hierarchy judgments consistent and makes regressions visible later. Make the entry requirement explicit and unapologetic: no packet, no review. Reviewers are the scarce resource the gate exists to protect.

Walk the diagram in order and name the owner of each step. The agent proposes the change on a branch, scoped to one component, and states the need it answers — a proposal that is only a diff is not yet a proposal. The agent then assembles the evidence packet from the previous slide. The automated checks are the first gate, and their failures loop straight back to the agent without consuming any human attention; that loop can run several times and nobody needs to care. Taste review is the human-led gate: density, hierarchy, restraint, and voice, judged against DESIGN.md rather than against the reviewer's mood, returned as findings with severity and evidence rather than as silent fixes.

The maintainer decision is deliberately separated from taste review. The reviewer recommends; the person accountable for the system's surface area decides, choosing between accept, accept with a narrowed scope, redirect to an existing composition, or decline — and records the reasoning in the packet so the decision survives staff turnover. On small teams the reviewer and the maintainer are the same person wearing two hats; keep the steps distinct anyway, because the reasoning record is what makes a decline land as governance rather than gatekeeping.

The dashed return edge is the slide's real argument. A gate that only filters is a cost centre. A gate that converts its recurring findings into rules and checks gets cheaper every round, which is where the next two slides go.

The previous slides covered changes to existing components. This one covers the harder case: a proposal for something new, which is where systems either grow by accretion or earn a reputation for saying no. The intake pipeline this course draws on runs in stages because each stage can end the process early. The overlap stage asks whether the need is already covered by an existing component, a documented composition, or a small extension — and a proposal that is fully covered exits with a worked example attached instead of a new component. The impact stage estimates adoption from the codebase rather than from the proposer's optimism: it counts the surfaces where the need already shows up as workarounds or hand-rolled near-duplicates, with file paths as evidence. The spec stage drafts what the thing would actually be — props, tokens, states, accessibility requirements — as something for the maintainers to argue with.

When the contributor is an agent, two things change. First, the proposal template matters more, because agents are happy to present a finished component as if its existence were the argument; requiring the need to be stated separately from the solution keeps the overlap check honest. Second, the volume goes up — an agent can raise five proposals in the time a product team raised one — which is exactly why the investigation has to be cheap and consistent rather than heroic.

Keep the boundary clear: the pipeline produces evidence and a labelled recommendation. Strategic scope, brand disputes, and appetite for new surface area belong to the people accountable for the system. A council that rubber-stamps the recommendation has outsourced governance to a script.

This format comes straight from the critique discipline covered in the school's article on critique loops, applied to component review. Severity does the triage: blocker, important, polish, and question are enough levels, and more taxonomy makes findings harder to act on, not easier. The named dimension and the DESIGN.md citation are what keep taste review from degrading into preference — if the reviewer cannot say which dimension the objection sits on, the finding goes into the question bucket and triggers a conversation rather than a demand.

The evidence field points at the packet from slide five: a specific screenshot, a specific width, a measurable difference against the existing system. The impact field forces the finding to be about users or about system coherence rather than about the reviewer's eye. The smallest-change field is what makes the finding actionable by an agent in the revision pass — and constrains that pass, because the standing rule is that revision addresses approved findings only and does not introduce a new direction.

The last line, decision needed, is the routing field. Most findings are covered by an existing rule or an established pattern and need no escalation. The ones that genuinely need a judgment call — this component wants a density the system has never allowed, do we want that — get routed to the maintainer explicitly instead of being settled by whoever reviewed the work that day.

This is the third learning objective and the part most teams skip, because closing the loop feels like extra work at exactly the moment the review is finished. The discipline is simple: when the same finding appears a second time, it stops being feedback and becomes a candidate for promotion, and the only question is where it goes. Findings that can be checked mechanically and apply everywhere become automated checks — that is how the token audit and the required-states check were born in most systems that have them. Findings that are judged but stable — the product prefers compact data surfaces, no decorative gradients, no new hues without approval — become lines in DESIGN.md or named anti-patterns, which gives future reviewers something to cite and future agents something to load.

Procedural feedback — the steps a good component proposal goes through, the order of a review — belongs in a skill, because skills load on demand and do not tax every session's context. Constraints that only matter for some file types belong in path-scoped rules. And feedback that is still contested is not a rule yet: writing a disputed preference into the harness just moves the argument into the files, where it is harder to see. Route those to the maintainer as an explicit system decision.

The payoff compounds. Each promotion removes a class of finding from future human review, which is what makes the gate sustainable as agent-driven contribution volume grows. This is also the seam into Module 6: a system that maintains itself is mostly a system that has been promoting its review feedback for long enough.

Walk the table as a timeline and keep drawing attention to who is spending time at each row. The proposal and the evidence packet cost the agent minutes and a human nothing. The automated checks caught exactly the defects they exist to catch — hardcoded values and a missing focus state — and the fix loop ran without a person in it. The interesting work starts at taste review: the density finding cited the table pattern, the restraint finding flagged a trend prop the impact evidence did not justify, and the voice finding pointed at an empty state that read like a template. All three went back as findings with severity and evidence, not as silent fixes, because silent fixes teach the agent nothing and leave no record.

The revision pass was scoped to the three approved findings only — that constraint is what keeps revision from becoming a second, unreviewed design pass. The maintainer accepted with a narrowed scope, deferring the trend display until more than one surface needs it, and recorded that reasoning in the packet, which is what makes the deferral revisitable rather than forgotten.

The last row is the one to linger on. The density rule was promoted to DESIGN.md and the empty-state voice guidance went into the review skill, so neither finding can recur as a surprise. This trace is a composite drawn from the contribution-intake and critique workflows behind this course rather than a single logged session — the shape and the division of labour are what to take from it, not the exact counts.

After three slides about encoding feedback into rules, this slide is the counterweight, and it matters because the failure mode of an enthusiastic gate-builder is trying to automate judgments that should stay deliberate. Scope is the clearest case: whether the system should expand into data visualisation, or absorb a pattern one team loves and the brand team distrusts, is a strategic call about surface area and maintenance appetite. No accumulation of intake packets settles it; they only inform it.

Taste shifts are subtler. The rules and DESIGN.md lines built through this module encode the system's current taste, and that is their value — but it also means that changing taste requires changing the rules deliberately, not letting individual reviews drift away from them one exception at a time. Treat a taste change like a breaking change: proposed, discussed, decided, and then encoded. Deprecations and breaking changes belong on this list because their cost lands on other teams; an agent can find every usage and draft every migration note, but the decision to spend other people's time is accountability, not analysis.

The last bullet is about how declines land. The contribution-intake case studies behind this course are consistent on this: a no that arrives quickly, with the reasoning recorded and an alternative attached — usually a composition of existing components — reads as help. A no that arrives slowly and unexplained reads as gatekeeping, and contributors stop proposing, which is its own kind of system failure.

The exercise produces the artifact this module has been circling: a one-page review gate for the participant's own system. Steer people towards honesty in the first step — most teams discover that several checks they think of as automated are actually a vigilant person, and that gap is the cheapest improvement available, because those checks already have an unwritten specification.

The evidence packet definition should be concrete enough to hand to an agent: exact widths, the named states, what the proposal text must contain. The taste dimensions step usually exposes gaps in DESIGN.md — a dimension the team judges constantly but has never written down — and that is a fine outcome; the missing line is homework from Module 2. Naming the decision-maker matters even on a team of three, because the difference between a recommendation and a decision is what makes declines defensible later.

The fifth step is deliberately small: three recurring findings, each assigned a destination — check, DESIGN.md line, skill, path-scoped rule, or escalation to a system decision. If participants do nothing else from this module, that habit, repeated on a schedule, is the part that compounds. Suggest they keep the page; Module 4 reuses it as the standard an audit measures the existing codebase against, and Module 6 turns it into the approval step of the maintenance loop.

Recap by walking the gate one more time, but frame it as a division of labour rather than a process diagram: agents produce and assemble evidence, automation enforces the floor, reviewers judge the named taste dimensions, the maintainer owns the decision, and the loop closes by promoting recurring findings into rules. The module's three objectives map onto that directly — the mechanical-versus-taste split, the gate design with its evidence requirements, and the promotion habit that stops feedback recurring.

The bridge to Module 4 is a change of direction, not of standard. This module pointed the gate at new work arriving into the system. Module 4 points the same standard backwards, at everything already in the codebase: the components built before the gate existed, the tokens that drifted, the patterns that were copied and mutated. The review gate checklist from the exercise becomes the audit's measuring stick, and the evidence discipline — no finding without a file, a line, and a screenshot — carries over unchanged.

If time allows, close on the cultural point: the gate's purpose is not to make contribution harder, it is to make the system's no fast, explained, and accompanied by an alternative — which is what keeps people and agents proposing.