todo

Falls Code geändert: Commit und Push


Repo- und Secret-Datei-Status ohne Secret-Ausgabe prüfen

Secret Loader/Provider-Code prüfen und Root Cause isolieren

OpenFIGI/FMP/Netzwerk gezielt aggregiert testen

Falls Codefehler: minimal fixen und Tests ergänzen

Compile, pytest, Git-Safety, diff-check, status ausführen

Falls Code geändert: Commit und Push


Sir, gezielter Provider-/Secret-Debug ist abgeschlossen. Kein neuer Feature-Block, nur Diagnose + minimaler Fix für Status-/Fehlerkategorien und Tests.

## Kurzbefund

Die Runtime-Secrets-Datei wird korrekt gefunden und gelesen.
Die Keys sind vorhanden und nicht leer.
Das Problem ist **nicht** der Secret Loader.

Der echte Smoke-Test scheitert, weil beide Provider die Authentifizierung ablehnen:

- **OpenFIGI:** HTTP `401` → `auth_failed`
- **FMP:** HTTP `403` → `auth_failed`

Mit anderen Worten: Die Keys liegen da, aber die Provider akzeptieren sie aktuell nicht. Charmant, wie APIs eben sind.

## 1. Secrets-Datei

Pfad:

`~/jarvis_runtime/finance-system/secrets/.env`

Ergebnis:

- Datei existiert: **ja**
- File Mode restriktiv / `600`: **ja** (`0o600`)
- Datei wird vom aktuellen Prozess gelesen: **ja**
- Runtime-Pfad korrekt: **ja**
- Keine `.env` im Repo: **ja**
- Keine Key-Assignments im getrackten Repo: **ja**

Variablenprüfung ohne Werte:

- `OPENFIGI_API_KEY`
  - vorhanden: **ja**
  - Länge > 0: **ja**
  - beginnt/endet nicht mit Leerzeichen: **ja**
  - offensichtliche Zeilenumbrüche im Wert: **nein**

- `FMP_API_KEY`
  - vorhanden: **ja**
  - Länge > 0: **ja**
  - beginnt/endet nicht mit Leerzeichen: **ja**
  - offensichtliche Zeilenumbrüche im Wert: **nein**

- `FINNHUB_API_KEY`
  - vorhanden: **nein**

- `EODHD_API_KEY`
  - vorhanden: **nein**

- `JARVIS_OPENFIGI_API_KEY`
  - vorhanden: **nein**

- `JARVIS_FMP_API_KEY`
  - vorhanden: **nein**

- `JARVIS_FINNHUB_API_KEY`
  - vorhanden: **nein**

- `JARVIS_EODHD_API_KEY`
  - vorhanden: **nein**

## 2. Secret Loader / Codeprüfung

Der Code lädt tatsächlich:

- OpenFIGI:
  - `OPENFIGI_API_KEY`
  - `JARVIS_OPENFIGI_API_KEY`

- FMP:
  - `FMP_API_KEY`
  - `FINANCIAL_MODELING_PREP_API_KEY`
  - `JARVIS_FMP_API_KEY`

- Finnhub:
  - `FINNHUB_API_KEY`
  - `JARVIS_FINNHUB_API_KEY`

- EODHD:
  - wird für Providerstatus geprüft über:
    - `EODHD_API_KEY`
    - `JARVIS_EODHD_API_KEY`
  - aber nicht als MVP-Suchprovider priorisiert

Loader-Verhalten:

- Lädt `~/jarvis_runtime/finance-system/secrets/.env`: **ja**
- Sucht nicht nur im Repo/Working Directory: **ja**
- Funktioniert bei Start aus `/home/agent/.hermes/repos/FinanceManager`: **ja**
- CLI und Dashboard nutzen denselben Loader-Pfad: **ja**
- Repo-`.env` wird nicht benötigt: **ja**

## 3. OpenFIGI Test

Test:

- Endpoint: `https://api.openfigi.com/v3/mapping`
- Auth-Methode: Header `X-OPENFIGI-APIKEY`
- Test-ISIN: `US9229087690`

Ergebnis:

