Add task-conditioned slicing v1 integration plan for context_pack

[mohanagy]

Goal

Turn the existing broad slicing roadmap (#73) into an integration plan for a first user-visible task-conditioned slicing path inside context_pack / retrieve flows.

This issue should not replace #73. It should define the smallest useful v1 integration that can ship safely after the benchmark and selector work.

Why

SPI gives better program structure, but graphify-ts still needs the real methodology shift:

task → anchors → backward/forward behavior slice → budgeted context pack

Without this, graphify-ts remains mostly "better graph + better retrieval" instead of a true task-conditioned context compiler.

Related

• Prototype task-conditioned program slicing for context packs #73 Prototype task-conditioned program slicing for context packs
• Benchmark v0.18 --spi vs legacy on backend-only and monorepo workspaces #130 Benchmark v0.18 --spi vs legacy
• Integrate value-per-token selector into retrieve/context_pack candidate selection #131 Integrate value-per-token selector
• Replace shallow summary/detail resolution with real multi-resolution context representations #132 Real multi-resolution representations

Scope

Create a v1 integration design and, if appropriate, a minimal implementation behind an opt-in strategy flag.

v1 task modes

Limit v1 to these modes:

1. explain
2. debug
3. impact
4. pr-review

v1 anchors

Support anchors from:

• explicit file path in prompt
• explicit symbol/class/function/method name
• framework route/path/http method metadata
• git diff changed ranges / changed symbols
• stack trace line if provided
• high-confidence lexical match fallback

v1 slice directions

explain

• include target node
• direct callees
• immediate callers
• containing module/file
• tests where available

debug

• backward: callers, config/env/db reads, guards/middleware
• forward: side effects, external calls, DB writes, queues/events where represented
• include stack-trace exact source if available

impact

• forward: dependents/callers/routes/tests/public boundaries
• include high-impact/god/bridge nodes only if directly connected

pr-review

• changed ranges → containing symbols
• direct callers/callees
• tests
• public API/config/db/route boundaries

Deliverables

• Design doc or implementation note describing v1 slicing semantics
• Slicer adapter interface compatible with current context_pack/retrieve path
• Optional strategy: 'default' | 'slice-v1' flag or equivalent if implemented
• Unit tests with small fixtures
• Comparison against default retrieval on at least 3 prompts

Acceptance criteria

• Slicing strategy emits selected nodes/paths with reasons
• Supports both backward and forward traversal where applicable
• Does not explode around hubs/barrels/common files
• Respects explicit node/token budget
• Can be enabled without breaking current default behavior
• Integration is designed to compose with Integrate value-per-token selector into retrieve/context_pack candidate selection #131 value-per-token selection and Replace shallow summary/detail resolution with real multi-resolution context representations #132 representations

Non-goals

• Do not build a perfect whole-program slicer in v1
• Do not make slicing the default until Benchmark v0.18 --spi vs legacy on backend-only and monorepo workspaces #130 proves it helps
• Do not solve Python/Go semantic slicing here

Suggested labels

retrieval, context-quality, architecture, spi, slicing