# JARVIS Command Dashboard — Architektur-, MVP- und Umsetzungsbericht

**Version:** 0.1 zur Freigabe  
**Datum:** 2026-06-13 15:27 CEST  
**Ziel-Repository:** `https://github.com/Gamexgit/Jarvis`  
**Betroffene Systeme:** JARVIS Finance, AutoShortsBot Dashboard, HealthManager/Gesundheitssystem, JARVIS/Hermes Systemebene  
**Autor/Rolle:** JARVIS/Hermes als Chef-Architekt und Orchestrator

---

## 1. Executive Summary

Das neue Repository `Gamexgit/Jarvis` soll nicht zu einem monolithischen Ersatz aller bestehenden Systeme werden. Die empfohlene Zielarchitektur ist ein **zentrales JARVIS Command Dashboard** als einheitliche Benutzeroberfläche im Iron-Man/JARVIS-Stil, darunter jedoch weiterhin **fachlich getrennte Systeme und Repositories**.

Die Kernentscheidung lautet:

> **Ein Frontend, ein Gateway, mehrere getrennte Domain-Backends.**

Das Dashboard wird der zentrale Einstiegspunkt und das Control Center. Finance, Health und AutoShorts behalten ihre eigenen Datenbanken, Backends, Repositories, Sicherheitsregeln und Audit-Logs. Das neue JARVIS-Dashboard aggregiert Status, Alerts, Freigaben und Reports über definierte API-Verträge.

Damit wird ausdrücklich verhindert, dass die Gesamtarchitektur gefährdet wird, wenn später in einem einzelnen Subsystem gearbeitet wird. Arbeiten am Gesundheitssystem, am AutoShorts-System oder am Finanzsystem bleiben möglich, ohne dass das Gesamtdashboard instabil wird — vorausgesetzt, jedes Modul hält sich an klare Adapter- und API-Kontrakte.

Der MVP soll zunächst **read-only und integrationsarm** starten: zentrale Shell, Modulübersicht, Systemstatus, Links zu bestehenden Dashboards, erste aggregierte Statuskarten. Danach folgen schrittweise native Module, beginnend mit AutoShorts Queue/Freigaben, Health Summary und Finance Review/Importstatus.

---

## 2. Ausgangslage

### 2.1 Bestehende Dashboards und Systeme

Aktuell existieren mehrere getrennte Dashboards beziehungsweise Systeme mit unterschiedlichem Reifegrad:

1. **JARVIS Finance / Finanzsystem**
   - Budget, Portfolio, Imports, Review-Queues, Reports, möglicherweise Einkaufs-/Grocery-Funktionen.
   - Hohes Sicherheitsniveau erforderlich.
   - Keine automatischen Buchungen, Trades oder echten Finanzaktionen ohne explizite Freigabe.
   - Keine sensiblen Beträge, IDs, Tokens oder Rohdaten in Chat/Frontend-Logs.

2. **AutoShortsBot Dashboard**
   - Lokale Hinweise zeigen ein bestehendes Vue/Vite Frontend unter `~/projects/AutoShorts_Dashboard/frontend`.
   - Backend-Struktur mit FastAPI-/Python-artigen Routen und Services erkennbar, z.B. Production Queue, Upload Requests, Website Bridge, YouTube Private Upload, Reconciliation, Analytics.
   - Starke Eignung für ein zentrales Approval-/Queue-Cockpit.

3. **HealthManager / Gesundheitssystem**
   - Lokale Datenstruktur unter `~/.hermes/assets/Gesundheit/`.
   - Remote-Repository `https://github.com/Gamexgit/HealthManager` ist erreichbar, privat, Default Branch `main`, letzte erkannte Aktualisierung: 2026-05-12.
   - Enthält laut Remote-Probe u.a. `scripts/health/health_pipeline.py`, `health_dashboard_v3.py`, Apple-Health-Sync, Reports, Backups und Skill-Dokumentation.
   - Kritisch: Gesundheitsdaten bleiben vertraulich. Das Repo darf Code/Doku enthalten, aber keine medizinischen Rohdaten, PDFs, Datenbanken oder Credentials.

4. **JARVIS/Hermes Systemebene**
   - Cronjobs, Agentenstatus, Telegram-Routing, Backups, Drive-Syncs, Modellrouting, Memory-Konzept.
   - Gehört als eigenes Modul in das Command Dashboard, aber nicht als unkontrollierter Adminzugang.

### 2.2 Neues Gesamt-Repository

Neues Repository:

```text
https://github.com/Gamexgit/Jarvis
```

Aktueller verifizierter Stand:

- Repository ist privat.
- Default Branch: `main`.
- Größe: `0 KB`, also leer beziehungsweise noch ohne produktiven Code.
- Push-/Arbeitsstart ist geeignet, sobald das Architekturkonzept freigegeben ist.

### 2.3 Hauptsorge: Kontextverlust im Hauptchat

