# FinanceManager 2.0 – Sprint-0 Baseline

**Status:** verbindliche Arbeitsbaseline
**Scope:** Sicherheits-, Entscheidungs- und Arbeitsbaseline; keine Portfolio-Performance-, Budget- oder Research-Implementierung

## 1. Autoritative Grundlagen

1. Repository `Gamexgit/FinanceManager`, Branch `main` als Integrationsbasis.
2. Überarbeitungskonzept `FinanceManager_Ueberarbeitungskonzept_v1.0_2026-07-22`.
3. Entwicklungsdokumente im Drive-Ordner `Finanzen`.
4. Bestehende ADRs, insbesondere Runtime außerhalb Git, inkrementelle FastAPI/Vue-Architektur sowie Preview → Confirm → Audit.
5. Die im Sprint-0-Auftrag vom 22.07.2026 festgelegten Produkt- und Arbeitsentscheidungen.

**Preflight-Hinweis:** Das benannte Überarbeitungskonzept war beim Sprint-0-Preflight weder im freigegebenen Drive-Konto noch lokal auffindbar. Bis es verfügbar ist, gelten die im Auftrag vollständig aufgeführten Entscheidungen als operative Baseline. Ein später gefundener Widerspruch ist vor einer fachlichen Implementierung als Entscheidungsänderung zu behandeln.

## 2. Produktentscheidungen

- Gemeinsamer Haushalt, zunächst ein Benutzer; Domänenobjekte dürfen spätere Rollen-/Haushaltstrennung nicht verhindern.
- Primärer Zugriff über Tailscale; Laptop-first, responsive für iPad.
- Beträge sind standardmäßig sichtbar. Ein globaler Privacy-Modus muss später alle sensiblen Beträge sofort verdecken.
- Budgetmodell: Fixkosten, Kategorienlimits, Rückstellungen, Sparziele und frei verfügbarer Betrag.
- Nach bestätigtem Import werden sichere Klassifikationen automatisch wiederverwendet; nur Ausnahmen gehen in die Review-Inbox.
- Pflichtquellen: Raiffeisen und AKB inklusive Kreditkarten, PostFinance, TrueWealth als verwaltete Gesamtposition sowie bestehende Crypto-Wallets.
- Erster sichtbarer Nutzen nach Sprint 0: Portfolio-Performance.
- TrueWealth bleibt ein verwalteter Gesamtbaustein. Anlagevorschläge adressieren primär PostFinance und Krypto.
- Spätere Handlungssprache: `ADD`, `TRIM`, `HOLD`, `WAIT`, jeweils mit Größenband, Why-now, These, Risiken, Invalidierung, Datenqualität und Quellen.
- Proaktive Anlageideen sind erlaubt; automatische Orderausführung bleibt ausgeschlossen.
- Steuer- und Reportingfunktionen sind nachrangig.
- CoinGecko wird zuerst offiziell und read-only integriert. Ein TradingView-Community-MCP benötigt vor Nutzung eine dokumentierte Security-, Lizenz- und Herkunftsprüfung.

## 3. Sicherheitsentscheidungen

- Produktive Runtime-Daten, Rohimporte, Datenbanken, Reports und Credentials bleiben außerhalb Git.
- Keine echten CSV/XLSX/PDF-, SQLite-, Report- oder Credential-Dateien im Repository.
- In Drive gefundene Tokens werden nicht gelesen oder verwendet. Rotation ist eine manuelle P0-Voraussetzung.
- Alle Order-/Execution-Felder sind fail-closed; `execution_allowed` bleibt immer `false` im FinanceManager-Dashboard.
- Bestehendes Preview → Confirm → Audit bleibt für produktive Mutationen verpflichtend.
- Die HTTP-Schicht startet mit deaktivierten Writes. Optionales `local_only` erlaubt Schreibzugriffe ausschließlich von einer Loopback-Quelladresse. Tailscale-Write-Zugriff bleibt bis zu einer separaten Auth-/Session-Entscheidung gesperrt.
- API-Diagnosen geben keine lokalen Runtime-Pfade, Credentials, Tokens, Prozess-IDs oder Logpfade aus.
- Klartext-Secret- und Repository-Safety-Scan ist Bestandteil jedes Merge-Gates.

## 4. Offene Annahmen und Blocker

1. **Authentifizierung:** Für Tailscale-Clients existiert noch keine freigegebene Benutzer-/Browser-Session-Architektur. Vor Tailscale-Writes ist eine Entscheidung zu Session-Cookie, CSRF/Origin, Bootstrap, Ablauf, Audit-Identität und Recovery nötig. Bis dahin bleibt remote read-only.
2. **Token-Rotation:** Vor Provider-Erweiterungen ist manuelle Rotation eventuell in Drive vorhandener Klartext-Tokens erforderlich.
3. **Überarbeitungskonzept:** Das benannte v1.0-Dokument muss auffindbar gemacht und gegen diese Baseline geprüft werden.
4. **Privacy-Modus:** Exakter Scope (Beträge, Charts, Tooltips, Druck, Browser-Storage) wird im Portfolio-Foundation-PR vertraglich festgelegt.
5. **Haushaltsidentität:** Ein einzelner Default-Haushalt ist zulässig; neue Kerntabellen müssen einen späteren stabilen Haushalt-/Owner-Bezug ermöglichen, ohne heute Rollen-UI zu bauen.
6. **Lint-Baseline:** Das Repository hat umfangreiche historische Ruff-Schulden. Sprint 0 führt keinen Whole-Repo-Format-/Lint-Rewrite durch; neue/geänderte Python-Dateien müssen lint-frei bleiben.
7. **Testbaseline-Audit:** Auf dem unveränderten Basis-SHA waren zehn Altfehler reproduzierbar. Zwei davon – der veraltete synthetische Portfolio-Preiszeitpunkt und ein von internen FastAPI-Strukturen abhängiger Portfolio-Routentest – waren im ursprünglichen Sprint-0-Arbeitsstand bereits nebenbei korrigiert. Deshalb wies der dort ausgeführte vollständige Lauf nur acht verbleibende Fehler aus. Der spätere direkte Basis-SHA-Lauf reproduzierte alle zehn; sämtliche zehn Korrekturen wurden in den separaten Baseline-Commit verschoben. Sprint 0 basiert auf dieser grünen Testbaseline.

