M16: isolate acceptance and harden readiness

PROJECT_STATE.md

@@ -2398,3 +2398,22 @@ evidence yet."
 - **Exact next action**: none for the locked PoC. All acceptance criteria are satisfied;
   subsequent work is routine production operation, monitoring and explicitly approved
   scope beyond this build.
+
+## M16 — reliability boundary and truthful delivery foundation (2026-08-10)
+
+- Added `compose.test.yaml` and `scripts/run-isolated-tests.sh`: backend acceptance now
+  runs in a fixed, disposable `mobilityops-test` Compose project with its own PostgreSQL
+  database/volume. The script cleans up on success, failure or interruption. The live
+  deployment database is no longer an acceptable test target.
+- Added a Gitea Actions workflow for isolated backend tests, ruff/mypy, the locked
+  frontend build and npm audit. `make test` now routes through the isolated test runner.
+- Split process liveness from database-backed readiness (`/health/live` and
+  `/health/ready`) while retaining `/health` compatibility.
+- Replaced count-derived return-inspection and scan-issue references with prefixed UUID
+  references, eliminating collisions between independent concurrent transactions.
+- Updated the README/runbook where they still claimed demo RAGcore, two n8n workflows or
+  unsafe in-place pytest execution.
+- Evidence: Compose merge validated; ruff and mypy clean; full isolated PostgreSQL suite
+  **218 passed** and the disposable database/network/volume were removed automatically.
+- Exact next action: implement honest loading states and RAG/source deduplication, then
+  revalidate live Knowledge and Integration flows.