Die Sorge ist berechtigt: Wenn alle Systeme in einem Hauptchat diskutiert, entwickelt und geändert werden, besteht das Risiko, dass:

- Domain-Regeln vermischt werden.
- Health-/Finance-Sicherheitsregeln versehentlich auf AutoShorts angewandt oder umgekehrt vergessen werden.
- Entscheidungen nur im Chat existieren und später verloren gehen.
- JARVIS bei Subsystem-Arbeiten den Gesamtzusammenhang verliert.
- Änderungen an einem Modul unbemerkt andere Module brechen.

Die Architektur muss deshalb nicht nur technisch, sondern auch organisatorisch modular sein.

---

## 3. Architekturprinzipien

### 3.1 Modularität vor Monolith

Jedes Subsystem bleibt eigenständig:

- eigenes Repository oder klar separater Codebereich
- eigene Datenbank
- eigene Secrets
- eigene Jobs/Cronjobs
- eigene Tests
- eigene fachliche Regeln
- eigene Audit-Logs

Das neue JARVIS-Dashboard wird nicht der Besitzer aller Daten, sondern der **Orchestrator und Visualisierer**.

### 3.2 API Contracts statt Chat-Erinnerung

Jedes Modul erhält einen stabilen Vertrag:

- Welche Statusdaten liefert das Modul?
- Welche Aktionen darf das Dashboard auslösen?
- Welche Aktionen sind read-only?
- Welche Daten dürfen niemals ans Frontend?
- Welche Felder sind Pflicht?
- Welche Fehlercodes und Statuszustände gibt es?

Diese Verträge werden versioniert im neuen Repository dokumentiert.

Beispiel:

```json
{
  "module": "health",
  "status": "ok",
  "severity": "normal",
  "updated_at": "2026-06-13T15:27:00+02:00",
  "summary": {
    "last_sync": "2026-06-12T23:45:00+02:00",
    "pending_reviews": 2,
    "latest_report": "arztbericht_aktuell.pdf"
  },
  "actions": [
    {
      "id": "generate_health_report",
      "label": "Arztbericht aktualisieren",
      "mode": "preview_confirm",
      "risk": "medium"
    }
  ]
}
```

### 3.3 Read-only First

Die erste Version darf primär anzeigen, nicht verändern. Schreibende Aktionen werden erst eingeführt, wenn:

1. API-Vertrag existiert.
2. Preview-Endpunkt existiert.
3. Confirm-Endpunkt existiert.
4. Audit-Log existiert.
5. Tests existieren.
6. UI den Risiko-/Impact-Text klar anzeigt.

### 3.4 Preview → Confirm → Audit

Alle relevanten Aktionen folgen diesem Muster:

```text
User wählt Aktion
        ↓
System erzeugt Preview
        ↓
User prüft Risiko/Impact
        ↓
User bestätigt explizit
        ↓
Backend führt Aktion aus
        ↓
Audit-Log + Resultat
```

Das gilt besonders für:

- Finance Imports / Kategorisierungen / Buchungen
- Health-Dokumentverarbeitung / Report-Generierung
- AutoShorts Produktion / Upload Requests / Website-Bridges
- Systemneustarts / Cronjob-Änderungen

### 3.5 Keine gemeinsame Super-Datenbank

Es wird keine zentrale Datenbank geben, die Finance-, Health- und AutoShorts-Daten vermischt.

Erlaubt ist eine kleine Dashboard-Datenbank für:

- UI Sessions
- User Preferences
- Modulregistrierung
- globale Activity Events
- Gateway Audit Events
- Feature Flags
- cached Status Snapshots ohne sensitive Rohdaten

Nicht erlaubt in der Dashboard-Datenbank:

- Gesundheitsdaten-Rohwerte
- Finanztransaktionen mit echten Beträgen
- PDFs, Dokumentinhalte, Kontoauszüge
- Tokens, Secrets, API Keys
- private YouTube-/Drive-Links ohne Schutzkonzept

### 3.6 Strikte Sicherheitsdomänen

Module werden in Sicherheitsdomänen eingeteilt:

- **Public-ish / Low Risk:** UI Theme, allgemeiner Systemstatus ohne Details.
- **Operational:** AutoShorts Queue, Renderstatus, nichtöffentliche Produktionsdaten.
- **Sensitive:** Finance, Health, Credentials, persönliche Dokumente.
- **Critical:** Trades, Buchungen, medizinische Interpretation, Public Publishing, Secret Rotation, destructive Actions.

Das Frontend muss diese Stufen sichtbar machen.

---

## 4. Zielarchitektur

### 4.1 High-Level-Struktur

