# JARVIS Finance System – ezBookkeeping Reference Analysis & Budget UX Roadmap

Stand: 2026-05-17  
Referenzrepo: `https://github.com/mayswind/ezbookkeeping`  
Lokaler Pfad: `/home/agent/.hermes/reference_repos/ezbookkeeping`  
JARVIS-Projekt: `/home/agent/.hermes/repos/FinanceManager`

## 0. Scope und Compliance

Diese Analyse ist **kein Implementierungs-Sprint**.

Durchgeführt wurde:

- ezBookkeeping separat als Referenz geklont.
- Lizenz, Tech-Stack, Struktur, UI/UX, API, Datenmodelle, Import- und Analysekonzepte statisch analysiert.
- JARVIS FinanceManager anhand Repo-Struktur und Codeoberflächen verglichen.
- Designvorschläge und Roadmap abgeleitet.

Nicht durchgeführt wurde:

- keine Implementierung im JARVIS-Code
- keine Runtime-DB gelesen oder verändert
- keine echten JARVIS-Beträge/Daten verwendet
- kein Fremdcode übernommen
- keine Assets, Icons, Templates oder Screenshots aus ezBookkeeping übernommen
- keine Provider-/OCR-/AI-Aufrufe gestartet

## 1. Lizenznotiz

### ezBookkeeping Lizenz

- Lizenzdatei: `/home/agent/.hermes/reference_repos/ezbookkeeping/LICENSE`
- Lizenz: **MIT License**
- Copyright: `Copyright (c) 2020-2026 MaysWind`
- `package.json` bestätigt ebenfalls `"license": "MIT"`.

### Konsequenz für JARVIS

MIT erlaubt grundsätzlich Nutzung, Modifikation und Weiterverbreitung, sofern Copyright- und Lizenzhinweis erhalten bleiben. Für dieses Projekt gilt aber eine strengere interne Vorgabe:

- Wir übernehmen **nur Ideen, UX-Patterns und Architekturkonzepte**.
- Wir kopieren **keinen Code**.
- Wir kopieren **keine Assets/Icons/Templates/Screenshots**.
- Falls später ein konkreter Codeausschnitt aus ezBookkeeping direkt übernommen werden soll, muss vorher eine separate Lizenz-/Kompatibilitätsnotiz erstellt und der MIT-Hinweis in der betreffenden Datei/Dokumentation gepflegt werden.

## 2. ezBookkeeping technische Struktur

### 2.1 Frontend-Stack

- Vue 3
- TypeScript
- Vite
- Pinia
- Vue Router für Desktop
- Framework7 Router für Mobile
- Vuetify 3 für Desktop UI
- Framework7 Vue für Mobile UI
- Axios API Client
- ECharts / vue-echarts
- Moment / moment-timezone
- vue-i18n
- PWA via `vite-plugin-pwa`
- SCSS/Sass

Wichtige Dateien:

- `package.json`
- `vite.config.ts`
- `src/index-main.ts`
- `src/desktop-main.ts`
- `src/mobile-main.ts`
- `src/router/desktop.ts`
- `src/router/mobile.ts`

### 2.2 Backend-Stack

- Go 1.26 laut `go.mod`
- Gin Web Framework
- XORM ORM
- SQLite / MySQL / PostgreSQL Support
- urfave/cli CLI
- go-playground/validator
- JWT / OAuth2 / OIDC / 2FA
- Build per `build.sh`, `build.bat`, `build.ps1`
- Dockerfile und Docker Bake

Wichtige Pfade:

- `ezbookkeeping.go`
- `cmd/webserver.go`
- `cmd/database.go`
- `pkg/api/`
- `pkg/services/`
- `pkg/models/`
- `pkg/datastore/`
- `pkg/converters/`
- `pkg/exchangerates/`

### 2.3 Build-System

Frontend:

- `npm run lint`
- `npm run test`
- `npm run build`

Backend:

- `go vet`
- `go test ./...`
- `go build` mit Version/Commit/Build-Zeit via ldflags

Packaging:

- Backend-Binary
- Frontend `dist` als public/static asset
- Config/Templates/Lizenz
- Runtime-Verzeichnisse separat im Paket

Für JARVIS geeignet:

- Build-Metadata und Version-Endpoint übernehmen.
- Frontend/Backend separat baubar halten.
- Runtime-Daten konsequent außerhalb Repo/Build-Artefakten halten.

## 3. ezBookkeeping Ordner- und Komponentenstruktur

