# FinanceManager 2.0 – Sprint-0 Baseline

**Status:** verbindliche Arbeitsbaseline, fortgeschrieben für Sprint 20
**Scope:** Sicherheits-, Entscheidungs- und Arbeitsbaseline; Sprint 20 trennt aktuellen Vermögenswert, Aktualität, Kontenabgleich, Performancebereitschaft und Portfolioorientierung, ohne zweite Performanceengine oder neue Persistenz.

## Arbeitsgate 2026-08-02 – Sprint 20

- Verbindliche Produktionsbasis: Sprint-19-Merge-/Deployment-SHA `d94a57e8f339dddad844b9cc4c5690f394495948`, Schema 49, aktive Services im read-only Modus.
- Vollständig gelesene Produktquelle: Drive-Übergabe `00_KANONISCH_FinanceManager_Kontext_nach_Sprint18.md`; die Sprint-20-Anweisung und der aktuelle Merge-SHA ersetzen deren technische Sprint-18-Baseline.
- Vor Implementierung wurde die produktive Datenbasis strikt read-only je AKB, Raiffeisen, PostFinance Cash, PostFinance Aktien/ETFs, True Wealth und Krypto auditiert. Ein vollständiger logischer Datenbank-Sentinel war vor und nach dem Audit identisch; die private Betragsmatrix bleibt ausserhalb von Git.
- Sprint 20 erweitert den bestehenden Wealth-Cockpit-/Performance-Coverage-Vertrag um getrennte Readiness-Kennzahlen und quellenspezifische Diagnose. Die bestehende TTWROR-Engine bleibt alleinige Performanceengine.
- Freshness folgt einer kanonischen Quellentyp-Policy: SIX-Handelssitzungen inklusive wiederkehrender Börsenfeiertage, Krypto 24/7, bestätigte Bankwerte im erwarteten Import-/Bestätigungsrhythmus und verwaltete Gesamtportfolios im manuellen/importierten Aktualisierungsrhythmus.
- Reale Cash-Konten werden pro Konto statt pauschal pro Provider dargestellt. Nicht-Cash-Oberkonten und Provider-Container ohne eigenen kanonischen Wert bleiben aus der primären Quellenliste ausgeschlossen; echte Konten mit fehlendem Saldo bleiben sichtbar.
- Fehlende Portfolioorientierung ist `not_applicable` und blockiert weder den aktuellen Wert noch Performance. Veraltete Werte bleiben mit Stichtag sichtbar; Freshness und Kontenabgleich bleiben unabhängig.
- Es gibt keine Migration und keine produktive Dateneingabe, keinen Import, Backfill, Marktupdate oder Policy-Confirm. Schema 49 bleibt unverändert.

## Arbeitsgate 2026-08-02 – Sprint 19

- Gelesener und gegen `origin/main` bestätigter Produktions-SHA: `9d25227a0a0c7b7ef8be4d6c070d4cba215eea53`; produktives Schema 49.
- Aktuelle Quellen: die Drive-Übergabe `00_KANONISCH_FinanceManager_Kontext_nach_Sprint18.md`, diese fortgeschriebene Baseline, `README.md`, `AGENTS.md`, die ADRs zur Runtime-/FastAPI-Vue-Grenze sowie `docs/operations/finance-manager-deployment-runbook.md`.
- Bewusst nicht als aktuelle Vorgabe verwendet: Status/Roadmap v0.3 vom Mai, Anforderungsdokument v0.1, Spezifikation v0.2, Überarbeitungskonzepte v1.0/v2.0/v2.1 und Zielkonzept v2.2 hinsichtlich Budgetassistent und obligatorischer Fixkosten-/Abo-Pflege.
- Wiederverwendung: kanonische `budget_categories`, `budget_category_baselines`, `budget_transactions`, `household_financials`, Budget-Forecast-/Coverage-Bausteine, `audit_log`, bestehender Budget-Router und Datenexplorer sowie die vorhandene Vue-Haushaltsseite.
- Speicherung: `budget_category_baselines` bildet Jahr, stabile Kategorie-ID, CHF-Betrag, Quelle, Änderungszeit, FK und Eindeutigkeit bereits semantisch passend ab. Ein vorhandener Datensatz mit `0.00` ist ein bestätigtes Nulljahr; kein Datensatz bedeutet nicht erfasst. Daher ist keine additive Migration erforderlich und Schema 49 bleibt bestehen.

### Implementierter Abschlussstand Sprint 19

