Liest den Lebenszyklus jedes Befunds (status + tracker_issue_url) aus dem
Scanner zurück und rollt ihn zu einem Management-Bild auf: % erledigt,
4-Phasen (offen/in Arbeit/erledigt/ausgeschlossen), offenes Restrisiko nach
Schweregrad, Fortschritt je CRA-Anforderung und eine Aufgaben-/Ticket-Tabelle
mit Jira-Link. Neuer Endpoint GET/POST /api/v1/cra/progress (dünn → Service
cra_progress, rein deterministisch, kein /assess-Schema-Drift). Frontend:
ProgressView in Ebene 1 (CRACyberView), live je Scanner-Repo, sonst Demo-Status.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Jede Normreferenz einer Maßnahme wird lizenzklassifiziert (eu_law /
public_domain / open / paid_reference) — paid-reference-Normen werden nur als
Verweis geführt, nie im Text gespeichert (idea/expression). Kuratierte
Maßnahmen tragen Tier 'core', KI-/Fallback-Maßnahmen 'review' (indikativ).
Frontend zeigt Quellen-Badges + "indikativ"-Kennzeichnung. Methodik in
docs-src/development/mapping-methodology.md (Szenario C, Due-Diligence).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Ersetzt die ephemere Dropdown-Auswahl durch DB-Persistenz pro IACE-Projekt:
- Migration 156: compliance_cra_scanner_repo_map (tenant_id, iace_project_id PK,
scanner_repo_id). Additiv + idempotent.
- GET/PUT /v1/cra/scanner-repo-map/{iace_project_id} (Upsert/Clear).
- useCRA lädt das gespeicherte Repo beim Laden + persistiert bei Auswahl.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
- GET /v1/cra/scanner-repos: distinct repo_ids (+counts) vom Scanner-MCP für den Picker.
- useCRA: scannerRepo-State; bei Auswahl POST /assess-from-scanner (echte Findings),
sonst by-iace/Demo wie bisher.
- ScannerRepoPicker im CRA/Cyber-Tab; leere Auswahl = Demo, Repo gewählt = echte Befunde.
Mapping repo_id↔Projekt aktuell UI-seitig (ephemeral); DB-Persistenz pro Projekt folgt.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Frontend (CRA/Cyber-Tab):
- Erklär-Zwischensätze je Ebene (Befund -> CRA-Anforderung -> Best-Practice-
Standard -> Maßnahmen) + "So liest du einen Befund"-Legende.
- Kuratierte M-Maßnahmen und atom-grain "Regulatorische Breite" in EINE Sektion
"Maßnahmen (wählbar)" zusammengeführt (statt zwei konkurrierender Listen).
- Standalone "Empfohlene Maßnahmen (Sollzustand)" entfernt (jetzt je Befund).
Backend:
- Atom-Controls-Query liefert jetzt cpl.source_article (Artikel/Anhang/Erwägungs-
grund-Anker) zusätzlich zu source_regulation; via LATERAL-Join.
- enrich_findings_with_breadth trägt source_article in regulatory_breadth.
- Daten waren schon ingestiert (682/691 CRA-Atome haben source_article) — wurden
nur nicht selektiert/angezeigt.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Migration 153 adds compliance_cra_projects.linked_iace_project_id (additive,
idempotent). New thin router cra_link_routes.py: POST /projects/{id}/link-iace
sets the reference; GET /by-iace/{iace_project_id} returns the linked CRA project
+ its latest assessment snapshot. The IACE "CRA / Cyber" tab now resolves the
linked CRA assessment first (real, from the snapshot) and only falls back to the
demo scenario when nothing is linked. One assessment, two views.
[migration-approved] — user approved the new column for the CRA<->IACE reference.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
All 6 security use_cases are atom-grain now. Per finding we draw two lanes: the
CRA corpus (use_case=cra, the most on-point CRA obligations) + the technical
depth (code_security for secure-dev, else network_security). Controls merged,
deduped, each tagged with its use_case (shown in the best-practice depth).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Both network_security and code_security are now atom-grain. Per-sub_topic
use_case routing: secure_development -> code_security (best for secure-dev
findings), everything else -> network_security. Findings carry breadth_use_case
so the source context (which atom corpus) is visible under the best-practice depth.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Semantic breadth (2): each finding's CRA-AI is mapped to a network_security
sub_topic and enriched with atom-grain, framework-traceable obligations from the
shared Controls-API (compliance.atom_classification) — at the endpoint/view layer
(SessionLocal), NOT in the pure mapper. CRA-AI anchor + curated measure +
NIST/OWASP crosswalk stay the lead; this is breadth + source evidence. Only
network_security is queried (atom-grain), scoped by sub_topic + limit. Frontend
renders it under the collapsible best-practice depth (control_id · title · source).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Snapshot/history: "Snapshot speichern" + a version list (status, date, coverage)
you can click through — makes the CRA Art. 13 running system visible (backend
endpoints already live). Measure-class: each finding shows a remediation-class
badge from its CRA evidence_type ("Code-nah" = scan-locatable, code-fix in the
ticket possible; otherwise Prozess/Doku), and the measures section is relabelled
as the Sollzustand (process/build) — no auto-fix buttons on process measures.
Backend: MappedFinding now carries evidence_type.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Deterministic bridge (cra_safety_bridge.py): a cyber finding's attack capability
(remote_actuation / code_tampering / integrity_loss / auth_bypass, derived from
its CRA category) is matched against what each CE safety function is vulnerable
to. A match re-opens the mitigated hazard, flags the finding safety_impact (which
floors it to P0), and produces the cross-link. Endpoint accepts safety_functions;
frontend passes the project's safety functions and renders the LIVE cross-links
(no more hardcode). Safety functions are demo input now; come from the CE risk
assessment in production.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
CRA tab now shows the priority layer: a weights control (5 business objectives,
high/medium/low) that re-computes the assessment live; a Prio column with
P0..P3 tier badges (P0 = non-negotiable floor, reason on hover); the table in
backend priority order; and a Quick-Wins block (high impact, low effort). Demo
flags the safety-cross-linked findings as safety_impact so the P0 floor shows.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
CRA tab now computes the assessment live: useCRA POSTs the scenario findings
through a new /api/v1/cra/* proxy to the backend mapper and merges the live
mapping (CRA requirement, risk, measures, NIST/OWASP crosswalk) with the
frontend scenario constants (full measure texts + cyber->safety cross-links,
until those move server-side in step 2). Falls back to the static scenario if
the backend is unreachable.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Per the Co-Pilot-calm principle: the findings table stays compact (Befund /
CRA-Anforderung / Risiko / Maßnahmen) and the NIST/OWASP + ISO 27001
best-practice depth is revealed per finding via a "NIST/OWASP" toggle. Keeps
the 3-layer model (CRA obligation -> measure -> best-practice depth) tidy.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Crosswalk (cra_security_crosswalk.py): deterministic, hand-curated CRA Annex I ->
NIST 800-53 Rev5 + OWASP Top 10:2021 mapping, the authoritative Security Golden
Set (no RAG; semantic breadth comes later via the shared Controls-API). Mapper
attaches NIST/OWASP refs per finding; golden-set completeness pinned by test
(every requirement has >=1 NIST ref). CRA tab now shows the NIST/OWASP best-
practice refs per finding and the full curated measure texts + norm references
(from measures_library_cra.go).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
New "CRA / Cyber" tab in the IACE project (Zusatzmodule). Treats the
Kistenhubgeraet CE project as if it had an IoT module; invented cyber findings
are mapped to CRA Annex I requirements via the REAL backend mapper output
(faithful), and crucially cross-linked to the existing CE safety hazards they
re-open (cyber defeats a mechanically-mitigated guard -> CRA x Machinery Reg).
Frontend fixture for now; live wiring to the mapper endpoint follows.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Quote-verifiable failure extraction via Claude (Haiku 4.5): PDF sent
directly, tool-schema forces verbatim source quotes + applicable flag +
confidence — replaces the unreliable local llama run. Only applicable=true
tuples ingest into bp_iace_failure_kb; every processed doc lands in the
source manifest.
Frontend: FMEA tab now shows a "Quelldokumente" register (every document we
use, with source + licence + link + what was extracted) served from the
embedded manifest via GET /iace/failure-knowledge/sources. Manifest is
placeholder until the 100-doc Haiku run is folded in.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
- architecture.go: DataSources now reflect the real ingested set (ESAW 2023,
BLS CFOI, OSHA OTM, PRISM, cobot CC-BY, HSE) with their RAG collections;
risk stage cites BLS + the searchable RAG layer; matrix stage now mentions
the distance-benchmark dimension.
- Architektur & Datenfluss tab: new DataFlowDiagram — 4 lanes (input →
knowledge/RAG-evidence → deterministic engine → outputs) with live counts.
- scripts/ingest_iace_kb.sh: idempotent E1 ingest — creates the 2 collections
and uploads the 6 datasources docs against a configurable RAG_URL (for prod
Qdrant), with retry.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Surface result.distances in the benchmark module: a DistanceComparison
panel showing agreement %, covered values (green), GT-only gaps (amber)
and engine-only extras — mirroring the RiskComparison panel.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The Risikobewertung page only mentioned the data sources as static prose.
Add a collapsible "Datenquellen & Evidenz" panel sourced from
/iace/risk-data-sources: the real Eurostat ESAW 2023 contact-mode shares
per mode, with license + ready-to-print attribution, and the note that
tiers anchor the ordering while values stay GT-calibrated.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Makes the OSHA minimum-distance anchor visible per measure in a project
without a DB schema change or re-seed: persisted mitigations store the
measure NAME verbatim (not the catalog ID), and measure names are unique
across the 578-entry library (pinned by test), so a name→ID resolver
bridges the gap.
Backend: MeasureIDByName + MinimumDistancesForMeasureName/LinksForMeasureName;
/iace/minimum-distances now accepts ?measure_name=; link table enriched with
measure_name for one-request UI matching.
Frontend: useMinimumDistances loads the link table once and keys it by name;
OshaDistanceNote renders the anchor (value/CFR/license/EU-hint/relation) on the
matching measure group in the Maßnahmen tab.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Adds an auditor-facing view of the IACE engine: a clickable 10-stage
pipeline flow (Grenzen-Formular → ParseNarrative → Pattern-Gates →
Relevanz → Caps → Gefährdungen → Maßnahmen → Risiko → Normen → Matrix),
plus live library counts, the data-source/license register (incl. the
DIN/Beuth + DGUV exclusions), and the norm-matching logic that reconciles
DIN/ISO/OSHA machine-type vocabulary via canonicalMachineType folding.
Backend: BuildArchitecture() with LIVE counts so the diagram can never
drift; GET /iace/architecture; collectAllNorms() extracted from
SuggestNorms as the single source of truth for the norm-library count.
Frontend: useArchitecture hook + page + new IACE nav tab.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Adds GET /projects/:id/risk-matrix — a confidence-aware risk view computed
on read from each hazard's category/scenario/lifecycle using the SAME model
as the GT benchmark (no persistence, so it never goes stale against the
model; the hand-defaulted iace_hazards risk columns stay untouched).
- risk_matrix.go: EstimateHazardRisk (single source of truth for S/F/W/P +
range + level + confidence) and BuildRiskMatrix (per-hazard list + a 5×5
Severity×Probability aggregation grid with dominant level per cell).
- Frontend: RiskMatrix grid in the Risikobewertung tab (muted colours per
the confidence-aware tonality), level counts + tool-confidence summary,
fed by useRiskMatrix. Shows risk for EVERY project, not only GT ones.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Eliminate the pre-existing TS errors that were masked by
next.config.js `typescript.ignoreBuildErrors: true`, then turn the flag
OFF so the compiler is a real safety net for future changes. `next build`
and `tsc --noEmit` now pass with 0 errors.
The errors were not cosmetic — several exposed real latent bugs hidden by
the flag, e.g. the drafting-engine ConstraintEnforcer read non-existent
fields (`t.rule.dsfaRequired`, `d.required`, `r.title`), so its DSFA hard
gate and risk-flag checks were silently no-ops; scopeDefaults read
snake_case CompanyProfile fields that never matched the camelCase type
(generator defaults never populated). Both fixed by aligning code to the
current types.
Highlights:
- Vitest globals: add vitest-globals.d.ts (config already had globals:true)
so the test files type-check; exclude Playwright specs from vitest.
- Add a minimal ambient `pg` module declaration (no @types/pg installed).
- Fix Next 15 route handlers to await Promise params.
- Reconcile drifted types across loeschfristen, compliance-scope, document-
generator, drafting-engine, vendor-compliance, agent and more.
Pre-existing (NOT caused here, proven by stashing the diff): 3 vitest
logic tests still fail — getNextStep (2) and buildDocumentScope priority (1).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Report the tool's risk number as a plausible range with a confidence
label instead of a false-precision point value (confidence-aware
tonality — the assessment is confirmed by the DSB / safety expert).
- risk_estimation.go: EstimateConfidence (hoch/mittel/niedrig from how the
contact mode resolved), EstimateRiskRange (S±1 and aggregate L=F+W+P ±1,
the empirically validated per-parameter accuracy), RiskLevelRange; share
the riskBandLabel thresholds with EstimateRiskLevel.
- risk_benchmark.go: RiskComparisonPair gains eng_risk_point/low/high +
level + level_range + confidence; RiskAgreement gains high_confidence_pct.
- RiskComparison.tsx: per-hazard range "low–high (level range)" + point,
confidence chip, and an aggregate confidence line; types in useBenchmark.ts.
- Unit tests for the range/confidence helpers.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Components view: three presence sections (Vorhanden / Nicht vorhanden /
Geloescht) with bidirectional move + soft-delete (audit-visible, restorable),
so the expert corrects the engine's best-effort negation in both directions.
- CE marking per component (bought robot/actuator/SPS) with a clear
"validate the integrated safety function (PL/SIL)" note when also safety-relevant.
Safe semantics: hazards are not suppressed, only provenance is surfaced.
- Project-create form: machine type is now a grouped dropdown from the engine's
controlled vocabulary (GET /machine-types) instead of free text.
- Knowledge graph: component→hazard edges use the real component_id.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The "Zugeordnet" tab already expanded to a GT-vs-Engine detail comparison; the
"Fehlend" and "Engine Findings" tabs were flat and could not be inspected.
Extracted GTDetailBlock / EngineDetailBlock from DetailComparison and made both
tables expandable (chevron) — missing rows show the full GT entry, extra rows
show the full engine hazard (incl. measures, norms, clarification status).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
#1 Risk-number comparison in the benchmark: ComputeRiskComparison derives the
tool's S/F/W/P + Fine-Kinney per matched hazard and compares to the GT values;
exposed on the benchmark response and rendered in a new RiskComparison table
with GREEN/YELLOW/RED traffic lights on the risk number R (like the Excel),
plus per-axis within-1 agreement cards.
#2 Generic misuse pattern HP2103 "Personenbefoerderung auf Hebezeug" — gated to
lift-family machine types, fires for ANY lifting device (not machine-specific).
#3 Benchmark matcher is now 1:n — one broad engine hazard may cover several
fine-grained GT sub-scenarios (foot/hand/leg crush), so coverage reflects real
risk coverage rather than 1:1 wording matches.
Validated on BOTH ground truths (robot cell + lift): leakage 0, ghosts 0,
coverage held.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
New tab /sdk/iace/[projectId]/risikobewertung. Per hazard it shows BOTH models
side by side — EN-62061-style (S/F/W/P) and Fine-Kinney (P/E/C) — with
BreakPilot's justified suggested values from public data, the visible formula,
and editable fields that recompute the score + risk band live. The professional
adjusts the values (e.g. from his own licensed DIN/Beuth data); we only supply
the formula + inputs, reproduce no norm table.
Consumes GET .../hazards/:hid/risk-suggestion. Registered in IACE_NAV_ITEMS.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
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>
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.
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.
[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>
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>
[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>
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>
[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>
[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>
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>
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>
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>
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>
- 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>
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>
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>
- 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>
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>
Benjamin Admin