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