architecture

# Architecture ## Workflow 1. Read the request and repository instructions. Then inspect existing architecture docs, manifests, entry points, configuration, schemas, migrations, infrastructure, tests, and a few important flows. 2. Choose the output: - For a whole repository document, use root `ARCHITECTURE.md`. - For a named subsystem, use its existing document or `docs/<subsystem>/architecture.md`. - For an explanation, map, review, or audit, answer in chat and do not modify files. 3. Treat code, schemas, configuration, infrastructure, and executable tests as evidence. Treat existing prose as a claim to verify. Resolve contradictions before repeating them. 4. Describe the system that exists now. Use the shape below for a document. For a chat report, use only the sections that answer the request. Link proposed changes to their design documents. 5. Run the review pass. Correct every claim you can verify, identify unresolved evidence gaps, and keep limitations restricted to verified implementation gaps. 6. Return the document or report for human review. Do not design future behavior, plan work, or change implementation. ## Document shape ```markdown # <System> architecture > **Status:** Current implementation > > **Verification basis:** `<commit or version>` or `working tree based on <commit>` ## 1. Executive summary In two or three short paragraphs, say what the system does, name its main parts, explain how they work together, say where the real data lives, and ...