- Jahreswerte werden gesammelt als fingerprint-gebundenes Preview/Confirm gespeichert und mit genau einem Audit-Ereignis pro Jahresaktion protokolliert.
- Die deterministische Prognose verwendet nur bestätigte kanonische Ausgabeneffekte: Ist bis Datenstand plus Monatsdurchschnitt aus mindestens drei zusammenhängenden, abgeschlossenen und konfliktfreien Monaten multipliziert mit den verbleibenden vollen Monaten und dem Restanteil des aktuellen Monats.
- Transfers, Kreditkarten-Ausgleiche und Recurring-/Abo-Kandidaten werden nicht zugeschlagen; bestehende Plan- und Recurring-Daten bleiben ausschließlich für rückwärtskompatible Diagnosefelder erhalten.
- Die Primärseite bietet Standardvergleich 2025, frei wählbare vergangene Jahre, read-only Monatsdurchschnitt, responsive Tabelle/Karten, Gesamtsummen und Fehlstellenzahl und endet nach der Monatsübersicht.
- Der Kategorie-Drill-down öffnet den bestehenden Daten-Explorer mit laufendem Jahr, bestätigten Ausgaben und der vollständigen Erklärung „So entsteht die Prognose“.
- Fixkosten & Abos sind aus der primären Haushaltsnavigation entfernt; bestehende technische Endpunkte bleiben erhalten, beeinflussen aber die Prognose nicht.

## Fortschreibung 2026-08-01 – Sprint 17E

- Verbindliche Produktionsbasis: `ef31adbcfb8ed7a9dd7be845113934f02f192506`, Schema 49, P0/P1/P2 = 0/0/0. Sprint 17E benötigt keine Migration und baut keine zweite Budget- oder Forecast-Engine.
- FinanceManager beantwortet für Marcel und Melanie verständlich: Ausgabentreiber, Abweichungen zur Jahresorientierung und zum Vorjahr, erwartete Jahreseinnahmen/-ausgaben, voraussichtlicher Jahresrest und frei planbarer Betrag.
- Das Budget ist eine flexible Jahresorientierung. Es gibt keinen buchhalterischen Monatsabschluss, keine Monatsfreigabe, keinen Perioden-Lock und keinen obligatorischen Vertrags-/Abo-Pflegeprozess.
- Deterministische Prognose: Ist bis Datenstand plus erwarteter Restzeitraum; saisonales Vorjahresmuster nur bei vollständiger Vorjahresabdeckung, sonst aktive Jahresorientierung, danach Durchschnitt erst ab mindestens drei Monaten, andernfalls verständlicher Unsicherheitszustand.
- Transfers bleiben neutral; Kreditkartenabrechnungen werden nicht zusätzlich zu den Käufen gezählt; Rückerstattungen behalten die kanonische Semantik. Quartals-, Halbjahres- und Jahreswerte werden korrekt annualisiert, einmalige Ausgaben nicht wiederholt.
- Kategorien sind die primäre Analyse- und Optimierungseinheit. Die Oberfläche zeigt maximal fünf Jahreskennzahlen und drei materielle Optimierungshinweise; Plan, Ist, Prognose und frei planbar bleiben getrennt bezeichnet.
- Geplante Sonderausgaben werden in einer einfachen Was-wäre-wenn-Rechnung genau einmal vom prognostizierten Jahresrest abgezogen. Ohne explizite Übernahme entsteht weder eine Buchung noch eine Finanzentscheidung.
- Jahresplanung hat höchstens drei Schritte: Einnahmen prüfen; Kategorien und besondere Anschaffungen prüfen; Jahresrest kontrollieren und übernehmen. Eine Übernahme erzeugt weiterhin eine neue unveränderliche Budgetversion.
- Die read-only XLS-Referenz bleibt außerhalb von Git und produktiver Datenbank. Korrekte Kontrollwerte: Ausgaben CHF 114’569.39, Einnahmen CHF 148’775.40, Überschuss CHF 34’206.01, Monatsdurchschnitt CHF 2’850.50; CHF 1’984.67 ist nicht der Jahresdurchschnitt. Hypothek: CHF 1’298.75 quartalsweise = CHF 5’195.00 jährlich = CHF 432.92 monatlich normalisiert.
- Fixkosten-/Abo-Erkennung darf intern Schätzungen unterstützen, blockiert den Jahresrest aber nicht wegen kleiner Kandidatenlücken und bleibt ausserhalb des primären Haushaltsworkflows.
- Produktive Mutationen bleiben Preview → Confirm → Audit; Sprint 17E führt beim Deployment und read-only Smoke keine Budget-, XLS-, Recurring-, Sonderausgaben-, Dubletten- oder VISECA-Entscheidung aus.
- Laufender Status und dynamische Releasebelege werden weiterhin ausschließlich in [`../status/jarvis-finance-status-roadmap-v0.3.md`](../status/jarvis-finance-status-roadmap-v0.3.md) beziehungsweise im PR-/Release-Audit geführt. Es entsteht keine zweite Baseline oder Roadmap.

## Fortschreibung 2026-08-01 – Sprint 17D

