architecture-friction-scanlisted

# Architecture Friction Scan Use this Skill before a broad refactor when the codebase feels difficult to understand, change, test, or navigate. The scan finds evidence-backed deepening opportunities; it does not silently choose an interface, edit production code, or turn every stylistic preference into architecture work. ## Establish scope and vocabulary Read repository instructions, the domain glossary or context map, relevant ADRs, architecture documentation, test conventions, and the current working tree. Use the repository's canonical domain terms. For architecture, use precise terms: **module**, **interface**, **implementation**, **depth**, **seam**, **adapter**, **leverage**, and **locality**. Do not rename a module merely to make the report sound consistent. If the user names a module, subsystem, pain point, or recent change, scope the scan there. Otherwise inspect a meaningful slice of commit history and prioritize hot spots: files and concepts that change repeatedly, attract bug fixes, have many consumers, or repeatedly require cross-module context. Record the scope and evidence window. ## Scan for real friction Explore the code, tests, contracts, and history for: - shallow modules whose interface is nearly as complicated as their implementation; - behavior duplicated across callers instead of concentrated behind one interface; - seams that leak provider, storage, ordering, retry, authorization, or error details; - pure helpers extracted for testability while