Task #21. The verification page used to manage a separate VerificationItem
entity that the expert had to populate by hand — disjoint from the actual
mitigations list. With the is_relevant flag from migration 029, the
verification step has a natural definition: confirm completion for every
mitigation the expert flagged as relevant for this project.
Page is now a derived view on useMitigations(): filter is_relevant=true,
group by title (same dedupe as Massnahmen page), expose two actions per
hazard×mitigation row:
1. "Kundenstandard" — already implemented at the customer's site, no
evidence file required. Sets is_customer_standard=true and
status='verified'.
2. "Verifizieren…" — opens a modal asking for a textual evidence
reference (Prüfprotokoll-Nr, audit reference, etc.). Calls the
existing POST /mitigations/:mid/verify with verification_result.
File upload is deferred to phase 2 once an object-storage backend
is in place — the modal explains this.
When a row is verified, a "Zurücksetzen" link reverts status to
'implemented' for accidental confirmations.
Header counters: total relevant / open / verified / Kundenstandard.
Maßnahmen-page polish (same commit):
- "Lösch."-column header removed — the trash icon is self-explanatory
- groupByTitle now additionally deduplicates by hazard_id within a
group (engine occasionally emits duplicate (name, hazard_id) pairs
when Reinit is clicked twice; a follow-up migration 030 will add
a UNIQUE constraint to prevent these upstream)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Benjamin Admin
3faa312b31