- Verbindliches Produktkonzept: [`FinanceManager_Umsetzungs_und_Zielkonzept_v2.2_2026-08-01.docx`](./FinanceManager_Umsetzungs_und_Zielkonzept_v2.2_2026-08-01.docx).
- Ausgangsstand und Produktion vor Sprint 17D: `eeb1806e76783277c41dd5a8dbe7b73ccf844f12`; Schema 48; 878 Backend- und 214 Frontendtests.
- Sprint-17D-Kandidat: genau eine additive Migration auf Schema 49; keine destruktive Datenumschreibung.
- Arbeitsbranch: `sprint17d/annual-budget-recurring-semantics`; ein vertikaler Sprint, ein PR; Sprint 17E ist Nicht-Scope.
- Bestehende Budget-, Forecast-, Recurring-, Kategorie- und Chart.js-Komponenten werden erweitert. Es entstehen keine zweite Ledger-, Forecast-, Import- oder Budgetengine und keine zweite permanente Navigation.
- Eine einzelne Transaktion beweist keine Periodizität. Kandidaten bleiben vor Confirm editierbar; die bestätigte Nutzerwahl überschreibt die Heuristik und ist über Preview-Fingerprint, Datenversion und Audit nachvollziehbar.
- Plan, Ist und Forecast sind fachlich und visuell getrennt. Frei beziehungsweise investierbar wird nur bei ausreichender Coverage ausgewiesen.
- Excel ist ausschließlich eine read-only Eingabequelle bis zu einem separaten Confirm; Sprint 17D führt keinen produktiven Excel-Confirm aus.
- Offene Apple-/Netflix-Dubletten und die unvollständige VISECA-Abrechnung bleiben sichtbare Coverage-Lücken und werden weder bestätigt noch als präzise Forecastbasis behandelt.
- Produktive Finanzentscheidungen verbleiben bei Marcel. JARVIS führt keine Kandidaten-, Dubletten-, VISECA-, XLS- oder Budget-Confirms aus.
- Laufender Status und Roadmap werden ausschließlich in [`../status/jarvis-finance-status-roadmap-v0.3.md`](../status/jarvis-finance-status-roadmap-v0.3.md) fortgeschrieben.
- Betrieb und Deployment sind in [`../operations/finance-manager-deployment-runbook.md`](../operations/finance-manager-deployment-runbook.md) dokumentiert.

### Sprint-17D-Abschlussnachweis

- Vorgesehener Integrations-PR: **#30**; der exakte Abschluss-, Merge- und Deployment-SHA sowie der finale GitHub-CI-Lauf werden im unveränderlichen PR-/Release-Audit festgehalten. Ein Git-Commit kann seinen eigenen SHA nicht als Dateiinhalt enthalten.
- Fokussierter Final-HEAD-Review: P1-Datenwahrheit für VISECA sowie P2-Grenzen für konservative Einzelbeobachtungen, Kategorie-Typ, bestätigte Periodizität und DB-Immutability korrigiert; danach P0 0 · P1 0 · P2 0.
- Lokale Abschlussgates: 26 relevante Backendregressionen grün; nach Reviewänderungen 16 betroffene Regressionen grün; Git-Safety 19 grün; vollständige relevante Frontendgruppe 25 grün; abschließende UI-Korrekturgruppe 15 grün; Typecheck, Produktionsbuild, Compileall, Ruff für geänderte Python-Surfaces, `git diff --check` und Repository-Safety grün.
- Migration: Schema 48 → 49 und frische DB → 49 erfolgreich; `PRAGMA integrity_check = ok`; persistente Fachtabellenzahlen unverändert. Der historische technische Schatten `budget_transfers__phase18_fixed` wird durch den bestehenden Kompatibilitätspfad entfernt und ist keine Fachtabelle.
- Lokaler Browser-UAT: 1440/820/390 px, 12 Seiten-/Breitenkombinationen, kein horizontaler Overflow, keine zu kleinen effektiven Touchziele, keine Console-Fehler; editierbarer Vignettenkandidat ergab im reinen Preview für CHF 12.00 vierteljährlich CHF 48.00 Jahreswirkung und CHF 4.00 Monatsrückstellung; kein Confirm.
- Kontrollrechnung: Hypothek CHF 1’298.75 vierteljährlich → CHF 5’195.00 jährlich → CHF 432.92 Monatsrückstellung. XLS read-only: Ausgaben CHF 114’569.39; Einnahmen CHF 148’775.40; Überschuss CHF 34’206.01; Monatsdurchschnitt CHF 2’850.50; kein XLS-Confirm.
- Produktive Coverage bleibt offen: Apple CHF 60.00 statt CHF 20.00; Netflix CHF 91.60 statt CHF 22.90; VISECA-Zahlung CHF 3’238.20, gefundene Käufe CHF 4’348.40, Restdifferenz CHF 1’110.20, zusätzliche Ausgabenwirkung CHF 0.00.
- Das Konzept-DOCX bleibt inhaltlich und bytegenau die vom Auftraggeber bereitgestellte Version v2.2; volatile Releasebelege werden nicht in das verbindliche Konzept eingebettet.

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