Every piece of work that enters SpecDevShip gets one explicit decision made about it before anything else happens: is this light tier, or full tier? Most teams never write this decision down anywhere — it lives as a vague feeling somewhere between "this seems small" and "this seems like a lot." SpecDevShip makes it a real, visible step, with reasoning attached.
The default is light tier, on purpose
Light tier is deliberately the default outcome. A new endpoint, a UI tweak, a refactor within existing architecture, a fix — even a fairly involved one — stays light tier. It gets one planning document, a focused regression script, and moves. The cost of light tier is low, so the bar to stay in it is generously high.
What actually triggers full tier
Full tier is reserved for work that's genuinely new-app-scale or introduces real architectural risk: a new external system integration, a new major subsystem, a data model change with real migration risk, or the very first spec for a brand-new application. Notice what's not on that list — "this will take a while" isn't a full-tier signal. Effort and risk are different axes, and only risk moves the needle here.
Why the wrong call in either direction hurts
Force everything into full tier and you'll burn hours writing EARS-format requirements for a one-line copy change — and worse, you'll train yourself to skip the process altogether out of sheer fatigue. Force genuinely risky work into light tier and you'll ship a data migration with no requirements doc, no architecture review, and no acceptance criteria to test against — exactly the kind of change where an AI agent's confident, plausible wrongness is most expensive.
The close-call cases
When it's a close call, the workflow says so explicitly and proposes a tier with its reasoning shown, rather than silently defaulting. That one habit — surfacing uncertainty instead of resolving it silently — is worth more than the tier decision itself. You can always overrule the call; what you can't do is fix a decision you never saw being made.
If you only adopt one piece of SpecDevShip's workflow before trying the rest, make it this one. It's the cheapest habit to build and it pays for itself the first time it catches a change that was quietly bigger than it looked.