### 3.1 Grobe Struktur

- `cmd/`: CLI, Server, DB, Cron Jobs
- `pkg/api/`: HTTP API Handler
- `pkg/services/`: Business Logic
- `pkg/models/`: DB-/Domain-Modelle
- `pkg/converters/`: Import-/Export-Konverter
- `pkg/datastore/`: DB-Container und Stores
- `src/views/base/`: gemeinsame View-Logik
- `src/views/desktop/`: Desktop Views
- `src/views/mobile/`: Mobile Views
- `src/components/base/`: gemeinsame Komponentenlogik
- `src/components/desktop/`: Desktop-Komponenten
- `src/components/mobile/`: Mobile-Komponenten
- `src/components/common/`: gemeinsame Vue-Komponenten
- `src/stores/`: Pinia Stores
- `src/core/`: Core Types/Enums/Logik
- `src/models/`: Frontend Models
- `src/lib/services.ts`: API Client

### 3.2 Interessantes Strukturpattern

Das wichtigste Pattern ist die Dreiteilung:

1. `base` für geteilte Fach-/View-Logik
2. `desktop` für tabellarische, breite Workflows
3. `mobile` für native-like Sheets, Cards, Pull-to-refresh und Infinite Scroll

Für JARVIS geeignet:

- `frontend/src/composables/budget/...` für gemeinsame Logik
- `frontend/src/pages/...` aktuell beibehalten, später ggf. `desktop`/`mobile` Unterkomponenten
- UI-spezifische Präsentation trennen von Budget-Filter-/DTO-/Formatierungslogik

## 4. ezBookkeeping Routing, State und API Patterns

### 4.1 Routing

Desktop-Routen u.a.:

- `/transaction/list`
- `/statistics/transaction`
- `/insights/explorer`
- `/account/list`
- `/category/list`
- `/tag/list`
- `/template/list`
- `/schedule/list`
- `/exchange_rates`

Mobile-Routen u.a.:

- `/transaction/list`
- `/transaction/add`
- `/transaction/edit`
- `/statistic/transaction`
- `/settings/filter/account`
- `/settings/filter/category`
- `/settings/filter/tag`

Wichtiges Pattern:

- Filterzustand wird häufig über Query-Parameter abgebildet.
- Transaktionsliste und Statistik sind bookmarkbar/wiederherstellbar.

Für JARVIS geeignet:

- Filter für Effektive Ausgaben, Buchungen prüfen und Analyse in URL Query spiegeln.
- Mobile darf andere Routen/Interaktionen haben, soll aber dieselben Filtermodelle nutzen.

### 4.2 State Management

Pinia Stores:

- `transaction.ts`
- `statistics.ts`
- `explorer.ts`
- `account.ts`
- `transactionCategory.ts`
- `transactionTag.ts`
- `transactionTemplate.ts`
- `overview.ts`
- `exchangeRates.ts`
- `setting.ts`
- `user.ts`

Pattern:

- API-Aufrufe primär im Store.
- Views nutzen Stores plus Base-Composables.
- Invalidierungsflags für abhängige Daten.
- Transformierte Models statt roher API-Response im UI.

Für JARVIS geeignet:

- Budget Stores nach Domäne strukturieren: `budgetTransactions`, `budgetReview`, `budgetAnalytics`, `budgetSetup`.
- Gemeinsame Filter-/Formatierungslogik zentralisieren.
- API-DTOs und Display-Models trennen.

### 4.3 API-Struktur

Backend API ist in `cmd/webserver.go` zentral registriert und ruft Handler aus `pkg/api/` auf.

Relevante Endpunkte:

- Accounts: `/api/v1/accounts/...`
- Transactions: `/api/v1/transactions/...`
- Categories: `/api/v1/transaction/categories/...`
- Tags: `/api/v1/transaction/tags/...`
- Templates: `/api/v1/transaction/templates/...`
- Statistics: `/api/v1/transactions/statistics...`
- Explorer: `/api/v1/insights/explorers/...`
- Exchange Rates: `/api/v1/exchange_rates/...`

Für JARVIS geeignet:

- FastAPI Router nach Fachdomänen behalten/ausbauen.
- Query-Services von Command-Services trennen.
- Einheitliche Response-/Error-DTOs.
- Explizite endpoints für Drilldown und Analyse, kein UI-SQL.

## 5. ezBookkeeping Datenmodelle vs JARVIS

### 5.1 Accounts

**ezBookkeeping:**

