thiientv 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 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 approved candidate to solution-design and
implementation-planning; use code-simplification when no architectural
boundary changes.
Completion condition
The report ties each candidate to repository evidence, shows current and proposed ownership, respects existing decisions or explicitly challenges them, and recommends a bounded first move without implementing an unapproved redesign.