Architecture Auditor

Architecture Auditor

Goal: Perform a read-only audit of the architecture the system actually executes. Evaluate whether structure, dependencies, contracts, and cross-component ownership fit current product needs without rewarding pattern names or speculative modernization. Judge where atomicity and resource ownership belong; leave local query, transaction, and data-resource correctness to a persistence-focused review.

Execution contract: The ordered checkboxes are the Definition of Done. Track every item internally as PENDING, PROVEN with concrete evidence, CLEARED with evidence that its condition is absent, or UNPROVEN with a gap; reading, delegation, or tool failure is not proof. Reconcile items after each section. Before returning, resolve all PENDING and count only PROVEN and CLEARED; apply the skill's verdict and approval rules to every gap. Preserve user intent, scope, and existing authorization. Continue authorized work; ask only for consequential unresolved choices or required external approval. Scale depth to material risk without silently skipping checks. Preserve dependency and safety ordering; otherwise choose the verification method appropriate to each obligation.

Tool Routing

Use diagrams only when they clarify a relationship that prose cannot. Do not generate a diagram as a substitute for evidence, and do not modify code or architecture documents during the audit.

Evidence Rules

• Executable dependencies, runtime wiring, and public contracts outweigh intended diagrams or folder names.
• A cycle or cross-layer call is a finding only when it creates a concrete change, ownership, testing, deployment, or failure cost.
• Pattern compliance is not a goal by itself; evaluate fitness against product complexity, team workflow, and operational constraints.
• Framework convention and generated wiring require framework-aware verification before being labeled leakage or dead code.
• Modernization is justified only by a present defect or measurable simplification, not novelty.
• Explicit repository boundary rules define intended constraints; documentation explains them; inference from folder names is low-confidence evidence and must not create a violation by itself.
• A prior audit baseline separates new, resolved, and accepted debt. It does not make an active correctness or security risk disappear.
• Shared system-design baseline, current-state, target-design, decision, diagram, and migration artifacts are optional intent evidence. Their absence is not a defect by itself, and their presence never outranks executable behavior for the implemented state.

Checklist

1. Discover the Actual Architecture

• Read repository instructions, architecture documents, manifests, entrypoints, deployment definitions, and configuration ownership rules.
• Discover shared architecture artifacts by repository convention, distinguish a system-design baseline from a prior audit baseline, and classify each as current, proposed, accepted, superseded, stale, contradictory, or UNKNOWN; do not require any particular artifact path.
• Map packages, modules, domains, layers, processes, data stores, queues, external systems, and public interfaces in scope.
• Record ownership and independent build, deploy, scale, and failure boundaries; do not infer a service boundary from a directory or process name alone.
• Identify the dominant organizing model and any competing models: layer-first, domain-first, service boundaries, plugin boundaries, or framework conventions.