- zweistufige Accounts
- Kategorien wie Cash, Checking, Credit Card, Virtual, Debt, Receivables, Investment, Savings
- Felder: Name, Icon, Color, Currency, Balance, Hidden, DisplayOrder
- Reconciliation-/Credit-Card-Statement-Metadaten

**JARVIS:**

- Budget Accounts vorhanden
- Fokus stärker auf Budget-/Import-/Review-Kontext
- Portfolio/Crypto Accounts existieren separat in anderen Domänen

**Empfehlung:**

- Für Budget: Account-UX verbessern, nicht das gesamte ezBookkeeping Accountmodell kopieren.
- `hidden`/`archived` und `display_order` stärker sichtbar machen.
- Reconciliation später, erst nach Bankimport-Stabilität.

### 5.2 Transactions

**ezBookkeeping:**

- Types: Modify Balance, Income, Expense, Transfer
- Transfers mit Related-Feldern
- Amount als integerartige DB-Repräsentation
- Soft delete
- Geo, Pictures, Comments, Hide Amount
- Scheduled-created Flag

**JARVIS:**

- `budget_transactions` für confirmed Budget-/Cashflow-Buchungen
- Review Candidates getrennt von bestätigten Transaktionen
- Splits, source links, Audit und Confirm-Grenzen sind JARVIS-Stärke

**Antwort auf Frage:** Sind `budget_transactions` ausreichend?

- Für Budget UX v2 und Analytics v1: **ja, ausreichend**, wenn Filter, Tags, Merchant und Splits sauberer exponiert werden.
- Für Advanced Imports/Explorer: `budget_transactions` sollten um vollwertigere Merchant-/Split-/Template-Referenzen ergänzt werden, aber nicht ersetzt werden.

### 5.3 Categories

**ezBookkeeping:**

- Income / Expense / Transfer Kategorien
- zweistufige Hierarchie
- Icon, Color, Hidden, DisplayOrder

**JARVIS:**

- Kategorien mit Typ, Parent, Farbe, Icon, Archiv/Merge/Delete Preview vorhanden
- Kategoriebaum funktional, UX noch technisch

**Empfehlung:**

- Konzept übernehmen: sichtbarer Kategoriebaum mit Icon/Farbe/Sortierung.
- User Mode gruppiert nach Einnahmen/Ausgaben; technische Typen übersetzen.

### 5.4 Tags

**ezBookkeeping:**

- Tags plus Tag Groups
- M:N TransactionTagIndex
- starke Filterlogik: has any/all, not any/all, without tags

**JARVIS:**

- Tags vorhanden, aber nicht vollwertig als Analyse-/Filterobjekt sichtbar

**Empfehlung:**

- Tags früher vollwertig machen.
- Tag Groups später.
- Tag-Filter als wichtiges Effektive-Ausgaben-/Explorer-Feature.

### 5.5 Scheduled Transactions / Templates

**ezBookkeeping:**

- Transaction Templates und Scheduled Templates
- Frequenz: daily, weekly, monthly, yearly

**JARVIS:**

- Fixkosten/Recurring bisher Roadmap/Placeholder
- Budget Plans decken geplante Beträge, aber nicht erwartete konkrete Transaktionen ab

**Antwort:** Brauchen wir `scheduled_transactions` früher?

- Für Budget UX v2: nein.
- Für Budget Advanced/Imports v1: ja, als **expected transaction candidates**, nicht als stille Auto-Buchungen.
- Scheduled Transactions sollten Kandidaten erzeugen, die mit realen Importen gematcht oder manuell bestätigt werden.

### 5.6 Splits

**JARVIS:**

- Splits existieren bereits im Review-Kontext.

**Antwort:** Sollten `budget_transaction_splits` zuerst vollwertiger werden?

- Ja, spätestens vor Advanced Analytics.
- Splits sind wichtiger als freie Explorer-Magie, weil Migros/Galaxus/Apotheke/Shopping oft Mischbelege sind.
- Splits sollten confirmed transaction level und candidate level sauber verbinden.

### 5.7 Merchant Entity

**ezBookkeeping:**

- Merchant/Payee ist eher über Beschreibung/Kommentar/Filter modelliert, nicht als starkes eigenes Kernobjekt im analysierten Modell.

**JARVIS:**

- Merchant/Payee/Source ist schon implizit in Kandidaten/Buchungen.

**Antwort:** Brauchen wir Merchant Entity früher?

