> ## Documentation Index
> Fetch the complete documentation index at: https://docs.highailabs.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Feature Test Specifications

> The product spec, expressed as its verification: every behavior each feature must have, and exactly how each one is proven.

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

| Column          | Meaning                                                                                                                     |
| --------------- | --------------------------------------------------------------------------------------------------------------------------- |
| **Behavior**    | A requirement in product language — what the app must do, phrased so a PM can verify it                                     |
| **Verified by** | The test IDs enforcing it. Test titles start with these IDs, so any ID greps straight to its assertion                      |
| **Tier**        | **A** = backend logic (in-memory) · **B** = UI↔backend contract · **C** = live staging with real signed-in users            |
| **Where**       | The test file. Tier meanings, commands, and conventions are on the [platform page](/planning/testing/feature-test-platform) |

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

* [Orders & Receipts](/planning/testing/specs/orders)
* [Gmail Import](/planning/testing/specs/gmail-import)
* [Notebooks & Daily Stories](/planning/testing/specs/notebooks)
* [Stash](/planning/testing/specs/stash)
* [Collection & Rankings](/planning/testing/specs/collection)
* [Achievements & Stats](/planning/testing/specs/achievements)
* [Dispensaries & Shopping Agent](/planning/testing/specs/dispensaries-shopping)
* [Users, Account & Subscription](/planning/testing/specs/users-account)

## 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).