```text
┌─────────────────────────────────────────────────────────────┐
│                 JARVIS Command Dashboard                    │
│              Vue/Vite Frontend im JARVIS HUD Stil           │
└───────────────────────────────┬─────────────────────────────┘
                                │ HTTPS/Tailscale/internal
                                ▼
┌─────────────────────────────────────────────────────────────┐
│                  JARVIS API Gateway / BFF                   │
│ Auth, Sessions, Module Registry, Aggregation, Audit, Proxy  │
└───────┬───────────────────────┬───────────────────────┬─────┘
        │                       │                       │
        ▼                       ▼                       ▼
┌───────────────┐       ┌───────────────┐       ┌────────────────┐
│ Finance API   │       │ Health API    │       │ AutoShorts API │
│ separate repo │       │ separate repo │       │ separate repo  │
└───────────────┘       └───────────────┘       └────────────────┘
        │                       │                       │
        ▼                       ▼                       ▼
Finance DB/Reports       Health DB/Reports       AutoShorts DB/Media
```

### 4.2 Frontend

Empfohlener Stack:

- Vue 3
- Vite
- TypeScript
- Pinia für State Management
- Vue Router
- Tailwind oder PrimeVue-kompatibles Styling
- ECharts oder Chart.js für Visualisierungen
- Zod oder TypeScript Runtime Validation optional für API-Contracts

Begründung:

- AutoShorts verwendet bereits Vue/Vite.
- Schnelle Entwicklung.
- Gute Dashboard-Eignung.
- Geringere Komplexität als ein schweres Enterprise-Framework.
- Gut für lokale/Tailscale-Deployments.

### 4.3 API Gateway / BFF

Empfohlener Stack:

- Python FastAPI
- Pydantic Models für API Contracts
- SQLite für Dashboard-eigene, nicht-sensitive Metadaten
- HTTPX für interne Adapter Calls
- Uvicorn/Gunicorn oder systemd/Docker für Betrieb

Alternative wäre Node/NestJS. Da die bestehenden Systeme stark Python-lastig sind, ist FastAPI naheliegend.

Aufgaben:

- Authentifizierung
- Autorisierung
- Modulregistrierung
- Healthchecks
- Aggregation von Statusdaten
- Gateway-Audit
- Rate Limiting
- sichere Proxy-Endpunkte
- API-Normalisierung
- Redaction von sensiblen Details
- Feature Flags

### 4.4 Domain Adapter

Jedes Domain-System erhält einen Adapter im Gateway.

```text
api-gateway/app/adapters/
├── finance.py
├── health.py
├── autoshorts.py
└── system.py
```

Der Adapter übersetzt zwischen dem JARVIS-Gateway-Vertrag und dem jeweiligen Backend.

Wichtig: Wenn ein Domain-Backend noch keine API hat, darf der Adapter zunächst:

- lokale Statusdateien lesen
- Reports erkennen
- Healthcheck-Skripte ausführen
- statische Links liefern
- nur read-only Daten aggregieren

Schreibende Aktionen werden erst erlaubt, wenn das Domain-Backend dafür sichere Endpunkte bereitstellt.

---

## 5. Repository- und Arbeitsmodell

### 5.1 Empfohlenes Repo-Modell

Bestehende Repositories bleiben bestehen:

```text
Gamexgit/Jarvis              # neues Command Dashboard + Gateway + Contracts
Gamexgit/HealthManager       # Health-Code, Pipelines, Dashboard v3, Reports, ohne Rohdaten
Gamexgit/AutoShorts...       # AutoShorts-System / Dashboard / Backend
Gamexgit/Finance...          # Finance-System / Backend / Imports / Reports
```

Das neue `Jarvis` Repo enthält:

```text
Jarvis/
├── apps/
│   ├── dashboard/              # Vue/Vite Frontend
│   └── api-gateway/            # FastAPI Backend-for-Frontend
├── packages/
│   ├── contracts/              # OpenAPI, JSON Schemas, TS/Python Typen
│   ├── ui/                     # gemeinsame UI-Komponenten
│   └── theme/                  # JARVIS HUD Design Tokens
├── docs/
│   ├── architecture.md
│   ├── mvp.md
│   ├── security.md
│   ├── decisions/              # ADRs
│   ├── module-contracts/
│   │   ├── finance.md
│   │   ├── health.md
│   │   ├── autoshorts.md
│   │   └── system.md
│   └── runbooks/
├── scripts/
│   ├── dev.sh
│   ├── healthcheck.sh
│   └── verify.sh
├── tests/
│   ├── contract/
│   └── e2e/
└── README.md
```

### 5.2 Wie verhindert man Kontextverlust?

Nicht der Telegram-Hauptchat darf die Quelle der Wahrheit sein, sondern das Repository.

Dafür werden verbindlich genutzt:

1. **Architecture Decision Records (ADRs)**  
   Jede wichtige Architekturentscheidung wird als Datei abgelegt:

   ```text
   docs/decisions/0001-separate-domain-backends.md
   docs/decisions/0002-read-only-first.md
   docs/decisions/0003-preview-confirm-audit.md
   ```

