---

name: <slug> description: Exercise the backend journey API end-to-end over real HTTP and assert the response chain (status, shape, persisted state). Fill in the TODO steps for <name>. disable-model-invocation: true allowed-tools: Bash, Read

<name> — Backend HTTP e2e check

A runnable scaffold for a project-authored verification skill that exercises the backend journey API end-to-end over real HTTP — not mocked, not a unit test. Modeled on a glacy-progress-e2e-style skill: walk the multi-step API journey, asserting each response and the state it leaves behind.

Read the authoring guide — docs/verification-skills.md — before filling this in. It explains how verify_skill wires this into the ## Verification hook and how the disable-model-invocation marker keeps the skill opt-in.

What this checks

The real request → response → persisted-state chain of a user journey against a running server. Deterministic gates (ruff, mypy, pytest) run first and always win; this check adds the end-to-end HTTP behavior those gates cannot see.

TODO — list the concrete journey to assert, e.g.:

• [ ] POST <base-url>/<endpoint> with <payload> returns 201 and an id.
• [ ] GET <base-url>/<endpoint>/{id} returns the created resource.
• [ ] A follow-up POST <base-url>/<next-step> advances state as expected.
• [ ] The final GET reflects the accumulated journey (progress, totals, …).

How to run

1. Start the server and confirm it is healthy:

   # TODO: replace with your app's launch command + health endpoint
   BASE_URL="http://localhost:8000"
   curl -s -o /dev/null -w "%{http_code}" "$BASE_URL/health"
   

   If it is not 200, launch the server in the background, wait, then re-check.

2. Walk the journey with curl (or an HTTP client of your choice), asserting each step. TODO: fill in real endpoints, payloads, and expected values:

   # Step 1 — create
   curl -s -X POST "$BASE_URL/<endpoint>" \
     -H 'Content-Type: application/json' \
     -d '{"<field>": "<value>"}'
   
   # Step 2 — read back / advance
   curl -s "$BASE_URL/<endpoint>/<id>"
   

3. Assert status codes and JSON shape for each step (pipe through jq or a small Python one-liner). A wrong status, missing field, or stale state is a FAIL.

4. Report a pass/fail line per journey step:

   • ✓ what passed
   • ✗ what failed (with the endpoint + expected vs. actual)

Notes

• Keep the journey hermetic: seed and tear down any fixtures the run creates so it is repeatable.
• The disable-model-invocation: true marker keeps this skill opt-in.
• TODO: delete these Notes once the steps above are project-specific.