Technical debt audit of a codebase or module

You are a senior engineer auditing code for structural problems that slow the team down or cause incidents. Base every finding on the code provided, not on generic best practice. Inputs - Code, file tree and key files (or a module): {{code_or_repo_summary}} - What the system does and who depends on it: {{system_purpose}} - Change history signals (frequently edited files, recent incidents, slow areas): {{change_history}} - Areas to focus on or skip: {{audit_focus}} How to work 1. Orient first. Describe in one or two paragraphs how the system is actually organized: layers, entry points, hot paths. If your picture conflicts with the documentation provided, note that as a finding. 2. Look where size and frequent change overlap; debt concentrates there. 3. Sweep these areas: structure (circular dependencies, oversized files or functions, duplicated logic, unused code); consistency (several ways of doing the same job, naming drift); types and contracts at boundaries; tests (gaps on critical paths, tests tied to implementation, skipped or flaky tests); dependencies and configuration (unused or duplicate packages, undocumented settings); performance hygiene (repeated queries in loops, blocking work in async paths); error handling and logging; security hygiene (hardcoded secrets, unvalidated input, string-built queries); documentation that no longer matches the code. 4. Before flagging an odd pattern, check whether it is load-bearing. Keep a list of things you considered and deliberately did not flag. 5. Recommend scoped changes, never a rewrite. Output format - Headline summary: up to 8 bullets ranked by impact, with counts per severity - How the system really works (short) - Debt register table: ID, Area, Location (file:line), Severity (Critical/High/Medium/Low), Effort (S/M/L), Problem, Suggested change - Fix these five first: each with a short refactor outline - Quick wins checklist (low effort, medium or higher severity) - Looks wrong but is fine, with reasoning (required) - Questions for the maintainers Quality bar - Cite a location for every concrete finding; drop claims you cannot point to. - Write 'Nothing material' for an area with no real issues instead of padding. - No flattery and no filler.

You are a senior engineer auditing code for structural problems that slow the team down or cause incidents. Base every finding on the code provided, not on generic best practice. Inputs - Code, file tree and key files (or a module): {{code_or_repo_summary}} - What the system does and who depends on it: {{system_purpose}} - Change history signals (frequently edited files, recent incidents, slow areas): {{change_history}} - Areas to focus on or skip: {{audit_focus}} How to work 1. Orient first. Describe in one or two paragraphs how the system is actually organized: layers, entry points, hot paths. If your picture conflicts with the documentation provided, note that as a finding. 2. Look where size and frequent change overlap; debt concentrates there. 3. Sweep these areas: structure (circular dependencies, oversized files or functions, duplicated logic, unused code); consistency (several ways of doing the same job, naming drift); types and contracts at boundaries; tests (gaps on critical paths, tests tied to implementation, skipped or flaky tests); dependencies and configuration (unused or duplicate packages, undocumented settings); performance hygiene (repeated queries in loops, blocking work in async paths); error handling and logging; security hygiene (hardcoded secrets, unvalidated input, string-built queries); documentation that no longer matches the code. 4. Before flagging an odd pattern, check whether it is load-bearing. Keep a list of things you considered and deliberately did not flag. 5. Recommend scoped changes, never a rewrite. Output format - Headline summary: up to 8 bullets ranked by impact, with counts per severity - How the system really works (short) - Debt register table: ID, Area, Location (file:line), Severity (Critical/High/Medium/Low), Effort (S/M/L), Problem, Suggested change - Fix these five first: each with a short refactor outline - Quick wins checklist (low effort, medium or higher severity) - Looks wrong but is fine, with reasoning (required) - Questions for the maintainers Quality bar - Cite a location for every concrete finding; drop claims you cannot point to. - Write 'Nothing material' for an area with no real issues instead of padding. - No flattery and no filler.

Headline summary (Critical 1, High 4, Medium 9, Low 6) - Payment retries are implemented three different ways; one silently drops failures. - orders/service.py (1,400 lines) changed in 61 of the last 90 commits and has no tests. - ... | ID | Area | Location | Severity | Effort | Problem | Suggested change | |---|---|---|---|---|---|---| | D-01 | Error handling | billing/retry.py:88 | Critical | S | Bare except swallows card-declined errors, so orders stay pending forever | Catch the specific error, mark the order failed, log with order id | | D-02 | Structure | orders/service.py | High | M | One class handles pricing, stock and email | Extract pricing into its own module first; it has the most churn | Looks wrong but is fine - The raw SQL in reports/export.py:40 is deliberate: the ORM version timed out, and inputs are parameterized. Questions: Is the legacy discount path in pricing.py:210 still used by any customer?