116 Commits

Author	SHA1	Message	Date
Benjamin Admin	94233b7c66	feat(iace): LLM gap-review (Task #7+#8) + tech-file sources appendix (#29) ... Three coupled pieces of work, all landing the same PoC: 1. Backend gap-review endpoint (Task #7) - internal/api/handlers/iace_handler_gap_review.go: POST /projects/:id/llm-gap-review feeds Limits-Form + current hazards + current mitigations to the configured LLM (Qwen / Claude / OpenAI via ProviderRegistry), parses a JSON suggestion list, filter+stamps confidence, falls back to a static checklist when LLM is unavailable. - Adopt step is NOT in this endpoint by design — the user clicks Adopt in the frontend which calls the existing CreateHazard / CreateMitigation handlers so provenance flows through the normal audit trail. 2. Frontend modal + button (Task #8) - app/sdk/iace/[projectId]/hazards/_components/LLMGapReviewModal.tsx: reusable modal that POSTs the gap-review endpoint, renders suggestions with Adopt/Reject UX, shows confidence + norm refs, source-stamp llm_gap_review vs fallback_static. - hazards/page.tsx: indigo "KI-Gap-Review" button next to the existing "Eigene Gefaehrdung" button + modal mount. 3. Tech-File sources appendix (Task #29 — Stufe 4) - internal/iace/document_export_sources.go: new pdfSourcesAppendix method appended to ExportPDF. Groups cited norms by license rule (R1 OSHA/EU-Recht / R3 BreakPilot patterns / R3 DIN-EN-ISO identifier-only) and emits the legally required statement that pauschal Impressum-Hinweise nicht ausreichen. - extractCitedNorms() scans hazard/mitigation text for EN/ISO/IEC/ DIN identifiers in a narrow grammar so prose isn't turned into spurious citations. Bonus refactor: - internal/app/routes.go reached the 500-LOC hard cap when the new llm-gap-review route was added. Extracted registerIACERoutes into routes_iace.go (136 LOC). Same wiring, no behaviour change. Three of the four Attribution-Renderer stages (1, 2, 4) now produce real output. Stufe 3 ships as <SourceBadge> + <LicenseModuleBanner> already (commits dfac940 + b9e3eea earlier in this branch). The PoC is intentionally conservative: every LLM-Suggestion stays unverbindlich until a human clicks Adopt, and Adopt goes through the existing normal CreateHazard/CreateMitigation flow (not yet wired in this commit — separate iteration). The endpoint, modal and provenance chain are in place for the next iteration to wire Adopt → write path.	2026-05-22 00:21:49 +02:00
Benjamin Admin	a616b64273	feat(iace): Customer-Standard-Reuse across customer's prior projects ... [migration-approved] Task #22. The IACE module is used by a single Maschinenhersteller, but their plants land at many different end customers. When the safety expert commissions the second or third plant at the same customer, whole classes of mitigations (company-wide PPE rules, locked-out energy isolation, customer-standard signage) are already in place there — but rediscovered from scratch every project. Migration 031: iace_projects.customer_name TEXT + partial index. The customer is stored as a plain text field rather than a normalised iace_customers table (option A from the design discussion). A proper customer-management screen can promote this to a FK later without data loss. Backend store_customer_standards.go: - ListCustomerStandardSuggestions(projectID, includeVerified) collects mitigations from all non-archived prior projects sharing the same tenant_id AND case-insensitive customer_name. Aggregates by mitigation.name (since same-named measures from different prior projects collapse into one suggestion) and surfaces: • source_project_count + source_project_names • is_customer_standard / has_verified_instances flags includeVerified=false → strictly is_customer_standard=true includeVerified=true → also status='verified' - ImportCustomerStandardSuggestion(projectID, name): for every prior (mitigation.name → hazard.name) pairing, finds matching hazards in the current project (by name) and ensures a customer-standard mitigation exists. New rows via CreateMitigation (idempotent through the UNIQUE(hazard_id, name) from migration 030); existing rows are flipped to is_relevant=true + is_customer_standard=true + status='verified' via UPDATE. Routes: GET /api/v1/iace/projects/:id/customer-standards?include_verified= POST /api/v1/iace/projects/:id/customer-standards/import body {name} Frontend: - New page /sdk/iace/[projectId]/customer-standards with: • empty-state hint pointing to Auftrag → Kundenname • per-suggestion checkbox + per-row Übernehmen button • bulk "N übernehmen" button • toggle "Auch verifizierte einbeziehen" widening the pool • per-suggestion source_project_count + status badges - Sidebar item "Kundenstandards" (building icon) placed between Verifikation and Nachweise. - Order-page now mirrors Auftraggeber.Firmenname into the top-level customer_name column on save, so the Reuse feature is fed automatically without a separate input field. The same expert effect from migration 029's is_customer_standard flag — "I already know it's covered, no evidence needed" — now becomes a cross-project asset rather than a per-project annotation. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-18 22:31:30 +02:00
Benjamin Admin	4a5924b8c4	feat(iace): CRA / DIN EN 40000-1-2 cyber-resilience spur ... [guardrail-change] Phase 18 adds an EU Cyber Resilience Act compliance track to IACE: the engine now fires patterns that surface the manufacturer-side CRA obligations whenever a project's components carry digital elements. Patterns (HP1910-HP1918, hazard_patterns_cra.go): HP1910 Missing SBOM HP1911 Unsigned firmware/software updates HP1912 Factory-default credentials still active HP1913 No coordinated vulnerability disclosure (CVD) policy HP1914 No documented security patch SLA HP1915 Missing user-facing hardening guide HP1916 No incident-notification process to ENISA / CSIRT HP1917 No security assessment prior to placing on market HP1918 AI component without cybersecurity risk assessment Each pattern carries ClarificationQuestionsDE so the operator gets auditor-grade questions to take back to the Anlagenbauer instead of the engine inventing prose. PatternMatch carries DefaultAvoidability (P=1 for all CRA patterns), feeding the PLr graph from Phase 17. Measures (M540-M548, measures_library_cra.go): M540 SBOM (SPDX or CycloneDX) with each machine release M541 Signed updates with rollback protection M542 Forced default-password change at first boot M543 Published CVD policy (security.txt / PSIRT) M544 Documented patch SLA with CVSS-tier response times M545 User-facing hardening guide in the machine docs M546 ENISA incident-notification process (24h/72h/14d) M547 Authenticated update channel + integrity check M548 Pre-market security assessment / pen-test The library is urheberrechtlich neutral: identifiers only (Verordnung (EU) 2024/2847, DIN EN 40000-1-2 Entwurf, IEC 62443, ETSI EN 303 645, ISO/IEC 5962, ISO/IEC 29147). No normative text is reproduced — DIN/Beuth proprietary content is referenced by section number only. Category-compatibility: cyber_resilience pattern category accepts measures with HazardCategory cyber_resilience, cyber_network, or software_control. Updated in both the runtime helper (iace_handler_init_helpers.go) and its test-mirror (pattern_coverage_test.go) — both must move in lockstep. Frontend (clarifications page): When at least one clarification references "2024/2847" or "40000-1-2" in its norm_references, a blue info-banner is rendered at the top of the page: "Cyber Resilience Act (CRA) — Hinweis zur Geltung Diese Klärungsliste enthält Fragen zur Verordnung (EU) 2024/2847 (CRA). Die CRA gilt für Produkte mit digitalen Elementen, die ab dem 11.12.2027 auf dem EU-Markt bereit- gestellt werden. ..." Reminds the user that the CRA pflichten are forward-looking while still allowing the manufacturer to bake them in now. LOC exceptions: Added three pre-existing files to .claude/rules/loc-exceptions.txt (manufacturer_safety_features.go, iace_handler_clarifications.go, routes.go). All three grew across Phases 16-17 and are tagged as Phase 5+ refactor backlog. [guardrail-change] marker required. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-17 02:15:51 +02:00
Benjamin Admin	2afa5a179b	feat(iace): Risikograph EN ISO 13849-1 PLr + Methoden-Kopf im Bericht ... Phase 17 of the risk-assessment polish. Two pieces: A) PLr per EN ISO 13849-1 Anhang A (Risikograph) - HazardPattern.DefaultAvoidability (1 = P1, 2 = P2). Optional; defaults to P1 if unset (conservative — operator can raise after review). - ComputePLr(s,f,p) implements the canonical 8-leaf binary tree (S1F1P1 -> a, ..., S2F2P2 -> e). Pinned by 8 table-driven tests. - SeverityToS / ExposureToF map the existing 1-5 fields to the binary S/F at the documented threshold (3). - At project initialise, every hazard's Description is appended with "Risikograph EN ISO 13849-1 (Anhang A): S2 · F1 · P1 -> PLr c" so the audit value is visible without leaving the hazard view. - PatternMatch carries DefaultAvoidability so the init handler can pick it up without a second pattern lookup. B) Methoden-Kopf am Bericht - GET /clarifications.html now opens with a standardised methodology block: ISO 12100 Anhang B (hazard ID) + ISO 13849-1 Anhang A (PLr graph) + ISO 12100 6.2/6.3/6.4 (reduction hierarchy). Same wording on every export, ready for the Anlagenbauer-Uebergabe. - Only norm identifiers — no norm text reproduced. C) ISO12100Section in Hazard Description - When a pattern is labeled with ISO12100Section, the hazard description gets a "Klassifikation: EN ISO 12100 Anhang B, Abschnitt 6.3.5.4" suffix. Provenance for the auditor. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-17 02:03:10 +02:00
Benjamin Admin	71d31c914b	feat(iace): ISO 12100 Anhang B mapping — split noise/vibration + section identifier ... Phase 16 of the Klaerungen / risk-assessment polish. Sources from EN ISO 12100 Anhang B Tabelle B.1 are now first-class: A) HazardPattern.ISO12100Section identifier (string), persisted only as the section number (e.g. "6.3.5.5") — not the norm text. Keeps the library urheberrechtlich neutral (DIN/Beuth license). 57 patterns labeled today; rest will follow on touch. B) Category split per ISO 12100 Nr. 4 vs Nr. 5: - 16 patterns reclassified noise_vibration -> noise_hazard - 7 patterns reclassified noise_vibration -> vibration_hazard - 1 pattern (HP228 UV-/Laermexposition) kept multi-cat acceptableMeasureCategories now accepts both new aliases plus the legacy noise_vibration. Coverage test recognises both as valid. C) 5 new ISO-12100-Annex-B gap patterns (HP1900-HP1904): - HP1900 Vakuum-Verletzung (6.3.5.5) - HP1901 Federenergie / elastische Elemente (6.2.10) - HP1902 Rutschen/Stolpern auf rauer Oberflaeche (6.3.5.6) - HP1903 Hochdruckinjektion (6.3.5.4) — includes clarifying "no hand-locating of leaks" question - HP1904 Ersticken durch Brustkorbquetschung (6.3.5.2) The library now mirrors the ISO 12100 Annex B structure for the gaps the Bremse benchmark surfaced. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-17 01:59:16 +02:00
Benjamin Admin	c4be077c5d	feat(iace): Klaerungen Phase 3 — DB-Tabelle + Multi-User + PDF-Export ... [migration-approved] Three pieces complete the Klaerungen lifecycle: 1. Migration 028: iace_clarifications + iace_clarification_comments + iace_clarification_history. Deterministic clarification_key (UNIQUE per project) so engine re-inits don't lose answers. History table logs every status/answer transition. The previous JSONB-in-metadata storage is kept as read-only fallback for pre-migration projects until a one-shot upcopy script runs. 2. Multi-User-Workflow: - assigned_to field on every clarification (free-text user kuerzel for now; an FK to users can be added in a follow-up). - Comment thread per clarification (POST .../comment, GET .../detail returns the thread). - Status-history log written by UpsertClarification when the status or answer actually changes. - Frontend Modal: Zugewiesen-an + Bearbeiter fields, comment thread with inline post, collapsible history section. 3. PDF-Export via print-friendly HTML: - GET /clarifications.html returns a standalone A4-styled document with status badges, norm references, affected hazards and a signature row at the bottom. The Bediener opens the link and uses Strg-P / Cmd-P to save as PDF. No server-side PDF dependency added. - Frontend "PDF / Druck" button next to CSV export. Backend: - internal/iace/store_clarifications.go: UpsertClarification, ListClarificationsForProject, GetClarificationByKey, AddClarificationComment, ListClarificationComments, ListClarificationHistory. - internal/api/handlers/iace_handler_clarifications.go: - AnswerClarification now writes the SQL row, falls back to legacy JSONB read on list. - PostClarificationComment, ListClarificationDetail, ExportClarificationsHTML added. Migration must be applied manually on Mac Mini and prod via psql -f /migrations/028_iace_clarifications.sql — pattern as in scripts/apply_*_migration.sh. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-17 01:39:17 +02:00
Benjamin Admin	f19a75d83d	feat(iace): Klaerungen Phase 2 — Sidebar-Counter + CSV-Export + Hazard-Banner ... Three pieces complete the Klaerungen UX: 1. Sidebar-Counter: layout.tsx polls /clarifications and shows a colored open-count badge on the "Klaerungen" nav item. Refreshes whenever the user changes route. 2. CSV-Export: new backend endpoint GET /sdk/v1/iace/projects/:id/clarifications.csv produces a UTF-8- BOM-prefixed semicolon-separated CSV (Excel-friendly) with ID, Quelle, Kategorie, Frage, Status, Antwort, Begruendung, Bearbeiter, answered_at, anzahl Gefaehrdungen, Gefaehrdungs-Namen, Norm-Refs. Frontend Klaerungen-Seite bekommt einen "CSV-Export"-Button. 3. Hazard-Banner statt Fragentext im Benchmark-Detail: the previous bulleted clarification list was duplicated across 48 hazards for a single FANUC question. Phase 2 replaces it with a compact status badge — "N offene Klaerung(en) — Klaerungen-Seite oeffnen" (orange) or "Alle N Klaerungen beantwortet" (green) with a direct link. Backend cleanup: iace_handler_init.go no longer appends the "Mit Anlagenbauer zu klaeren" block to Hazard.Description. The description stays focused on the scenario; clarifications live in the dedicated endpoint and answers persist across re-inits via project.metadata. The aggregated "Referenzierte Normen" line on the hazard is kept. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-17 01:25:36 +02:00
Benjamin Admin	79efa54898	feat(iace): Klaerungen MVP — Phase 1 ... New page "Klaerungen" between Massnahmen and Verifikation. Backend: - internal/iace/clarifications.go: Clarification struct + ClarificationAnswer + BuildProjectClarifications() — aggregates pattern-level + manufacturer- level questions from collectAllPatterns + GetManufacturerSafetyFeatures. Deterministic IDs ("pattern:HP1640:0", "manuf:fanuc:dual-check-safety-dcs:1") so persisted answers survive every re-init. - internal/api/handlers/iace_handler_clarifications.go: - GET /projects/:id/clarifications returns aggregated list with affected hazard names + persisted answer state, sorted (open first). - POST /projects/:id/clarifications/:cid/answer writes status/answer/ reasoning/answered_by/answered_at to project.metadata.clarification_- answers — no DB schema change. Frontend: - admin-compliance/app/sdk/iace/layout.tsx: new "Klaerungen" nav item. - app/sdk/iace/[projectId]/clarifications/page.tsx: table grouped by source (FANUC / Pattern HP1640 / …), Filter Offen/Beantwortet/Alle, search field, Antwort-Modal with status/answer/Begruendung/Bearbeiter. A clarification answered once applies to ALL referenced hazards — the operator no longer has to answer the same FANUC DCS question on 48 mechanical hazards individually. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-17 01:05:53 +02:00
Benjamin Admin	e9002175ac	feat(iace): manufacturer safety feature library (Stufe A — 50+ entries) ... Adds a curated database of safety-relevant features for the major manufacturers across mechanical/plant engineering, written entirely in own words with norm anchors. No verbatim manufacturer texts — therefore no copyright issue: - Markennennung (§ 23 MarkenG nominative use) is permitted. - Fakten ueber Produkt-Sicherheitsfunktionen are not protected by § 2 UrhG (only Werke, not facts). - NormReferences contain only the identifiers (e.g. "EN ISO 13849-1 PLd Kat.3"), never the norm text itself. Coverage (52 entries across 12 categories): Industrieroboter (10): FANUC DCS, KUKA SafeOperation, ABB SafeMove, Yaskawa FSU, Staeubli CS9, Kawasaki Cubic-S, Mitsubishi MELFA, Universal Robots PolyScope, Doosan PRS, Comau SafeNet CNC/WZM (8): DMG MORI, Mazak, TRUMPF, Okuma, Hermle, Heidenhain SPLC, GROB, Heller Pneumatik (4): Festo, SMC, AVENTICS, Parker Hydraulik (3): Bosch Rexroth, HAWE, HYDAC Safety-PLC / Sicherheitstechnik (8): PILZ, SICK, Schmersal, Euchner, Leuze, Phoenix Contact, Banner, Wieland Standard-PLC (5): Siemens, Beckhoff, Rockwell, Schneider, B&R Pressen (3): Schuler, Bruderer, AIDA Spritzguss (3): Arburg, KraussMaffei, ENGEL Verpackung (2): Krones, Bosch Packaging/Syntegon Laser/Schweissen (3): Bystronic, Amada, Fronius Foerdertechnik (2): Interroll, SEW EURODRIVE Engine integration: - LookupManufacturerFeaturesInText() scans the project narrative for any of the manufacturer aliases (case-insensitive, umlaut-tolerant). - Init-Handler appends matched feature clarifications to the relevant hazard's "Mit Anlagenbauer zu klaeren:" block — for the right HazardCategory only (e.g. FANUC DCS only on mechanical_hazard). - For a Bremse project narrative mentioning "Fanuc Robodrill", the engine now adds clarification questions like "Ist DCS am Roboter konfiguriert?" to relevant mechanical hazards automatically. Tests: 7 new pin tests — manufacturer count, norm prefixes, FANUC/KUKA detection in narrative, umlaut robustness (Staeubli vs Staubli). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-16 23:04:56 +02:00
Benjamin Admin	69729ef6ac	feat(iace): norm references in mitigations + aggregated norm panel per hazard ... Library measures carry NormReferences (EN/IEC/ISO/DIN/TRBS/TRGS Ziff./Kap./ Pos.) but they were dropped on persist: CreateMitigationRequest only wrote Name + Description. The Fachmann benchmark file lists Normen for 34 of 60 hazards — the engine had this data already but lost it on the way to the UI. Fix without DB schema change: - Mitigation.Description gets a "Normen: EN 60204-1 Ziff. 6.2 | EN 61140" line appended when the measure has NormReferences. Pipe separator keeps the inline panel short and grep-friendly. - After all mitigations land, the aggregated dedup'd norm list for the hazard is appended to Hazard.Description as a single "Referenzierte Normen: ..." line so the UI can show one panel per hazard without scanning every mitigation. Audit of library coverage (per-pattern) showed GT-Bremse Normen are generally present and richer: - HP1640 covers GT 2.2 (EN 60204-1 Ziff. 6.2, Ziff. 8.2.3, EN 61140 +) - HP1641 covers GT 2.4 (EN 60204-1 Ziff. 8.2.6 +) - HP1605 covers GT 1.7 (ISO 10218-1 Ziff. 5.6.2, 5.8.3 — Ziff. 5.7.3 fehlt) - HP1671 covers GT 1.30 (EN 12417 — Pos. detail fehlt) Followup: 2 fine-grained sub-paragraph references (5.7.3, Pos. 1.1.4) can be added later as measure-text updates. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-16 22:51:50 +02:00
Benjamin Admin	5ea68ebea4	feat(iace): clarification questions + HP1632 Bersten + HP1637 KSS-Aerosol fix ... 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>	2026-05-16 22:23:56 +02:00
Benjamin Admin	6a3e96d54c	fix(iace): set-based measure-category filter + 235 pattern-author fixes ... 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>	2026-05-16 21:11:02 +02:00
Benjamin Admin	77308b783f	debug: log CreateMitigation errors	2026-05-15 21:52:04 +02:00
Benjamin Admin	9797234ff6	fix(iace): add abbreviations + action words to genericSafetyTerms ... 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>	2026-05-15 16:05:20 +02:00
Benjamin Admin	7080eb5f45	fix(iace): boost robot cell priorities 96-99, remove debug code ... 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>	2026-05-15 16:01:52 +02:00
Benjamin Admin	c93cf2719a	debug: trace M420 in Priority-1 loop	2026-05-15 14:56:05 +02:00
Benjamin Admin	7a27dbc01b	debug: check M420 in measureByID	2026-05-15 14:53:49 +02:00
Benjamin Admin	de35dfce18	debug: add pattern-measure count to init step details	2026-05-15 14:51:26 +02:00
Benjamin Admin	69240faf24	fix(iace): accumulate SuggestedMeasureIDs across dedup'd patterns ... 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>	2026-05-15 14:45:37 +02:00
Benjamin Admin	2b5376ed54	fix(iace): pattern-specific measures take priority over category fallback ... 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>	2026-05-15 14:17:32 +02:00
Benjamin Admin	708c61e50d	fix(iace): max 5 mitigations per hazard — clean per-hazard assignment ... 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>	2026-05-14 23:45:41 +02:00
Benjamin Admin	dc55253b9d	fix(iace): prevent mitigation explosion — fallback only for unassigned ... 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>	2026-05-14 23:41:54 +02:00
Benjamin Admin	8069d0ea89	fix(iace): assign mitigations to ALL hazards per category ... 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>	2026-05-14 23:34:57 +02:00
Benjamin Admin	29fbd03c79	fix(iace): lifecycle labels in benchmark + store all phases ... - 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>	2026-05-14 23:17:27 +02:00
Benjamin Admin	4b9317b4fd	feat(iace): lifecycle phases in patterns + broader robot cell scenarios ... - 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>	2026-05-14 22:38:02 +02:00
Benjamin Admin	cca714755a	fix(iace): stronger relevance filter + matcher wrong-machine penalty ... Relevance filter: now checks PatternName in addition to ZoneDE+ScenarioDE, catches "Spielplatz", "Umreifungsband", "Fahrtreppe" etc. in pattern names. Added more generic safety terms to whitelist (welle, getriebe, kette, etc.) Matcher: rebalanced weights (category 0.3, keywords 0.3, zone 0.4) to prioritize zone/component specificity. Added wrong-machine penalty (0.3x) when engine hazard mentions machine-specific terms absent from GT context (e.g. "Kollision zweier Roboter" for a single-robot GT entry). Fixes 18 problematic matches: 8 wrong-machine, 9 zone-mismatch, 1 category. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-13 15:49:50 +02:00
Benjamin Admin	d31c2fe018	feat(iace): hazard block view — parent/child grouping ... 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>	2026-05-13 11:36:04 +02:00
Benjamin Admin	733d2bcc7b	feat(iace): per-category hazard caps for precision improvement ... Add categoryHazardCap() with ISO 12100-proportional limits: - mechanical: 3x components (min 15, max 60) - electrical: 1x components (min 8, max 20) - secondary (thermal, noise, material): 4-8 - software/IT/organizational: 2-5 (minimal for machinery assessment) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-13 10:00:45 +02:00
Benjamin Admin	be2ac762bd	feat(iace): narrative vocabulary overlap filter replaces blacklist ... 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>	2026-05-13 09:55:25 +02:00
Benjamin Admin	1bd892afbf	feat(iace): narrative relevance filter + zone normalization for precision ... - 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>	2026-05-13 09:51:00 +02:00
Benjamin Admin	8bb90d73e5	feat(iace): benchmark system + erklaerteil + dedup-fix ... - 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>	2026-05-13 01:02:33 +02:00
Benjamin Admin	e785b6d695	fix(use-case-compiler): compile questions from MCs, not hardcoded ... 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>	2026-05-12 17:34:41 +02:00
Benjamin Admin	edbf6d2be5	feat(dsms): Stufe 2+3 — Evidence/TechFile → DSMS + Version Chains + Audit Timeline ... Stufe 2A: Evidence Upload → automatische DSMS-Archivierung - Nach SHA-256 Hash → archive_to_dsms(), CID im Audit-Trail - Evidence mit CID wird automatisch zu E2 (hash-verifiziert) hochgestuft Stufe 2B: IACE Tech-File Export → DSMS - PDF/Excel/DOCX/Markdown Exporte werden nach DSMS archiviert - archiveTechFile() Helper fuer alle 4 Formate Stufe 3A: DSMS Gateway — parent_cid + History Endpoint - parent_cid + tenant_id Felder in DocumentMetadata - GET /documents/{cid}/history — folgt parent_cid-Chain (max 50 deep) Stufe 3C: Audit Timeline UI - Neue Seite /sdk/audit-timeline - Vertikale Timeline mit farbigen Action-Dots - Filter: Alle, Nachweis, DSMS-Archiv, Control, Dokument, DSFA, VVT, TOM - CID-Badges fuer DSMS-archivierte Eintraege Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-12 13:55:07 +02:00
Benjamin Admin	06bfbd1dca	feat(use-case-compiler): MC-based compliance questionnaires with scoring ... Implements the Use-Case Compiler that turns Master Controls into interactive compliance audits. 5 templates (Vendor Check, SAST/DAST, DSGVO, NIS2, CRA), deterministic + LLM question generation, scoring engine with regulation/severity breakdown, and gap detection. - Backend: 9 API endpoints, 22 unit tests (all pass) - Frontend: Template selector, questionnaire, result dashboard - Migration 027: usecase_audits + usecase_answers tables Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-12 13:49:16 +02:00
Benjamin Admin	7d9f5a1f76	feat(iace): LLM-gestuetzte Failure Mode Erkennung ... 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>	2026-05-12 09:52:16 +02:00
Benjamin Admin	6ce5b4bf41	feat(iace): VDA-Format FMEA Excel Export ... - GET /projects/:id/fmea/export → xlsx im VDA-Formblatt - Spalten: Nr, Komponente, Typ, Fehlerart, Fehlerfolge, S, O, D, RPZ, AP, Massnahme - AP-Zellen farbig: H=rot, M=gelb, L=gruen - Dependency: github.com/xuri/excelize/v2 (BSD-3-Clause) - Frontend: "VDA Excel exportieren" Button auf FMEA-Seite Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-12 09:45:18 +02:00
Benjamin Admin	f5664612ad	feat(iace): Einsatzbereich / Branche — filtert branchenspezifische Patterns ... 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>	2026-05-12 09:09:28 +02:00
Benjamin Admin	66d30568e2	feat(dsms): Stufe 1 — Gap-Analyse Report wird in DSMS archiviert ... - Go DSMS Client (internal/dsms/client.go): Archive() + Verify() - Python DSMS Client (compliance/services/dsms_client.py): archive_to_dsms() + verify_dsms() - Gap-Analyse AnalyzeProject() archiviert Report-JSON nach DSMS - Response enthält dsms_cid wenn Archivierung erfolgreich - Frontend: Grünes "Revisionssicher archiviert" Badge mit CID im GapDashboard - DSMS Proxy Route (/api/sdk/v1/dsms/[...path]) für Verify-Abfragen Stufe 2 (Evidence Upload → DSMS) und Stufe 3 (Version Chains) folgen. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-11 23:39:26 +02:00
Benjamin Admin	a0bb9e3aed	feat(iace): "Neu initialisieren" Button + DeleteHazard ... - 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>	2026-05-11 09:17:50 +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	285b74382a	fix(iace): Initialize pipeline reads operational_states from metadata ... 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>	2026-05-11 08:19:53 +02:00
Benjamin Admin	53c641800f	feat(iace): Phase 5 — Betriebszustand-UI + E2E Tests ... - GET /operational-states endpoint (9 States + 20 Transitions) - Frontend: Operational States page with state cards, transitions graph, delta preview - Navigation: Betriebszustaende entry between Grenzen and Normenrecherche - E2E: 60+ new Phase 5 tests (operational states, hazards, mitigations, classification) - E2E: Updated expected counts for expanded libraries (476 measures, 1114 patterns) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-11 00:26:07 +02:00
Benjamin Admin	dabc2358ab	feat(gap): Regulatory Gap Analysis Engine — Phase A Backend ... Product Profile → Regulatory Classification → MC Gap Assessment → Priority List. - 12 regulations supported (CRA, AI Act, NIS2, DSGVO, Data Act, MiCA, PSD2, AML, MDR, Machinery, TDDDG, LkSG) - Scope signal extraction from product profile - Priority scoring: Severity × Deadline × Dependency - 5 industry templates (IoT, Exchange, Cobot, SaaS, Medical) - 8 API endpoints under /sdk/v1/gap/ - DB migration for gap_projects table - Full build passes Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-10 23:11:30 +02:00
Benjamin Admin	9c0d471277	feat(iace): Sprint 4D — Failure Mode Layer (FMEA-Faehigkeit) ... 150 Failure Modes in 11 ComponentTypes: - Sensor (20): Signalverlust, Drift, Falschmeldung, Encoder-spezifisch - Controller (20): Watchdog, Speicher, Bus, Safety-SPS CCF, Antrieb - Actuator (15): Blockiert, Ueberlast, Haltekraftverlust, Schuetz verschweisst - Mechanical (20): Ermuedungsbruch, Lagerschaden, Kettenriss, Werkzeugbruch - Electrical (15): Isolation, Kurzschluss, Erdschluss, Lichtbogen - Software (15): Exception, Race Condition, Buffer Overflow, Timing - Hydraulic/Pneumatic (15): Schlauchplatzer, Ventil blockiert, Kavitation - Safety Device (15): Failure-to-trip, CCF, Bremsenverschleiss, PL-Degradation - Network (10): Paketverlust, Latenz, Man-in-the-Middle - AI/ML (5): Model Drift, Adversarial Input, Bias Architektur: - FailureModeEntry Struct mit FMEA-Scores (Severity/Occurrence/Detection 1-10) - RPZ = S x O x D (max 1000, Schwelle >= 100 = Massnahme erforderlich) - RequiredFailureModes auf HazardPattern fuer FM-gesteuertes Pattern-Matching - MatchInput.FailureModes + MatchReason "failure_mode" (Explainability) - GET /failure-modes?component_type= API-Endpoint 10 Tests: Count, UniqueIDs, ValidTypes, NonEmpty, Distribution, RPZ (3x), NilFires, RPZDistribution Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-10 22:24:02 +02:00
Benjamin Admin	9a9a11b248	feat(iace): Sprint 4C — Delta Impact Analysis ... Neuer Endpoint POST /projects/:id/delta-analysis: - Input: aktuelle + vorgeschlagene Aenderung (Components, Energy, States, Roles) - Output: Diff der Pattern-Matches (added/removed Patterns, Hazards, Measures) - DeltaMatch() auf PatternEngine: Match(current) vs Match(proposed) - DeltaResult mit AddedPatterns, RemovedPatterns, Counts, SummaryDE Beispiel-Output: SPS hinzufuegen → +55 Patterns, +5 Hazard-Kategorien, +17 Massnahmen Maintenance-State hinzufuegen → +10 Patterns, +2 Hazards, +2 Massnahmen 7 Tests: NoChange, AddComponent, RemoveComponent, AddState, AddRole, Summary, Symmetric Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-10 21:23:46 +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	f07c4db164	feat(iace): Sprint 3B — Human Interaction Model ... - 6 Standard-Rollen: operator, maintenance_tech, programmer, cleaning_staff, bystander, supervisor - HumanRoles []string Feld in HazardPattern, MatchInput, PatternMatch - patternMatches() filtert Patterns nach Rolle (nil = feuert fuer alle Rollen) - MatchReason um human_role Typ erweitert (Explainability) - 25 bestehende Patterns mit Rollen annotiert: - Cobot HP059/062/064 → operator/programmer - Maintenance HP700-714 → maintenance_tech/programmer - Operational HP070/073-078/080 → operator/maintenance_tech/programmer - Init + Parser Handler reichen Roles an MatchInput durch - 4 neue Tests: NilFiresAlways, MaintenanceTechFilter, ProgrammerTeachMode, RoleCount Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-10 08:22:55 +02:00
Benjamin Admin	77a497d930	feat(iace): Sprint 3A — Operational State Graph + fix(ucca) flaky keyword sort ... State Graph: - 9 Standard-Betriebszustaende (startup, homing, automatic_operation, manual_operation, teach_mode, maintenance, cleaning, emergency_stop, recovery_mode) - 20 State-Transitions als gerichteter Graph - OperationalStates + StateTransitions Felder in HazardPattern, MatchInput, PatternMatch - patternMatches() filtert Patterns nach Betriebszustand (nil = feuert immer) - Narrative-Parser extrahiert States aus Maschinenbeschreibung (22 Keywords + 4 Transition-Keywords) - 27 bestehende Patterns mit State-Einschraenkungen annotiert (10 operational, 15 maintenance, 2 cobot) - MatchReason um operational_state + state_transition Typen erweitert (Explainability) - 6 neue Tests: NilFiresAlways, MaintenanceFilter, StateTransition, MatchReasons, Count, TransitionValid UCCA fix: - Stabiler Tiebreaker (Pattern-ID aufsteigend) bei gleichem Keyword-Score in MatchByKeywords - Behebt flaky TestControlPatternIndex_MatchByKeywords (1/10 Failure-Rate durch Go map iteration order) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-10 08:05:02 +02:00
Benjamin Admin	2e29b611c9	feat(iace): Phase 1 — Haftungs-Fixes, Massnahmen-Verkabelung, Explainability Engine ... Phase 1A — Haftungs-kritische Fixes: - SIL/PL-Badges als "Vorab-Einschaetzung" mit Tooltip gekennzeichnet - Coverage-Disclaimer in CE-Akte, Projekt-Uebersicht und Print-Export - Norm-Referenzen: 42 Kapitelverweise durch Themen-Deskriptoren ersetzt Phase 1B — Massnahmen-Verkabelung: - 16 neue Massnahmen (M201-M216) fuer bisher unabgedeckte Kategorien (communication_failure, hmi_error, firmware_corruption, maintenance, sensor_fault, mode_confusion) - Kategorie-Fallback im Initialize-Endpoint: ordnet Massnahmen aus der Bibliothek automatisch per HazardCategory zu (max 8 pro Kategorie) - Total: 225 → 241 Massnahmen, 0 Kategorien ohne Massnahmen Phase 1C — Explainability Engine: - MatchReason Struct in PatternMatch (type, tag, met) - Pattern Engine schreibt fuer jeden Match strukturierte Begruendungen - Frontend zeigt "Erkannt weil: Komponente X, Energie Y, Kein Ausschluss Z" Weitere Aenderungen: - BAuA/OSHA Regulatory Hints: 3 Enrich-Endpoints (per Hazard, per Measure, Batch) - Dokumente-Tab in IACE-Bibliothek (36.708 Chunks aus Qdrant) - Varianten-UX: Basis-Projekt-Summary auf Varianten-Seite - Projekt-Initialisierung: POST /initialize kettet Parse→Komponenten→Patterns→Hazards→Massnahmen→Normen - 18 pre-existing TS-Fehler gefixt, Route-Konflikt behoben - Component-Library + Measures-Library Tests aktualisiert Tests: Go alle bestanden, TS 0 Fehler, Playwright 141+ bestanden Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-09 21:32:23 +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