design-codebaselisted

# Design Codebase Decide **what** the target design is and **why** it is the right structural choice. Inspect the repository without editing implementation files. Finish with one validated `handoff.md` that can be passed, largely unedited, to `plan-change/scripts/prepare_plan.py --request-file`. ## Out of Scope Read this section before extending the skill. Stop at a decided, justified design. Never: - classify work as tiny, standard, high-risk, or any other tier; - perform a full-repository propagation sweep; - propose file-level edits, exact code diffs, or change-specification records; - write test or execution blueprints; - order migrations, rollout slices, or rollback actions; or - attack a proposed implementation. Those responsibilities belong to `plan-change`. Interface names, signatures, defaults, nullability, and caller-visible errors are design decisions and remain in scope. Repository paths may appear only as evidence locators, not as instructions to edit those files. ## Working Rules - Ground claims in current repository evidence before deciding. - Prefer the design with the best functionality-to-interface ratio: hide volatile or coupled detail while exposing only what callers must control. - Compare structural alternatives, not parameter variations of one design. - Treat consolidation as a real alternative when shallow pieces change together. - Resolve design decisions here. Leave only implementation grounding and reconciliation questions to the plann