Commit Graph

5 Commits

Author SHA1 Message Date
Benjamin Admin 8f4f59f0e3 feat(iace/mitigations): is_relevant + is_customer_standard flags
[migration-approved]

Expert-driven workflow refinement on the Massnahmen page. The engine seeds
~80 mitigations per project, but for a concrete customer site most need a
relevance decision before they're meaningful in verification:

  status: 'planned' | 'implemented' | 'verified'   (existing — verification track)
  is_relevant          bool   (new)                (does this apply to *this* site?)
  is_customer_standard bool   (new)                (already in place at customer — no evidence)

Decision flow on the Mitigations tab:
  Engine-seeded → is_relevant=false (Default, waiting for expert)
  Expert checks "Relevant" → is_relevant=true → surfaces in verification
  Expert clicks trash       → DELETE (banner warns: do not click Reinit
                                       afterwards or seeds come back)
  In verification, customer_standard=true bypasses evidence upload

is_customer_standard implies is_relevant (DB CHECK constraint).

Migration 029_iace_mitigation_relevance.sql:
  ALTER TABLE iace_mitigations ADD COLUMN is_relevant ..., is_customer_standard ...
  + CHECK constraint + partial index on is_relevant for the verification
    page's filter.

Backend (Go):
  - Mitigation struct gains two bool fields
  - CreateMitigation: defaults to false/false (engine-seeded mitigations
    start unbewertet)
  - UpdateMitigation: new case clauses for both keys; setting
    is_customer_standard=true auto-flips is_relevant=true to satisfy
    the CHECK constraint
  - All three SELECT statements (ListMitigations, ListMitigationsByProject,
    getMitigation) extended with the two new columns

Frontend:
  - Maßnahmen-page columns: [Relev. ☑] [Lösch. 🗑] Title | #Hazards | P·I·V
  - Group-header checkbox shows tri-state (indeterminate when partial),
    flips all instances in the group at once
  - Banner above the table: "Markiere jede Maßnahme als Relevant oder
    lösche sie. Nach Löschen kein Neu initialisieren mehr drücken."
  - Relevant rows tinted emerald, customer-standard label visible
  - Legacy bulk-select state + helpers removed (the Relevant checkbox
    now IS the primary mass action)
  - useMitigations gains handleSetRelevant, handleSetCustomerStandard,
    handleDeleteSilent (for non-confirm bulk deletes)

Future use: is_customer_standard mitigations from a prior project at the
same customer can later be auto-suggested when commissioning the next
plant — turning expert knowledge into reusable customer-profile data.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-17 14:35:56 +02:00
Benjamin Admin cb8fb65d3e feat(iace): Betriebszustand-Traceability auf Hazards + Mitigations
Hazards zeigen jetzt farbige Badges mit den Betriebszustaenden die sie
ausgeloest haben (z.B. "Wartung", "Not-Halt"). Mitigations erben die
States ihrer verknuepften Hazards.

Backend: OperationalStates im Function-Feld encodiert (kein DB-Schema),
beim Lesen als operational_states[] JSON-Feld zurueckgegeben.
Frontend: Indigo-Badges in HazardTable + MitigationCard.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-05-11 09:04:20 +02:00
Benjamin Admin d339d1edc7 feat(iace): Sprint 4B — ISO 12100 Hazard/Situation/Harm Trennung
ISO 12100 trennt: Hazard (Quelle) → Hazardous Situation (Person exponiert) → Harm (Verletzung).
Bisher war alles in einem Hazard-Record vermischt.

Implementierung als abgeleitetes Feld (keine DB-Migration noetig):
- HazardType Feld auf Hazard Entity ("hazard"|"hazardous_situation"|"harm")
- DeriveHazardType() berechnet Typ aus Scenario/PossibleHarm/Category
- Explizites Override moeglich (HazardType direkt setzen)
- GeneratedHazardType auf HazardPattern fuer Pattern-gesteuerte Zuweisung
- Store: GetHazard/ListHazards setzen HazardType automatisch
- Init-Handler: Fuellt jetzt TriggerEvent, PossibleHarm, AffectedPerson, HazardousZone
  aus Pattern-Match-Daten (vorher leer gelassen)

6 neue Tests: ScenarioAndHarm, HarmOnly, CategoryOnly, ExplicitOverride,
EmptyFallback, PatternMatchField

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-05-10 20:55:26 +02:00
Benjamin Admin 8682522212 feat: Variantenmanagement — Sub-Projekte mit GAP-Analyse
Backend:
- parent_project_id auf iace_projects (DB + Go Struct)
- POST/GET /variants + GET /variant-gap Endpoints
- GAP-Analyse: Differenz Hazards/Massnahmen/Kategorien

Frontend:
- VariantPanel auf Projekt-Uebersicht
- Variante erstellen Dialog
- Sidebar-Anzeige (Variantenanzahl / Basis-Link)

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-05-09 10:47:01 +02:00
Sharang Parnerkar 3f1444541f refactor(go/iace): split tech_file_generator, hazard_patterns, models, completeness
Split 4 oversized files (503-679 LOC each) into focused units all under 500 LOC:
- tech_file_generator.go → +_prompts, +_prompt_builder, +_fallback
- hazard_patterns_extended.go → +_extended2.go (HP074-HP102 extracted)
- models.go → +_entities.go, +_api.go (enums / DB entities / API types)
- completeness.go → +_gates.go (gate definitions extracted)

All files remain in package iace. Zero behavior changes.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-04-19 10:03:44 +02:00