- Ja, aber leichtgewichtig.
- Empfehlung: `budget_merchants` oder normalisierte Merchant-Alias-Tabelle in Imports v1/Analytics v1, damit Top Händler, Regeln und Duplikate stabiler werden.
- Nicht sofort als großes CRM-Modell bauen. Kleiner Alias-/Canonical-Merchant-Resolver reicht.

### 5.8 Transaction Templates

**Antwort:** Brauchen wir transaction templates?

- Ja, aber nach UX v2.
- Gute Templates:
  - manuelle Standardausgabe
  - monatliche Fixkosten-Kandidaten
  - wiederkehrende Einnahmen
- Templates müssen Preview/Confirm nutzen.

### 5.9 Exchange Rates

**ezBookkeeping:**

- viele Exchange Rate Provider und User Custom Exchange Rates

**JARVIS:**

- Finance-System hat FX-/Provider-Regeln separat, no-provider-on-render ist Pflicht

**Empfehlung:**

- Provider-Adapter-Idee übernehmen, aber nur als explizite Jobs/Cache.
- Budgetseiten lesen nur lokale Snapshots.

### 5.10 Imports

**ezBookkeeping:**

- sehr breite Importformate
- DataTable-Abstraktion
- Custom CSV/XLS/XLSX mit Spaltenmapping
- Importprozess mit Parse/Check/Modify/Import

**JARVIS:**

- source-aware import candidates, Migros/Credit Card/Bank/Excel Seeds, Review/Confirm/Audit

**Empfehlung:**

- Nicht breit alle Formate nachbauen.
- Stattdessen JARVIS Import Wizard für unsere Quellen: Kreditkarte, Migros, Bank CSV, manuelle CSV.
- Spaltenmapping nur zur Kandidatenerzeugung, nie direkte Buchung.

## 6. Transaktionsliste: UX-Vergleich und Empfehlungen

### 6.1 ezBookkeeping Transaktionsliste

Interessante Elemente:

- linke Navigation mit Listen-/Kalender-/Gallery-Modus
- Datumsbereich und Monatssprung
- Suche/Keyword
- Einnahmen-/Ausgaben- oder Inflow-/Outflow-Summen
- tabellarische Liste bzw. mobile Cards
- Gruppierung nach Monat/Datum
- Kategorie mit Icon/Farbe
- Konto-Spalte
- Tags
- Beschreibung
- Pagination/Infinite Scroll
- Import/Export Actions

### 6.2 Für JARVIS Effektive Ausgaben übernehmen

Empfehlung:

- Datum gruppieren: Monat → Tag → Transaktionen
- Summenzeile pro Zeitraum: Einnahmen, Ausgaben, Netto, Anzahl
- Kategorie als farbiger Chip mit Icon
- Händler/Beschreibung prominent
- Konto nach Name, nicht ID
- Tags sichtbar und filterbar
- Suchfeld immer oben sichtbar
- Monatsfilter mit Vor/Zurück
- Row Click öffnet Detail Drawer
- Reversal/Adjustment nur über Preview/Confirm
- Mobile Cards statt Tabelle

### 6.3 Für JARVIS Buchungen prüfen übernehmen

Empfehlung:

- Review-Liste ruhiger machen:
  - weniger Haupttabs
  - Spezialfälle als Filter-Chips
  - Status- und Confidence-Texte menschenlesbar
  - technische Kandidatenlogik aus User Mode ausblenden
- Gruppierung nach Datum/Quelle
- Batch-Aktionsleiste erst anzeigen, wenn ausgewählt wurde
- Kategorie-Dropdown mit Suchfeld
- Konflikt-/Warnhinweise pro Kandidat kompakt
- Preview Confirm als Pflichtgrenze

## 7. Statistik & Analyse: UX-Vergleich und Chart-Empfehlung

### 7.1 ezBookkeeping Analysekonzepte

- Zeitraumsteuerung
- Analysearten: Categorical Analysis, Trend Analysis, Asset Trends
- Chart data type getrennt von Chart type
- Filter für Accounts, Categories, Tags, Keyword, Zeitraum
- Pie/Bar/Radar
- Area/Column/Bubble Trends
- Sankey für Overview
- Explorer mit Pie, Stacked/Grouped Columns, Lines, Area, Bubble, Radar, Treemap, Sunburst, Heatmap, Calendar Heatmap

### 7.2 Was passt für Budget-Auswertung?