2. **Module Contracts**  
   Jede Domäne erhält eine Vertragsdatei:

   ```text
   docs/module-contracts/health.md
   docs/module-contracts/finance.md
   docs/module-contracts/autoshorts.md
   ```

3. **Roadmap und Milestones**

   ```text
   docs/roadmap.md
   docs/milestones/mvp-0-shell.md
   docs/milestones/mvp-1-gateway.md
   ```

4. **GitHub Issues statt Chat-TODOs**  
   Für jedes Modul werden Issues angelegt:

   - `module:health`
   - `module:finance`
   - `module:autoshorts`
   - `module:gateway`
   - `module:frontend`
   - `risk:security`
   - `phase:mvp`

5. **Branching pro Subsystem**

   ```text
   feature/frontend-shell
   feature/gateway-module-registry
   feature/health-adapter-readonly
   feature/autoshorts-queue-integration
   feature/finance-summary-readonly
   ```

6. **Contract Tests**  
   Das Dashboard testet nicht jedes Domain-System intern, sondern prüft, ob jedes Modul seinen Vertrag erfüllt.

Damit kann Sir jederzeit an einem Einzelsystem arbeiten lassen, ohne dass das Gesamtkonzept verloren geht.

### 5.3 Arbeiten an einzelnen Systemen ohne Gefährdung des Gesamtkonzepts

Ja, das ist ausdrücklich vorgesehen.

Beispiel Health:

- Änderungen an `HealthManager` erfolgen im Health-Repo.
- Solange der Health Adapter weiterhin die Contract-Felder liefert, bleibt das JARVIS Dashboard stabil.
- Neue Health-Funktionen erscheinen erst im JARVIS Dashboard, wenn Contract und UI bewusst erweitert werden.

Beispiel AutoShorts:

- AutoShorts kann weiterhin eigene Sprints fahren.
- Das JARVIS Dashboard konsumiert nur freigegebene API-Endpunkte: Queue, Packages, Approval Status, Upload Requests.
- Wenn AutoShorts intern Refactoring betreibt, muss nur der Adapter oder Contract stabil bleiben.

Beispiel Finance:

- Finance kann getrennt weiterentwickelt werden.
- Das Dashboard bekommt zunächst nur Summary/Review Counts/Importstatus.
- Keine Finance-Schreibaktion wird ohne Preview/Confirm/Audit in das Gesamt-Dashboard gehoben.

---

## 6. MVP Definition

### 6.1 MVP-Ziel

Der MVP soll beweisen:

1. Ein zentrales JARVIS Dashboard kann alle Systeme übersichtlich darstellen.
2. Die bestehenden Systeme bleiben separat.
3. Statusdaten können sicher aggregiert werden.
4. Das UI ist als dauerhaftes Command Center geeignet.
5. Die Architektur ist erweiterbar, ohne Big Bang Rewrite.

### 6.2 MVP Scope

Der MVP umfasst:

#### Frontend

- JARVIS HUD Layout
- Login oder lokaler Access Gate
- Dashboard Home
- Modulnavigation
- Statuskarten für:
  - Finance
  - Health
  - AutoShorts
  - JARVIS System
- Activity Timeline
- Pending Approvals Panel
- Reports Panel
- Links zu bestehenden Dashboards
- Responsive Layout für Desktop und Tablet; Mobile als sekundäres Ziel

#### Gateway

- FastAPI App
- `/api/healthz`
- `/api/modules`
- `/api/overview`
- `/api/activity`
- `/api/approvals`
- read-only Adapter Stubs für Finance, Health, AutoShorts, System
- Redaction Layer
- lokales Audit für Gateway Requests

#### Contracts

- Gemeinsamer Modulstatus-Vertrag
- Gemeinsamer Approval-Vertrag
- Gemeinsamer Report-Link-Vertrag
- Gemeinsamer ActivityEvent-Vertrag

#### Betrieb

- lokale Entwicklung per `scripts/dev.sh`
- `.env.example` ohne Secrets
- README mit Startanleitung
- Smoke Test Script
- Basis-CI als Vorlage oder aktive GitHub Action, abhängig von Token-Scope

### 6.3 MVP Nicht-Ziele

Der MVP soll ausdrücklich noch nicht:

- echte Finance-Aktionen auslösen
- medizinische Entscheidungen treffen
- Health-Rohdaten anzeigen
- AutoShorts automatisch public posten
- Website automatisch ohne Freigabe aktualisieren
- alle alten Dashboards ersetzen
- ein Public-Internet-Service sein
- eine zentrale Datenbank für alles einführen

### 6.4 MVP Screens

#### 1. Command Overview

Zentrale Übersicht:

- Systemstatus
- Modulstatus
- kritische Alerts
- nächste Freigaben
- letzte Aktivitäten
- schnell erreichbare Reports

#### 2. Module Pages

Jedes Modul bekommt zunächst eine einfache Seite:

- Status
- letzte Aktualisierung
- wichtigste KPIs
- offene Reviews/Freigaben
- Link zum Legacy-Dashboard
- Link zu Reports
- bekannte Einschränkungen

