| name | freenet-mail-qa |
| description | QA inventory for the freenet-email project. Use this skill before merging feature PRs, after fixing bugs, or when asked "what's tested" / "what's manual". Source of truth is docs/qa/manual-test-inventory.md. |
Freenet Mail QA
When to invoke
- User asks: "what's tested?", "what's manual?", "what bugs are we missing?",
"did we test X?", "QA inventory", "what should I test before merging?".
- About to merge a non-trivial UI/contract/delegate PR.
- After a bug fix — the row needs to flip from
manual to auto, or a new
row needs to be added.
- Before a release — walk
manual rows for the touched areas.
How to use
- Read
docs/qa/manual-test-inventory.md first. The matrix is keyed by
feature area (Identity, Contacts, Inbox, Compose, Drafts, Sent, Archive,
Settings, Layout, Network).
- Filter to the area the PR / bug touches. Each row has a
Status
column: auto / manual / automatable / blocked.
- For
auto rows: confirm the linked test still exists and still
exercises the behavior (search ui/tests for the title).
- For
manual rows: do the recipe; report what passed / failed.
- For
automatable rows: if you're already touching that area, write
the test in the matching spec file. Then flip the row to auto.
- For
blocked rows: cite the blocking issue; don't try to automate.
Updating the inventory
When you add a test:
| <Behavior> | auto | <suite>: `<test title>` |
Suites: offline (ui/tests/email-app.spec.ts), iso
(ui/tests/live-node.spec.ts), liveness
(ui/tests/production-liveness.spec.ts), rust (cargo test).
When you remove a test, flip the row back to manual (with recipe) or
delete the row if the behavior is gone.
Running the suites
| Suite | Command |
|---|
| offline | cargo make test-ui-playwright |
| iso (cross-node gated) | FREENET_LIVE_E2E_SEND=1 cargo make test-e2e-real-node |
| liveness | scripts/smoke-test-production.sh <url> |
| rust | cargo test --workspace |
Iso harness is heavy (~5–10 min, full freenet net + dx build + headed
browser). Don't run on every change — gate to tags / nightly.
WIP settings gating
Settings controls whose backend isn't fully wired live behind the
wip-settings cargo feature (off by default). When you add or modify
a Settings control:
- Has a real consumer in non-Settings code? Ship it ungated. Verify
by grepping the persisted field name across
ui/src/ excluding
settings.rs — if zero hits, it's WIP.
- No consumer yet? Gate with
#[cfg(feature = "wip-settings")] on
the enum variant / route / nav entry / locals / SettingRow rsx
block. Cite the blocking issue (#69, #85, etc.) in the surrounding
comment.
- Backend just landed? Drop the gate, add row to the matrix as
manual (with recipe) or auto (with test link).
Verify all three configs build clean before pushing:
cargo check -p freenet-email-ui
cargo check -p freenet-email-ui --features wip-settings
cargo check -p freenet-email-ui --no-default-features --features example-data,no-sync
The matrix's "Settings" section flags WIP rows with (gated behind \wip-settings`)and statusblocked` + the issue link.
Anti-patterns
- Don't add a test that requires
--features example-data,no-sync for
cross-node behavior. Mock data lives in offline; real protocol behavior
belongs in iso.
- Don't flip a row to
auto without linking the spec + title. Future
agents need to verify the link.
- Don't automate
blocked rows. Cite the issue and move on.
- Don't delete rows just because they're tedious to test. Mark them
automatable and add to the gap-conversion list at the bottom of the
matrix.
