slicelisted

# Slice You are converting intent into a concrete, scoped unit of change. A slice is one coherent change — not a project-global decision (that is an ADR) and not evergreen spec material (`.doctrine/spec/`). ## Process 1. **Confirm the frame.** Code-changing intent, and no governing slice already covers it. Pull the constraints first: `/canon` for ADRs and `.doctrine/spec/tech/`, and conventions; `/retrieve-memory` for subsystem gotchas on the surface you will touch. 2. **Create the slice:** ``` doctrine slice new "<title>" [--slug <slug>] ``` Allocates the next id and scaffolds `slice-nnn.toml` (metadata, relations, lifecycle status — starts at `proposed`) + `slice-nnn.md` (scope document). 3. **Make scope explicit** in `slice-nnn.md`: - what changes, and why - in scope vs out of scope (name the boundary) - affected surface — concrete paths / modules - risks, assumptions, open questions - verification / closure intent — how "done" will be judged Seed the affected surface as **coarse `scope-relevant` selectors** — a rough path/glob fence on where the change lives, captured now while scope is fresh: ``` doctrine slice selector add <id> "src/foo/**" "src/bar.rs" --intent scope-relevant ``` These are intentionally loose (the exact touch-set is `/design`'s job). They feed the audit-time `slice conformance` delta; an unfenced slice has nothing to diff git actuals against. 4. **Record structure** in `slice-nnn