#### 3. Approvals Center

Ein zentrales Freigabecenter:

- AutoShorts Concept Approval
- AutoShorts Upload Request
- Health Report Generation Request
- Finance Review Items zunächst nur als read-only Count

#### 4. Reports Center

Ein zentraler Einstieg zu Reports:

- Health Arztbericht
- Health Dashboard HTML
- Finance Monatsreport
- AutoShorts Analytics/Learning Reports
- System Backups/Run Logs

#### 5. System Page

- Cronjob Status
- letzte Syncs
- letzte Backups
- verfügbare Services
- Fehlerzustände mit gekürzten Logs

---

## 7. Funktionalitäten nach Modul

### 7.1 Global / Command Center

Funktionen:

- Globaler Statusring: `ok`, `warning`, `critical`, `offline`
- Modulübersicht
- Alerts
- Pending Approvals
- Activity Timeline
- Report Shortcuts
- System Health
- Search/Command Palette später optional
- Theme: JARVIS/Iron-Man, aber lesbar und produktiv

### 7.2 Health Modul

MVP read-only:

- Status der Health Pipeline
- letzter Apple-Health-Sync
- letzter YAZIO-Sync, falls verfügbar
- letzter Arztbericht
- Link zu `reports/health_dashboard.html`
- Anzahl offener Review-/Validierungsitems
- Dokumentstatus aggregiert
- Labortrend-Summary ohne sensible Detailtabellen im MVP

Später:

- Labortrend-Visualisierung im JARVIS UI
- Medikamenten-/Symptom-/Event-Timeline
- Report generation mit Preview/Confirm
- Dokumentverarbeitungsstatus
- Review Workflow für unbestätigte Laborwerte
- Export/Drive-Link Management

Sicherheitsregeln:

- Keine Health-Rohdaten in globalen Logs.
- Keine finale medizinische Diagnose im Dashboard.
- Unvalidierte Werte klar markieren.
- Arztberichte/Drive-Links geschützt behandeln.

### 7.3 Finance Modul

MVP read-only:

- Importstatus
- Anzahl Review Items
- Budget-/Portfolio-Summary mit redacted/aggregierten Daten
- letzter Report
- Datenqualität: fehlende Kategorien, Dubletten, offene Zuordnungen
- Link zum bestehenden Finance Dashboard

Später:

- Review Queue mit Preview
- Merchant/Category Confirm Flow
- Monatsabschluss Cockpit
- Portfolio Snapshot
- Szenario-/Rebalancing-Unterstützung
- Grocery/Budget Optimizer als separater Bereich

Sicherheitsregeln:

- Keine echten Kontodetails im Frontend ohne Bedarf.
- Keine Autobookings.
- Keine Trades.
- Keine Beträge in Chat-Ausgaben.
- Jede bestätigende Aktion: Preview → Confirm → Audit.

### 7.4 AutoShorts Modul

MVP read-only plus eventuell einfache Approval-Links:

- Production Queue
- Concept Gate Status
- Director Pass Status
- Renderstatus
- Upload Requests
- Website Companion Status
- Analytics Import Status
- Link zum bestehenden AutoShorts Dashboard

Später:

- Concept Approval direkt im JARVIS Dashboard
- Director Review Page
- private YouTube Upload Request
- Website Update Preview
- Learning Loop: Results / Improvements / Import Data
- Content Calendar
- Package Review mit Thumbnail/Video Preview

Sicherheitsregeln:

- YouTube Upload private-only.
- Keine automatische Public-Veröffentlichung.
- TikTok bleibt manuell.
- Kein Website Push/Delete ohne explizite Freigabe.
- Imported analytics dürfen private CSV-Zeilen/Private Videos nicht falsch in öffentliche Metriken mischen.

### 7.5 JARVIS System Modul

MVP:

- Hermes/JARVIS Dienststatus
- Cronjob Summary
- letzter Morning Briefing Run
- letzte Backups
- Telegram Topic Routing Hinweise
- Modell-/Workerstatus als redacted Summary

Später:

- Cronjob Detailseite
- Runbook Actions mit Confirm
- Log Viewer mit Redaction
- Tailscale Service Status
- Gateway/API Health Monitor

Sicherheitsregeln:

- Keine Secrets in Logs.
- Keine destruktiven Systemaktionen ohne Confirm.
- Keine automatischen Änderungen an Modellrouting/Secrets aus UI ohne explizite Freigabe.

---

## 8. API-Contract Entwurf

### 8.1 ModuleStatus

```json
{
  "id": "autoshorts",
  "name": "AutoShorts",
  "status": "ok",
  "severity": "normal",
  "updated_at": "2026-06-13T15:27:00+02:00",
  "summary": "2 packages waiting for review",
  "metrics": [
    {"key": "pending_reviews", "label": "Pending Reviews", "value": 2},
    {"key": "failed_jobs", "label": "Failed Jobs", "value": 0}
  ],
  "links": [
    {"label": "Legacy Dashboard", "url": "http://...", "kind": "internal"}
  ]
}
```

