Scope Hygiene for Tickets and Tooling

The craft of keeping work-tracking and shared tooling clean: scope tickets so they don't block each other or duplicate, manage cross-ticket dependencies instead of refactoring through them, keep relationship links pointed the right way, and place shared tools and project names where the people who need them will find them.

Explanation

The source (Working Heuristics — Data, Matching, Product, Org, Tooling) collects six tactical rules. They fall into three groups:

Scoping the work

• Split orthogonal scope so neither deliverable blocks the other. If two pieces don't actually depend on each other, don't bind them into one ticket where one stalls the other.
• Scope work to what you uniquely deliver; cut duplicative items explicitly rather than letting them rot. Don't let work you don't own linger on your board pretending to be tracked.

Managing dependencies

• Don't refactor a downstream spec while the upstream decision is open. Flag the dependency, freeze the contingent parts, and rewrite once the upstream lands — rather than churning the downstream spec against a moving target.
• Directional links are load-bearing — a reversed relationship (blocks vs. blocked-by, parent vs. child) gets silently misfiled, and the tracker quietly lies about what depends on what.

Tool & project setup

• Put a shared tool at the scope where the people who need it are — team-and-repo → project scope, personal-and-cross-repo → user scope, one-off → local. Match the tool's home to the boundary of who uses it.
• Name projects in the stakeholders' words and after the outcome, matching existing conventions rather than inventing a scheme — so the people who care can find and recognize the work.

Why it matters / where it shows up

• Directionality is load-bearing across domains. "A reversed relationship gets silently misfiled" is the ticket-tracker twin of [[Pipeline Legibility|"name tables for the direction data flows, or you encode a lie"]] — the same principle that wrong direction is worse than no direction, in two different tools.
• Match scope to where the need is. "Put a shared tool at the scope where the people are" rhymes with Data Gravity (put compute where the data is) and Build It as an Extension (put capability where the mental model is): locate the thing where its users/mass already sit.
• Freeze the contingent, rewrite once. Not churning a downstream spec against an open upstream decision is "do it once at the right time" — the temporal cousin of deriving once at the boundary.

Connections

• Do It Once, at the Right Place — "freeze the contingent parts, rewrite once" is the temporal face of that meta-principle (don't churn against an open decision).
• Pipeline Legibility — shares the "directionality is load-bearing" principle in the data domain.
• Build With, Not Against — "draw the seam explicitly" / "cut duplicative items" is the collaboration-level version of clean scoping.
• Match Process Weight to Stage and Stakes — see also (related process craft, not a grounding): this is the hands-on hygiene of running tickets well; the seed is the higher claim that process weight should scale with stage and stakes.

Sources

• Working Heuristics — Data, Matching, Product, Org, Tooling — the six ticket/tooling hygiene rules.