Architecture Review & Fix Strategy

Perform a high-level architecture check on the code we are working on. Focus on structure, not line-by-line debugging.

Produce these sections:

1) **Scope Recap** — One sentence that states the suspected issue and execution path.

2) **Components** — Bullet list of modules/functions/files that touch the issue; give each a one-line role.

3) **Interaction Map** — An ASCII sketch of calls/data flow and boundaries (network, DB, filesystem, threads/async), e.g. A -> B -> C.

4) **Assessment** — 3–6 bullets evaluating:
   - Coupling/cohesion and ownership of responsibilities
   - Error handling & propagation (fail-fast vs silent failure)
   - State management & side effects (shared/mutable/hidden)
   - Sync vs async boundaries; timing/concurrency hazards
   - Data contracts (types, nullability, validation) and config

5) **Possible Fixes** — Propose the most appropriate solution(s):
   - If a small, elegant patch reduces complexity, suggest that.
   - If a structural refactor is warranted, outline that.
   - If both are relevant, present both options.

6) **Risks & Trade-offs** — Short list of consequences of the proposed fixes.

**Rules:**
- Stay strictly within components that touch the target issue.
- Prefer minimal structural changes over broad refactors.
- Decide whether a patch, a structural refactor, or both are necessary.
- Ask at most three clarifying questions only if progress is blocked.
- Keep output concise and decision-oriented.