Add VERIFY.md template for service-UI acceptance (ADR-017)

docs/testing/service-verify-template.md

@@ -0,0 +1,43 @@
+# 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;