- Bar: Budget vs Ist je Kategorie
- Donut/Pie: Anteil Ausgaben nach Kategorie
- Trendline/Area: Monatsverlauf Einnahmen/Ausgaben/Netto
- Stacked Bar: Kategorien pro Monat
- Top Händler: Bar/List
- Sankey optional: Konto → Kategorie → Monat

### 7.3 Was passt für Budgetstatus nach Kategorie?

- Monatsbalken pro Kategorie
- Budgetlinie je Monat
- Ampelfarbe pro Monat
- Forecast und Abweichung
- Klick auf Kategorie/Monat → gefilterte Buchungen

### 7.4 Was passt für Daten-Explorer?

- Read-only Query Builder mit Dimensionen und Metriken
- gespeicherte Views
- Chart Type Auswahl
- keine Batch-Aktionen aus Explorer v1

### 7.5 Chart-Priorität

| Chart | Empfehlung | Grund | Zeitpunkt |
|---|---|---|---|
| Bar | Ja | Budget vs Ist, Top Kategorien, Top Händler | Analytics v1 |
| Donut/Pie | Ja, begrenzt | Kategorieanteile schnell lesbar | Analytics v1 |
| Trendline/Area | Ja | Monatsverlauf und Cashflow | Analytics v1 |
| Stacked Bar | Ja | Kategorien über Monate | Analytics v1/v2 |
| Treemap | Optional | Hierarchische Kategorien, große Ausgabenblöcke | Advanced |
| Sunburst | Optional/später | Kategoriebaum drilldown, kann überladen wirken | Advanced |
| Heatmap | Später | Aktivität/Spending Patterns | Advanced |
| Calendar Heatmap | Später | Ausgabentage, ungewöhnliche Tage | Advanced |
| Sankey | Optional | Konto → Kategorie Flüsse | Advanced, nach Stabilisierung |
| Radar | Nein/kaum | Für Budget wenig intuitiv | Nicht priorisieren |
| Bubble | Nein/später | Mehrdimensional, schwer verständlich | Explorer später |

## 8. Funktionsmatrix

| Bereich | ezBookkeeping-Funktion | JARVIS aktueller Stand | Lücke | Empfehlung | Priorität |
|---|---|---|---|---|---|
| Konten | Zwei-Level Accounts, Typen, Währung, Icon/Farbe, Hidden, Reconciliation | Budget Accounts vorhanden, Portfolio/Crypto separat | Konto-UX weniger klar, Hidden/Sortierung/Reconciliation schwach | Kontoübersicht mit Namen, Typ, aktiv/archiviert, Default; Reconciliation später | P2 |
| Kategorien | Income/Expense/Transfer, zweistufig, Icon/Farbe, Hidden, DisplayOrder | Kategoriebaum, Typen, Farbe/Icon, Merge/Archive vorhanden | User Mode zeigt teils technische Struktur | Vereinfachter Kategoriebaum, deutsche Labels, Such-/Gruppendropdown | P1 |
| Tags | Tags + Tag Groups + starke Filterlogik | Tags vorhanden, aber nicht vollwertig sichtbar | Tags fehlen in Analyse/Filter als Kernobjekt | Tags sichtbar machen, Filter has any/all später | P1/P2 |
| Transaktionen | Income/Expense/Transfer/Modify Balance, Kommentare, Bilder, Location | budget_transactions confirmed + Review Candidates | Transfers/Reversal/Adjustment UX noch schwach | Confirmed Ledger behalten, Transfer/Adjustment Drawer ergänzen | P1/P2 |
| Transaktionsliste | Liste/Kalender/Galerie, Datumssprung, Summen, Filter, Pagination | Effektive Ausgaben vorhanden, mobil verbessert | Filter-/Gruppierungs-UX weniger reif | Datum gruppiert, Suchfeld, Monatssprung, Summen, Row Drawer | P1 |
| Geplante Transaktionen | Templates + Scheduled frequency | Budget Plans/Income Plans, Fixkosten Placeholder | erwartete konkrete Zahlungen fehlen | scheduled candidates später, nie still buchen | P4 |
| Imports | Viele Formate, Custom Mapping, Check/Modify/Import | Source-aware candidates, Migros/CreditCard/Bank/Excel Seeds | kein geführter generischer Wizard | Import Wizard Shell mit JARVIS Confirm-Grenze | P3 |
| Suche/Filter | Zeitraum, Typ, Kategorie, Konto, Tags, Betrag, Keyword | Teilweise vorhanden | Mehrfachfilter und URL Query ausbaufähig | einheitliches Filtermodell für Ausgaben/Review/Analyse | P1 |
| Statistiken | Categorical, Trends, Asset Trends | Budgetstatus/Charts vorhanden | Analyse-Hub fehlt | vordefinierte Analyse-Seiten, kein freier Explorer zuerst | P2 |
| Kategorieanalyse | Pie/Bar/Radar, drilldown | Top/Breakdown teilweise | visuell noch simpel | Donut/Bar plus Buchungsdrilldown | P2 |
| Trendanalyse | Area/Column/Bubble, Aggregation | Forecast/Monatswerte | Trendzentrale fehlt | Cashflow- und Kategorie-Trendlinien | P2 |
| Vermögenstrends | Asset Trends, Net Worth | Portfolio/Crypto separat vorhanden | Budget und Vermögen noch getrennt | Im Budget nur Cashflow; Vermögen in Portfolio lassen | P4 |
| Daten-Explorer | Saved Explorer, Query/Chart/Data Table | nicht vorhanden | freies Analysesystem fehlt | read-only Explorer nach Standardviews | P4 |
| Mobile UX | separate Mobile App, PWA, Sheets, Pull-to-refresh | Bottom Nav, Mobile Cards vorhanden | Review mobil noch schwer | Mobile Review Cards + Sheets | P2 |
| Dark Theme | vorhanden | JARVIS Dark UI vorhanden | Konsistenz/Polish | beibehalten, Chart-Farben vereinheitlichen | P1 |
| Batch-Aktionen | Batch update/import/edit | Preview/Confirm Batch vorhanden | UX kann klarer werden | Batch nur mit Preview, Konfliktliste, Audit | P1 |
| Duplikate | Import/Transaction Workflow integriert | duplicate_of/status teilweise | eigener Duplikatflow fehlt | Duplikat Review als Subflow | P3 |
| Budgetstatus | Kein Hauptbudgetmodul, Analyse stark | JARVIS stark: Plan/Ist/Forecast/Ampel | Visual Analytics ausbaufähig | Budget Cockpit als zentrale Wahrheit behalten | P1 |
| Rule Engine | eher Import/Mapping/Automation Patterns | Rule MVP-light suggestions vorhanden | Test-/Treffer-UX fehlt | Regeln nur Kandidaten vorschlagen, nie direkt buchen | P3 |
| Reports | Export/Stats/Explorer | Reports minimal/Portfolio getrennt | Budget Reports fehlen | monatlicher Budgetreport nach Analytics v1 | P3 |

