break and ship

Two verbs test against reality instead of taste. break asks what one component does with real data. ship asks what the whole app does in its first hour.

break

Reach for it when a component renders data it didn't write: names, emails, counts, labels from an API. Especially before you trust a list.

$ /design-engineering break components/MemberRow.tsx

Its posture is unusual: adversary, then judge. It builds the worst case, shows you, and stops. It never fixes until you name which breaks to fix.

1. Map

   Every value the component renders, with its source and its real limit from the schema, the API type or the form's maxLength. No limit anywhere is written down as "unbounded", which is already a finding.

2. Build the worst case

   One fixture shaped like your demo data, every value plausible or at the real limit, failures spread across the first rows the way real data does. Plus Empty, One, and 1,000 rows if the list isn't paginated.

3. Wire a toggle

   A dev-only switch (Demo, Worst case, Empty, One, 1,000) that swaps the data at the data boundary, never by editing the markup. The choice lives in the address: ?data=worst.

4. Break it

   At the real width, at 320px, at the widest layout, at 200% zoom, and right-to-left if you ship it. It says which breaks it saw and which it inferred from CSS.

5. Report and stop

   Then waits.

What comes back:

Severity has three levels: Broken (unreadable, unreachable or wrong data), Ugly (readable but visibly off), Fragile (fine until one realistic step more).

fix 1, 3

After a fix, it flips through every state again, including the happy-path demo, so a worst-case fix can't quietly break the normal case. The fixture stays as a regression test; only the toggle goes, when you ask.

ship

Reach for it last: launch week, on an app whose design is settled. It fixes defects, not taste.

$ /design-engineering ship

Its posture is fix. It sweeps the whole app, not one change, across nine lanes: accessibility, performance, mobile, forms, states, motion, theme, content and leftovers, and marketing (only if marketing pages exist).

It comes in sizes:

How it works. Recon first: the stack, the root layout and head, which routes are product and which are marketing, every data view, existing tokens, where each dev tool mounts. Then each lane against its owner node. Then it vets: re-reads every cited line itself and drops anything by-design, duplicated or misattributed. A finding not confirmed at its file and line is never shown.

Then it ranks with the severity tree and fixes in order: accessibility blockers, leaks, the production baseline (one change that clears dozens), per-file fixes, polish. Then it runs your typecheck, build and tests.

What comes back:

1. Verdict, first line. Ship, or Not yet with each open blocker in one line. A leaked secret's "rotate it now" sits above even that.
2. One table per lane with findings: Severity, Before, After, Why, Status (Fixed or Open, with the reason). A clean lane is one line: "Performance: clean."
3. Needs a device. The exact thing to look for: "open the drawer on an iPhone; the padding clears the home indicator."
4. Needs a human. Unapplied fixes, each with why, the change it would make, and the owner.
5. Verification. The commands it ran and their output, verbatim, failures included.

review, break or ship?