M16: isolate acceptance and harden readiness

docs/17-runbook.md

@@ -26,10 +26,15 @@ Verify:
 ```bash
 curl http://localhost:8128/health          # {"status":"ok",...}
 curl -o /dev/null -w "%{http_code}\n" http://localhost:1228/   # 200
-docker compose run --rm api pytest -q      # all tests pass
+make test                                  # isolated test project/database, all tests pass
 docker compose run --rm api ruff check .   # clean
 ```
 
+Never execute `pytest` inside the deployed API container: the acceptance fixtures reset
+their database deliberately. `make test` uses `compose.test.yaml`, a fixed
+`mobilityops-test` Compose project and its own disposable PostgreSQL volume, and removes
+that project on success or failure. The Gitea workflow uses the same isolation boundary.
+
 ## Operational mode (non-demo login)
 
 Keep the current demonstration environment on `MOBILITYOPS_DEMO_MODE=true`. For an
@@ -173,7 +178,8 @@ Publish the scheduled quality-scan workflow the same way:
 
 ## Required operational checks
 
-- API and web health (`GET /health`, web root `200`);
+- API liveness (`GET /health/live`), database-backed readiness (`GET /health/ready`) and
+  web health (web root `200`);
 - database migration level (`docker compose exec api alembic current`);
 - pending/failed outbox count (Automation page, or `GET /api/v1/workflows?status=failed`);
 - RAGcore provider state (`GET /api/v1/knowledge/status`; demo provider is always