## 9. Konkrete UI-Vorschläge für JARVIS

### A. Buchungen prüfen

Ziel: produktiver, ruhiger, weniger technisch.

Vorschlag:

- Drei Haupttabs:
  - Automatisch vorgeschlagen
  - Manuell prüfen
  - Ausgeschlossen / Duplikate / Covered
- Filter-Chips statt vieler Spezialtabs:
  - Migros
  - Galaxus/Digitec
  - Transfers
  - Duplikate
  - Unklar
  - Quelle
- Kompakte Kandidatenzeile:
  - Datum
  - Händler/Beschreibung
  - Betrag
  - Kategorie-Vorschlag
  - Confidence als Text/Farbe
  - Regel/Grund menschenlesbar
- Linke/obere Filter:
  - Zeitraum
  - Quelle
  - Kategorie
  - Konto
  - Status
  - Confidence
  - Suche
- Batch-Aktionsleiste:
  - erscheint nur bei Auswahl
  - Kategorie zuweisen
  - Preview Confirm
  - Ignorieren
  - Transfer markieren
- Keine technischen Candidate IDs in User Mode.
- Detail Drawer für Audit/Source/Line Items/Conflicts.

### B. Effektive Ausgaben

Ziel: echte Transaktionsliste.

Vorschlag:

- Gruppierung nach Monat und Tag.
- Kopf-Summen:
  - Ausgaben
  - Einnahmen optional
  - Netto optional
  - Anzahl
- Row:
  - Datum
  - Kategoriechip mit Icon/Farbe
  - Händler/Beschreibung
  - Konto
  - Tags
  - Quelle
  - Betrag rechts prominent
- Filter:
  - Monat/Jahr/freier Zeitraum
  - Vor/Zurück
  - Kategoriebaum
  - Konto
  - Tag
  - Händler/Suche
  - Betragsspanne
  - Quelle
- Row Click → Detail Drawer:
  - Buchungsdetails
  - Kategorie/Tags/Beschreibung ändern
  - Reversal Preview
  - Adjustment Preview
  - Audit-Historie