### 8.2 ActivityEvent

```json
{
  "id": "evt_...",
  "timestamp": "2026-06-13T15:27:00+02:00",
  "module": "health",
  "type": "report_generated",
  "severity": "info",
  "title": "Health report generated",
  "description": "Arztbericht aktualisiert",
  "artifact_ref": "health:report:arztbericht_aktuell"
}
```

### 8.3 ApprovalItem

```json
{
  "id": "approval_...",
  "module": "autoshorts",
  "title": "Concept approval required",
  "status": "pending",
  "risk": "medium",
  "created_at": "2026-06-13T15:27:00+02:00",
  "actions": [
    {"id": "preview", "label": "Preview", "method": "GET"},
    {"id": "confirm", "label": "Confirm", "method": "POST", "requires_confirmation": true}
  ]
}
```

### 8.4 ReportLink

```json
{
  "id": "health_doctor_report_current",
  "module": "health",
  "title": "Aktueller Arztbericht",
  "kind": "pdf",
  "updated_at": "2026-06-12T23:00:00+02:00",
  "url": "/api/health/reports/doctor/current",
  "sensitivity": "high"
}
```

---

## 9. Phasenplan bis zum finalen Dashboard

### Phase 0 — Freigabe & Inventar

Ziel:

- Architekturbericht prüfen und freigeben.
- Repositories, Pfade, Ports und Startbefehle erfassen.
- Sicherheitsgrenzen bestätigen.

Tasks:

- `Gamexgit/Jarvis` initialisieren.
- README, Architekturdocs, ADRs anlegen.
- Bestehende Repos inventarisieren.
- HealthManager-Repo mit lokaler Health-Installation vergleichen.
- AutoShorts API/Frontend strukturieren.
- Finance System Pfad/Repo/Status ermitteln.

Deliverables:

- `docs/architecture.md`
- `docs/security.md`
- `docs/module-contracts/*.md`
- GitHub Issues/Milestones

Akzeptanzkriterien:

- Sir kann das Zielbild prüfen.
- Kein Code greift auf echte sensitive Daten zu.
- Alle offenen Architekturfragen sind dokumentiert.

### Phase 1 — Repository Bootstrap

Ziel:

- Neues Repo enthält lauffähige Projektstruktur.

Tasks:

- Monorepo-Struktur anlegen.
- Frontend App erstellen.
- Gateway App erstellen.
- Contracts Package vorbereiten.
- `.env.example`, README, dev scripts.
- Smoke tests.

Deliverables:

- Lokaler Start per `scripts/dev.sh`.
- `/api/healthz` funktioniert.
- Dashboard Shell lädt.

Akzeptanzkriterien:

- Frontend zeigt JARVIS Shell.
- Backend Healthcheck grün.
- Keine Secrets im Repo.
- Initialer CI/Verify läuft lokal.

### Phase 2 — MVP Shell

Ziel:

- Zentrale Oberfläche mit Modul-Kacheln und Legacy Links.

Tasks:

- JARVIS HUD Design System.
- Home Dashboard.
- Module Registry.
- statische/read-only Module Cards.
- Activity Timeline Mock/Stub.
- Reports Panel Stub.

Deliverables:

- Benutzbares zentrales Dashboard.
- Noch ohne tiefe Backend-Abhängigkeit.

Akzeptanzkriterien:

- Sir kann alle bestehenden Systeme zentral erreichen.
- UI ist klar und nicht überladen.
- Desktop-Ansicht produktiv nutzbar.

### Phase 3 — Gateway Read-only Integrationen

Ziel:

- Dashboard bekommt echte Statusdaten aus den Systemen.

Tasks:

- Health Adapter read-only.
- AutoShorts Adapter read-only.
- Finance Adapter read-only.
- System Adapter read-only.
- Redaction Layer.
- Contract Tests.

Deliverables:

- `/api/overview` mit echten Modulstatusdaten.
- `/api/modules/{id}` Details.

Akzeptanzkriterien:

- Backend-Ausfall eines Moduls bricht nicht das Gesamtdashboard.
- Fehler werden als degraded angezeigt.
- Sensitive Daten werden nicht versehentlich angezeigt.

### Phase 4 — AutoShorts Native Integration

Ziel:

- AutoShorts wird als erstes tief integriertes Modul umgesetzt.

Begründung:

- Hoher Nutzen durch Queue-/Approval-Cockpit.
- Bestehendes Vue/Vite-Frontend erleichtert Übernahme von Patterns.
- Risiken geringer als bei Health/Finance.

Tasks:

- Production Queue anzeigen.
- Packages anzeigen.
- Concept Gate Status.
- Director Pass Status.
- Upload Request Status.
- Website Companion Status.
- erste gated Actions nur nach Preview/Confirm.

