Improve the Architecture

Scan the codebase for accumulated friction, present deepening candidates as a visual report, and carry the one the user picks into the normal spec cycle. The goal is testability and navigability — modules deep enough that their interface is the test surface.

Vocabulary is strict throughout: module, interface, implementation, seam, adapter (plus depth/locality/leverage as qualities) — a seam is a public surface where behavior is both observable and substitutable (the same seam test-first and design-solution name). Never drift into "component", "service", "layer", or "boundary" — precision in the nouns is what keeps the findings comparable run over run.

1. Take the posture

The scan opens here, before any reading. Run it, do not estimate:

cd <repo root> && python3 <skill-root>/scripts/posture.py --days 180

The working directory decides which repo is measured — run it from the repo under scan, never from the skill's own folder.

It prints and records four things: rules mechanised/total with the prose-only IDs named, change locality (median files and modules per commit, and the share of commits spanning more than one module), cross-module co-change pairs, and the most-changed files. A rule no check defends is a wish, and this count says how many the repo is carrying.

The record lands in .skills/scan-architecture/posture.json (local, never committed). When one already exists, every number comes back with its delta since the previous scan — that delta is the only evidence that the last scan's pick moved anything.