methodology-architecture-fitness

Architecture fitness

Architecture intent that lives only in a doc is a suggestion. Intent that runs in CI is enforced. A fitness function is an automated check that fails the build when the system drifts from an intended architectural property — a layering rule, an allowed-dependency rule, a cycle ban, a bundle-size budget.

This follows the evolutionary architecture idea of fitness functions. For a review: a documented rule and an enforced rule are not the same, and the score must reflect which one you actually found.

When to use

Use while scoring the architecture_fitness dimension, when designing checks for a new architecture, or when a finding's fix is "and keep it from coming back." A boundary repair without a check to hold it will rot again; the plan should add the check.

Skill navigation

• Missing architecture intent: use architecture-design to define it or architecture-review to reconstruct it from docs and code.
• Current skill: use methodology-architecture-fitness to distinguish existing enforced checks from recommended checks.
• Next skill: use architecture-scorecard when scoring a review, include checks in architecture-design, or sequence approved missing checks in architecture-plan.

Existing checks vs recommended checks

Keep these strictly separate — conflating them inflates the score.

• Existing check — a check that actually runs and can fail the build today. Evidence: a CI step, a lint/dep-rule config, a test that asserts an architectural property, or an archfit gate wired into CI. Cite it. Only existing, enforced checks raise the architecture_fitness score.
• Recommended check — a check you propose because intent is currently unenforced. It is a recommendation, not evidence of fitness. It belongs in the report's recommendations and the refactoring plan, and does not raise the score.

A repo with thorough architecture docs and zero enforcement scores low on fitness, not high. Documentation is intent; fitness is enforcement.