mapping-architecturelisted

# Mapping Architecture ## Overview Produce a single self-contained HTML page describing how a codebase actually works, derived from the code rather than from its README. **Core principle: every box, edge, and claim on the page cites a file path. No evidence, no box.** The failure this skill exists to prevent is a beautiful, plausible, wrong page - one that renders the architecture the docs *describe* instead of the one the code *implements*. Docs go stale. Imports do not. ## The Evidence Rule Every finding carried into the page is a record with a REQUIRED `evidence` field: | Field | Content | |---|---| | `claim` | What is true, one sentence | | `evidence` | `path/to/file.ts:42` - a real path you opened | | `confidence` | `verified` (read the code) or `inferred` (pattern-matched only) | Any number in a claim carries its scope, in the claim: "255 importers under `src/`, tests included". Fan-in, file and call-site counts all move by 30% or more depending on whether tests, generated code and dynamic imports are counted, so a bare integer is two agents' numbers silently disagreeing. Cannot fill `evidence`? The claim does not go on the page - it goes in the Gaps section. `inferred` findings render with a visible marker. Never silently promote inferred to verified. ## Workflow ### 1. Recon - single pass, cheap Establish shape before spending agents. See `references/probes.md` for per-ecosystem commands. - Manifests and lockfiles, giving languages, frameworks, dependenci