Skip to main content
These pages are the canonical answer to “what must this feature do, and how do we know it does?” Each feature area gets one page listing its behavior contract: every user-facing behavior as a plain-English requirement, alongside the test IDs that enforce it, the tier(s) they run at, and the file they live in. If a behavior is not on these pages, it is not guaranteed; if it is, a named, passing test enforces it on every run.

​
How to read a behavior table

A behavior verified at multiple tiers is proven at multiple depths: the logic is right (A), the app sends and renders it correctly (B), and the deployed system actually does it end-to-end (C).

​
The areas

​
Keeping these pages true

The spec and the tests must never drift: a new behavior lands as a test first, then as a line on its area page, in the same change. When a behavior changes intentionally, its test changes in the same commit — a failing named test is the signal that the spec and the code disagree, and the fix is a decision, not a silenced assertion. The machine-readable ledger behind these pages lives in the repo at docs/testing/feature-audit/TEST-MATRIX.md (every case, every status) and BUGS.md (every defect ever triaged, with disposition).