From 4bc3e339536c089177f1658fd49ee828233e93ec Mon Sep 17 00:00:00 2001
From: NuklearRabbit <145918611+NuklearRabbit@users.noreply.github.com>
Date: Sun, 2 Aug 2026 06:16:50 +0200
Subject: [PATCH] docs(state): record Batch 3 completion

---
 PROJECT_STATE.md | 35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/PROJECT_STATE.md b/PROJECT_STATE.md
index bac8b86..8b3d92d 100644
--- a/PROJECT_STATE.md
+++ b/PROJECT_STATE.md
@@ -391,3 +391,38 @@ any change at `docs/functional-completion/server-baseline.md`.
 - Deployed to Unraid and re-verified; demo data reset afterward.
 - Exact next action: Batch 3 — data-quality workbench (typed snapshots, bounded
   resolution flows for all 5 rule types, manual scan UI).
+
+### Batch 3 — complete (commits `6e227a2`, `477b5e7`)
+
+- Typed related-entity snapshots by the reference's own prefix (CUS-/MO-/BK-/INSP-)
+  instead of inferring from `rule_type`. Fixed a real gap this exposed: a
+  `booking_overlap` issue's related refs are bookings, but `get_issue` always resolved
+  them as vehicles, so `_snapshot()` silently returned nothing for them.
+- Added one bounded resolution endpoint per remaining rule type: `provide-fields`
+  (missing_required_field; re-runs the check, resolves only once nothing required is
+  missing), `resolve-odometer-regression` (retain canonical or correct the reading —
+  correction is rejected if it would still be below canonical), `resolve-overlap`
+  (blocks one of the two bookings, re-verifies no overlap remains — found and fixed an
+  autoflush=False bug where the re-verification query didn't see the just-blocked
+  booking's in-memory status change), `apply-recommended-status` (one authoritative
+  recommendation function mirroring the scan's own conflict conditions, re-validated
+  after applying). `possible_duplicate_customer` already had merge; all five rule types
+  now have a real bounded resolution path, not just generic defer/reject.
+- Reintroduced evidence after a non-open decision links the new issue back to the prior
+  one (`evidence.reopened_from` / `previous_decision`) per the documented lifecycle
+  ("reintroduced evidence creates a new issue linked to the prior issue").
+- `DataQualityIssueDetail.tsx` rewritten: a typed panel per rule type instead of a raw
+  `JSON.stringify` dump for four of five types; raw evidence moved behind a `<details>`
+  disclosure. Added a "Run quality scan" action to the workbench (confirmation,
+  progress, per-rule result counts, auto-refresh) — the scan endpoint already existed
+  with no UI trigger.
+- New regression coverage: backend — one resolution test per rule type plus the
+  role-gate/validation-rejection paths and the recurrence-linking behavior (reject an
+  issue, rescan, assert the new issue links back). Frontend — one Playwright test per
+  resolution flow plus the manual scan trigger.
+- Local evidence: `pytest` 96 passed, `ruff check .` clean, `mypy app` 0 issues/44 files,
+  `npx tsc -b` clean, `npm run build` clean, `npx playwright test` **32 passed**, stable
+  across two repeated full-suite runs.
+- Deployed to Unraid and re-verified against the live server; demo data reset afterward.
+- Exact next action: Batch 4 — global search backend + UI, demo reset UI trigger,
+  truthful aggregate integration status (n8n/RAGcore/MCP).