- OpenFIGI Key geladen: **ja**
- OpenFIGI HTTP erreichbar: **ja**
- HTTP Status: `401`
- Auth-Methode korrekt: **ja**, Header verwendet
- Kandidaten gefunden: **nein**
- Fehlerkategorie: `auth_failed`

## 4. FMP Test

Tests:

- Name-Suche: `Vanguard Total Stock`
- Ticker-Suche: `VTI`
- Quote: `VTI`

Ergebnis:

- FMP Key geladen: **ja**
- FMP HTTP erreichbar: **ja**
- HTTP Status: `403`
- API-Key als Query/API-Parameter übergeben: **ja**
- Kandidaten gefunden: **nein**
- Preis/Quote möglich: **nein**
- Fehlerkategorie: `auth_failed`

## 5. Netzwerk / VM

- DNS funktioniert: **ja**
- HTTPS outbound funktioniert: **ja**
- `api.openfigi.com` erreichbar: **ja**
- `financialmodelingprep.com` erreichbar: **ja**
- Proxy/Firewall-Hinweis: **nein**

Damit ist Netzwerk/VM sehr wahrscheinlich nicht die Ursache.

## Ursache des vorherigen Fehlers

Zwei Dinge:

1. **Primäre Ursache:** Provider lehnen die Keys ab.
   - OpenFIGI: `401`
   - FMP: `403`

2. **Code-Diagnose war zu grob:**
   - Bisher wurden `401/403` als generischer HTTP-/Providerfehler bzw. negativer Smoke-Test zusammengefasst.
   - Dadurch sah es wie „nicht erreichbar / keine Kandidaten“ aus, obwohl tatsächlich **Auth fehlgeschlagen** war.

## Code geändert

Ja, minimal und diagnostisch:

- `401/403` werden nun als `auth_failed` klassifiziert.
- `429` bleibt `rate_limited`.
- Netzwerkfehler bleiben `network_error`.
- Providerstatus unterscheidet jetzt:
  - `key_missing`
  - `key_loaded`
  - `auth_failed`
  - `rate_limited`
  - `network_error`
  - `no_results`
  - `provider_error`
- Dashboard/Providerstatus zeigt ohne Live-Probe nicht fälschlich „aktiv“, sondern z.B. `Key geladen`.
- Explizite Probe kann `Auth fehlgeschlagen`, `Netzwerkfehler`, `Keine Treffer`, etc. differenzieren.
- Keine Keys werden zurückgegeben oder geloggt.

## Tests ergänzt

Ergänzt und grün:

- Runtime-Secrets-Datei wird geladen
- Repo-`.env` wird nicht benötigt
- Secrets werden nicht geloggt / nicht im Status ausgegeben
- OpenFIGI-Key wird als Header verwendet
- FMP-Key wird als API-Parameter verwendet
- Providerstatus unterscheidet `auth_failed`, `network_error`, `no_results`
- CLI/Dashboard-nahe Provider verwenden denselben Secret Loader
- Git-Safety bleibt sauber

## Verification

- Compile: **OK**
- pytest: **278 passed**
- Git-Safety: **GIT_SAFETY_OK**
- `git diff --check`: **OK**
- Git status nach Push: **clean**

## Git

- Code geändert: **ja**
- Commit: `a870bb32fbd064954f11f51f3f8f34b1b3f991c0`
- Message: `fix: diagnose provider auth status safely`
- Push-Status: **OK**, `main -> origin/main`

## Was Sie prüfen müssen

Bitte bei den Provider-Portalen prüfen:

- OpenFIGI:
  - Ist der Key aktiv?
  - Ist es wirklich ein OpenFIGI API-Key, nicht ein Account-/UI-Key?
  - Wurde er eventuell neu erzeugt und der alte gespeichert?
  - Hat der Account API-Zugriff freigeschaltet?

- FMP:
  - Ist der Key aktiv?
  - Ist der Free-Tier-Key für `/api/v3/search`, `/profile`, `/quote-short` freigeschaltet?
  - Ist eventuell ein anderer API-Key nötig oder der aktuelle deaktiviert/abgelaufen?
  - FMP antwortet mit `403`, also eher Berechtigung/Auth als Netzwerk.

Keine Keys wurden ausgegeben, geloggt oder ins Repo geschrieben.