# Approach

## Start from the markup

Design the DOM before the API. If the element you would have written by hand is
a `details`, the component is a `details`. Props exist to arrange markup, not to
hide it.

## Measure instead of reasoning

Where a question has a number attached, get the number. Whether a rebuild is
redundant is a hash comparison, not an argument. Whether a role belongs on an
element is a count of how many appear on a page. Whether a colour passes is a
pixel read back off a canvas with the whole ancestor stack composited onto it.

Reasoning is what you do when measurement is impossible, not when it is
inconvenient.

## Verify the thing that ships

A green build proves the code compiles. It proves nothing about what a browser
does with the output. After a component change, open the page.

The corollary is that verification has to be *hostile*: run the check against a
case whose answer you already know, and if it agrees, then trust it on the cases
you do not.

## Let the gate do the blocking

A check you read with your eyes is a report. If it is meant to block, the exit
code has to be the condition.

## Write down what you decided not to do

A decision that produces no diff leaves no trace. The next review will reach the
same question, spend the same time, and may answer it differently. Where it
matters, a test pins the current shape and names the reason in its title.

## Prefer the boring failure

Given two designs, prefer the one whose failure is loud. A class name assembled
from a template literal produces no CSS and no error — the markup looks correct
and the element is simply unstyled. A literal string that is wrong produces a
rule you can see in the stylesheet.