Improve Codebase Architecture

Scan a codebase for architecture improvement opportunities grounded in ../coding-standards/. This is planning-only: do not edit code, run refactors, update docs, create ADRs, run tests, or run static checks unless the user explicitly asks after the scan.

The output is a globally ranked set of refactor candidates. Each candidate names the concrete friction, the standards areas involved, and the leverage the refactor would create.

Principles

• Look holistically across the coding standards; do not privilege one lens such as deepening.
• Prefer architecture opportunities with concrete leverage: safer invariants, clearer boundaries, smaller caller burden, stronger locality, better test seams, clearer runtime ownership, or reduced duplicated policy.
• Evidence beats vibes. Every candidate needs concrete files, call paths, caller burden, duplicated behavior, leaked DTOs, bad seams, test contortions, or runtime friction.
• Do not estimate effort. Effort estimation is left to humans.
• Do not produce a tech spec. Prepare a brief for ../tech-spec/ when the user chooses a candidate.
• Do not design for backwards compatibility, migrations, rollout, backfill, dual-write/read paths, or deployment sequencing unless the user explicitly asks.

1. Establish scan scope

Use the user's explicit scope when provided: repo, directory, feature area, module, file set, or concern.