to-tickets: vertical-slice rule has no completeness check, so layer-cut slices can leave a connecting path unowned

## Summary `to-issues` correctly states that slices must be vertical — *"Each slice delivers a narrow but COMPLETE path through every layer … NOT a horizontal slice of one layer."* But there is **no step that verifies this**, and **no guidance for legitimately-horizontal prep/refactor slices**. As a result a plausible-looking set of layer-named slices can omit the *connecting* step between them — owned by no slice — and when `to-issues` runs on a pre-authored plan/PRD, Step 4 ("Quiz the user") tends to **rubber-stamp** the existing cut rather than re-derive it. ## Failure mode (generic) A feature needs data **captured** (slice A, framed as "backend/storage") and later **surfaced** (slice C, framed as "config UI"). A deliberately byte-neutral prep slice builds half the read path; the UI slice assumes the rest "just works." The read path that turns stored data into a *displayed value* is split across A and C and **owned by neither**. It compiles, each slice looks reasonable in isolation, and the gap surfaces only during a later slice's recon — one slice too late. The root cause is that a complete *intent* (the PRD/user stories were fine) does **not** guarantee complete *slices*: a set of layer-cut slices can each look reasonable while the union omits a connective step. ## Why Step 4 doesn't catch it The "Quiz the user" questions are about granularity, dependencies, and merge/split — **not** "is each user-facing slice actually end-to-end, and is any connective path unowned?" A layer-name title (*"Config UI"*, *"Backend resolver"*) reads as a fine slice while hiding that the vertical isn't covered. ## Suggested fix — a verification step before publishing 1. **Outcome titles, not layer titles.** Title each *user-facing* slice as `" → "`, never as a layer. A layer-only title hides whether the full vertical is covered. 2. **Account for prep slices.** A slice MAY be a deliberate prep/refactor/byte-neutral slice that is *not* end-to-end — but then it must name the user-facing half it defers AND the later slice that closes it. A deferred half with no named closing slice is the gap. 3. **Trace the first outcome slice.** For the first outcome slice after any prep slices, trace one concrete value through all layers against the code before publishing; a missing layer → carve a new slice. 4. **Don't rubber-stamp.** When run on a pre-authored plan/PRD, re-derive the slices and run the checks above — the table is only "done" when every user-facing row passes the trace. ## Context Hit this on a real project using a vendored copy of `to-issues` (MIT). The miss was a connective read-path that fell between a byte-neutral prep slice and a "UI" slice, caught a slice too late during recon. Happy to send a PR adding the verification step if the direction is welcome.