architecture-statelisted

# Architecture State ## Activation Contract Use this skill to establish the verified current state of a project's architecture: what it is built with, how it is shaped, and where the gaps are. Do not use it for code-level findings (naming, method size, class design) — those belong to the refactor harness. ## Hard Rules - Every claim carries `file:line` evidence. Build files, manifests, and configs beat READMEs; a README-only claim is `aspirational`, never `verified`. - Style identification names the concrete evidence that justifies it, plus the strongest counter-evidence when the style is mixed. - Gaps are architecture-level: boundaries, cycles, missing guardrails, missing CI/tests wiring — not style nits. ## Detection Checklist Record, each with evidence: - Languages and runtime versions (e.g. `java.version` in `pom.xml`, `engines` in `package.json`, `requires-python`). - Build and dependency tooling (Maven/Gradle/npm/pnpm/pip/poetry), lockfile presence. - Frameworks and platforms (from dependencies, not docs). - Module layout: top-level modules/packages and their declared dependencies. Resolve module layout and inter-module dependency edges from imports, build-file declarations, or a code-graph index (for example, CodeGraph MCP/CLI) when available, before file-by-file reading. - Nested projects: manifests and build files below the root (`package.json`, `pom.xml`, `build.gradle*`, `pyproject.toml`, `go.mod`, `Cargo.toml`, …) and nested `.git` directories. More than o