Drei nachhaltige Verbesserungen, getrieben durch die Bremse-Benchmark-
Faelle GT 1.4, GT 1.30 und GT 7.4. Die Engine erfindet weiterhin
keine Fachmann-Kommentare — Kommentare bleiben aus, weil sie ein
Verstaendnis der konkreten Anlage erfordern, das die Engine nicht
hat. Statt dessen liefert die Engine norm-basierte Klaerungsfragen
und ein praeziseres Pattern-Vokabular.
A) HazardPattern.ClarificationQuestionsDE — neues optionales Feld:
- Pattern hinterlegt prueffaehige Fragen, die der Bediener mit dem
Anlagenbauer abklaert. Beispiele:
- HP1640: "Liegt ein Pruefprotokoll nach EN 60204-1 vor?"
- HP1666: "Ist die WZM als CE-konformes Subsystem integriert?"
- HP1604: "Ist DCS am Roboter konfiguriert und validiert?"
- Init-Handler haengt die Fragen an Hazard.Description an mit dem
Marker "Mit Anlagenbauer zu klaeren:". Kein DB-Schema-Aenderungs-
bedarf.
- 11 Patterns mit Klaerungsfragen versehen (HP1602, HP1604, HP1611,
HP1612, HP1620, HP1622, HP1637, HP1640, HP1641, HP1666, HP1685).
B) HP1632 "Bersten druckbeaufschlagter Pneumatik-Komponente" — neues
Pattern, semantisch DISTINKT zu HP1630 "Abspringen":
- Bersten = Material-/Druckversagen der Komponente, Mediumaustritt
- Abspringen = Verbindung loest sich, Peitscheneffekt
Bremse-Benchmark GT 1.4 sprach von Bersten, HP1630 nur von
Abspringen — ein 66%-Frontend-Match war eine Sackgasse. Mit
HP1632 feuert die Engine ein eigenes Hazard, das auf GT 1.4
einen sauberen Volltreffer liefert.
C) HP1637 "Einatmen von KSS-Aerosolen" — Massnahmen vervollstaendigt:
Vorher nur M141 (Sicherheitszeichen), neu zusaetzlich M405 (KSS-
Aerosolabsaugung), M418 (AGW-Ueberwachung), M526 (WZM-Tueren
geschlossen waehrend Bearbeitung), M408 (Hautschutzplan).
Klaerungsfrage: "Wurde die Aerosolkonzentration nach Bearbeitungs-
ende messtechnisch ermittelt und mit dem AGW verglichen?"
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two-part nachhaltiger fix replacing the previous "fill to 5 mitigations
no matter what" behavior that the GT-Bremse benchmark proved
unfaithful (e.g. HP1625 "scharfe Kanten" returning M005 "Rotations-
bewegung vermeiden" via category fallback; HP1651 "Wiederanlauf
Roboter" returning M054 "Sichere thermische Auslegung" via
mismatched pattern reference).
PART A — Set-based category filter (handlers package):
- acceptableMeasureCategories: replaces 1:1 patternCatToMeasureCat
with a curated set per pattern category, so e.g.
safety_function_failure now accepts software_control measures
(watchdogs, plausibility checks) and emc_hazard accepts both
electrical and software_control measures
- isCategoryCompatible: gate every measure id against the accepted
set before creating a mitigation; mismatches log MEASURE-SKIP
- The old category fallback is REMOVED. A hazard whose pattern has
no category-compatible measure is now created with zero mitigations
and logged as COVERAGE-GAP — the operator must consult an expert.
No more silent invention of generic defaults.
PART B — 235 pattern author-error fixes across 26 files:
- HP040-HP044 (AI): M101/M102/M103 (Auffangwanne/Absauganlage) ->
M133 Anomalieerkennung + M214 Plausibilitaet + M213 Sensor-Redundanz
+ M044 Zweikanalige Steuerung + others
- HP011-HP015, HP104-HP109, HP1085-HP1095, HP1281-HP1334 (electrical):
M001-M005/M054/M061 placeholders -> M481/M482 Isolation +
M511-M522 PE/Schutzleiter/RCD/Hauptschalter
- HP110-HP1331 (material_environmental): M101-M103 -> M384-M395
Brandschutz/Laserschutz + M533/M408 SDB/PSA
- HP800-HP858, HP1178-HP1264 (software/sensor/hmi):
M101/M104 -> M105/M106/M107/M214 SPS/Watchdog/Plausibilitaet
- HP026, HP611-HP1690 (ergonomic): M001/M082 -> M353-M360 +
M530-M532 Hebehilfe/ergonomische Hoehe
- HP201-HP1697 (mechanical): M054/M051 -> M002/M008/M061/M141 +
M487/M488 Tueroeffnung-Stillsetzung/Wiederanlauf
- Plus EMF/Strahlung/Brand/Lärm/Vibration/Kommunikation/Cyber
Coverage shift (Pattern-Author-Fehler bei aktiviertem Set-Filter):
start: 237 patterns with zero category-compatible measures
after Stufe 1A: 5 (AI)
after Stufe 1B: 20 (mechanical Bestand)
after Stufe 1C: 35 (electrical Bestand)
after Stufe 1D: 29 (material_environmental)
after Stufe 1E: 29 (software/sensor/hmi)
after Stufe 1F: 20 (ergonomic)
after Stufe 1G: 80 (thermal/comm/radiation/fire/safety)
final: 0 (28 extended.go/extended2.go duplicates fixed)
New regression tests:
- TestEveryPattern_HasCategoryCompatibleMeasure: every pattern in
collectAllPatterns() must reference at least one category-compatible
measure; gaps must be explicitly listed in AllowlistKnownGaps
(currently empty). Fails CI for any new pattern that drifts.
- TestAcceptableMeasureCategories: pins the set-mapping for the
7 most-bug-prone pattern categories.
- TestIsCategoryCompatible_EmptyMeasureCat: protects legacy entries.
A separate task #11 tracks 58 HP-ID duplicates between
extended.go/extended2.go and cobot.go/press.go/operational.go —
patterns are semantically different and TestGetBuiltinHazardPatterns_-
UniqueIDs misses them because it only checks HP001-HP044.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
KSS, EMV, ESD, DCS, PLR, SIL, HMI, SPS, RCD, LOTO, PSA are
abbreviations that should NOT trigger the relevance filter.
bersten, platzen, abspringen, spritzen, einatmen, ausrutschen,
herabfallen, durchschlaegen, wegschleudern are action words that
appear in many patterns and don't indicate a specific machine.
Fixes: HP1633-HP1675 (KSS patterns) were filtered out because
"kss" was not in the narrative but also not in genericSafetyTerms.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Robot cell patterns now fire BEFORE generic patterns (Priority 96-99
vs generic 85-95). This ensures pattern-specific SuggestedMeasureIDs
(M420 for KSS, M410 for Potentialausgleich) reach the hazard.
Removed debug fmt.Println statements.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
When multiple patterns match the same category+zone, the first creates
the hazard and later patterns add their SuggestedMeasureIDs to the
existing hazard. This ensures KSS-specific measures (M420) reach the
hazard even if a generic pattern created it first.
seenCatZone changed from map[string]bool to map[string]uuid.UUID
to track which hazard ID was created for each dedupKey.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Each hazard now gets measures from its SOURCE PATTERN first
(SuggestedMeasureIDs), then category fallback for remaining slots.
Previously all mechanical hazards got the same generic top-5 measures
(Gefahrstelle eliminieren, Sicherheitsabstaende, Scharfe Kanten...).
Now a KSS-Schlauch hazard gets M420 (Druckfeste Auslegung) first.
SuggestedMeasureIDs added to PatternMatch struct and passed through
from pattern definition to hazard creation to measure assignment.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Replaced category-broadcast logic with per-hazard loop:
each hazard gets up to 5 measures (pattern-suggested first, then
category fallback). Expected: 108 × 5 = max 540 total.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Pattern-suggested measures go to all hazards in category (correct).
Category-based fallback only for hazards WITHOUT pattern suggestions
(max 3 per hazard). Prevents 1654 mitigations explosion.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
hazardIDsByCategory changed from map[string]uuid.UUID to
map[string][]uuid.UUID — measures are now distributed to every
hazard in a category, not just the last one created.
Previously 94/108 hazards had no measures, now all get them.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Store ALL applicable lifecycles (comma-separated) not just first
- Frontend maps internal keys to German labels (normal_operation ->
Automatikbetrieb, maintenance -> Wartung, etc.)
- Show Betroffene Personen in engine detail column
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- ApplicableLifecycles field in HazardPattern: patterns now declare which
lifecycle phases the hazard applies to (Output, not just filter)
- Init handler writes first applicable lifecycle into Hazard.LifecyclePhase
- Robot cell patterns HP1600-1601 broadened: "Betrieb, Einrichten, Reinigung,
Wartung, Fehlersuche" instead of only "Teach-Betrieb"
- All robot cell patterns get ApplicableLifecycles for proper phase display
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Backend:
- hazard_blocks.go: ComputeHazardBlocks() groups hazards by category +
component + zone. Parent = highest risk in group. Children covered by
parent's measures are flagged (no separate assessment needed).
- iace_handler_blocks.go: GET /projects/:id/hazard-blocks endpoint
with summary stats (blocks, covered children, assessments saved)
Frontend:
- HazardBlockView.tsx: Expandable block view with summary cards,
parent-child hierarchy, coverage badges, and "abgedeckt" indicators
- hazards/page.tsx: New "Bloecke" tab alongside "Hazard-Liste" and
"Risikobewertung"
No database schema changes — grouping is computed at runtime.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Replace machine-specific term blacklist with generic vocabulary overlap:
- Extract significant words (>=5 chars, not generic safety terms) from
pattern zone/scenario
- If pattern has specific words but NONE appear in narrative → filter
- genericSafetyTerms whitelist with ~50 terms that appear in all assessments
- Truly generic approach: works for any machine type without maintenance
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- isPatternRelevant() filters patterns whose zone/scenario mentions
machine-specific terms (extruder, stanzpresse, spielplatz, etc.)
absent from the actual machine narrative
- normalizeZoneKey() clusters similar zones for smarter dedup
(e.g. "Schaltschrank, Sammelschiene" = "Schaltschrank-Innenraum")
- machineSpecificTerms list with 40+ terms for generic filtering
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Erklaerteil-Template fuer Risikobeurteilungen (risk_assessment_template.go)
in PDF-Export, Markdown-Export und Frontend ReportPrintView eingebaut
- Ground Truth Benchmark-System: Datenmodell, Fuzzy-Matching-Engine,
3 API Endpoints (import-gt, benchmark, benchmark/summary)
- Frontend Benchmark-Tab mit Score-Cards, Kategorie-Breakdown,
Hazard-Vergleichstabelle (Zugeordnet/Fehlend/Extra), Business Impact
- Erster Benchmark: 13.3% Coverage (Baseline) gegen 60 GT-Eintraege
- Dedup-Fix: seenCat[cat] -> seenCatZone[cat+zone] erlaubt mehrere
Gefaehrdungen pro Kategorie an verschiedenen Gefahrenstellen
- Komponenten-spezifische Hazard-Namen und Zone-basierte Zuordnung
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Changes the compile flow to always query Master Controls from DB first:
1. doc_check_controls → Mode A (deterministic)
2. LLM generation via Ollama/Claude → Mode B
3. Derive from MC name → fallback
4. Template hardcoded questions → absolute fallback
Previously, templates with pre-defined questions just returned those
without ever hitting the DB. Now MC-compiled questions take priority
and template questions fill gaps for uncovered topics.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
POST /projects/:id/components/:cid/suggest-fms
- Baut FMEA-Experten-Prompt aus Komponentenname + Maschinenkontext
- LLM antwortet mit 5 FMs als JSON (Mode, Effect, S/O/D)
- Fallback auf Bibliotheks-FMs wenn LLM nicht verfuegbar
- Nutzt ProviderRegistry (Ollama primary, Anthropic fallback)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Neues Feld "Einsatzbereich" auf Interview-Seite (Sektion 7) mit 15 Branchen.
Pattern Engine bekommt MachineTypes aus MatchInput → branchenfremde Patterns
(Medizin, Aufzug, Bau etc.) feuern nur wenn die Branche ausgewählt ist.
Refactoring: iace_handler_init.go aufgeteilt in init + init_helpers (LOC-Limit).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- POST /initialize?force=true loescht bestehende Hazards + Mitigations
und erstellt sie neu mit aktuellen Betriebszustaenden
- Orange "Neu initialisieren" Button auf Interview-Seite (mit Confirm-Dialog)
- DeleteHazard Store-Methode (kaskadiert Risk Assessments)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
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>
The Betriebszustand-UI saved states to metadata.operational_states but
the initialize handler only read states from the parsed narrative text.
Now merges both sources so the UI selection actually affects which
patterns fire during initialization.
Added integration E2E test that verifies: 2 states → fewer patterns,
9 states → more patterns.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
PROBLEM: Cobot-Projekt hatte 52 Pressen-Hazards weil Keywords wie
"stempel" und "stoessel" ohne Maschinentyp-Kontext matchten.
FIX an 3 Stellen:
1. KeywordEntry.MachineTypes — Pressen-Keywords nur fuer press/*_press
2. ParseNarrative(text, machineType) — Parser laedt Maschinentyp aus Projekt
3. HazardPattern.MachineTypes — Pressen-Patterns (HP045-HP058) nur fuer Pressen
Verhindert zukuenftig falsche Zuordnungen bei neuen Kundenprojekten.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
462 einzelne Queries (Assessments + Mitigations pro Hazard) durch
2 Batch-Queries ersetzt. GetProject von ~22s auf <1s.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Ersetzt 231 einzelne DB-Queries durch 1 Batch-Query mit
DISTINCT ON (hazard_id) JOIN. Ladezeit von ~40s auf <1s.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Automatische Erkennung von DSGVO/AI Act/CRA/NIS2/Data Act
Implikationen bei CE-Gefaehrdungen. 50 Trigger-Mappings auf
Hazard-Patterns → Compliance-Module mit Modul-Links.
- compliance_triggers.go: 50 Pattern→Regulation Mappings
- compliance_crossover.go: Engine die Projekt-Hazards gegen Trigger prueft
- iace_handler_compliance.go: GET /compliance-triggers API
- ComplianceAlerts.tsx: Frontend Alert-Panel auf Projekt-Uebersicht
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Benjamin Admin