Per-service verification record — template

Copy this file to roles/<service>/VERIFY.md and fill it in when building a service role (ADR-008 Level 4 / ADR-017). It is the per-service acceptance spec: the critical user journeys that define "working" for this service. /verify-service <name> reads it, drives a browser through them against the staging deploy, and explores beyond them.

Delete this preamble in the copy and start from the heading below.

Verify — <service>

Critical user journeys

The acceptance criteria — what "working" means for this service. Numbered; each is an action and its expected result. Example shape (replace with this service's flows):

SSO login via Authentik succeeds and lands on the service's home/dashboard.
<core action> — e.g. "upload a test image" → <expected> — "a thumbnail renders".
<core action> → <expected>.

What good looks like

Key states/screens Claude should confirm (and screenshot) — the visual/textual signals that the journeys above actually succeeded.

<e.g. "the uploaded image appears in the library grid within ~10s">

Not browser-verifiable

Items to route to the manual-test handoff — things a headless browser can't or shouldn't judge.

<e.g. hardware passthrough, a paid/external integration, subjective media quality>

Test data

What the journeys need, provisioned in the staging Authentik test group (ephemeral, torn down by staging rebuild).

<e.g. "one test user; no pre-seeded content">

1.5 KiB Raw Permalink Blame History