scopelisted

# scope: the boundary is a decision, not a feeling `docs/product/BRIEF.md` is the single measuring stick. This skill is the only path that changes it. ## Sharpening scope For each candidate capability, make it earn its place: 1. Which user, in which situation, is blocked without it? 2. Does an existing capability (SC-item), a platform feature, or an off-the-shelf product already cover it? (Decision ladder: don't rebuild what exists.) 3. Can version one ship without it? If yes, it goes to *Out of scope* or INTAKE with a trigger. Write results as numbered, testable SC-items. Vague scope ("a dashboard") is not scope; scope says what the user can *do* ("SC-3: owner sees per-project hours, filterable by month"). Phrase each one so the owner recognizes it without a translation: their words, no jargon, no component names. The progress overview quotes these lines back to them verbatim (`node checks/progress.mjs`), so a line only they can read is a line they cannot check. A fuzzy word in any answer ("you said account: the Customer or the User?") gets pinned in the glossary `docs/product/CONTEXT.md` the moment it surfaces. Sharpen at the project's class depth: `begin` §2 defines personal, team, and organization and names which BRIEF discovery rows each class answers. A change that shifts the class upward - a personal tool gains team users, a team tool reaches a client - reopens every BRIEF discovery row that says `n/a`: re-ask those at the new depth before widening anything e