Context / Problem
During /map-codebase Phase 2, the system proposes 3–5 lens-based clusterings and presents each with name, clusters, pros/cons, and best-for (SCALE-MAP-008). Nothing in that evaluation looks at the dependency structure between the components a lens produces. The clusterings best suited to become LID segments are those where components either have no dependencies on each other (the intent split is fully MECE), or where the dependencies that do exist can be expressed as clear, high-level, involatile contracts. LID doesn't focus on this today.
The cost is structural and permanent: segments bound cascades (free within, pause across). A lens that reads well as a mental model but produces components entangled by volatile, implicit dependencies bakes cross-segment cascade pauses into every future change. The user makes the lens choice — the workflow's primary edge-detection mechanism — without ever seeing this cost.
The raw material already exists: the Phase-1 sweep records per-file dependencies (SCALE-MAP-005, SCALE-MAP-026); Phase 2 just never aggregates them per candidate into an inter-component dependency picture. Phase 4's component quality check ("an independent system achieving an independent purpose") and the anti-pattern lens filters both judge segments individually — neither examines how the proposed set inter-depends.
Direction (not yet design)
The criterion, not the mechanism: prefer clusterings whose components are mutually independent (MECE) or whose inter-dependencies are expressible as clear, high-level, involatile contracts. Whether that lands as a dependency profile in each candidate's presentation, a ranking input at candidate generation, a reconciliation-phase check, or some mix is left to the arrow walk.
Acceptance criteria
- When choosing among lens candidates, the user can see the inter-component dependency structure each candidate implies (or its absence).
- The MECE-or-contract criterion informs which clusterings get proposed and how they're weighed, using dependency data the sweep already collects.
- Absorbed into the existing lens-selection surface — no new command or phase.
Scope & non-goals
Intent touchpoints
Existing intent covers the surface: docs/intent/arrow-maintenance/map-codebase/ (design + specs). SCALE-MAP-008 (candidate presentation: lens, clusters, pros/cons, best-for) would likely change; new specs land under the SCALE-MAP prefix (IDs allocated during the arrow walk). The Phase-4 reconciliation quality check is a possible secondary touchpoint.
Related
Context / Problem
During
/map-codebasePhase 2, the system proposes 3–5 lens-based clusterings and presents each with name, clusters, pros/cons, and best-for (SCALE-MAP-008). Nothing in that evaluation looks at the dependency structure between the components a lens produces. The clusterings best suited to become LID segments are those where components either have no dependencies on each other (the intent split is fully MECE), or where the dependencies that do exist can be expressed as clear, high-level, involatile contracts. LID doesn't focus on this today.The cost is structural and permanent: segments bound cascades (free within, pause across). A lens that reads well as a mental model but produces components entangled by volatile, implicit dependencies bakes cross-segment cascade pauses into every future change. The user makes the lens choice — the workflow's primary edge-detection mechanism — without ever seeing this cost.
The raw material already exists: the Phase-1 sweep records per-file dependencies (SCALE-MAP-005, SCALE-MAP-026); Phase 2 just never aggregates them per candidate into an inter-component dependency picture. Phase 4's component quality check ("an independent system achieving an independent purpose") and the anti-pattern lens filters both judge segments individually — neither examines how the proposed set inter-depends.
Direction (not yet design)
The criterion, not the mechanism: prefer clusterings whose components are mutually independent (MECE) or whose inter-dependencies are expressible as clear, high-level, involatile contracts. Whether that lands as a dependency profile in each candidate's presentation, a ranking input at candidate generation, a reconciliation-phase check, or some mix is left to the arrow walk.
Acceptance criteria
Scope & non-goals
/map-codebasePhases 2–4 (lens proposal, slicing granularity, reconciliation) in arrow-maintenance.Intent touchpoints
Existing intent covers the surface:
docs/intent/arrow-maintenance/map-codebase/(design + specs). SCALE-MAP-008 (candidate presentation: lens, clusters, pros/cons, best-for) would likely change; new specs land under theSCALE-MAPprefix (IDs allocated during the arrow walk). The Phase-4 reconciliation quality check is a possible secondary touchpoint.Related