# Sprint 16 – versionsgebundene Inventur und Umsetzungsrahmen Stand: Basis `852aac4a8060d2dfec716fc630560a11d297abde`, produktives Schema 47. ## 1. Verifizierte Basis Vor der ersten Produktänderung wurden `refs/heads/main`, `origin/main`, Deployment-HEAD, Feature-HEAD und Merge-Base auf den Basis-Commit gebunden. Der neue Worktree und der Deployment-Worktree waren sauber. Branch: `Sprint16/smart-household-inbox-real-data-onboarding-v2`. ## 2. Bestehende URL- und UI-Flächen Kanonisch: - `/household` → `HouseholdOverviewPage.vue` - `/household/transactions` → `HouseholdTransactionsPage.vue` - `/household/review` → `HouseholdReviewPage.vue` - `/household/imports` → `HouseholdImportsPage.vue` Legacy-Aliasse in `frontend/src/router/index.ts` leiten insbesondere Budget-Übersicht, Transaktionen, Expense Review, Review Backlog, Import Review, Importe, Monthly Import und VISA Import auf die kanonischen Household-Routen weiter. `BudgetImportReviewPage.vue` bleibt als Altkomponente im Quellbaum, ist aber über die kanonischen Aliasrouten nicht mehr direkt produktiv geroutet. Sie enthält die zu entfernende technische Komplexität: sieben Kennzahlenkarten, zahlreiche Quellen-/Statusreiter, dauerhaft sichtbare Massen- und Zeilenaktionen sowie Typ-, Confidence-, Reason- und Statusspalten. Die produktive `/household/review`-Seite nutzt bereits `HouseholdTabs.vue`, gruppierte Reviewdaten sowie getrennte Preview-/Confirm-Aufrufe, ist aber noch gruppen- statt buchungsorientiert und zeigt alle Fachaktionen gleichzeitig. Minimale Wiederverwendung: - Household-Shell, Navigation und Aliasrouten bleiben erhalten. - Bestehende PrimeVue-Komponenten, Formatierer und API-Client werden weiterverwendet. - Die neue Inbox ersetzt weder Router noch Budget-Review-Store, sondern legt eine alltagssprachliche Sicht auf dieselben kanonischen Kandidaten und Confirm-Verträge. ## 3. Bestehende API- und Vertragsflächen Household-Endpunkte in `src/jarvis_finance/api/routers/budget.py`: - `GET /budget/household/overview` - `GET /budget/household/transactions` - `GET /budget/household/review` - `POST /budget/household/review/preview` - `POST /budget/household/review/confirm` - `GET /budget/household/imports/options` - `GET /budget/household/imports` - `POST /budget/household/imports/preview` - `POST /budget/household/imports/confirm` - Legacy-Aliasse für singular `import` und Batch-History - explizite, bestätigungspflichtige Source-Mapping-Endpunkte `household_import_v1` bindet Eingabe, stabile Kontozuordnung und DB-Baseline per HMAC-Fingerprint. Confirm rekonstruiert die Preview unter Schreiblock, lehnt Staleness ab und ist über den Preview-Fingerprint idempotent. `transfer_pairing_v3` bleibt die kanonische Transferpaarung. GET und Preview sind fachlich read-only; der Providerpfad bleibt auf dem expliziten Drive-Scan-Endpunkt. ## 4. Bestehende Engines und Tabellen Wiederzuverwenden: - `household_import.py`: Normalisierung, dreistufige Dubletten, Preview/Confirm, Audit, Migros-Verknüpfung und Review. - `budget_csv_imports.py`: struktur- statt dateinamenbasierte Profilerkennung für AKB, Raiffeisen, VISA und Migros. - `transfer_pairing.py`: kanonische, budgetneutrale Transferbestätigung. - `budget_transactions.py` und bestehende Kandidaten-/Batchfunktionen: kanonische Buchungsmaterialisierung. - `budget_merchants`, `budget_merchant_aliases`, `budget_review_rules`, `budget_rule_suggestions`, `budget_recurring_payments`, `budget_categories`, `budget_transaction_candidates`, `budget_transactions`. - Schema-47-Tabellen `household_account_source_mappings`, `household_import_batches`, `household_import_files`, `household_import_items`, `household_migros_links`. Bestätigte historische Kategorien sind über `budget_transactions.category_id`, optional verknüpft mit `source_candidate_id`, Kandidatenhändler/-beschreibung, Quelle und Konto lesbar. Händlerstammdaten und Aliasse liefern explizite Regeln; wiederkehrende Zahlungen liefern Rhythmusevidenz. Es wird keine zweite Ledger-, Haushalts-, Import-, Transfer- oder Regelengine angelegt. Persistente Erweiterungen sind nur zulässig, wenn die vorhandenen Audit- und Regeloberflächen den versionsgebundenen Lernnachweis nicht tragen. ## 5. Fachliche Lücken auf Basis 852aac4 - Es existiert noch kein versionierter `household_classification_v2`-Orchestrator mit der geforderten Prioritätsreihenfolge. - Gewöhnliche Importzeilen werden nicht deterministisch aus bestätigter Händlerhistorie kategorisiert. - Kategorieänderungen sind noch nicht Bestandteil des vollständigen Import-Preview-Fingerprints. - Die Household-Reviewantwort ist gruppenorientiert und liefert keine alltagssprachliche Zeilen-Inbox. - Kartenrückzahlungen ohne Gegenbuchung benötigen eine explizit neutrale, nicht als Einkommen materialisierbare Semantik. - Raiffeisen-Fortsetzungszeilen werden im generischen CSV-Leser noch als physische Dict-Zeilen gelesen; die logische Faltung muss vor Fingerprint und Klassifikation erfolgen. - AKB-Saldensnapshots im XLSX-Format besitzen noch keinen Household-Previewvertrag und dürfen nie zu Buchungen werden. - Migros-Belege werden unabhängig vom Betrag bei beidseitig eindeutiger Datum-/Betragsübereinstimmung mit genau einer bestehenden Bank-/Kartengeldbewegung verknüpft. Der Beleg bleibt Detail/Split, erzeugt nie eine zweite Ausgabe; Mehrdeutigkeit bleibt Review und ein fehlender Gegenpost bleibt ohne synthetische Geldbewegung. - Transaktionen werden nicht über datum-/betrags-/händlerspezifische Ausnahmen im Produktcode neutralisiert. Transferneutralität verlangt eine sichere Gegenbuchung oder einen getrennten auditierten Entscheidungsvertrag. ## 6. Zielvertrag und Zustandsmodell `household_classification_v2` wird als deterministische, read-only Klassifikationsschicht vor der vorhandenen Materialisierung implementiert. Eingaben umfassen normalisierten Händler/Gegenpartei, Quelle, kanonische Kontorolle, Vorzeichen, optionale MCC-/Land-/Währungsmerkmale, Betragsband, maskierte Gegenparteiidentität, Rhythmus, bestätigte Kategoriehistorie und Konflikte. Priorität: 1. eigener Transfer; 2. Kartenrückzahlung, Refund oder Storno; 3. explizite Nutzer-Ausnahme; 4. explizite exakte Händlerregel; 5. konfliktfreie bestätigte Händlerhistorie auf gleicher Quelle/Kontorolle; 6. quellenspezifische Text-/MCC-/Gegenparteiregel; 7. stabiler Rhythmus; 8. Ähnlichkeit; 9. ungeklärter Ausnahmefall. Nutzerzustände sind ausschliesslich `Vorschlag bereit`, `Entscheidung nötig` und `Sonderfall erkannt`. Interne Confidence-/Reasondaten bleiben für Audit/Diagnose erhalten. Eine gelernte Vorschlagsregel entsteht erst aus mindestens zwei konsistenten Bestätigungen für denselben normalisierten Händler und dieselbe Kontorolle ohne Konflikt. Sie wirkt nur auf künftige Vorschläge; eine einzelne Korrektur und Ähnlichkeitsfunde erzeugen keine globale Regel. Historische Buchungen werden nie rückwirkend verändert. ## 7. Preview-, Confirm- und Auditgrenzen - Preview bleibt vollständig read-only und liefert nur maskierte, alltagssprachliche Daten. - Kategorie-Overrides werden in die finale kanonische Preview und deren Fingerprint aufgenommen. - Batch-Confirm materialisiert exakt diese Preview; Staleness führt zu 409, Wiederholung zu No-op. - Sichere Transfers und Kartenpaarungen werden atomar im selben Batch bestätigt; Ausnahmen bleiben offen. - Relevante Klassifikations-, Evidenz-, Override-, Zähl- und Schreibwirkungsdaten werden im bestehenden Auditpfad gebunden, nicht in der Standardansicht angezeigt. - Kein produktiver Confirm realer Dateien erfolgt ohne das abschliessende Nutzer-Stop-Gate. ## 8. Realdaten- und Datenschutzgrenze Reale Dateien bleiben ausserhalb von Git und Tests. Die Analyse erzeugt ausschliesslich aggregierte, private Runtime-Evidenz. Tests verwenden synthetische Strukturäquivalente. Keine Rohzeile, vollständige Kontoreferenz, Kartenkennung oder Quelldatei wird in UI, Logs, Git oder Browserantworten ausgegeben. Die Referenzwerte für AKB, Raiffeisen, VISA und Migros sind Release-Akzeptanzwerte, keine hartkodierten produktiven Korrekturen. Abweichungen werden erklärt; sie werden nicht still angepasst. ### 8.1 Read-only Quelleninventur vom 28.07.2026 Die aktuellen AKB-, Raiffeisen-, VISA- und Migros-Quellen wurden in einem privaten Verzeichnisbaum mit Modus `0700`/`0600` ausserhalb des Repositories analysiert. Rohzeilen, Dateinamen, Kontosuffixe, Providerreferenzen, Transaktionsdaten und Salden bleiben im owner-only Autorisierungsmanifest und im privaten Abschlussbericht; Git enthält davon weder Kopien noch Klarwerte. Versionierter Releasevertrag: - AKB-Saldensnapshot und AKB-Transaktionen werden getrennt und read-only analysiert; ein Saldenabgleich darf nur gegen denselben Stichtag erfolgen. - Raiffeisen rekonstruiert 127 physische CSV-Zeilen inklusive Header deterministisch zu den ausdrücklich freigegebenen **69 logischen Buchungen (Referenz A 68, Referenz B 1)**. Unquotierte Beschreibungsdelimiter und Fortsetzungszeilen werden strukturell verarbeitet; Textähnlichkeit darf keine Buchung unterdrücken. - VISA verwendet eine stabile Providerreferenz plus eine explizite Fallback-Rolle für Zeilen ohne Referenz; beide Rollen zeigen auf dieselbe CHF-Kartenverbindlichkeit. Käufe sind Ausgaben, Rückzahlungen werden nur mit beidseitig eindeutiger Gegenbuchung zu Transfers. - Migros-Belege reichern höchstens eine bestehende Geldbewegung an, erzeugen keine zweite Ausgabe und ziehen Kleinbelege nicht unnötig in den Reviewpfad. Aufgelöster Stop-Gate und verbindliches Onboarding: - Referenz A wird dem bestehenden kompatiblen CHF-Cash-Konto zugeordnet; Referenz B wird als separates verwaltetes CHF-Cash-Asset mit `portfolio_bucket=cash` und `performance_included=0` angelegt. Die Referenzen werden weder zusammengeführt noch gegeneinander saldiert. - Unterschiedliche Stichtagssalden bleiben getrennt; es wird weder eine künstliche Ausgleichs- noch eine Saldenkorrekturbuchung erzeugt. - Die einzelne Buchung von Referenz B ist Einkommen, kein Transfer und keine Saldenkorrektur. Sie verwendet die bereits vorhandene passende Einkommenskategorie. - VISA wird als CHF-Kartenverbindlichkeit mit `portfolio_bucket=liability` und `performance_included=0` angelegt: kein Cash-Asset und kein Portfoliovermögenswert. - Konto- und Source-Onboarding sind autorisiert; der Realimport-Confirm bleibt ausgeschlossen. **Source-Truth-Korrektur, freigegeben am 28.07.2026 um 18:52 Uhr Schweiz:** Die vorläufige Vorgabe 68 wurde transparent auf **69 (68+1)** korrigiert. Das private, owner-only Audit belegt zwei eigenständige Buchungsblöcke derselben Referenz A: keine Fortsetzungszeilen, zwei rechnerisch korrekte Saldenübergänge, unterbrochene Saldenkette bei Entfernung eines Eintrags, keine identische Provider-ID und kein Vorgemerkt-/Definitiv-Paar. Der Raiffeisen-Stop-Gate ist aufgehoben. Die zugehörigen Klarwerte werden nicht in Git versioniert. ## 9. Migration und Schutzflächen Die produktive Schema-47-Kopie wurde vor Implementierung mit `integrity_check=ok` und unveränderten 62 Budget-, Household-, Portfolio-, Performance-, Cash-, PostFinance-, TrueWealth-, Krypto- und Auditflächen gesichert. Die Kopie enthält drei bereits vor Sprint 16 vorhandene Foreign-Key-Findings in `broker_import_execution_plans`; das getestete Onboarding erzeugt einen Delta von null und verschlechtert diesen Bestand nicht. Sprint 16 persistiert keine neue Relation und keine neue Spalte: Klassifikationsversion, Kategorieentscheidung, Multi-Source-Zuordnung, Baseline und Audit verwenden die vorhandenen Schema-47-Felder und Tabellen. Daher bleibt das produktive Schema verbindlich auf **47**; eine inhaltslose Schema-48-Migration wird ausdrücklich nicht erfunden. Konto- und Source-Onboarding sind auditierte Fachdatenänderungen, keine DDL-Migration. Das versionierte, defaultmässig read-only Artefakt `scripts/sprint16_household_onboarding.py` bindet Quellverträge, Kontorollen, exakte Autorisierung, Audit, Integrität und FK-Delta. ## 10. Dependency-Hardening Die direkt produktionsrelevante Build-Kette wurde ohne `npm audit fix --force` gehärtet: Vite 8.0.16, PostCSS 8.5.18 und alle direkten Frontendabhängigkeiten sind exakt statt mit `latest`/Ranges gepinnt; `engines.node` verlangt mindestens 22.13.0. CI nutzt Node 22, der geprüfte Deployment-Builder Node 24.17.0. `npm ci`, Frontendtests, Typecheck und Produktionsbuild sind grün. `npm audit --omit=dev` meldet **0 Findings**. Der vollständige Audit weist noch sechs rein entwicklungsseitige High-Findings im Testwerkzeugpfad `@vue/test-utils → js-beautify/editorconfig/glob/minimatch/brace-expansion` aus; npm bietet dafür nur ein nicht sachgerecht verifiziertes Downgrade von `@vue/test-utils` an. Dieser Dev-only-Pfad gelangt nicht in den Browser-Build und wird in einem separaten Hardening-Schritt untersucht. ## 11. Responsive und Release Verbindliche Viewports: 1440-Pixel-Laptop, ca. 820-Pixel-iPad und 390×844 Mobile. Keine horizontale Aktionsleiste oder Seitenoverflow. Nach allen fokussierten Gates folgen Vollsuiten, `make verify`, unabhängiger Exact-HEAD-Review, PR/CI/normaler Merge, exakter Merge-Deploy, read-only Produktions-UAT und die reale aggregierte Preview. Roadmap: - Sprint 17: Budget, Fixkosten, Abos und Monatsabschluss v1. - Sprint 18: Vermögens-Cockpit, Gesamtwertentwicklung und Performance-Abschluss. - Sprint 19: Research-Grundgerüst und Assetaktionen. - Sprint 20: Heute-Cockpit und geräteübergreifender Feinschliff.