Get an architecture review from Claude Code that cites file and line, not a generic 'consider microservices' essay

Review the architecture of the services/ and rag/ directories of the RAG API, excluding tests/. Read the actual code and dependency structure before writing anything — do not produce a generic architecture essay that would apply to any codebase.

What I actually want checked: whether the retrieval service still talks directly to the Qdrant SDK anywhere instead of going through VectorStorePort, after last month's refactor.

The expected layering, if the project has one, is: Presentation (api/) -> Application (services/) -> Domain (rag/) -> Infrastructure (vectorstore/, llm/); domain code must never import a vendor SDK directly. Check whether the code actually respects it — trace real import statements and call chains, not what the folder names imply.

Produce exactly these sections:

1. LAYERING VIOLATIONS — every place a supposedly lower layer imports from or depends on a higher one, or a domain module imports a framework/vendor SDK directly instead of going through an abstraction. Cite the actual file and line for each one found. If none are found, say so plainly rather than inventing a marginal one to have something to report.

2. COUPLING HOTSPOTS — modules with an unusually high number of inbound or outbound dependencies relative to the rest of the codebase, named specifically with the count, not just asserted as 'this module does a lot.'

3. RISK RANKING — of everything found above, rank by (a) how many other modules would need to change if this were fixed, and (b) how likely this pattern is to cause a bug the next time someone extends the code nearby. State both factors per item, not a single unexplained severity label.

4. FIXES, SCOPED TO WHAT WAS ACTUALLY ASKED — for each item in the risk ranking, one concrete, minimally invasive fix. Do not propose a framework swap, a full rewrite, or a different architecture paradigm unless the finding genuinely requires it — most layering violations are fixed by introducing one interface or moving one import, not by starting over.

Depth for this pass: Focused pass — the two directories named above only, not a full-repo audit.

WHAT NOT TO DO
- Do not flag naming conventions, formatting, or code style — this is an architecture review, not a lint pass.
- Do not recommend microservices, a new database, or a different language as a default suggestion; only raise it if a specific finding above actually points there, and say which finding.
- Do not pad the report with restated best practices that aren't tied to a specific thing found in this codebase.
- Do not claim a violation exists without naming the file and line where it lives — an unverifiable claim is worse than no claim, since it can send a reviewer chasing something that isn't there.