docs: record Batches 1-3 evidence and exact next action

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

PROJECT_STATE.md

@@ -1698,3 +1698,64 @@ Handler — both net-new, not yet built.
     warranted by anything in this branch's changes).
 - **Not done**: no PR opened/merged to `master` — the user asked for commit, push, and
   redeploy, not a merge; `master` is untouched and still 19 commits behind this branch.
+
+## Final integrations pass — Batches 1-3 (branch `feat/fleet-ops-final-integrations`, 2026-08-05)
+
+Branched from `feat/live-n8n-ragcore-integration` @ `3ebca9e` (the actually-validated,
+deployed line — `master` is stale, 19 commits behind). Full audit at
+`docs/final-integrations/current-state-audit.md`.
+
+- **GUI polish**: dashboard Attention Queue now shows a curated severity mix (grouped
+  "Handle now / Follow up today / Review later" headers) instead of pure severity-sort
+  crowding out medium/low items. Seed `bookings.csv` curated so a fresh reset lands ≥2
+  departures and ≥2 returns on the anchor day (new `test_seed_today_movements_are_a_credible_mix`
+  test). About Demo restructured into a compact grid with `<details>` progressive
+  disclosure for architecture/security/testing. Duplicate Merge shows match/conflict
+  counts, hides matching fields by default (toggle to reveal), and previews the final
+  merged record before confirmation.
+- **n8n**: fixed genuinely invalid JSON in the committed `fleet-ops-vehicle-return.json`
+  (a missing `},` — the file could not be parsed). Live-validated workflow 3 (RAGcore
+  Procedure Sync): 6 real nodes confirmed built and saved but correctly still inactive;
+  found and fixed two real defects via the safe `n8n import:workflow` CLI path (not the
+  REST API) — three body-parameter expressions had a stray trailing `}}`, and
+  `settings.errorWorkflow` was unset. Exported as `n8n/workflows/fleet-ops-ragcore-procedure-sync.json`,
+  added to `MANIFEST.md`/`check_drift.py`. **Still not published** — daily unattended
+  runs against production remain a separate go-live decision.
+- **RAGcore retrieval root cause — found and fixed (live, user-approved)**: the "zero
+  candidates" bug was a filesystem permission bug, not authorization or data —
+  `/workspace/.state/models/embedding_profiles.json` (read on every retrieval call) was
+  `root:root` mode `600` on the host bind mount, unreadable by the app's actual runtime
+  uid (10001). Verified every other suspect healthy first (grants, real
+  `RetrievalAuthorizationService` resolution run in-process, exact production Qdrant
+  filter run directly, real ANN query) before finding this. Fixed via `chown`/`chmod` on
+  the host-mounted path; re-verified in-process — 5 real relevant hits, up from 0.
+  **Second, deeper gap found (not fixed)**: `DEFAULT_RERANKER_PROFILE` calls
+  `{ollama}/api/rerank`, which does not exist on the deployed Ollama (`0.32.5`) — a plain
+  404, not a missing-model problem (pulled `xitao/bge-reranker-v2-m3:latest`, 1.2GB, with
+  approval; did not fix it). `/v1/answers` still returns `not_answerable`/0 citations
+  live for real NL/EN/FR questions against real matching content. User decision: leave
+  `KNOWLEDGE_PROVIDER=demo`, do not chase the reranker fix further this session — it
+  needs either a shared-Ollama version upgrade (affects every other project on that
+  instance) or a RAGcore-side code change, and `C:\Projects\RAGcore`'s working directory
+  had 36 uncommitted files from what looks like another active session, so no commits
+  were made there. **Side effect**: minting the live-test credential rotated the existing
+  "Fleet Ops Knowledge Assistant (production)" RAGcore service-account credential (its
+  2-active-credential cap was already reached) — a fresh credential must be issued before
+  actually flipping `KNOWLEDGE_PROVIDER=ragcore`, the old one is now invalid.
+- **MCP Hub status**: `derive_mcp_hub_status()` now reports real tool-call audit
+  evidence (last tool/client/timestamp, total calls) instead of just echoing
+  `MCP_HUB_REGISTRATION_ENABLED`. Confirmed via a sibling-repo investigation that the
+  Fleet Ops connector is already live in ITWorx MCP Hub's own production deployment
+  (Tower, commit `c4a0f6d`), with a real contract fix already applied there (`vehicle.get`
+  wire parameter normalized to `vehicleRef`) — Batch 4 is narrower than the task brief
+  assumed.
+- Repo hygiene: removed untracked `backend;C` (empty dir) and a 31MB `MobilityOps.zip`
+  stray export; `.gitignore` now excludes `*.zip`/`*.tar.gz`.
+- Evidence: `docker compose run --rm api pytest -q` — **172 passed**; `ruff check .` —
+  clean; `mypy app` — clean (50 files); `cd frontend && npm run build` — clean.
+- Committed `34df66d`, pushed to `origin/feat/fleet-ops-final-integrations`. Not yet
+  deployed to the live Fleet Ops instance at this point in the session.
+- **Exact next action**: deploy this revision to `http://192.168.10.150:1236`; Batch 4
+  (MCP Hub — confirm Fleet Ops-side config wiring, tool naming, locale param, correlation
+  ID propagation); Batch 5 (AI Operations Brief using the demo knowledge provider since
+  RAGcore stays off; GUI activity showcase; final regression; evidence write-up).