Choosing a mode
===============

Spec: descriptive guidance, not a checkable rule.
It carries no forbidden and instead pair, and no `jig check` detector applies to it directly.
Section: Interface modes

1. If the project config declares a mode for this route or surface, use it.
2. If not, infer from the signals below and **state the inference in one line** before building.
3. If the signals conflict, ask. Do not guess — the density decision is expensive to reverse.

| Signal | → mode |
| --- | --- |
| Visitor arrives from search or a link, may never return | `editorial` |
| User has an account and a task | `product` |
| User is doing this job all day, knows the system, uses the keyboard | `operator` |
| Content is primarily prose or media | `editorial` |
| Content is primarily records, rows, filters | `operator` |
| Success is measured in comprehension or trust | `editorial` |
| Success is measured in task completion | `product` |
| Success is measured in throughput or error rate | `operator` |

### The one-sentence distinction

**`editorial` optimises for first use. `operator` optimises for the thousandth. `product` sits between and must serve both.**

When a mode decision is genuinely ambiguous, resolve it with that sentence rather than by taste.

### Mixed projects

Mode is a property of a **surface**, not a project. A single site routinely spans all three: marketing pages (`editorial`), an authenticated app (`product`), an admin area (`operator`).

At a seam between modes:
- Brand stays constant. Same palette, typeface, logo, radius personality.
- Density, type scale and motion switch cleanly at the route boundary.
- Never blend two modes inside one view. A dense table inside a spacious marketing page is a mode error; give the table its own surface or redesign it as editorial content.