rene.fichtmueller/shieldx
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
shieldx/docs/flexoptix-os/07-roadmap-offene-fragen.md
Claude 1b5f698f4c
Some checks failed
security-scan / secret-scan (push) Failing after 3s
Details
feat(compliance): add NIS2/ISO27001/SOC2 mappers, Compliance-Robot, EU-AI-Act-Agent; docs(flexoptix-os): consolidation concept 
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.
2026-07-14 14:46:51 +00:00

3.8 KiB
Raw Blame History

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 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.