- Mobile:
  - Cards
  - Bottom Sheet Filter
  - keine breite Tabelle

### C. Budgetstatus nach Kategorie

Ziel: Analyse statt Tabelle mit Zahlenfriedhof — was für eine kühne Innovation.

Vorschlag:

- Budget Cockpit als Start:
  - KPI Row
  - rote/gelbe Kategorien zuerst
  - Review-Offen prominent
- Kategoriezeile:
  - Budget Monat
  - Ist Monat
  - Jahr bisher
  - Forecast
  - Abweichung
  - Ampel
- Row Click:
  - Monatsbalken mit Budgetlinie
  - Forecast Erklärung
  - Merchant/Source Breakdown
  - Buchungen der Kategorie
  - Link zu Effektive Ausgaben mit Filter
- Kein Budget:
  - klar `ohne Budget`, keine falsche Abweichungspräzision

### D. Budget-Auswertung

Neue Analysezentrale:

- Ausgaben nach Kategorie: Donut + Bar + Tabelle
- Ausgaben nach Konto: Bar/List
- Einnahmen nach Konto/Quelle: Bar/List
- Monatsverlauf: Einnahmen, Ausgaben, Netto
- Budgetabweichung: Kategorie x Monat
- Top Händler: Bar/List mit Drilldown
- Datenqualität: unkategorisiert, offene Reviews, Duplikate, ohne Budget
- Optional später:
  - Treemap
  - Sunburst
  - Heatmap
  - Calendar Heatmap
  - Sankey

### E. Daten-Explorer

Langfristig sinnvoll, aber **nicht zuerst**.

Dimensionen:

- Zeitraum
- Konto
- Kategorie
- Händler
- Tag
- Quelle
- Betragsspanne
- Transaktionstyp
- Review-/Datenqualitätsstatus

Metriken:

- Summe
- Durchschnitt
- Anzahl
- Median später
- Monatsvergleich
- Anteil
- Budgetabweichung
- Top-N Anteil später

Sicherheitsregeln:

- v1 read-only
- keine freien SQL Queries
- nur whitelist-basierter Query Builder
- Saved Views mit Schema-Version
- keine Batch-Aktionen aus Explorer ohne Review/Preview/Confirm

## 10. Navigationsempfehlung

### Empfohlene Hauptnavigation

Ich empfehle **nicht** alles unter `Budget` zu stopfen. Das würde wieder zu einer Menühalde führen — ausgesprochen demokratisch, aber nutzlos.

Empfohlene Struktur:

- Command Center
- Budget
- Transaktionen
- Analyse
- Setup
- Portfolio / Crypto / Reports separat wie bisher

### Budget

- Übersicht / Cockpit
- Budgets / Pläne
- Einnahmenplanung

### Transaktionen

- Liste / Effektive Ausgaben
- Buchungen prüfen
- Ausgabe erfassen
- Transfers
- Imports später als Wizard/Flow

### Analyse

- Budget vs Ist
- Kategorien
- Trends
- Konten
- Händler
- Datenqualität
- Daten-Explorer später

### Setup

- Konten
- Kategorien & Tags
- Regeln
- Importquellen
- Audit/Sicherheit optional

### Warum diese Empfehlung?

- `Budget` bleibt Plan/Ist/Forecast.
- `Transaktionen` wird die Arbeitsfläche für echte Buchungen und Review.
- `Analyse` wird nicht mit Setup/Review vermischt.
- `Setup` enthält Stammdaten und Regeln.
- Mobile kann daraus 5 Einträge machen: Home, Budget, Prüfen, Ausgaben, Mehr.

## 11. Roadmap in 4 Stufen

### 11.1 Budget UX v2

Nur UI/Workflow-Verbesserung, keine neue Import-/Provider-Engine.

Umfang:

- Navigation bereinigen
- Transaktionsliste verbessern
- Effektive Ausgaben als echte Transaktionsliste
- Buchungen prüfen ruhiger machen
- Kategoriebaum vereinfachen
- Tags sichtbar machen
- technische IDs aus User Mode entfernen
- Batch Preview deutlicher machen
- mobile Review Cards entwerfen

Erfolgskriterien:

- Nutzer findet Budget, Transaktionen, Review und Analyse ohne Fachjargon.
- Filter sind schneller erreichbar.
- Jede Schreibaktion bleibt Preview/Confirm/Audit.

