architecture-reviewlisted

# Architecture Review Find structural changes that reduce the cost and risk of likely future work. Do not produce a generic best-practices checklist. ## Scope the review Use `codebase-orientation` first when ownership and execution paths are not known. Focus on the user-named subsystem or on evidence-backed hotspots from history, incidents, change coupling, and test failures. Read relevant ADRs and domain vocabulary before proposing alternatives. ## Inspect structural pressure Look for: - behavior spread across many callers instead of owned behind one interface; - interfaces that expose nearly as much complexity as they hide; - dependency cycles, unstable direction, duplicated policy, and hidden global state; - abstractions with one hypothetical implementation or pass-through layers; - tests that require internal knowledge because the public seam is wrong; - concepts named inconsistently across code, data, and product language. Apply the deletion test: if removing a module only moves its complexity into every caller, it may be earning its place; if complexity disappears, it may be ceremony. Use [candidate-report.md](references/candidate-report.md) to compare current and proposed ownership. ## Prioritize, do not redesign silently Rank candidates by observed friction, expected locality/leverage, migration risk, reversibility, and relevance to upcoming work. Include a smallest useful change and explicit non-goals. Mark speculative ideas as speculative. Hand an approv