1b5f698f4c
Some checks failed
security-scan / secret-scan (push) Failing after 3s
Extends the existing ATLAS/OWASP/EU-AI-Act compliance module with three new control-framework mappers (NIS2 Art. 21(2), ISO/IEC 27001 Annex A, SOC 2 Trust Services Criteria), each honestly marking what ShieldX covers vs. what remains an organizational/legal gap. ComplianceRobot aggregates all four frameworks into a single prioritized, owned action plan. EUAIActAgent adds active workflows on top of the existing static reporter: Art. 6/Annex III risk pre-screening, Annex IV technical documentation scaffolding, Art. 72 post-market monitoring plan, and the corrected 2027/2028 enforcement timeline. Adds docs/flexoptix-os/ — a broader consolidation concept covering the current state (Magatama/ShieldX, EO Global Pulse), target architecture for BEO (LibreChat/Presidio-based), a Transceiver Intelligence Platform architecture recommendation, and RunWork OS externalization strategy, grounded in adversarially-verified research citations.
69 lines
3.8 KiB
Markdown
69 lines
3.8 KiB
Markdown
# Roadmap und offene Fragen
|
|
|
|
## Offene Fragen, die nur du beantworten kannst
|
|
|
|
Diese Punkte blockieren die nächsten konkreten Schritte — bitte im nächsten Gespräch klären:
|
|
|
|
1. **Repo-Zuordnung.** Welche der in [00-overview.md](./00-overview.md) gelisteten Repos
|
|
(`LibreChat`, `adaptive-llm-gateway`, `llm-gym`, `netbox-flexoptix-api`, `netprobe`,
|
|
`peeringdb-ts`, `PeerCortex`, `switchblade`, `leakguard`, `PaperCortex`) entsprechen
|
|
tatsächlich BEO, Fossy, Lupo/Lobu, EO Pulse, FoCI? Fehlt eines komplett (noch nicht als
|
|
Code vorhanden)?
|
|
2. **"EO Global Pulse" vs. "BEO" vs. "EO Pulse".** Ist EO Global Pulse (das Next.js-Projekt,
|
|
das die vorhandene ShieldX-Middleware nutzt) identisch mit dem, was du "BEO" nennst,
|
|
oder ein separates, drittes System? Das entscheidet, ob Kapitel 02 direkt umsetzbar ist
|
|
oder neu gedacht werden muss.
|
|
3. **Freigabe für Repo-Zugriff.** Sobald die Zuordnung steht: Sollen die entsprechenden
|
|
Repos per `add_repo` in eine Folge-Session geholt werden, damit eine echte
|
|
Code-Analyse (statt Namens-Heuristik) möglich wird?
|
|
4. **RunWork OS Timing.** Stimmst du der Empfehlung zu, RunWork OS erst nach 2-3 produktiven
|
|
Flexoptix-OS-Fachtools zu starten (Kapitel 05), oder soll parallel vorgearbeitet werden?
|
|
|
|
## Vorgeschlagene Phasen
|
|
|
|
### Phase 0 — Klärung (diese Woche)
|
|
- Die vier Fragen oben beantworten.
|
|
- Betroffene Repos per `add_repo` freigeben.
|
|
|
|
### Phase 1 — Magatama härten (vor Breiteneinsatz)
|
|
- Die in `CONCEPT-shieldx-v1.0.md` dokumentierten Lücken schließen (Stub-Scanner wiring,
|
|
Pattern-Persistenz, Testabdeckung Richtung 80%).
|
|
- Fail-open-Verhalten der EO-Global-Pulse-Middleware bewusst dokumentieren/entscheiden
|
|
(Kapitel 01) — für NIS2/EU-AI-Act-Zwecke muss ein ShieldX-Ausfall selbst als Ereignis
|
|
sichtbar sein, nicht nur stillschweigend durchgereicht werden.
|
|
- `ComplianceRobot`/`EUAIActAgent` (bereits gebaut) an ein echtes Dashboard anbinden
|
|
(Erweiterung des bestehenden `dashboard/ShieldXDashboard.tsx`).
|
|
|
|
### Phase 2 — BEO aufbauen
|
|
- LibreChat-Fork als Basis nehmen, Skills-System + Subagents-Muster für Flexoptix-eigene
|
|
Adapter (Fossy-Adapter, FoCI-Adapter, Lupo-Adapter, BIO-Adapter) konfigurieren.
|
|
MCP/OpenAPI Actions statt Legacy-LangChain-Tools verwenden.
|
|
- Presidio-Anonymisierungsschicht + Policy-Gate (lokal vs. extern) einbauen.
|
|
- Magatama-Middleware (Vorbild: `eo-global-pulse-middleware.ts`) vor jeden BEO-Chat-Turn
|
|
schalten.
|
|
- GPTCache für semantisches Caching als ersten Kostenoptimierungs-Baustein.
|
|
|
|
### Phase 3 — Fachtools anschließen
|
|
- Jedes Fachtool (Fossy, FoCI, Lupo, BIO) bekommt: (a) die Magatama-Middleware, (b) einen
|
|
BEO-Adapter/Skill, (c) einen `ComplianceRobot`-Aufruf für sein eigenes QM-Cockpit-Panel.
|
|
|
|
### Phase 4 — Flexoptix OS Cockpit
|
|
- Zentrales Dashboard, das pro Fachtool die ComplianceRobot-/QM-Kennzahlen aggregiert.
|
|
- Für BIO: DDM/DOM-Telemetrieschicht (Telegraf/TimescaleDB) + Live-Dashboard.
|
|
|
|
### Phase 5 — RunWork OS
|
|
- Erst nach Phase 3/4 mit mindestens 2 produktiven Fachtools starten (siehe Kapitel 05).
|
|
|
|
## Nicht in diesem Branch enthalten (bewusste Abgrenzung)
|
|
|
|
- Kein Code für BEO/Fossy/Lupo/BIO/RunWork OS — die liegen (falls vorhanden) in anderen
|
|
Repos, auf die diese Session keinen Zugriff hatte.
|
|
- Keine Entscheidung über Hosting/Infrastruktur für die Zeitreihen-DB (BIO) oder für
|
|
Mandantentrennung (RunWork OS) — das sind Infrastruktur-Entscheidungen, keine
|
|
Architektur-Empfehlungen, die aus einer Recherche folgen.
|
|
- Block 3 der Recherche (EU AI Act OSS-Tooling) blieb in der ersten, adversarial
|
|
verifizierten Welle leer; die Ergänzung aus Welle 2 hat niedrigere Evidenzstärke (siehe
|
|
Kapitel 06). Vor einer Investitionsentscheidung in Richtung eines vollständigen
|
|
OSCAL-basierten Evidence-Collectors empfiehlt sich eine dedizierte dritte Rechercherunde,
|
|
sobald das Subagenten-Wochenlimit zurückgesetzt ist.
|