# break and ship

> Run break to feed one component the realistic worst case and stop with a report, and ship to sweep the whole app before launch, fix in order, and say what still needs a phone or a person.

Module: The /design-engineering toolkit · Level: intermediate · 8 min · https://school.agents.org.in/design/toolkit/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.

*[Interactive demo: break: what broke and how badly, worst first, then the toggle to see it yourself. It stops there.]*

```bash
/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.

  **Step: 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.

  **Step: Build the worst case.** One fixture (A saved set of test data shaped like the real thing, such as a worst-case list of members. Kept in the project so the next person can see the same breaks) 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.

  **Step: 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`.

  **Step: 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.

  **Step: Report and stop.** Then waits.

**What comes back:**

| Section | Holds |
|---|---|
| What broke | #, Severity, Field, Worst-case value, What happens, Fix with file and line. Worst first. |
| Decisions for you | breaks with more than one right answer: wrap or truncate? paginate or virtualize? |
| What held up | the cases already handled, so you trust the test |

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

**Then fix some (paste into your agent):**

```text
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.

*(Taste problems aren't break's job. "It's ugly with normal data" is review or polish.)*

## ship

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

*[Interactive demo: ship: a verdict first, what it fixed, then what still needs a real device.]*

```bash
/design-engineering ship
```

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

It comes in sizes:

| Invocation | Does |
|---|---|
| `ship` | recon, every lane, vet, fix, build, report |
| `ship audit` | the same sweep, no edits; every row stays Open |
| `ship quick` | blockers only, every lane, fixed. The hour before a demo. |
| `ship mobile` (or any lane) | recon plus that lane; lanes combine, and compose with `audit` |
| `ship app/checkout` | everything, scoped to one path |

**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.

> **Never invent.** Copy, a brand colour, a link-preview image, the header height, testimonials: it reads them from the code. If they're missing, it flags the gap. Invented content in production is worse than a flagged hole. It also asks before any fix that changes chosen behaviour, like removing an animation or a route.

**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.

**"Already in good shape, small diff" is a valid and good result.**

## review, break or ship?

| You have | Verb |
|---|---|
| one change to judge | `review` |
| one component and real-world data | `break` |
| the whole app, and a launch date | `ship` |

**Check yourself:** It's the hour before a demo. You want only the things that would embarrass you fixed, across the whole app. Which invocation?

- [ ] /design-engineering review
- [x] /design-engineering ship quick
- [ ] /design-engineering ship audit
- [ ] /design-engineering break app/

*Why:* ship quick sweeps every lane for blockers only and applies the fixes. audit wouldn't edit anything, review judges one change, and break tests one component's data.

## In the skill

- https://school.agents.org.in/skill/commands/cmd-break.md
- https://school.agents.org.in/skill/commands/cmd-ship.md