# Verification record and runbook

The repository contains executable validation rather than a CI-only claim. Run from a clean checkout with Python 3.12:

```bash
python -m venv .venv
. .venv/bin/activate
pip install -e '.[dev]'
ruff format --check .
ruff check .
mypy app
pytest -q
docker build -t endpoint-monitor:verify .
docker run -d --rm --name endpoint-monitor-verify -p 18000:8000 endpoint-monitor:verify
curl --fail http://127.0.0.1:18000/healthz
curl --fail http://127.0.0.1:18000/readyz
curl --fail -H 'content-type: application/json' -d '{"name":"example","url":"https://example.com"}' http://127.0.0.1:18000/monitors
docker stop endpoint-monitor-verify
```

`pytest` covers CRUD, status publication, error envelopes, timeout/network mapping, stale-update conflicts, DNS filtering, redirect revalidation, and log redaction with no live outbound traffic. A successful smoke response is `{"status":"ok"}` for both operational endpoints and a 201 monitor document.

Generation environments that do not expose a command runner cannot truthfully record execution results here. The commands above are the exact execution contract; downstream validation should record tool versions, exit codes, and test count. The architectural limitation remains that all monitor data is process-local, ephemeral, and isolated per worker.