Akzeptanzkriterien:

- Keine automatische Veröffentlichung.
- Upload Requests bleiben private-only.
- UI zeigt klar, welche Pakete worauf warten.

### Phase 5 — Health Native Summary

Ziel:

- Health bekommt sichere, aggregierte Übersicht.

Tasks:

- letzter Sync.
- letzter Arztbericht.
- Labor-/Dokument-/Review-Counts.
- Links zu Reports.
- ausgewählte Trendcards ohne Rohdaten-Overexposure.
- Validierungsstatus sichtbar.

Akzeptanzkriterien:

- Keine Roh-PDFs oder medizinischen Details im globalen Overview.
- Unvalidierte Werte markiert.
- Bestehender HealthManager bleibt unabhängig.

### Phase 6 — Finance Native Summary

Ziel:

- Finance bekommt sichere, aggregierte Übersicht.

Tasks:

- Importstatus.
- Review Counts.
- Monats-/Budgetstatus redacted.
- Portfolio Summary redacted/aggregiert.
- Data Quality Status.
- Link zu Finance Reports.

Akzeptanzkriterien:

- Keine Auto-Trades.
- Keine Auto-Buchungen.
- Keine Secrets/Beträge in Logs/Chat.
- Schreibaktionen bleiben deaktiviert bis Contract reif ist.

### Phase 7 — Unified Approvals Center

Ziel:

- Eine zentrale Freigabezentrale für alle Module.

Tasks:

- ApprovalItem Contract produktiv.
- Preview Views.
- Confirm Flow.
- Gateway Audit.
- Domain Audit Bridge.

Akzeptanzkriterien:

- Jede Aktion ist rückverfolgbar.
- UI zeigt Risiko/Impact.
- Confirm braucht bewusste Nutzerhandlung.

### Phase 8 — Reports & Intelligence Layer

Ziel:

- JARVIS fasst zusammen und priorisiert, entscheidet aber nicht autonom in kritischen Domänen.

Tasks:

- Report Center.
- “Needs Attention” Engine.
- Daily/Weekly Summaries.
- Qwen/GPT read-only Summaries.
- keine kritischen Aktionen ohne Sir.

Akzeptanzkriterien:

- Empfehlungen sind erklärbar.
- Unsicherheiten werden angezeigt.
- Finance/Health Entscheidungen bleiben bei Sir.

### Phase 9 — Production Hardening

Ziel:

- Stabiler Dauerbetrieb.

Tasks:

- Auth hardening.
- Tailscale deployment.
- systemd/Docker service.
- Backup/restore.
- Monitoring.
- Error boundaries.
- E2E tests.
- Documentation.

Akzeptanzkriterien:

- Reproduzierbarer Start.
- Dienste überleben Neustarts.
- Ausfälle einzelner Module degradieren sauber.
- Tests und Runbooks vorhanden.

---

## 10. Sicherheitskonzept

### 10.1 Grundregeln

- Keine Secrets im Frontend.
- Keine Secrets im Git Repo.
- Keine Health-/Finance-Rohdaten in Dashboard-DB.
- Keine Public-Verfügbarkeit ohne bewusstes Security-Konzept.
- Tailscale-only als bevorzugter erster Betriebsmodus.
- Alle externen Links klassifizieren: internal, drive, github, local, public.
- Logs werden redacted.

### 10.2 Authentifizierung

MVP:

- Tailscale-only plus lokales Dashboard Secret oder Passwort.

Später:

- Session-basierte Auth.
- Optional 2FA oder OAuth.
- Rollen/Rechte:
  - Admin
  - Read-only
  - Health restricted
  - Finance restricted
  - Creator/AutoShorts only

### 10.3 Logging

Logging darf enthalten:

- Request ID
- Modul
- Aktion
- Status
- Dauer
- redacted Fehlertext

Logging darf nicht enthalten:

- Tokens
- Passwörter
- Gesundheitsdetails
- Konto-/Brokerdetails
- private Dokumentinhalte
- vollständige Drive URLs, falls sensibel

### 10.4 Audit

Gateway-Audit:

- Wer hat was über das zentrale Dashboard ausgelöst?

Domain-Audit:

- Was hat das jeweilige System tatsächlich getan?

Beide Ebenen bleiben getrennt, werden aber verlinkt.

---

## 11. Betrieb und Deployment

### 11.1 MVP Betrieb

Empfohlen:

- lokal auf JARVIS/Hermes Host
- Zugriff über Tailscale
- Frontend auf internem Port
- Gateway auf internem Port
- Domain-Backends bleiben lokal oder über interne Ports erreichbar

### 11.2 Dev Start

Ziel:

```bash
scripts/dev.sh
```

Startet:

- API Gateway
- Frontend Dev Server
- optional Mock Adapter

### 11.3 Healthchecks

```text
GET /api/healthz
GET /api/modules
GET /api/overview
```

