work-tierslisted

# Work tiers The quality of what gets delivered is the objective. Tokens and wall-clock are the budget you spend to reach it, not a second goal competing with it. Spending the same on a favicon and an authentication flow gets both wrong — it overpays for one and underpays for the other, and the underpaid one is the one that costs somebody. One decision per task fixes both ends at once, because the tier that says how much to spend is the same tier that says how strictly to judge the result. **Tier is not size.** Three lines touching auth are load-bearing. Four hundred lines of static marketing copy are not. Judge what the code carries, never how large the diff is. This is a different axis from the brief's `Classification`. That says how big the request is and how it routes. This says what a single task inside it carries. A `bounded` brief routinely contains one load-bearing task and three scaffolding ones. ## Deciding the tier Four questions, asked per task: 1. **Blast radius** — if this is wrong, who notices? One screen, one feature, every user, or the data itself? 2. **Exposure** — does untrusted input reach it? Does it touch credentials, money, personal data, or an authorisation decision? 3. **Reversibility** — does anything else build on this shape? Schema, public API, routing, design tokens, and the scaffold every builder copies are contracts: changing them later means changing everything downstream too. 4. **Longevity** — is this thrown away next week,