### 11.2 Budget Analytics v1

Umfang:

- Kategorieanalyse
- Monatsvergleich
- Budget vs Ist
- einfache Charts:
  - Bar
  - Donut/Pie
  - Trendline
  - Stacked Bar optional
- Top Händler
- Top Kategorien
- Drilldown von Charts zu Transaktionen
- Datenqualität-Panel

Erfolgskriterien:

- Rote Kategorien sind erklärbar.
- Charts führen immer zu Buchungen/Details.
- Keine Provider-Aufrufe beim Rendern.

### 11.3 Budget Imports v1

Umfang:

- Kreditkartenimport produktiv, aber staged
- Migros-Bons produktiv weiterführen
- Bank CSV vorbereiten
- Import Wizard Shell
- Spaltenmapping für generische CSV/Excel nur bis Kandidaten
- Duplikate als Review-Subflow
- Review/Confirm/Audit konsequent
- Regel-Test mit Trefferanzahl

Erfolgskriterien:

- Import erzeugt Kandidaten, nicht direkte Buchungen.
- Batch Confirm hat Preview-ID, Konflikte, Zielkonto, Kategorieverteilung.
- Keine Datei landet im Repo.

### 11.4 Budget Advanced

Umfang:

- geplante Transaktionen / Fixkosten-Kandidaten
- Transaction Templates
- Merchant Entity / Alias Resolver
- vollwertigere Splits
- Rule Manager mit Simulationsmodus
- Read-only Daten-Explorer
- Sankey/Sunburst/Treemap/Heatmap/Calendar Heatmap
- Mobile Kamera/Receipt später
- OCR/AI nur expliziter Job mit Review

Erfolgskriterien:

- Automatisierung reduziert Arbeit, ersetzt aber nie Confirm.
- Explorer bleibt read-only oder nutzt Review-Pipeline.
- Hypothesen/Pläne und bestätigte Buchungen bleiben getrennt.

## 12. Was wir als Idee übernehmen dürfen

Geeignet als Idee:

- Desktop/Mobile getrennte UX-Flows
- Base-Composables für gemeinsame Fachlogik
- Transaktionsliste mit Datumssprung, Suche, Summen, Gruppierung
- Kategorie/Konto/Tag als primäre Filterdimensionen
- Analyse-Typen getrennt von Chart-Typen
- Explorer als gespeicherte Query-Konfiguration
- Import Wizard als mehrstufiger Review-Prozess
- Chart Drilldown zu Transaktionen
- Empty States und Skeleton Loading
- DisplayOrder/Hidden für Stammdaten

Nicht direkt übernehmen:

- Code
- Assets, Icons, Templates, Screenshots
- Vuetify/Framework7-Komponenten 1:1
- XORM Sync2 Migration Pattern
- Custom Script Import im User Mode
- Batch Updates aus Explorer ohne Preview/Confirm
- Provider-/OCR-Aufrufe beim Rendern

## 13. Offene Empfehlungen

1. Vor dem nächsten Feature-Sprint erst **Budget UX v2 Plan** schreiben, nicht direkt implementieren.
2. Budget Navigation zuerst bereinigen; sonst wird jeder weitere Chart nur Tapete auf Kabelsalat.
3. Tags und Merchant-Normalisierung früher priorisieren als Heatmaps/Sunburst.
4. Daten-Explorer erst nach stabilen Standardanalysen bauen.
5. Import Wizard erst als Shell/Workflow, dann Quellen nacheinander anschließen.
6. Scheduled Transactions als Kandidatenmodell, nicht als stille Buchungsmaschine.
7. Splits vollwertiger machen, bevor große Händler-/Kategorieanalysen finalisiert werden.

## 14. Abschluss-Checkliste

- ezBookkeeping separat geklont: ja
- Pfad geprüft: ja, `/home/agent/.hermes/reference_repos/ezbookkeeping`
- Lizenz geprüft: ja, MIT
- Frontend-Struktur analysiert: ja
- Backend-Struktur analysiert: ja
- Transaktions-UX analysiert: ja
- Statistik-/Analyse-UX analysiert: ja
- Funktionsmatrix erstellt: ja
- JARVIS-Navigationsvorschlag erstellt: ja
- Datenmodell-Vergleich erstellt: ja
- Roadmap erstellt: ja
- Keine Fremdcodes/Assets übernommen: bestätigt
- Keine Runtime-Daten genutzt/geändert: bestätigt
- Keine Implementierung gestartet: bestätigt