Improve architecture

Features pile up, and an app that was easy to change gets hard to change. A check-in catches that early: survey, propose, let the user pick, then refactor in small steps that keep behavior the same. The target shape for apps that grow is in architecture.md.

When to run

Any one signal is enough:

• The end of a milestone (the improve-loop skill calls this skill there).
• Before a big feature. Ask: "What change to the code would make this feature easy?"
• A Swift file over 600 lines (act at 1,000), a type over 400 lines, or "unable to type-check this expression".
• One feature touched more than 6 files or more than 2 targets.
• The same area shows up in 3 fix-log entries, or the same kind of bug happens twice.
• State that changes more than 10 times a second sits on a model that many views observe.
• A dependency cannot be replaced in a test.

Vocabulary

Use these words exactly, so proposals stay comparable:

• Module: anything with an interface and an implementation (a type, a file group, a target).
• Interface: everything a caller must know: signatures, ordering, error modes, threading, performance.
• Depth: how much a module does per unit of interface. Deep modules hide a lot behind a small interface. Shallow modules are pass-throughs.
• Seam: a place where you can swap behavior without editing callers.
• Adapter: one implementation behind a seam. One adapter is a hypothetical seam. Two (production and test) make it real.
• Locality: a change touches one place. Leverage: callers get a lot for little.

1. Survey

Change no code in this step.

1. Read CLAUDE.md, ARCHITECTURE.md, docs/adr/, and docs/FIXLOG.md where they exist.

2. Find hot spots:

   git log --since=30.days --name-only --format= | sort | uniq -c | sort -rn | head -20
   find Sources -name '*.swift' | xargs wc -l | sort -n | tail -20