Jedes Modul erhält:

- last_successful_check
- last_error
- degraded_reason
- version/contract_version

---

## 12. Teststrategie

### 12.1 Unit Tests

- Adapter Mapping
- Redaction
- Contract Validation
- Permission Logic

### 12.2 Contract Tests

- Health Adapter erfüllt Health Contract.
- AutoShorts Adapter erfüllt AutoShorts Contract.
- Finance Adapter erfüllt Finance Contract.
- Fehlerzustände werden korrekt dargestellt.

### 12.3 E2E Smoke Tests

- Dashboard lädt.
- Overview API erreichbar.
- Modulstatus sichtbar.
- Legacy Links vorhanden.
- Kein Token/Secret im DOM.

### 12.4 Security Tests

- Secret scan.
- `.env` nicht committet.
- Redaction Tests.
- Sensitive Endpoints brauchen Auth.

---

## 13. Offene Fragen zur Freigabe

Vor Umsetzung sollten diese Punkte beantwortet werden:

1. Soll der MVP zunächst **nur lokal/Tailscale** erreichbar sein? Empfehlung: ja.
2. Soll das neue Dashboard **Vue/Vite/FastAPI** verwenden? Empfehlung: ja.
3. Sollen bestehende Dashboards im MVP nur verlinkt oder teilweise embedded werden? Empfehlung: erst verlinken, kein iframe als finale Lösung.
4. Welche Domain soll als erste native Integration priorisiert werden? Empfehlung: AutoShorts.
5. Soll Health im Overview nur aggregierte Daten zeigen? Empfehlung: ja.
6. Soll Finance im Overview echte Beträge zeigen oder nur redacted/aggregierte Statuswerte? Empfehlung: zunächst redacted/aggregiert.
7. Soll `Gamexgit/HealthManager` als aktueller Code-Stand gelten oder zuerst gegen lokale Health-Skripte verglichen werden? Empfehlung: zuerst vergleichen.
8. Wie sollen GitHub Issues/Milestones im neuen Repo organisiert werden? Empfehlung: Labels nach Modul, Risiko und Phase.
9. Soll das Dashboard später auch Telegram Topic Routing/Memory Cards anzeigen? Empfehlung: ja, aber erst ab Phase 5+.
10. Soll es einen Demo-/Screenshot-Modus geben? Empfehlung: ja, besonders wegen Health/Finance.

---

## 14. Konkrete erste Umsetzung nach Freigabe

Nach Freigabe würde ich folgende Reihenfolge ausführen:

1. `Gamexgit/Jarvis` lokal klonen.
2. Repo bootstrap:
   - README
   - docs
   - ADRs
   - apps/dashboard
   - apps/api-gateway
   - packages/contracts
3. Erste ADRs schreiben:
   - separate Domain Backends
   - read-only first
   - preview-confirm-audit
   - no shared sensitive database
4. MVP Contracts definieren.
5. FastAPI Gateway mit Healthcheck bauen.
6. Vue/Vite Dashboard Shell bauen.
7. Mock-Module anzeigen.
8. Read-only Adapter für AutoShorts/Health/Finance vorbereiten.
9. Tests und Smoke Script hinzufügen.
10. Ergebnis als Pull Request oder initialer Push bereitstellen.

---

## 15. Freigabevorschlag

Ich empfehle folgende Freigabeentscheidung:

> Freigabe für Phase 0 und Phase 1: Aufbau des `Gamexgit/Jarvis` Repositories als JARVIS Command Dashboard mit Vue/Vite Frontend, FastAPI Gateway, dokumentierten Modulverträgen, read-only-first Architektur, getrennten Domain-Backends und Preview→Confirm→Audit als verbindlichem Aktionsmuster.

Noch nicht freigegeben wären damit:

- Finance-Schreibaktionen
- Health-Rohdatenanzeige
- Public Deployment
- automatische Publishing-Aktionen
- Auto-Trades oder Auto-Buchungen
- medizinische Entscheidungsautomation

---

## 16. Schlussfolgerung

Das neue JARVIS Dashboard sollte kein großer, riskanter Ersatzbau werden, sondern ein sauberer **Command Layer** über den bestehenden Systemen. Damit wird der zentrale Wunsch erfüllt: ein Iron-Man-artiges, übersichtliches, mächtiges Dashboard — ohne die Sicherheits- und Wartbarkeitsvorteile der getrennten Systeme zu verlieren.

Die getrennten Repositories sind kein Hindernis, sondern ein Vorteil. Mit klaren Contracts, ADRs, Issues, Roadmap und einem stabilen Gateway kann jedes Subsystem weiterentwickelt werden, während das Gesamtkonzept geschützt bleibt.

Kurz gesagt:

> **JARVIS wird das Cockpit. Die bestehenden Systeme bleiben die Triebwerke. Und wir bauen eine saubere Avionik dazwischen — nicht einfach Klebeband und Hoffnung.**