useCRA leitet aus den Hazards+Mitigations DES IACE-Projekts cyber-relevante
safety_functions ab (Bewegung/Quetschen/safety_function_failure/Pneumatik →
prevent_unexpected_actuation; Signal/Sensor/Kommunikation → signal_integrity;
rein physische wie Thermik/Ergonomie ausgeschlossen) und gibt sie statt der
Demo-Hardcodes an /assess. build_cross_links zeigt dann, welche REALE
Projekt-Schutzmassnahme ein Cyber-Befund wieder oeffnet. Fallback auf Demo-Set,
bis die Projekt-Hazards geladen sind.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Nach dem Setzen der limits_form ruft createProject jetzt POST /iace/projects/
:id/initialize — IACE liest die limits_form als Narrative → Komponenten →
Gefährdungen → Maßnahmen → Verifikation → Normen (idempotent, best-effort).
Navigiert danach auf die Projekt-Übersicht (Risiko-Summary). Interview-Felder
bleiben editierbar, Ableitung im IACE re-triggerbar. Schliesst die Kette
Datenblatt → Grenzen → Gefährdungen/Maßnahmen.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
#1 _machinery_obligations: SET statement_timeout=4s + run_in_threadpool — auf
prod hing die maschinen-Query ~30s (langsame/unindizierte DB nach DB-Swap)
und blockierte den async-Worker. Jetzt: bei Langsamkeit graceful 'keine
Maschinen-Pflichten' statt Hang. (Fehlender prod-Index = Controls/DB-Session.)
#2 parse_grenzen_json: tolerant ggue. ```json-Fences / Prosa-umschlossenem JSON
(gehostete Modelle wie OVH ignorieren z.T. response_format) → Datenblatt-
Extraktion liefert auch ueber den OVH-Fallback Felder.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
1) createProject las proj.id, der Create-Response ist aber {project:{id}} →
'Projekt anlegen' war kaputt. Jetzt proj.project?.id. E2E verifiziert
(create→put limits_form→get→delete = 200).
2) MaschinenVO-Sicherheitspflichten wurden in die CRA-Cyber-Buckets
(Code/Prozess/Doku) gemischt → fehl-kategorisiert (Maschinen-Safety ≠
CRA-Annex-I-Cyber). Jetzt eigene Response-Liste machinery_guideline +
eigener Frontend-Abschnitt 'Maschinensicherheit (MaschinenVO 2023/1230)';
geklebtes 'MaschVO'-Badge entfaellt damit.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
CreateProjectRequest verlangt machine_name, machine_type UND manufacturer
(alle required) → leere Werte gaben 400. Fallback 'Nicht angegeben', wenn das
Datenblatt sie nicht liefert (im Interview editierbar).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
DatasheetExtract: Button legt ein IACE-Projekt an (POST /iace/projects) und
speichert die extrahierten Grenzen + Rückfrage-Antworten als metadata.limits_form
(PUT), dann Navigation ins Interview. Das Interview-Formular bleibt voll
editierbar (jedes vorbefuellte Feld aenderbar, Auto-Save). Manuelles Anlegen
ueber /sdk/iace bleibt unveraendert.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
qwen3.5:35b-a3b ist ein Thinking-Modell → generierte erst Reasoning, riss das
90s-Timeout → leere Extraktion. llm_cascade additiv um think-Param erweitert
(Cache-Key kennt think); Datenblatt-Extraktor setzt think=False → sauberes JSON
in ~1s. Default fuer alle anderen Cascade-Nutzer unveraendert.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
llm_cascade additiv modell-faehig (optionaler model-Param, Cache-Key kennt
model_hint → keine Kollision; Default unveraendert für alle anderen Nutzer).
Datenblatt-Extraktor nutzt jetzt qwen3.5:35b-a3b (CRA_DATASHEET_MODEL, gleiches
Modell wie der Compliance Advisor) für bessere semantische Zuordnung. Plus
llm_status (ok|empty|unavailable) + Logging statt stillem except; Frontend zeigt
bei 'unavailable' einen Hinweis statt leerer Felder (wichtig auf prod ohne
lokales Ollama → Cascade-Fallback bzw. Hinweis).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Hybrid-Extraktion Datenblatt → IACE Grenzen (ISO 12100): deterministischer
Detektor (Schnittstellen/Einheiten per Regex) + lokales 35B via llm_cascade
(Qwen-lokal-first) fuer die semantische Zuordnung auf die echten LimitsFormData-
Keys. Nichts erfinden: Feld nicht im Text → leer + Quellen-Zitat je Feld.
Essenzielle ISO-12100-Felder, die leer bleiben → gezielte Rückfragen
(foreseeable_misuses, person_groups, qualification, temporal_limits …).
Endpoint POST /api/v1/cra/extract-datasheet. 13 Tests gruen (reine Teile).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
3-Tier-MaschinenVO-Verdict (direkt / sicherheitsrelevant / nicht relevant) aus
Personengefährdungs-Signal: eine Komponente ist keine Maschine, aber wenn ihre
Funktion bei Fehler ODER Manipulation Personen gefaehrden kann (Bewegung, Laser/
Auge, Kraft, Temperatur, elektrisch), ist sie sicherheitsrelevant — Pflicht
trifft den Maschinenbauer, Zulieferer liefert Nachweise, und ein Cyber-Angriff
kann die Sicherheitsfunktion aushebeln (Cyber-Safety-Bruecke). OWIS-mit-Laser
landet so korrekt als 'sicherheitsrelevante Komponente'. Engine + /readiness
additiv; Frontend: Gefährdungs-Frage + -Typen, MaschinenVO-Ergebnisblock.
Presets aktualisiert (OWIS: Laser+Bewegung, Zwick: Bewegung). 22 Tests gruen.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Reine, deterministische Verdict-Schicht ueber der bestehenden Annex-III/IV-
Klassifikation (kein vierter Klassifizierer): trennt Rechtspflicht von Markt-
Druck. Kern: das Inverkehrbringen (ab 11.12.2027), nicht der Entwicklungs-
zeitpunkt, entscheidet — Bestandsprodukte, die nach der Frist weiter verkauft
werden, fallen unter CRA. Producer-Typen (component/end_device/machine_
integrator/software_app) steuern Default-Annahmen (Anlagenbauer: Vernetzung/OTA
vorausgesetzt) + Verdict-Betonung (Komponente => Markt-Druck). Plus Evidence-
Checkliste (SBOM/VDP/Patch/Lifecycle/Threat-Model/Logging/Auth/Incident) +
Reifegrad. /readiness additiv erweitert (verdict/maturity/digital_elements/
producer_type). 15 Tests gruen. Beispiele: OWIS PS90+, ZwickRoell roboTest.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
prod-canonical_controls (aus dem DB-Swap) hat weder PK noch Unique auf id →
FK InvalidForeignKey. control_uuid bleibt UUID (logische Referenz), wie die
bereits FK-lose atom_classification auf prod. [migration-approved]
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
11 Modul-Eintraege entfernt, deren exakte Route bereits ein immer-sichtbarer
Pipeline-Schritt ist (advisory-board, ai-act, source-policy, loeschfristen,
einwilligungen, cookie-banner, dsr, vendor-compliance, consent-management,
email-templates, training) — Heimat bleibt die Pipeline, kein Feature-Verlust
(keiner dieser Schritte hat visibleWhen). "Datenschutz"-Gruppe zu "Cookie &
Consent" (Consent Dashboard + Cookie Live-Vorschau) verschlankt. Aehnlich
benannte, aber VERSCHIEDENE Seiten bewusst behalten (document-generator≠
catalog-manager, control-library≠coverage, consent≠consent-management,
cookie-banner≠/preview, vendor-compliance≠vendor-assessment).
Vollstaendige Routen-Inventur (Pipeline + Module + aufgeloeste Dups) in
docs-src/development/sdk-navigation-inventory.md — damit kein Feature
unsichtbar verloren geht.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Die vier Kern-Module in eine Gruppe "Produkt-Compliance (CE & Cyber)"
(Gap-Analyse, Maschinensicherheit/CE, Cyber Resilience/CRA) — iace+cra
benachbart, KI-Compliance nicht mehr dazwischen gekeilt. Labels entschaerft
(kein "IACE"-Codename, keine doppelten Header). Interne/Entwickler-Module
(Kataloge/Templates, Korpus/coverage, Quellen, Engine-Internals, Admin) in
eine per useInternalUI() gegatete Sektion "Intern · Entwicklung" — Kunden
sehen sie nie (Default versteckt; intern = macmini/localhost o. Browser-Opt-in).
coverage erstmals erreichbar (war verwaist). Toter SidebarModuleNav.tsx
geloescht. Alle bestehenden Routen erhalten.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Die "Korpus-Dokumente"-Tabelle wird nach Dokument-Art geordnet
(Gesetze & Verordnungen → Behörden-Leitfäden → Standards & Best Practice →
Rechtsprechung) mit Zwischenüberschriften, und je Herausgeber-Familie
zusammengefasst (alle DSK, alle EDPB, alle OWASP/NIST/ENISA gemeinsam).
Deterministischer Kategorisierer (categorizeCorpusDoc) + Grouper
(groupCorpusDocs), pure + unit-getestet.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
Ergänzt nach Rückmeldung der Controls-Session: ID-Stabilität schützt auch deren
atom_classification (~161k) + addressee (control_uuid-gebunden); deren Step-1/2 ist
additiv (tier/source_type/core_count/addressee, bricht Verträge nicht); eine
Wahrheit — Muster-Schicht aus atom_classification speisen, nicht neu ableiten.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Andock-Vertrag für die Maßnahmen-Schicht: stabile Muster-Einheit + feste ID,
control→pattern-Mapping, Framework-Crosswalk pro Muster. Abstimmung mit der
Controls-Session (core/control-pipeline). CRA-Spine/M5xx bleiben unabhängig.
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>
Der harte relevant=true-Filter versteckte ~25% des Korpus (40.926 Atome),
~70% davon echte Pflichten (500er-Validierung). relevant wird zur Stufe:
- Service: tier-Param (core=Default schuetzt Agent/CRA; all=alles inkl. review),
ORDER BY relevant DESC; pro Control relevant/tier/source_type
(own_library bei license_rule=3, sonst derived) + source_regulation/article;
core_count/review_count. Pure Helper tier_label + source_type (+ Tests).
- Route: optionaler tier-Query (default core) — contract-safe (additiv).
- Frontend: Coverage-Drill-down /sdk/coverage/[useCase] — Kern-Pflichten vs.
"zur fachlichen Pruefung", je mit Herkunfts-Badge; Uebersicht zeigt Delta.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- FastMCP transport_security: enable_dns_rebinding_protection nur an, wenn
MCP_ALLOWED_HOSTS gesetzt; sonst aus (sonst HTTP 421 "Invalid Host header" bei
Aufrufen über nginx/Container-Name). Bearer bleibt die Zugriffskontrolle.
- bp-compliance-mcp: Host-Port-Mapping entfernt (8099 war von bp-core-health
belegt) → expose-only im breakpilot-network, Routing via nginx (Folgeschritt).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Reframe: BreakPilot ist Audit-VORBEREITER, nicht Prüfstelle. Jede Kachel zeigt
jetzt eine "Mit BreakPilot"-Zeile (Selbstbewertung = end-to-end; EUCC/benannte
Stelle = audit-fähig machen, formale Prüfung durch ITSEF/benannte Stelle) plus
aufklappbaren Erklär-Text (was EUCC ist, wie es läuft, was der Nutzer tut).
Normtext (ISO/IEC 15408/18045) nur referenziert, nicht reproduziert.
Kachel von <button> auf <div> + separater Wählen-Button + Info-Toggle umgebaut.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
(a) Labels: Module korrekt zugeordnet — Modul A = Selbstbewertung, Modul B+C =
benannte Stelle, EUCC = eigenes Zertifikat (nicht Modul H), "harmonisierte
Norm" ist kein Modul sondern Konformitätsvermutung. Für den CRA noch KEINE
harmonisierte Norm veröffentlicht → Kachel als "noch nicht verfügbar"
(erwartet ~2027), nicht wählbar, mit Hinweis. (page/path/documents-Labels.)
(b) Gating: wichtige Klasse II + kritische Produkte dürfen NICHT selbst bewerten;
harmonisierte Norm allein genügt dort nicht → ALLOWED_PATHS IMPORTANT_II/
CRITICAL = {eucc, notified_body}; DEFAULT_FOR II = notified_body. _PATH_HINT
entsprechend. Regressionstest test_cra_conformity_paths.py.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
- _ATOM_LIST_SQL via LATERAL: zusaetzlich cpl.source_article (Gesetzes-Artikel)
im atom-grain Response. Spalte control_parent_links.source_article verifiziert
(macmini + prod).
- Registry-Mapper-Test (neue Domaenen) nach compliance/tests/ verschoben — CI
faehrt compliance/tests/, nicht tests/; schliesst die CI-Luecke der
6-neue-Use-Cases-Erweiterung.
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>
Schliesst die CI-Luecke (Tests lagen in tests/, CI faehrt compliance/tests/) und
flaggt backend in detect-changes, damit der zuvor uebersprungene Backend-Build
(43 Use Cases, /corpus, + Migration 153 der CRA-Session) auf Prod nachgezogen wird.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
apt-get install git scheiterte (exit 100) auf dem Runner — Debian-apt-Mirrors
nicht erreichbar — und brach damit den Checkout ALLER python:3.12-slim-Jobs
(validate-canonical-controls, test-python-backend, iace-gt-coverage, …) seit
#863. Dadurch wurde CI nie grün und Orca hat nie deployt. Das volle python:3.12
bringt git mit -> apt-get-Zeile entfällt. (dep-audits nodejs/golang-apt ist
PR-only und ausserhalb des Deploy-Pfads.)
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Readiness check: legally tighter + sales-sharper copy per review — names both
regulations cleanly (CRA + Machinery Reg 2023/1230 in plain language), frames CRA
Art. 13 as "more than a yearly pentest: assess/document/handle cyber risk across
the lifecycle" (not over-claiming a "continuously documented risk assessment"),
adds the "we turn regulation into code" positioning, and reorders the 8 questions
in CRA order (machine -> connectivity -> software -> updates -> remote -> app ->
personal data -> critical env).
Track B: the Compliance Agent Pre-Scan wizard now detects the shared
CompanyProfile and offers "Aus Profil übernehmen" — tolerant mapping (legal_form,
industry, employee_count) across the differing module vocabularies, user-
triggered (never silent), so company context isn't re-asked.
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>
CRA frontend pages hardcoded tenant 00000000-…-001 while IACE uses the dev
tenant 9282a473-… → a demo customer was split/invisible across modules. Align all
app/sdk/cra pages to 9282a473-… so the whole CRA<->IACE journey lives under ONE
tenant. Add scripts/seed_demo_customer.py: seeds CompanyProfile + IACE project
(components, hazards, mitigations) + CRA project (intake, scope-check, assessment
snapshot from faked repo findings + components + safety functions) — the source-
repo layer is faked so the full frontend is walkable once.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Follow-up to the machinery_reg_cyber.py removal: the readiness endpoint now pulls
Machinery Regulation 2023/1230 cyber-with-safety obligations from the shared
Controls-API (use_case=maschinen), tagged "Maschinen-VO", best-effort.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Machinery Regulation 2023/1230 cyber-with-safety obligations are already in the
shared Controls-API (use_case=maschinen, atom-grain, classified, license-clean) —
so remove the hand-authored machinery_reg_cyber.py spine. The readiness check now
fetches them from use_case=maschinen (sub_topics sicherheitsanforderungen ->
code, risikomanagement -> process, konformitaetsbewertung -> document), tagged
source "Maschinen-VO" alongside the CRA obligations. Same pattern as the security
cluster; no own formulation, no license question.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Machine/plant builders are hit by BOTH the CRA and the new Machinery Regulation.
New machinery_reg_cyber.py models its two well-corroborated Annex III cyber-with-
safety essential requirements (1.1.9 protection against corruption, 1.2.1 control-
system safety incl. foreseeable manipulation) in our own words; EU legal text is
freely reusable (Commission Decision 2011/833/EU, source acknowledged), harmonised
standards referenced by identifier only. The readiness check asks "is it
machinery?" and, if so, adds these obligations tagged "Maschinen-VO" alongside the
CRA ones — the combination is visible (regulations list + per-item source badge).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Benjamin Bönisch