# 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 — &lt;service&gt;

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

1. SSO login via Authentik succeeds and lands on the service's home/dashboard.
2. &lt;core action&gt; — e.g. "upload a test image" → &lt;expected&gt; — "a thumbnail renders".
3. &lt;core action&gt; → &lt;expected&gt;.

## What good looks like

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

- &lt;e.g. "the uploaded image appears in the library grid within ~10s"&gt;

## Not browser-verifiable

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

- &lt;e.g. hardware passthrough, a paid/external integration, subjective media quality&gt;

## Test data

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

- &lt;e.g. "one test user; no pre-seeded content"&gt;