43 lines
1.5 KiB
Markdown
43 lines
1.5 KiB
Markdown
# 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):
|
|
|
|
1. SSO login via Authentik succeeds and lands on the service's home/dashboard.
|
|
2. <core action> — e.g. "upload a test image" → <expected> — "a thumbnail renders".
|
|
3. <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">
|