Every requirement in this project has a named verification tier, and none is unknown. That is
itself a requirement, and this page is the published statement of it.

Five tiers, in the order you meet them:

The commands behind the first three are in testing.

Inspection is not a shrug. It is what a requirement gets when only a person can judge whether it
holds — whether the README actually answers a newcomer’s questions, whether a security channel
actually reaches someone. Each one is an item on a checklist that is walked before every release,
not a gap.

Requirements of feature 003 — release readiness

This table is not copied from the plan; it is the plan’s table, included at build time from
specs/003-oss-release-readiness/plan.md.
The published statement and the planning document are the same bytes, so they cannot diverge.

Tiers: Unit (cargo test --lib) · E2E (cargo test --test 'e2e_*') · CI (a check in
the pull-request workflow) · Release (a precondition or step of the release workflow) ·
Inspection (a named item on the release checklist in quickstart.md).

Requirements of features 001 and 002 — the program itself

Derived from those features’ own E2E coverage mappings in
001-workspace-swap-overlay/plan.md
and
002-overlay-visuals/plan.md,
which remain authoritative for what each test drives. The overwhelming majority are E2E, because
the overwhelming majority describe what the program does when a real person presses a real key
against a real compositor — and that is the only place such a claim can honestly be checked.

The seven that are not end-to-end, and why

Six of them are pixel properties — that the highlight is visible, that an icon keeps its aspect
ratio, that artwork is not recoloured, that the icon slot follows the text height. Asserting those
end-to-end would mean comparing screenshots, which was considered and rejected as brittle across
fonts, scaling and compositor versions. They are unit-tested against computed rectangles instead,
and confirmed by eye on the quickstart walk.

One, FR-013c, is the failure of a rollback — provoking it end-to-end would mean corrupting the
compositor mid-swap, so it is unit-tested against an injected double failure.

FR-061 is documentation completeness, which no end-to-end test could see. It is the catalogue
walk: a unit test reads the published style catalogue and compares it against the const tables
theme.rs actually resolves from. Adding a setting without documenting it fails
cargo test --lib — which is the same mechanism that keeps the configuration
and appearance pages honest.

What is measured rather than tested

Three of the project’s success criteria are human measurements, not checks: how long it takes a
newcomer to get an overlay on screen, how long to get a test suite running, and whether a user can
assemble a custom appearance from the documentation alone. These are walked once along the published
path and recorded, in the same way feature 001 measures its own usability criterion. A number that
can only be got by watching a person is not improved by automating something adjacent to it.