1712 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
Benjamin Admin	f37081b60b	test(advisor): E2E for the Clarity-Gate chain (Playwright, stubbed endpoint) ... Per the "always write E2E" rule: drives the floating advisor widget end-to-end against a stubbed /api/sdk/compliance-advisor/chat with contract fixtures — clarify (L1 + context chips), answer ([n] citation + evidence pane), and clarify->pick-context->scoped-answer. No backend needed (route interception). Runs on CI/macmini (Next app on :3002); validated here via tsc + `playwright --list` (3 tests discovered). check-loc 0. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-07-01 14:06:02 +02:00
Benjamin Admin	3f372bcb39	feat(advisor): Phase 1 — endpoint backward-compat (keep breakpilot-workspace working) ... The advisor endpoint now serves two shapes off one orchestration: - new FE ({question}) -> v3 JSON contract (clarity/answer/evidence/citations/...). - legacy consumer ({message}, e.g. breakpilot-workspace which reads a text stream and persists raw bytes) -> plain-text stream of the L2 answer (clean prose, no [n] markup, no clarify gate). isLegacyRequest() discriminates; answerSystem() gains withCitations. Prevents the v3 contract from breaking breakpilot-workspace's chat (CLAUDE.md rule #4, keep every consumer working). No deploy. tsc clean, 13 vitest (incl. isLegacyRequest), check-loc 0. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-07-01 13:53:17 +02:00
Benjamin Admin	5a513181cc	feat(advisor): Clarity-Gate orchestration in route.ts (consumes /retrieve) ... Completes the advisor stack (FE + orchestration; /retrieve is SDK/RAG-owned). The route now returns the FE contract instead of a text stream: - retrieveFull() calls /retrieve with {query, context}; consumes clarity/evidence/ visual_evidence/footnotes (exact shape per board 2026-07-01 12:25). - mode-routing (resolveMode): clarify unless a context was chosen and /retrieve's clarity.mode says so. clarify -> L1 general answer (completeAdvisorAnswer, ungrounded, no sources). answer -> L2 answer over numbered evidence with [n] markers. - citations generated here ([n] -> nth evidence unit); footnotes remapped; evidence / visual_evidence passed through. - advisor-llm: non-streaming completeAdvisorAnswer(). Pure mappings in retrieve-mapping.ts (+ tests). Removed the dead v2 evidence.ts/evidence-adapter (RegulationRef moved to regulation-display). controls-augmentation kept (tested; re-integrable later). NOT deployed: joint deploy with the SDK /retrieve endpoint (deploy-coupling). tsc clean, 25 vitest (mapping/clarify/answer/markdown/registry/rag), check-loc 0. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-07-01 12:39:47 +02:00
Benjamin Admin	f9b7ba2424	feat(advisor): v3 Clarity Gate — Case model + clarify/answer contract, [n] citations ... Builds the FE against the SDK<->FE Clarity-Gate contract (board 2026-07-01 / advisor-clarity-gate-contract). The advisor is now a CASE, not a chat: - Request {question, context?}; response {mode: clarify|answer, clarity, general_answer, answer, evidence, citations, visual_evidence, footnotes}. - clarify mode: short L1 general answer (marked "allgemeine Definition, ohne Rechtsquelle") + domain context chips; picking a chip re-runs the case scoped (-> answer). - answer mode: markdown answer with clickable [n] citation markers coupled to evidence cards (highlight + scroll), evidence grouped by document family, visual_evidence (visual_type), footnotes, honest summary counts (no trust score). - FE never parses the answer for structure — only the deliberate [n] markers, mapped via citations[]. New: contract.ts, useAdvisorCase, useCitationHighlight, ClarifyView, EvidenceUnitCard, VisualEvidencePane, CaseView. Removed the v2 stream/chat components. NOT deployed: FE shape-switch (JSON modes) must deploy TOGETHER with the SDK endpoint delivering the contract (board deploy-coupling). Proxy/route.ts unchanged (SDK-owned). tsc clean, 16 vitest (incl. clarify+answer fixtures), check-loc 0. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-07-01 11:31:28 +02:00
Benjamin Admin	591cae5ebc	feat(advisor): Case Workspace v2 — Evidence grouping, human names, 3-column, summary ... Reworks the advisor toward a Compliance Case Workspace (review feedback): - Rename user-facing "Quellen" -> "Evidence". - Evidence grouped by document/regulation family (count + expandable) — no more unsorted DSK/DSK/DPF/... jumble. - Human-readable regulation names via a display registry (DSK Sdm B51 -> "DSK Standard-Datenschutzmodell (SDM)" / Kapitel B51); generic, bridges G2. - Evidence summary "Antwort basiert auf" with meaningful counts; Regelwerke = distinct FAMILIES (fixes the inflated count). NO fabricated trust score (needs a defined basis). - Expanded mode = 3-column workspace (question+summary | answer | evidence, independent scroll) + history switcher; narrow mode stays stacked. - Prompt: push aggressive markdown structure (## per aspect, numbered phases). Deferred/coordinated on board: C8 diagrams (RAG contract), answer<->evidence coupling [1] (needs LLM citation anchors — phase 2), G1 retrieval relevance + G2 metadata (RAG). tsc clean, 17 vitest, check-loc 0. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-07-01 10:38:06 +02:00
Benjamin Admin	3884038b06	fix(advisor): generic — drop trailing source list in answer + de-duplicate source card ... Two structural fixes (not query-specific): - Proxy prompt: forbid ANY trailing "Quellen:"/"Quellen im RAG-System" list and make it the LAST instruction so it overrides the soul file's answer-structure + example that teach a closing sources section. Applies to every answer. - KnowledgeUnitCard: render the label only when it differs from regulation.short, so a source whose label == short name no longer prints twice. Applies to every source. Answer text is still never parsed in the FE (sources live in the pane). + card test. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-07-01 10:13:58 +02:00
Benjamin Admin	49171e841f	feat(advisor): Evidence Workspace — structured panes, markdown, sources as knowledge units ... Rebuilds the Compliance Advisor floating widget from a plain chat into an Evidence Workspace: pinned last question, markdown-rendered answer (clean prose), and separate panes for Sources (hierarchical Knowledge Units), Figures (C8, conditional) and Footnotes (C-FN), plus a stats bar (Quellen/Regelwerke/Diagramme/Fußnoten). Scrollable turn history; stays a floating icon on every SDK page. Architecture (user direction): the frontend renders ONLY structured evidence and NEVER parses the answer text. The proxy now returns a JSON AdvisorEvidenceMeta line followed by the streamed markdown answer; advisor-rag exposes structured results; an adapter maps RAG/compiler output to the frontend envelope. Figures/footnotes wire in once the RAG-ingestion contract lands (requested on the board) — figures pane is conditional. - lib/sdk/advisor/{evidence,evidence-adapter}.ts (+ adapter test, 7 cases) - components/sdk/advisor/* panes + in-house safe Markdown (no new dep, no dangerouslySetInnerHTML) + test - useAdvisorStream (meta-line parse + streamed answer) + useAdvisorEmail (escaped) - proxy: evidence-meta-v1 envelope + clean-prose prompt (no inline citations) - tsc clean, 11 vitest pass, check-loc 0. ESLint not installed in this node_modules -> CI lints on push. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-07-01 07:46:37 +02:00
Benjamin_Boenisch	f0120b237e	fix(ucca): Cross-Reg 0070 — beide Domaenen im Router-Top-K (#47)	2026-06-30 13:42:28 +00:00
Benjamin Admin	1d65d99d5f	style(ucca): gocritic equalFold in balanceByRegulation (go-lint gruen) ... strings.EqualFold(code, cv) statt code==strings.ToUpper(cv) — behebt den einzigen gocritic-Befund auf der neuen Zeile (CI go-lint, new-from-merge-base). Verhalten unveraendert (case-insensitive exakter regulation_code-Match); Unit + 0070-e2e bleiben gruen. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-06-30 15:30:58 +02:00
Benjamin Admin	f2d445b891	fix(ucca): Cross-Reg 0070 — beide Regelwerk-Domaenen im Router-Top-K (Known Defects 0) ... Der einzige offene Retrieval-Haertefall: eine Query mit >=2 genannten Regelwerken ("CRA und Maschinenverordnung") lieferte nur die keyword-dominante Domaene (CRA), MaschVO fiel raus. Drei zusammenwirkende Ursachen, alle behoben: 1. CodeValues-Mismatch: MaschVO heisst je Collection anders (Slice MASCHVO · gesetze MVO · ce MACHINERY/MASCHINENVO), der Catalog hatte nur ["MASCHVO","MaschVO"] → Filter fand MaschVO nur in der Slice. Jetzt alle Varianten als CodeValues. 2. Per-Collection-Truncation: der Router gab perColl=3 → searchMultiRegulation holte 3+3=6, schnitt auf 3 → konnte eine Domaene je Collection verlieren. Multi-Reg-Queries bekommen jetzt perColl = 3*len(regs). 3. Router-Score-Merge starvte die nicht-dominante Domaene. Neue balanceByRegulation() gruppiert den gemergten Pool per Regelwerk (exakter regulation_code-Match) und nimmt round-robin ueber die genannten Domaenen → jede Domaene mit Treffern ist im Top-K. Generisch ueber jede genannte Menge; Single-Domain-Pfad unveraendert. Validierung: Go-Unit (balanceByRegulation: dominante CRA verdraengt MaschVO NICHT mehr); 0070-e2e gegen dev (Retrieve() → [CRA MVO CRA MVO CRA MVO CRA MASCHINENVO] = beide Domaenen, vorher nur CRA); CB-100-Stichprobe REGR 0 (Gain-Profil unveraendert). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-06-30 15:08:18 +02:00
Benjamin_Boenisch	08086ee75f	feat: Authority Router — Advisor collection-agnostisch, KB-2026.1 live (#46)	2026-06-30 12:26:53 +00:00
Benjamin Admin	1e5aaf7103	feat(advisor): Authority Router — Advisor collection-agnostisch, KB-2026.1-Gewinn im Produktpfad ... Der Advisor fan-outete bisher selbst ueber eine feste Liste expliziter Collections (advisor-rag.ts) und umging damit das #61-Scope-Routing (das nur den Default-Pfad routet) → der gemessene +28-Retrieval-Gewinn (CB-100: 53→81, 0 Regr) kam nie beim Antwort-LLM an. Dieser Router zieht den Fan-out in die Retriever-Schicht: - SDK: LegalRAGClient.Retrieve() + POST /sdk/v1/rag/retrieve {query, top_k} — fan-outet server-seitig ueber die Broad-Authority-Base + die KB-2026.1-Slice bei inKBScope, merge+dedup, sortiert nach Authority-Score (rerankByAuthority je Collection), top-K. Index-Warmup vor dem nebenlaeufigen Fan-out (Map-Race-frei). Per-Env via RAG_ROUTER_COLLECTIONS. - admin: advisor-rag.ts ruft EINMAL /retrieve statt 6-fach expliziter Collections. Advisor ist collection-agnostisch (Vertrag Compiler→Collections→Retriever→Advisor); COMPLIANCE_COLLECTIONS/searchCollection entfernt. Validierung: Go-Unit (Router-Selektion, dedup); e2e gegen dev-Qdrant (echter Retrieve(), CB-100-Stichprobe stride 5): OLD-hit 11/20 → NEW-hit 15/20, GAIN 4 (alle DS-Guidance), REGR 0 — reproduziert den +28/0-Regr durch den Produktionscode. TS-Tests auf den Single-/retrieve-Call angepasst. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-06-30 14:13:09 +02:00
Benjamin_Boenisch	af11d21f6e	feat(ucca): Blue-Green KB-2026.1 Scope-Routing (authoritative slice) (#45)	2026-06-30 10:01:59 +00:00
Benjamin Admin	e2c74fd243	feat(ucca): Blue-Green „authoritative slice promotion" — KB-2026.1 Scope-Routing ... Additiv (KEIN CE-Ersatz): faellt eine Query in den KB-2026.1-Scope (DP/CRA/MaschVO/ NIS2/DataAct/DORA/AIAct + EDPB/DSK-Guidance), wird die hochwertige Slice-Collection `kb_2026_1_build` abgefragt; sonst bleibt der breite Default `bp_compliance_ce`. Damit werden die Guidance-Intent- + Multi-Reg-Fixes (PR #42/#43) fuer den Slice LIVE, Broad-Corpus (OWASP/NIST/ENISA/IFRS/ISO) unangetastet -> 0 Regressionen by construction. - resolveCollection(query, requested): explizit angefragte Collection unveraendert; Default-Request -> Slice bei inKBScope, sonst CE. Env RAG_KB_SCOPE_ROUTING=false = Rollback ohne Redeploy; RAG_KB_SLICE_COLLECTION ueberschreibt den Slice-Namen. - inKBScope: detectRegulations (in-Slice-Regelwerke) + DP-Guidance-Marker (edpb/dsk/wp/gl) + DP/Compliance-Topics. Bewusst NICHT die generischen Verben aus guidanceIntentSignals (sagt/laut) und NICHT enisa/bsi/nist/owasp (die liegen in CE) -> konservativ, in-scope->Slice. Validierung: Unit (Scoping + resolveCollection); dev-e2e (RUN_E2E, geroutetes Search() gegen dev): WP248/MaschVO/CRA+MaschVO -> Slice (Treffer da, fehlen in dev-ce); NIST -> CE (NIST-Treffer). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-06-30 11:49:34 +02:00
Benjamin_Boenisch	8ed99c255d	Merge pull request 'fix(api): F821-Regression (Extract-Service-Halb-Refactor) — 7 Route-Dateien' (#44) from fix/api-f821-extract-service-regression into main	2026-06-30 09:06:08 +00:00
Benjamin Admin	3389fa3e7a	fix(api): F821-Regression in 6 weiteren Route-Dateien beheben ... Gleiche Wurzel wie evidence_routes (Extract-Service-Refactor a638d0e5 ff.): Signaturen/Imports halb umgestellt → undefined names → NameError beim Aufruf. - routes.py: db-Param in get_control/update_control/review_control + EvidenceDB-Import - dsfa_routes.py: db-Param in create_dsfa + HTTPException/text-Import - dashboard_routes.py: timezone-Import - canonical_control_routes.py: logger-Definition - ai_routes.py: timezone in den lokalen datetime-Imports - vvt_routes.py: HTTPException-Import Verifiziert: ruff F821 0 über das gesamte compliance/api/, alle 6 py_compile, 294 Tests grün auf den betroffenen Modulen (die 2 dsfa-invalid-status/risk-Failures sind vorbestehend = 400-vs-422, unabhängig von diesem Fix). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-06-30 10:51:00 +02:00
Benjamin Admin	79abf23ea8	fix(api): evidence_routes F821-Regression beheben (Extract-Service-Halb-Refactor) ... a638d0e5 ("extract EvidenceService") stellte Signaturen auf service=Depends um, ließ aber Bodies + Imports auf dem alten Stand → 43 F821 (NameError zur Laufzeit). - gelöschte stdlib-Imports restauriert (os/json/hashlib/uuid/datetime/timedelta) - db: Session = Depends(get_db) an den betroffenen Endpoints restauriert - translate_domain_errors + _update_risks_impl (=evidence_service._update_risks) importiert - unerreichbaren toten Block (alte get_ci_evidence_status-Impl nach dem return) entfernt - dsms_cid=None no-op in create/review/reject (DSMS-Commit-Copy-Paste) Verifiziert: ruff F821 0, py_compile, test_evidence_routes.py 35 passed. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-06-30 10:19:28 +02:00
Benjamin Admin	d5925e57af	feat(ai-sdk): pin accepted proposer decisions into the GT gate (P3) ... When a human accepts a proposer proposal, an AcceptedPin records a machine-scoped invariant — a pattern MUST fire (coverage/vocab→tag) or must NOT fire (dedup/framing) — that a test re-checks on every run. This makes the library's growth COMPOUND into the gate instead of eroding it: a change that re-introduces a dropped duplicate, un-gates a foreign pattern, or removes a coverage hazard breaks a pin and fails CI. One boolean covers all four proposal types. Seeded testdata/accepted_pins_warewashing.json with the accepted P1 supersessions (HP016/HP018/HP013 must NOT fire; their clean equivalents HP2201/HP144 must fire). TestWarewashing_AcceptedPins re-checks 5/5 against the live engine output; GenerateDedupPin turns an accepted dedup verdict into its pin. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-06-30 09:42:31 +02:00
Benjamin Admin	1877829b1d	Merge remote-tracking branch 'gitea/main' into reconcile-dev	2026-06-30 09:04:58 +02:00
Benjamin_Boenisch	866889b453	Merge pull request 'feat(ucca): Multi-Regulation-Retrieval (Cross-Regulation-Fragen)' (#43) from fix/multi-regulation-retrieval into main	2026-06-30 06:46:21 +00:00
Benjamin Admin	9760dca443	feat(ucca): Multi-Regulation-Retrieval für Cross-Regulation-Fragen ... Nennt eine Query EXPLIZIT >=2 Regelwerke ("Wie greifen CRA und Maschinen- verordnung ineinander?"), retrievt searchInternal pro Regelwerk separat (regulation_code/regulation_id-Filter) und merged — damit BEIDE Domänen im Prompt landen statt nur der keyword-dominanten. Generisch (Query->Regelwerke, KEINE doc-spezifische Logik), gegated auf >=2 erkannte Regelwerke; sonst unveränderter Single-Domain-Pfad. Behebt GQ-0070: vorher CRA x8 / null MaschVO -> Modell halluzinierte MaschVO=2019/2144 + falsche "CRA ausgenommen"-Konklusion. Nachher CRA + MaschVO im Prompt -> korrekt "beide gleichzeitig anwendbar" + Art. 20(9) Konformitätsvermutung, gegroundet. Validierung (Build-Collection, echtes SearchCollection): - Unit: detectRegulations-Scoping (>=2 -> multi, 1/0 -> single) - 5 Cross-Reg-Fälle (0070 + DSGVO+TDDDG/CRA+NIS2/DORA+NIS2/AI Act+DSGVO): beide Regelwerke in Top-8 - CB-100 Freeze-Regression: NUR GQ-0070 + GQ-0095 geändert (beide echte Cross-Reg, beide verbessert), 98/100 byte-identisch - 10 Hard Cases: 9 Single-Domain unverändert, 0070 behält CRA Rang 1 Filter erweitert auf regulation_id UND regulation_code (rückwärtskompatibel, aktiviert die re-ingestierte Build-Collection). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-06-30 08:18:06 +02:00
Benjamin_Boenisch	e5e7b825af	Merge pull request 'fix(ucca): Guidance-Intent für direkt benannte WP/GL-Dokumente' (#42) from fix/legal-rag-guidance-intent into main	2026-06-29 18:42:27 +00:00
Benjamin Admin	4818fc51c2	fix(ucca): guidance-intent erkennt direkt benannte Guidance-Dokumente ... queryWantsGuidance verfehlte rein dokument-namige Fragen ("Welche Kriterien nennt WP248 ...", "Was sagt GL 07/2020 ..."): guidanceIntentSignals enthielt zwar Herausgeber (edpb/dsk/enisa) und Verben (empfiehlt/laut), aber keine Working-Paper-/Guideline-Identifier. Dadurch loeste der Authority-Lift nicht aus -> binding_law (bzw. im homogenen Korpus sogar off-domain MaschVO/CRA) verdraengte die Guidance aus den Top-K. Fix: WP2xx / GL 0x / "working paper" als Guidance-Signal ergaenzt. Generisch ueber alle WP-/GL-Dokumente, KEINE doc-spezifische Regel (Query->Intent, nicht Query->konkretes Dokument). Validierung (homogener Build-Korpus, bge-m3 + Qdrant Cosine): - 10 Hard Cases: 8/10 -> 10/10 (WP248/WP260 zurueck in Top-8) - ComplianceBench-100: 0/100 Norm-Fragen veraendert (Freeze-Regression gruen), 18/18 Guidance-Intent-Fragen verbessert (binding -> korrekte Guidance-Klasse) - Hybrid == Dense (Keyword-RRF war NICHT die Ursache, der Lift-Gate war es) Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-06-29 20:22:27 +02:00
pilotadmin	f0da86ca19	Merge pull request 'feat(onboarding): advisor responsiveness — moving headline + auto-recompute' (#54) from feat/advisor-ux-responsiveness into main	2026-06-28 19:31:20 +02:00
Benjamin Admin	867f8c3854	feat(onboarding): make the advisor visibly responsive — headline leads with the moving number + auto-recompute ... Testing surfaced that toggling certifications appeared to "do nothing": the headline led with the TOTAL requirement count (constant per target, e.g. 17 for CRA), and the page only recomputed on an explicit button click. Both fixed: - engine.py headline now leads with the number that actually moves: "11 von 17 Anforderungen offen · 6 wahrscheinlich (Zertifikate) · 5 zu klären" (was "17 Anforderungen erkannt · …"). Keeps the "automatisch erkannt (Intake)" substring. - frontend auto-recomputes on certifications / target / scanner-signal change (no button needed). Now ISO27001 alone -> "13 von 17 offen · 4 wahrscheinlich"; + ISO9001+TISAX+IEC62443 -> "11 von 17 offen · 6 wahrscheinlich". (Domain truth stays visible: CRA's product-cyber gaps barely move with management-system certs.) 28 onboarding+transition tests pass, check-loc 0.	2026-06-28 19:31:15 +02:00
pilotadmin	26a8518107	Merge pull request 'feat(onboarding): surface curated expert text + human labels' (#53) from feat/advisor-human-text into main	2026-06-28 18:47:07 +02:00
Benjamin Admin	807a7002b2	feat(onboarding): surface curated expert text + human capability labels (advisor was showing snake_case) ... The advisor was structurally correct but unusable: every question showed a snake_case capability id plus a single generic fallback reason ("Keine Anhaltspunkte im Unternehmensprofil — klären"). The expert text already EXISTED in the transition patterns (why_asked / reviewable_claim) — the pipeline just dropped it. - transition_reasoning: TargetRequirement gains `rationale`; assess_transition uses it as the request reason when present, else the generic fallback (additive, backward-compatible for all consumers). - onboarding_service._target carries the pattern's why_asked (delta) and reviewable_claim (likely_covered) into the requirement rationale -> the question's `why`. - knowledge/onboarding/capability_labels.yaml: curated DE labels (id -> human), reusable across targets; labels_for() + response.capability_labels expose them; the frontend renders label || prettified id. Now ISO27001->TISAX reads "Auftragsverarbeitung (Art. 28 DSGVO) — If a TISAX data label is in scope, you must show Art. 28 GDPR processing-on-behalf controls; ISO 27001 does not establish these." instead of "data_protection_processing_on_behalf — klären". why_asked text is still EN (existing knowledge; translation is curation). 34 onboarding+transition tests pass, mypy --strict clean (13 modules), check-loc 0.	2026-06-28 18:46:56 +02:00
pilotadmin	5beb5a319a	Merge pull request 'feat(admin): ETO / Onboarding-Advisor test page' (#52) from feat/onboarding-advisor-frontend into main	2026-06-28 17:12:44 +02:00
Benjamin Admin	239702fdca	feat(admin): ETO / Onboarding-Advisor test page (thin operator surface over the advisor endpoint) ... A focused client page at /sdk/onboarding-advisor that exercises POST /api/compliance/onboarding/ advisor-start through the existing compliance proxy: pick certifications + target + scanner findings (observation / partial / requirement) and render the result — headline, silent-intake summary, auto-detected (green), indications (amber), next-best questions with WHY, inferred (Welt-1) vs rejected assumptions, capability delta, evidence requests, completeness. NOT the regulation gap engine (/sdk/gap-analysis is a different flow). No new backend; calls only the existing endpoint. 195 lines.	2026-06-28 17:12:40 +02:00
pilotadmin	d1a5fc7205	Merge pull request 'feat(onboarding): Observation Log — append-only JSONL calibration store (59b/c)' (#51) from feat/observation-log into main	2026-06-28 16:29:58 +02:00
Benjamin Admin	7df15010ff	feat(onboarding): Observation Log — append-only JSONL calibration store (Task 59b/c v1) ... Per the user's decision (2026-06-28): observations are CALIBRATION data for the knowledge base, NOT business data and NOT product-DB data. So they live with the other versioned knowledge artifacts as an append-only JSONL log under knowledge/observations/ — NO migration, NO DB. (A real persistence layer is only warranted once thousands of onboardings exist; not before.) - ObservationRecord = Observation + log metadata (observation_id, timestamp [caller-stamped, no hidden clock], customer_archetype [anonymised — NEVER a real name], evidence, provenance, knowledge_version). - append_observation() writes one JSON line; append-only, lines are never rewritten. A later review is a NEW line with the same observation_id; load_observations(reconcile=True) keeps the latest per id. - load_observations() reads a single .jsonl or a directory of monthly .jsonl files. - aggregate_by_hypothesis() (59c) -> per-hypothesis distribution + confidence, COMPUTED from the log (computed-not-stored); the review gate (reviewed-only) is enforced in empirical_distribution/confidence. - review_queue() -> the unreviewed worklist. Observation -> Review -> Accepted -> recompute, never Observation -> confidence++. Nothing is ever written back to a hypothesis. You can `rm` the log and recompute, `git diff` it over months, or rebuild confidence under a new policy — fully consistent with computed-not-stored and the product/knowledge data separation. Non-runtime (module + tests only, no endpoint) -> origin/main, NO dev deploy. 5 new tests (append-only, review supersession, review-gate statistics, queue, monthly-file load); 27 onboarding tests pass, mypy --strict clean (9 modules), check-loc 0. 59d (surface computed confidence at runtime) stays a later step.	2026-06-28 16:29:54 +02:00
pilotadmin	e54f3cde94	Merge pull request 'fix(onboarding): review decisions — ISO13485 + patch rationale + summary counter' (#50) from feat/review-decisions into main	2026-06-28 16:18:32 +02:00
Benjamin Admin	77459d06d6	fix(onboarding): apply hypothesis/vocabulary review decisions (ISO13485, patch-policy rationale, summary) ... Two reviewed knowledge decisions (2026-06-28) + the deferred cosmetic counter, before #59. 1. ISO13485 removed from the incident_management hypothesis. ISO 13485 CAPA / quality-safety incident handling is NOT security incident management — the mapping was too broad and would seed false hypotheses for the empirical loop. A dedicated manage_quality_and_safety_incidents capability can come later IF a target needs it; not forced now. (ISO27001/TISAX/IEC62443 keep incident_management.) 2. patch_policy_doc -> secure_signed_update_distribution stays `partial`, but the curated rationale is sharpened: "indicates update governance, does not evidence signed distribution" (a patch policy is not proof of SIGNED distribution). New optional SignalMapping.rationale field carries the curated note. (github_actions_ci -> SDL and dependency_scanning -> vuln-mgmt reviewed and APPROVED as-is.) 3. Cosmetic (folded in since we touched the file): the silent-intake summary now counts detected and indications SEPARATELY ("N automatisch erkannt, M Indikation(en)") instead of lumping partial signals into "automatisch erkannt" — consistent with the three-state model just shipped. Tests: ISO13485 no longer resolves to incident_management; summary counts split correctly. 29 onboarding tests pass, mypy --strict clean, demo runs, check-loc 0. Runtime-visible (hypothesis resolution + summary text) -> deploy + smoke.	2026-06-28 16:18:28 +02:00
pilotadmin	3202e555ab	Merge pull request 'fix(onboarding): partial != detected — indication, not auto-detect (Fix B)' (#49) from feat/partial-decouple into main	2026-06-28 16:02:55 +02:00
Benjamin Admin	978052b5a2	fix(onboarding): decouple partial/indicative signals from detected — partial no longer removes a question ... Fix B of the pre-#59 semantic correction. The Silent Pass had only TWO effective states though the data carries three: a `detected` mapping (a concrete artifact) AND a `partial` mapping (an indicative signal, e.g. a CI pipeline -> secure-development-lifecycle) both flowed through capability_ids() and were fed to the Advisor as already-present — so a weak indication silently removed a question, exactly the Welt-1/ Welt-2 transparency we want to keep. Now three distinct states: - detected -> reduces the delta immediately (auto_detected, not asked). [unchanged] - partial -> raises assumption strength but does NOT replace the question (surfaced as `indications`, the capability stays in the delta and is still asked). - requirement-> describes a target, never the present state (already handled by Fix A's kind split). Changes (data + thin wiring, no new architecture): - SilentIntakeResult.capability_ids() returns only relationship==detected; new indicative_capability_ids() returns the partial ones. - advisor_start() gains indicative_capabilities (NOT fed into the profile) and surfaces result.indications = indicative ∩ required − auto_detected. - AdvisorResult / AdvisorResponse gain `indications` (additive, contract-safe); the service passes the indicative ids through. Tests: a partial CI signal is indicative-not-detected and does NOT shrink the delta; end-to-end it appears in `indications`, not `auto_detected`, and the gap is still asked. 28 onboarding tests pass, mypy --strict clean on the onboarding modules, demo runs, check-loc 0. Runtime effect -> deploy + smoke.	2026-06-28 16:02:35 +02:00
pilotadmin	19931208a9	Merge pull request 'fix(onboarding): observation vs requirement signals — demanded ≠ present (Fix A)' (#48) from feat/signal-kind-split into main	2026-06-28 15:53:10 +02:00
Benjamin Admin	c39787ad96	fix(onboarding): separate observation vs requirement signals — a demanded SBOM is not a present SBOM ... Semantic correction of the knowledge base BEFORE the empirical loop (#59) is built — otherwise the Observation Store would learn from already-misclassified signals. The Silent Pass conflated two kinds of signal into one: an OBSERVATION ("I saw an SBOM in the repo") and a REQUIREMENT ("a tender DEMANDS an SBOM"). They were aliased to the same canonical id, so a tender clause read as "SBOM already present" and suppressed the very question that should have been asked. Fix — make the kind explicit and authoritative (no new architecture, data + thin wiring): - `kind` ∈ {observation, requirement} on ProducedSignal (producer may declare) and on the canonical SignalVocabularyEntry (AUTHORITATIVE — a mislabelled producer cannot collapse the two). - Vocabulary split: sbom_file_found → sbom_present (obs) + sbom_required (req); security_txt_or_cvd_policy → cvd_policy_present (obs) + psirt_required (req); add signed_updates_required. requirement signals are intentionally UNMAPPED in intake_signal_map (they describe a target, not state). - silent_intake() consumes ONLY kind==observation; requirement signals are preserved in `requirements_seen` (visible/auditable) but NEVER become a detected capability. - normalize_signals() stamps the vocabulary's kind onto every IntakeSignal; unknown ids still pass through. This is the same Observation-vs-Requirement split the Requirements Verification Platform rests on: observations are reality, requirements are targets, and their comparison is the delta. A tender / OEM spec / law now produces requirement signals; scanners / repos / documents produce observation signals. Tests: rewrote the two test_signal_producer cases that previously ASSERTED the bug (tender == repo) to pin the correct split; regression — `requires_sbom` yields no capability + stays in requirements_seen while `cyclonedx_found` still detects sbom_creation; endpoint-level regression that a tender requirement does not auto-detect and the gap stays asked; vocabulary-kind-overrides-mislabelled-producer. 25 onboarding tests pass, mypy --strict clean, demo runs, check-loc 0. Runtime effect → deploy + smoke. (Fix A; partial-vs- detected decoupling follows as Fix B before #59.)	2026-06-28 15:52:50 +02:00
pilotadmin	b5b6cdddb3	Merge pull request 'POST /onboarding/advisor-start — expose the Advisor at runtime (#58)' (#47) from feat/onboarding-advisor-endpoint into main	2026-06-28 15:14:05 +02:00
Benjamin Admin	a4123ace71	feat: POST /onboarding/advisor-start — expose the Smart Onboarding Advisor at runtime (#58) ... This exposes the existing Smart Onboarding Advisor through a runtime endpoint; it does not add new reasoning logic. Tightly scoped: adapter boundary + endpoint, no big frontend, no persistence, no empirical learning, no new scanners, no LLM. POST /onboarding/advisor-start : (company + certifications + target + scanner_findings[ProducedSignal]) -> Normalizer -> Silent Knowledge Pass -> Advisor -> { silent_intake_summary, inferred_assumptions, rejected_assumptions, top_5_questions, capability_delta, top_measures, evidence_requests, completeness_summary, auto_detected, headline } GET /onboarding/targets : the supported target ids (CRA, TISAX, MDR, Environmental) compliance/services/onboarding_service.py is the app-caller: it loads the curated knowledge (hypothesis library, signal vocabulary + map, the target's required capabilities) once and calls the pure, tested orchestration (normalize_signals -> silent_intake -> advisor_start). The scanner ADAPTER boundary is the ProducedSignal format the request carries — existing scanners emit it, no new scanners. Thin handler (<30 LOC), registered in the auto-load list. No DB. Additive to the OpenAPI contract (contract test is additive-friendly; baseline regenerates on CI/py3.12). First deployable runtime feature -> dev deploy + smoke. mypy --strict clean, 22 onboarding tests pass, check-loc 0.	2026-06-28 15:14:00 +02:00
pilotadmin	3bb48f2147	Merge pull request 'Signal Producer interface + Normalizer — one signal language' (#46) from feat/silent-knowledge-pass into main	2026-06-28 14:51:08 +02:00
Benjamin Admin	c2c8f7e424	feat: Signal Producer interface + Normalizer — one signal language for all sources (before #58) ... Not scanner stubs — the scanners exist. The Silent Pass needs only their UNIFIED output. This adds the small common DATA FORMAT (not a new module/framework) the user asked for, exactly the Requirement- Source / MCAP / regulation-alias pattern: many inputs, one language. Producer A / B / C -> normalize_signals (vocabulary: id + aliases) -> canonical IntakeSignal -> Silent Pass - ProducedSignal {signal_id, source_type, confidence, evidence, provenance} = what ANY source emits (website scanner, repo scanner, PDF parser, tender parser, API, the user). - knowledge/onboarding/signal_vocabulary.yaml reduces producer dialects to a canonical signal: "SBOM present" arrives as cyclonedx_found / spdx_found / sbom_uploaded / requires_sbom (tender) — all become `sbom_file_found`. The Silent Pass cannot tell where it came from -> no per-scanner special logic, ever. - Unknown signals pass through (a new producer stays visible). confidence/evidence/provenance flow to the detected capability for the audit trail. A tender that "requires SBOM" now produces the same effect as a repo that HAS one — fits Vision V2 (Requirement Source over Regulation). Endpoint (#58) then has its final shape: POST -> Producers -> Normalizer -> Silent Pass -> Profile -> Delta -> Questions -> Roadmap. Non-runtime -> no deploy. mypy --strict clean, 14 onboarding tests pass, check-loc 0.	2026-06-28 14:49:57 +02:00
pilotadmin	b70c1b7c37	Merge pull request 'Silent Knowledge Pass — recognise before asking (Phase 0)' (#45) from feat/silent-knowledge-pass into main	2026-06-28 14:34:31 +02:00
Benjamin Admin	9c33582412	feat: Silent Knowledge Pass — recognise before asking (Phase 0, before the endpoint) ... Not the endpoint yet — the bigger knowledge lever first. The Advisor can say "I need 5 answers" but does not yet decide what it can find out by ITSELF. The Silent Knowledge Pass runs in front of the Advisor and, from signals existing scanners/parsers already produce (website, repository, documents, product data), deterministically derives capabilities the company demonstrably HAS + product facts that drive scope — so every recognised item shrinks the delta and removes a question. compliance/onboarding/silent_intake.py: silent_intake(signals, signal_map) -> detected_capabilities (+ evidence already in hand) + product_facts. The signal->conclusion map is curated DATA (knowledge/onboarding/intake_signal_map.yaml), signals are injected (scanners are upstream). Pure, deterministic, no LLM. advisor_start gains detected_capabilities (folded into the profile at HIGH confidence -> covered, not asked) and an auto_detected result + headline. The experience flips from a question wall to "we already recognised 4 capabilities, 2 product facts and have 4 pieces of evidence in hand — only these few remain". Order now: Silent Pass -> #58 endpoint/frontend -> #59 empirical loop. NOT new architecture, just an orchestration step in front. Non-runtime (no app caller) -> no deploy. 15 onboarding tests pass, mypy --strict clean, check-loc 0.	2026-06-28 14:34:27 +02:00
Benjamin Admin	23d977e26b	deploy: promote macmini staging to dev — merge live dev ai-sdk fixes (ePrivacy/§25 TDDDG, national-law subsidiarity) with +86 backend-compliance commits (Phase Ω, onboarding, hypotheses). Coordinated GO from all 4 sessions.	2026-06-28 13:57:07 +02:00
pilotadmin	88b83d4daf	Merge pull request 'Observation Model — empirical learning unit (Task 59a)' (#44) from feat/observation-model into main	2026-06-28 13:34:54 +02:00
Benjamin Admin	98d616d82b	feat: Observation Model — the empirical learning unit, defined BEFORE persistence (Task 59a) ... The learning point is not the hypothesis, it is the QUESTION — and confirmed/refuted is too coarse. "partial, only critical suppliers" or "certified but not lived" are not "wrong", they are valuable knowledge. So the chain is Hypothesis -> Question -> Observation -> (Review) -> Hypothesis, and the observation model must be defined cleanly before any store/API (else thousands of too-coarse observations get migrated later). compliance/onboarding/observations.py: - ObservationType: confirmed / partial / refuted / not_applicable / unknown (richer than binary). - Observation: {hypothesis_id, capability, question, answer (free text), observation_type, scope_note ("only critical suppliers"), evidence_uploaded, reviewed, reviewed_by}. - empirical_distribution() -> a DISTRIBUTION (confirmed 61 / partial 31 / refuted 8), not one %. - empirical_confidence() -> (confirmed + 0.5*partial) / (confirmed+partial+refuted); n.a./unknown excluded; None until calibrated. - REVIEW GATE: only reviewed observations calibrate — a raw answer never changes a hypothesis (no learning from outliers). Refactor: the hypothesis is now PURE curated knowledge — the binary observations counter and any confidence are removed from CapabilityHypothesis and the YAML; confidence is COMPUTED from the separate reviewed observation stream. Pure, mypy --strict clean. Persistence/aggregation/calibration are 59b/c/d. Non-runtime -> no deploy. 12 tests pass, check-loc 0.	2026-06-28 13:31:43 +02:00
pilotadmin	59b7006e5a	Merge pull request 'Certification Capability Hypotheses — capability-centric + empirical confidence' (#42) from feat/certification-hypotheses into main	2026-06-28 13:17:20 +02:00
Benjamin Admin	2d2cb2a244	feat: Certification Capability Hypotheses — capability-centric library + empirical confidence ... The bottleneck is knowledge, not the endpoint. This builds the knowledge the Onboarding Advisor needs, restructured per the user's key insight: NOT "ISO27001 -> 30 capabilities" but each hypothesis as its own object "capability -> supported_by: [certs]". A capability is written ONCE with all supporting certs, so the shared management-system core (document control, incident, supplier, audit, access, asset, monitoring, training, crypto, release, risk) covers most certifications with ~18 hypotheses instead of ~300 — and multi-certification merges AUTOMATICALLY (a company's inferred caps = every hypothesis whose supported_by intersects its certs). Welt-1 throughout: "IF cert present, EXPECT capability (verification required)", never "erfüllt". Capabilities NO cert suggests (SBOM, signed updates, CVD, support period) have no hypothesis -> they stay in the delta and get asked. confidence is EMPIRICAL: computed from real-onboarding observations (confirmed/(confirmed+refuted)), None until calibrated — never an LLM/expert score (record_observation + empirical_confidence). The long-term moat: knowledge that learns from reality, not from a norm. compliance/onboarding/hypotheses.py (resolve_for_certifications / inferred_hypotheses / empirical_ confidence / record_observation) feeds the existing advisor_start unchanged; the demo now runs on the curated library. Pure, mypy --strict clean, library is DATA (no norm text, no real names). Non-runtime -> no deploy. 12 tests pass, check-loc 0.	2026-06-28 13:16:45 +02:00
pilotadmin	02c9fdb18e	Merge pull request 'Smart Onboarding Advisor (ADR-012) — orchestration over existing engines' (#41) from feat/smart-onboarding-advisor into main	2026-06-28 12:46:23 +02:00
Benjamin Admin	3ba90f49cf	feat: Smart Onboarding Advisor — make the knowledge usable in onboarding (ADR-012) ... The user-named "right next runtime step": stop building knowledge, start using it automatically in onboarding — no sales training, no regulation picking. compliance/onboarding/ is an ORCHESTRATOR (not a new engine) wiring Company 2A -> RS-005 -> optimization -> completeness: advisor_start(input, cert_hypotheses, target_requirements, ...) -> AdvisorResult From (company + products + certifications + target) it returns inferred_assumptions, rejected_ assumptions, next_best_questions (<=5, ranked by information_gain + leverage + unknown_high_risk + evidence_missing, each self-explaining), capability_delta, top_measures, evidence_requests, unsupported_domains, completeness_summary. apply_answer() updates the profile (delta shrinks). Welt-1 throughout: certificates REDUCE questions but satisfy nothing automatically (verification_ required); relevance(evidence,target) keeps ISO 14001 out of the CRA result. Certificate->capability hypotheses + target requirements are INJECTED (curated knowledge, outsourced; not in code). All 7 acceptance criteria pass; mypy --strict clean. First app-caller wiring the engines into a product flow — still no endpoint/persistence, so 0 runtime effect -> no deploy yet (deploys when POST /onboarding/advisor-start + frontend are wired). check-loc 0.	2026-06-28 12:45:49 +02:00