## 5. Vertikale PR-Roadmap

### PR 0 – Security & Decision Baseline

- Arbeitsbaseline, PR-Template und Agentenregeln.
- Advisor-Naming auf Allokations-/Datenchecks (Beta).
- Execution-Sperre verifizieren.
- reproduzierbarer Secret-/Git-Safety-Scan.
- Diagnose-Redaktion.
- Writes fail-closed; Tailscale-Writes blockiert.

### PR 1 – Transfer Pairing v2

- signierte Importkandidaten und bekannte eigene Konten als Matcher-Basis;
- generischer Cross-Source-/Cross-Import-Matcher mit explizitem Datumsfenster;
- Pair-Lifecycle `proposed`, `confirmed`, `rejected`, `superseded`, `unmatched`;
- atomarer, idempotenter Confirm beider Kandidaten mit Budgeteffekt null;
- gemeinsame Review-Darstellung; keine automatische Bestätigung.

### PR 2 – Navigation & Design Shell

- Hauptnavigation auf Heute, Haushalt, Vermögen und Research konsolidieren;
- Feature Flags für unfertige Flächen;
- kleine wiederverwendbare Basiskomponenten und Partial-Error-Pattern;
- keine neuen Finanzberechnungen oder Importquellen.

### PR 3 – Hybrid Budget Foundation

- Fixkosten, Limits, Rückstellungen, Sparziele, frei verfügbarer Betrag.
- bestätigte Ist-Daten; keine Blindbuchung.

### PR 4 – Research Data Foundation

- CoinGecko offiziell/read-only, Caching, Rate-Limit, Datenqualität und Quellenprovenienz.
- kein Community-MCP ohne vorgelagerte Freigabeprüfung.

### PR 5 – Advisor/IPS Foundation

- erst nach Performance-/Quellenbasis: `ADD/TRIM/HOLD/WAIT`-Contract, Größenband und vollständige Begründungs-/Risiko-/Invalidierungsfelder.
- keine automatische Orderausführung.

## 6. Definition of Done

Ein PR ist nur fertig, wenn:

- Ziel, Scope und Nicht-Scope eindeutig sind;
- Migration und Rollback beschrieben sind, auch wenn jeweils „keine“;
- API-Contract und Kompatibilitätswirkung dokumentiert sind;
- produktive Runtime-Daten und Secrets nicht in Git gelangt sind;
- Python Compile und betroffene/full Tests tatsächlich ausgeführt wurden;
- Frontend-Test, Typecheck und Build tatsächlich ausgeführt wurden, sofern Frontend betroffen ist;
- Secret-/Git-Safety-Scan und `git diff --check` grün sind;
- UAT-Schritte mit synthetischen Daten beschrieben sind;
- Sol den vollständigen Diff final geprüft und alle Findings dispositioniert hat;
- kein Push, Merge, Deployment oder Secret-Rotation ohne ausdrückliche Freigabe erfolgt;
- Entscheidungserklärung/ADR aktualisiert ist, falls Architektur, Sicherheit, Datenvertrag oder Produktsemantik geändert wurde.

Reproduzierbares lokales Gate:

```bash
make PYTHON=.venv/bin/python verify
git diff --check
```

Der historische Whole-Repo-Ruff-Status ist separat zu berichten und darf nicht als grün bezeichnet werden.

## 7. Sol-/Spark-Routing

### Sol – verpflichtend

Sol besitzt Architektur, Security, Auth, Datenmodell, Migrationen, Performanceformeln, Advisor-/IPS-Logik, Finanzsemantik, finale Diffprüfung sowie jede externe Side Effect-Entscheidung.

### Spark – nur sequenziell und klein

Spark darf nur ein einzelnes Ergebnis bearbeiten, höchstens ungefähr drei Dateien verändern und weder Secrets noch produktive Finanzdaten, Authentifizierung, Migrationen oder Finanzberechnungen berühren. Das Ticket muss erlaubte Dateien, Nicht-Scope, Akzeptanzkriterien und den exakten Test enthalten. Spark darf nicht committen, pushen, deployen oder Folgeaufträge starten. Sol prüft jeden Diff und führt den Test selbst erneut aus.

Parallel schreibende Agenten sind verboten. Bei nicht erfüllten Kriterien übernimmt Sol direkt.

## 8. PR-Vertrag

Jeder PR verwendet die Repository-Vorlage und enthält mindestens:

- Ziel
- Scope
- Nicht-Scope
- Migration
- API-Contract
- Tests
- UAT
- Rollback
- aktualisierte Entscheidungserklärung
- Datenschutz-/Secret-Bestätigung