75 Commits

Author	SHA1	Message	Date
Benjamin Admin	916dec87ee	Merge feat/iace-llm-fm-frontend: KI-Vorschlag Uebernehmen/Ablehnen + AP tests	2026-05-22 12:00:10 +02:00
Benjamin Admin	872145d883	feat(iace-fmea): KI-Vorschlag Uebernehmen/Ablehnen flow + AP unit tests ... Closes the loose end from IACE Phase 5 handover: the LLM FM-suggest button existed and the backend endpoint was wired, but accepted suggestions had no path into the FMEA worksheet. Hook (useFMEA.ts): - acceptSuggestion(fm, componentId): builds an FMEARow from FM defaults, prepends to rows (sorted by RPZ), removes the FM from suggestions. No-ops + drops the suggestion when (component, fm.id) is already in rows. - rejectSuggestion(fmId): drops the FM from suggestions list. Page (fmea/page.tsx): - Suggestion cards now have explicit Uebernehmen / Ablehnen buttons. - Counter "X Vorschlaege uebernommen" tracks accept count for the run. - RPZ in each suggestion is colour-coded (red >200, orange >100). - Hinweis line explains S/O/D adjustability after acceptance. - acceptedCount auto-resets when suggesting starts or panel closes. Tests (useFMEA.test.ts): - 8 calculateAP cases covering AIAG-VDA 2019 boundary points for severity 10 / 9 / 7 / 5 / 3, validating the H/M/L action priority matrix. LOC: fmea/page.tsx hits 320 (soft target 300, well under 500 hard cap). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-22 09:56:05 +02:00
Benjamin Admin	0a84c747f2	feat(iace): wire crossref into tech-file, library UI, and contract tests ... Three follow-ups to the 671-norm cross-reference matrix: 1. Tech-file renderer (Go): standards_applied section now gets a deterministic Markdown appendix with the DIN/ANSI/GB/JIS mappings for the project's suggested norms. Built from registry, never hallucinated by LLM. Applied both to LLM and fallback content paths. 2. Frontend NormCrossRefPanel (Next.js): expandable row in the IACE library norms tab now has a "Internationale Aequivalenzen anzeigen" button that lazy-loads /iace/norms-library/:id/crossref and renders a colour-coded table (relation + confidence). Region labels humanised (US — ANSI, China (GB), Japan (JIS), etc.). 3. Contract tests (Go): 4 new handler tests pinning the response shape of GetNormCrossRef and ListNormCrossRefs. Equivalent to an OpenAPI snapshot for these specific endpoints — ai-compliance-sdk has no full OpenAPI baseline yet (separate ticket). Tests: 6 renderer tests + 4 handler contract tests, all green. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-22 09:48:07 +02:00
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	c5c168592b	feat(licenses): Task #25 — SDK module attribution rollout (11 modules) ... Per project_sdk_module_attribution_matrix.md the Stufe-3 rollout is prioritized by audit visibility. This batch covers Schritte 2-9 in one sweep: New reusable component: components/sdk/LicenseModuleBanner.tsx — single-line license banner placed at the top of an SDK module page. Renders rule pill (R1/R2/R3), source label, descriptor and link to /sdk/licenses. Replaces the copy-paste banner blocks I inlined in the earlier modules. Integration points (per cluster): Cluster B (DSGVO/EU-Recht, R1): - vvt: existing "Vorlage" pill upgraded with R1 marker + tooltip explaining Bundeslaender-DSGVO provenance - dsfa: inline R1 banner citing DSGVO Art. 35 Cluster C (EU AI Act / CRA, R1): - ai-act: inline R1 banner citing EU 2024/1689 - cra: inline R1 banner citing EU 2024/2847 + ENISA-Guidance Cluster D (Mix R2/R3): - isms: R3 banner + ISO/IEC 27001 reference disclaimer - security-backlog: R2 banner with OWASP CC-BY-SA attribution Cluster A (Eigenwerk, R3): - tom-generator: R1 source (DSGVO Art. 32) + R3 own-work disclaimer - audit-checklist: R3 banner for own audit methodology - document-generator: own templates R3 + cited rights R1 Cluster E (Direct controls listing): - catalog-manager: System/User tag upgraded with rule classification - iace hazards: pattern_id pill upgraded with R3 + tooltip explaining BreakPilot Pattern-Engine provenance The 11-module sweep brings audit transparency to the modules a paying customer encounters most often. Stufe 3 of the attribution renderer is now actually visible across the platform — previously it shipped only the reusable <SourceBadge> component without integration points. Pre-existing TS errors (drafting-engine constraint-enforcer, dsfa types tests) untouched — not in scope for this licensing rollout.	2026-05-21 23:16:09 +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	3faa312b31	feat(iace/verification): derived view on relevant mitigations + 2 actions ... 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>	2026-05-17 14:49:56 +02:00
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	f4c9cea770	feat(iace/mitigations): group measure rows by title, collapse 21x→1 row ... The "Maßnahmen" page in the Bremsscheibe project showed a flat list with heavy redundancy — e.g. "Sicherheitszeichen nach ISO 7010" appeared on 21 separate rows, one per linked hazard. Same for "Gefahrenpiktogramme", "Flucht- und Rettungswege" etc. The signal got lost in the noise. This is a presentation-only regrouping. Each Hazard×Mitigation pair stays a separate DB row with its own status, notes and edit history (option B from the discussion: instances remain independently editable). The page now collapses rows that share the same `m.title` into one group row. Group row shows: - title + ISO 12100 sub-category (if encoded in description) - count of linked hazards on the right - compact status distribution "P · I · V" (Planned/Implemented/Verified) - shared checkbox that selects all instances in the group Click expands the group and reveals the individual hazard×measure rows, each with its own StatusBadge and detail-expand for MitigationHints. State additions: - expandedGroup: Set<string> with keys `${type}:${title}` so the same title across different reduction stages stays independently togglable - groupByTitle() helper trims the title, falls back to "(ohne Titel)" - statusCounts() helper for the P·I·V breakdown Pagination semantics swapped from 50 instances/page to 50 groups/page — makes the list far easier to scan at the ~80-instance scale this project exhibits. LOC: 267 → 346 (well under the 500 hard cap). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-17 13:50:45 +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	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	74f66c4c34	fix(admin/iace/benchmark): show Klaerungsfragen + Normen on Engine column ... The Go init handler appends two annotated blocks to Hazard.Description ("Mit Anlagenbauer zu klaeren: ..." and "Referenzierte Normen: ...") without changing the DB schema. The benchmark detail view only rendered hazard.scenario || hazard.description, so the appended blocks were silently hidden because scenario is always populated. Split the description into three structured pieces: 1. extractScenario() — pure scenario text, stripped of trailing blocks 2. extractClarifications() — bullet list of "Mit Anlagenbauer zu klaeren" 3. extractEngineNorms() — pipe-separated norm references Each piece is rendered as its own DetailRow. The FANUC DCS clarification that already lives in the DB (48/115 hazards on the Bremse project) is now visible in the Engine column. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-17 00:42:41 +02:00
Benjamin Admin	3b7ab4cbd7	feat(iace): 50% display threshold — weak matches shown as separate ... Matches below 50% are now split: - GT entries → "Fehlend" tab (not matched by engine) - Engine entries → "Engine Findings" tab (additional findings) Only matches >= 50% shown in "Zugeordnet" tab. Coverage score now counts only real matches (>= 50%). "Extra" tab renamed to "Engine Findings" for clarity. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-15 10:33:29 +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	98e5b1a8aa	feat(iace): show lifecycle phases + affected persons in benchmark detail ... Backend: HazardSummary now includes lifecycle_phase and affected_person Frontend: Engine detail column shows Lebensphasen and Betroffene Personen Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-14 23:10:15 +02:00
Benjamin Admin	6940271672	feat(iace): expandable detail comparison in benchmark tab ... Backend: HazardSummary now includes description, scenario, possible_harm, trigger_event, and mitigations[] for side-by-side comparison. Frontend: Each matched pair row is now clickable/expandable showing two-column detail view: - Left (GT): hazard type, cause, zone, lifecycle phases, risk values (F/W/P/S->R), residual risk, measures, type (KM/TM/BI), norms, comment - Right (Engine): name, scenario, zone, possible harm, trigger, measures Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-13 15:36:18 +02:00
Benjamin Admin	64e3a47b8c	fix(iace): confirmation dialog for ungrouping + undo/regroup ... - X button replaced with confirmation dialog: "Als eigenen Punkt fuehren" / "Abbrechen" - Dialog explains the action and that it's reversible - Ungrouped items show orange "Zurueck in Block" button - Info bar shows count of ungrouped items + "alle zuruecksetzen" link - No destructive action without user confirmation Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-13 15:19:39 +02:00
Benjamin Admin	81a0568537	feat(iace): block-aware risk table + benchmark quality badges ... Risk Assessment tab now shows block grouping: - BlockAwareRiskTable: Parents bold/purple, children indented - Collapse/expand blocks, "Abgedeckt" badge for covered children - Ungroup button to remove child from block - Info bar showing block count and covered children Benchmark tab improvements: - Green/Yellow/Red quality badges (Exakt/Aehnlich/Schwach) - GT risk factor detail (F/W/P/S) shown per entry - Match counts in tab header (X exakt, Y aehnlich) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-13 15:00:19 +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	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	65b4857be5	feat(iace): KI-Vorschlag Button im FMEA-Tab ... - Dropdown: Komponente waehlen → "KI-Vorschlag" klicken - Ruft POST /projects/:id/components/:cid/suggest-fms auf - Zeigt LLM-generierte oder Bibliotheks-FMs als Overlay - Jeder Vorschlag mit Name, Auswirkung, S/O/D, RPZ Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-12 10:07:10 +02:00
Benjamin Admin	93028b443e	feat(iace): FMEA Bedienungsanleitung — ausklappbare Info-Box ... Erklaert S/O/D Skalen, RPZ + AP Kennzahlen, konkretes Beispiel (SPS Kommunikationsausfall), Workflow-Schritte. Fuer Nicht-Experten. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-12 09:54:56 +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	4e865d2997	feat(iace): CE-Flag auf Komponenten + AIAG-VDA Action Priority (AP) ... CE-Flag: - Toggle "Bereits CE-gekennzeichnet" im ComponentForm - ce_marked Boolean auf Component (via metadata JSONB, kein DB-Change) - Hinweis "(Nur Schnittstellen bewerten)" im Formular AIAG-VDA Action Priority: - CalculateAP(S,O,D) → H/M/L nach AIAG-VDA FMEA Handbuch 2019 - AP-Spalte in FMEA-Worksheet: H=rot, M=gelb, L=grün - Ergänzt (nicht ersetzt) die bestehende RPZ-Berechnung Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-12 09:15:43 +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	6586d2cb5e	fix(iace): Delta + FMEA — derive component tags from names when library_id missing ... Auto-created components have no library_id. Delta analysis and FMEA now derive pattern-engine-compatible tags from component names (e.g. "Roboter" → cobot/robot_arm, "SPS" → controller/plc, "Scanner" → sensor). Also: new E2E test file iace-extensions.spec.ts (FMEA, Knowledge Graph, Delta API, Failure Modes API). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-12 08:26:15 +02:00
Benjamin Admin	df15f6f098	feat(iace): Erweiterung 5 — Safety Knowledge Graph (React Flow) ... Interaktiver Graph: Komponente → Gefaehrdung → Massnahme - 3-Spalten-Layout: Indigo (Komponenten), Rot (Hazards), Gruen (Massnahmen) - Animierte Kanten mit Pfeilmarkern - Zoom, Pan, MiniMap, Controls - Dependency: @xyflow/react v12 (MIT-Lizenz) Alle 5 IACE Phase-5 Erweiterungen jetzt abgeschlossen: 1. Betriebszustand-UI 2. FMEA-Worksheet 3. Delta-Impact-Preview Modal 4. Textil + Landmaschinen Patterns 5. Safety Knowledge Graph Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-12 07:20:38 +02:00
Benjamin Admin	bcf78c120a	feat(iace): Erweiterungen 2-4 — FMEA Worksheet, Delta Modal, Textil+Agri ... Erweiterung 2: FMEA-Worksheet Tab (/fmea) - Tabelle: Komponente | Typ | Fehlerart | Auswirkung | S | O | D | RPZ | Bewertung - RPZ-Farbcodierung: >200 Kritisch, >100 Handlungsbedarf, >50 Beobachten - Stats: Gesamt, Kritisch, Handlungsbedarf, Akzeptabel Erweiterung 3: DeltaPreviewModal (wiederverwendbar) - Modal zeigt +/- Patterns, Hazards, Massnahmen bei Aenderungen - Nutzt POST /delta-analysis Endpoint - Summary Grid + detaillierte Listen Erweiterung 4: Textilmaschinen (EN ISO 11111) + Landmaschinen (ISO 4254) - 21 neue Patterns: HP1550-HP1559 (Textil), HP1565-HP1575 (Agri) - 23 neue Massnahmen: M452-M460 (Textil), M461-M474 (Agri) - Walzenspalt, Zapfwelle, ROPS, autonomer Traktor, Siloexplosion etc. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-12 07:08:56 +02:00
Benjamin Admin	6f776b2fa8	fix(iace): FAB pointer-events fix + Initialisieren auf Betriebszustaende-Seite ... - FAB-Container bekommt pointer-events-none, nur Button + Panel sind klickbar (behebt: Buttons auf der rechten Seite waren nicht klickbar) - Initialisieren + Neu-Initialisieren Buttons von Interview-Seite auf Betriebszustaende-Seite verschoben (natuerlicher Flow: Grenzen → States → Init) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-11 11:18:12 +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	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	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
Benjamin Admin	4d708b4443	feat(iace): add withdrawn filter to norms library frontend ... - Add withdrawn/valid_until/replaced_by to Norm interface - Add Status filter (Aktiv/Zurueckgezogen) — defaults to "Aktiv" - Withdrawn norms hidden by default, viewable via filter Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-09 08:50:26 +02:00
Benjamin Admin	c89e46a828	feat: Dokumenten Upload im Normenrecherche-Tab ... Drag & Drop Upload-Zone fuer kundeneigene PDFs (Normen, Spezifikationen). Tenant-isoliert, Status-Tracking, Backend-Placeholder fuer RAG-Pipeline. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-09 08:07:58 +02:00
Benjamin Admin	c6229a2c22	fix: Tech-File html_content → content Mapping ... API liefert html_content, Frontend erwartet content. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-08 06:46:51 +02:00
Benjamin Admin	c27022d11b	feat: CE-Akte mit Anhang IV + Tech-File Sections fuer alle 4 Projekte ... - 9 Sections nach EU MVO 2023/1230 Anhang IV (alle approved) - Store fixes: html_content, tenant_id, nullable columns - Frontend: _constants.ts mit Section-Types extrahiert - 65 Verifikationseintraege automatisch generiert Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-08 01:49:14 +02:00
Benjamin Admin	89af88ef7d	feat: Fortschritts-Tracker + Verifikation-Endpoints + Tech-File Erweiterung ... - Übersicht: Completeness Gates durch Projektfortschritts-Tracker ersetzt (6 CE-Prozessschritte mit Status + Naechster-Schritt Empfehlung) - Verifikation: GET/POST/DELETE /verifications Endpoints + Alias-Handler - Tech-File: Anhang IV Struktur-Erweiterung - Maßnahmen: Expandable Details vorbereitet Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-08 01:02:41 +02:00
Benjamin Admin	136dc4d553	feat: Normen-Referenzen in Hazards + Massnahmen + Normenrecherche-Tab ... - Hazard Log: Top 2 relevante Normen pro Kategorie unter dem Kategorie-Badge - Massnahmen: Normen-Referenzen aus measures_library inline anzeigen - Navigation: Neuer Normenrecherche-Tab (zwischen Grenzen und Komponenten) - Normenrecherche-Seite: SuggestedNorms + A/B/C Erklaerung Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-08 00:18:45 +02:00
Benjamin Admin	a708d139ab	feat: IACE Bibliotheks-Browser — 751 Normen, 1000 Patterns, 200 Massnahmen ... Neue Seite /sdk/iace/library mit 3 Tabs: - Normen: Suche + Filter A/B/C + Pflicht + Beuth-Links - Patterns: Suche + Filter Kategorie/Prioritaet + Details aufklappbar - Massnahmen: Suche + Filter Design/Schutz/Information Alle mit Pagination (50/Seite) und Zaehler-Badges. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-08 00:09:31 +02:00
Benjamin Admin	78d7273b82	fix: Verifikation — Suchfeld statt 654 Mini-Kacheln + Lazy-Load ... - SuggestEvidenceModal: Suchfeld + max 20 Ergebnisse statt alle Kacheln - Verification page: Mitigations nur on-demand laden (nicht beim Seitenstart) - Deutlich schnellerer Seitenaufbau Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-07 18:33:21 +02:00
Benjamin Admin	58a3fb285f	fix: Erstbewertung aus risk_assessment + Pagination + Projektname ... - Erstbewertung S/E/P liest jetzt aus risk_assessment statt hazard - Hazards: Pagination 50 pro Seite mit < > Navigation - Massnahmen: Lazy-Load 50 pro Accordion mit "Mehr laden" - Sidebar: Projektname (z.B. "Kniehebelpresse HP-500") prominent - Uebersicht: Nur 2 API-Calls (keine schweren Listen) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-07 17:51:59 +02:00
Benjamin Admin	5be1c171cb	fix: Performance + Hazard-Tabelle Layout ... - Uebersicht: Nur noch 2 leichte API-Calls statt 4 (risk-summary statt alle Hazards/Mitigations laden) - RiskAssessmentTable: Gefaehrdungs-Spalte min-w-[250px] statt max-w-[200px], kein truncate mehr Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-07 17:26:28 +02:00
Benjamin Admin	a3671d4a06	fix: Massnahmen-Layout proportional statt fix ... 2fr:1fr statt 1fr:200px — skaliert auf allen Bildschirmgroessen. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-07 16:48:42 +02:00
Benjamin Admin	cd5f986489	fix: Massnahmen-Tabelle Layout — volle Textbreite statt truncate ... Grid-Layout statt flex mit fixen Breiten. Texte umbrechen statt abschneiden. Gefaehrdung-Spalte 200px, Status 80px. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-07 16:35:09 +02:00
Benjamin Admin	a1b9273649	fix: Grenzen-Formular — groessere Textfelder + vollstaendige Daten ... Allgemeine Beschreibung: 12 Zeilen (war 5) Fehlanwendungen: 10 Zeilen (war 6) Default TextArea: 6 Zeilen (war 3) Seed v2: Vollstaendige Texte + maschinenspezifische Inhalte Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-07 16:20:05 +02:00
Benjamin Admin	a93ba9ee40	feat: Custom Hazard Modal + Residual Risk Panel ... - CustomHazardModal: Eigene Gefaehrdung erstellen mit S/E/P/A Slidern - ResidualRiskPanel: Akzeptabel-Toggle pro Hazard + Fortschrittsbalken - RiskAssessmentTable: Accept/Reject Buttons pro Zeile integriert Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-07 16:09:50 +02:00