Run an evidence-grounded software architecture audit workflow that builds a repo brief, selects single-auditor or specialist-panel mode, inspects boundary, layering, dependency, composition, cohesion, and testability risks, writes required finding blocks, and sequences incremental refactors. Use when asked for an architecture audit, architecture review, repo-structure review, software architecture report, audit_report.md, structural issue findings, or specialist-panel synthesis across multi-module systems.
100
100%
Does it follow best practices?
Impact
100%
1.85xAverage score across 3 eval scenarios
Passed
No known issues
The BankCore platform team is preparing to onboard a second engineering squad to work on the Ledger Service — a Go package responsible for financial transaction recording, balance tracking, and account history. Before handing off, the current lead engineer wants an architecture review to identify structural problems that will slow down the new squad.
The ledger service is intentionally small and contained. It is a single Go package (not a multi-module monorepo). The source files are in inputs/.
Produce an architecture audit report as audit_report.md that covers the structural issues in this specific package.
The report should clearly state what sources and code surfaces you examined, give each problem its own finding with supporting evidence from the actual files, and include a prioritized set of recommendations for what to fix first. Where you can't confirm something from the available files, note it clearly rather than speculating.