finance-system-architecture

---
name: finance-system-architecture
description: "Design/implement the user's JARVIS Finance System: CHF ledger, portfolio accounting, dashboard, imports, reports, secrecy."
version: 1.0.0
author: Hermes Agent
license: MIT
metadata:
  hermes:
    tags: [finance, portfolio, accounting, dashboard, csv, fx, tax, privacy]
---

# Finance System Architecture

## When to use

Use this skill whenever the user asks about the **Finance System – Architektur & Scripts** topic or work involving the user's personal finance-management system: portfolio imports, transaction accounting, Bank/Broker/CSV processing, dashboards, reports, tax/income views, FX logic, market data jobs, alerts, or later implementation.

Do **not** use it for pure investment-strategy discussion; those belong in the separate finance strategy topic unless the user explicitly asks for technical implementation.

## Core principles

1. **No automated trading.** The system may prepare orders and recommendations, but never executes orders or connects to broker trading APIs for execution.
2. **Accounting first, opinions later.** MVP must prioritize correct transaction ledger, cash ledger, FX handling, income/tax data, and dashboard before complex scores, news, analyst ratings, or LLM analysis.
3. **Rule-based first.** Calculations, scores, alerts, rebalancing and reports must be deterministic and auditable. LLMs may only summarize/explain text or assist extraction with human review.
4. **CHF as base currency.** Store every transaction in original currency and CHF using historical FX at transaction/payment date; current valuations use current FX.
5. **Financial data secrecy.** Never expose real financial values, portfolio files, raw exports, reports with real numbers, DBs, API keys, or credentials in chat, GitHub, logs, or shared docs unless the user explicitly approves scope.
6. **Data ownership.** All data must be exportable: CSV, JSON, Parquet, SQLite/Postgres dump, Markdown/HTML/PDF reports.

## Current v0.3 decisions

See `references/spec-v0.2-decisions.md` for the baseline, `references/spec-v0.3-decisions.md` for the priority update, `references/spec-v0.4-implementation-blueprint.md` for the MVP 1 technical implementation blueprint, `references/spec-v0.4.1-corrections.md` for accepted corrections, `references/spec-v0.5-repo-blueprint.md` for the concrete repo/implementation plan, `references/mvp-safety-gate-implementation.md` for the implementation safety-gate sequence and verification commands, `references/mvp-import-pipeline-tasks-9-13.md` for the synthetic CSV import/FX/transaction pipeline pattern, `references/mvp-ledger-cash-wac-positions.md` for cash/WAC/position ledger calculation rules and tests, `references/mvp-crypto-wallet-ledger.md` for crypto wallet/assets/holdings/transfers/buy-sell/fee MVP rules, `references/crypto-xlsx-initial-snapshot-dry-run.md` for the controlled real-file XLSX crypto initial-snapshot dry-run pattern and mapping decisions, `references/crypto-xlsx-initial-snapshot-production-import.md` for productive safe-subset XLSX import operations, compatibility/partial-write recovery, and dashboard correction follow-up, `references/crypto-single-coin-runtime-test.md` for controlled one-coin productive runtime tests and the coin-vs-holding ambiguity guard, `references/multi-wallet-crypto-and-equity-manage-ui.md` for approved multi-wallet single-coin snapshots, SQLite Decimal/TEXT affinity pitfalls, and synthetic-first Equity/ETF Manage UI patterns, `references/crypto-price-refresh-and-idempotent-btc-runtime.md` for robust batch price refresh and re-run-safe BTC/single-coin runtime checks, `references/crypto-runtime-db-consistency-verification.md` for post-import runtime DB consistency checks, exact safe-set verification, dashboard no-live-API testing, and runtime-only report generation, `references/mvp-crypto-manual-management-ui.md` for audited dashboard add/correct/remove crypto holding workflows after an initial snapshot, `references/mvp-market-import-safety-hardening.md` for CoinGecko provider/backoff, CSV importer completion, alert lifecycle, Git-safety and crypto Decimal precision patterns, `references/git-safety-verification-coverage.md` for the verifier-warning workflow and minimum Git-safety test matrix, `references/mvp-streamlit-dashboard.md` for the safe local Streamlit dashboard shell/read-model/testing pattern, `references/mvp-crypto-report-export.md` for local-only crypto report context/export rules, `references/github-token-push-from-drive.md` for the safe Google-Drive-token push workflow when local FinanceManager commits are ahead of GitHub, `references/runtime-backup-and-broker-mapping.md` for runtime DB backup/restore hardening plus PostFinance/True Wealth/Raiffeisen structural mapping/dry-run rules, `references/import-wizard-mapping-layer.md` for the Phase B1 import wizard, instrument/account mapping, review queue, data-quality and read-only safety pattern, `references/broker-parser-dry-run-pipeline.md` for the Phase B2 synthetic broker parser, dry-run, runtime review-item and UI quality-flag pipeline, `references/controlled-real-broker-dry-run.md` for the Phase B3 controlled real-file dry-run pattern with backup, aggregate-only reporting, runtime-only review items, and no productive position writes, and `references/broker-review-queue-hardening.md` for Phase B4 manual review queue filters, auditable mapping actions, import-readiness gating, dry-run session management, and Data Quality Center hardening without productive portfolio writes, and `references/guided-manual-review-pilot.md` for Phase B5 small-scope runtime metadata pilots that move selected review items to `ready_for_import` without productive imports, `references/broker-import-execution-plan-mini-import.md` for Phase B6 final dry-run execution plans plus exactly-one productive broker mini-import, `references/broker-mini-import-regression-and-corrections.md` for post-mini-import regression, void/correction workflows, backup/restore checks, and one-at-a-time follow-up imports, and `references/broker-mini-import-completion-and-dq-consolidation.md` for completing the last ready True-Wealth mini-import plus active-vs-resolved Data Quality alert consolidation, `references/equity-fx-market-data-phase-c.md` for the local FX/market-data foundation after broker mini-imports and before broader Equity/ETF valuation/imports, and `references/true-wealth-valuation-pilot-c2.md` for the True-Wealth valuation pilot safeguards around hedge metadata, provider mappings, historical FX failures, timestamp alignment, corporate-action flags, and aggregate-only runtime reporting, `references/true-wealth-mapping-candidate-review-c3.md` for the controlled mapping-candidate review pattern before any productive Equity/ETF price or FX valuation, `references/instrument-catalog-manual-add-workflow.md` for the general Instrument Catalog + dashboard manual-add workflow that must underpin future Equity/ETF/Crypto adds, and `references/public-instrument-lookup-candidate-generator.md` for runtime-only public metadata lookups, candidate review packs, alert dedupe, and no-auto-selection rules, and `references/mapping-candidate-ranking-decision-pack.md` for ranking raw candidates into a manual-review decision aid, Data Quality alerts, confirmation workflow, and migration pitfalls, and `references/dashboard-user-mode-ux-and-runtime-review.md` for User/Admin dashboard navigation, crypto wallet drilldowns, audited Crypto Manage actions, and runtime-only mapping demotion patterns, and `references/dashboard-functional-ux-stabilization.md` for removing duplicate Streamlit navigation, hiding unfinished User Mode pages, enforcing Read-only/Edit Mode button behavior, and testing explicit-click price/report actions, and `references/dashboard-usability-simplification.md` for the stricter MVP User Mode reduction, calm Command Center, compact Crypto/Wallet pages, direct inline action forms, and disabled-not-fake button rule, and `references/crypto-adjusted-xlsx-and-equity-docx-dryrun.md` for adjusted real crypto XLSX completion using CoinGecko IDs plus aggregate-only True Wealth/PostFinance DOCX Equity/ETF dry-run preparation, and `references/equity-docx-instrument-resolver-review-workflow.md` for the controlled Equity/ETF DOCX staging, resolver, review queue, local-Qwen-as-parser-only, and confirmed-only initial-snapshot workflow, `references/manual-equity-etf-entry-wizard.md` for the preferred manual Equity/ETF search/add-position wizard when DOCX imports are too unsafe or not approved, and `references/manual-position-entry-provider-ux.md` for User Mode placement, explicit-click provider lookup, runtime-secret loading, caching, and final verification/push discipline, and `references/equity-etf-provider-integration-openfigi-fmp.md` for the concrete OpenFIGI-first/FMP-second integration pattern, provider merge rules, local-price preview semantics, and `update-equity-prices` workflow, `references/provider-integration-sprint-v2.md` for the multi-provider Free/Fallback pattern covering OpenFIGI/FMP/Finnhub/Twelve Data/Massive/EODHD, explicit-action dashboard semantics, sanitized status/error categories, and low-volume EODHD handling, and `references/provider-secret-auth-debugging.md` for targeted runtime-secret/provider-auth debugging when keys are present but OpenFIGI/FMP smoke tests fail, and `references/mvp-freeze-zwischenbericht-abnahme.md` for the MVP-freeze Zwischenbericht/Abnahmeplan pattern after an accepted implementation sprint, and `references/mvp-dashboard-workflow-regressions.md` for MVP dashboard regression coverage around cached FX, Cash wizard writes, explicit-click Equity/Crypto price refresh, Crypto cache-detail UX, runtime cleanup archives, and authenticated push verification, and `references/mvp-acceptance-dashboard-fx-valuation-cleanup.md` for acceptance-mode dashboard fixes covering hidden internal FX statuses, cache/provider/manual/missing FX flows, Equity/ETF valuation labels, runtime cleanup backup/audit, and final push verification, and `references/dashboard-user-mode-finalization-and-push.md` for integrated Portfolio User Mode finalization, hidden report paths, post-pytest Git-safety cleanup, Streamlit restart sanity, and authenticated push/hash verification, and `references/fastapi-vue-dashboard-transition.md` for the FastAPI read-only API + Vue User Mode transition pattern, DTO contracts, frontend Git-safety additions, and TestClient threading pitfall. Key decisions:

- Platform/account views: Raiffeisen, PostFinance, True Wealth, Crypto-Coins, plus Gesamtansicht.
- Existing Google Drive files under `Finanzen/01 Aktueller Stand Portfolios` are **initial-snapshot reality checks**, not full ledgers.
- MVP means the smallest useful first version: correct data foundation, ledger, CHF/FX logic, platform views, crypto inventory, watchlist, reports, workflows and audit log.
- Stock/ETF tax documents are downgraded: optional reference/control module and dividend/distribution transparency, not MVP 1 and not a complete tax dossier replacement.
- Crypto inventory is promoted to MVP 1: wallet/platform-level holdings, Crypto PDF, CoinGecko valuation, stale-price warnings and manual verification.
- Crypto snapshot values are stale; use quantities only and recalculate current values via CoinGecko later.
- MVP dashboard recommendation: Streamlit + SQLite + SQLAlchemy/Pandas/Plotly for the initial safe operations/admin shell; when moving toward a premium User Mode, use a thin FastAPI read-only API first and Vue 3 + TypeScript frontend later, following `references/fastapi-vue-dashboard-transition.md`.
- MVP inputs: manual dashboard entry, standard CSV import/export, later broker/bank export import. No direct broker integrations initially.
- Telegram crypto buys/sells/transfers should be parsed as pending transactions and only saved after explicit confirmation.
- Every portfolio or crypto change must create a History/Audit entry.

## Required data model areas

At minimum design for:

- `platforms`, `accounts`, `instruments`
- `transactions` with original currency and CHF fields
- `cash_ledger`
- derived `positions_current`
- `dividends_distributions`
- `market_prices`, `fx_rates`
- `watchlist_items`
- `alerts`
- `decision_journal`
- `reports`
- `data_quality_issues`

## CSV/import rules

- For broker/bank imports (PostFinance, True Wealth, Raiffeisen), build the safe review layer before productive imports: Import Wizard, instrument mappings, platform/account mappings, dry-run summaries, Manual Review Queue, Data Quality Center and visible read-only/write-enabled state. Follow `references/import-wizard-mapping-layer.md`. When wiring parser output into the wizard, use the synthetic-first parser/dry-run/review-item pipeline in `references/broker-parser-dry-run-pipeline.md`. After explicit approval for real-file dry-runs, follow `references/controlled-real-broker-dry-run.md`: preflight, verified runtime backup, temp-only file handling, aggregate-only reporting, runtime-only review items, and verification that productive positions/ledger rows stayed unchanged. For DOCX portfolio extracts from True Wealth/PostFinance, follow `references/crypto-adjusted-xlsx-and-equity-docx-dryrun.md`: use structural/masked parsing only, count field coverage and mapping status, treat ticker-without-exchange as review-needed, and stop before productive import. If the DOCX dry run shows low ISIN coverage/no cost basis/no transaction history or the user withholds final import approval, switch to `references/equity-docx-instrument-resolver-review-workflow.md`: create `instrument_import_candidates`-style staging, use local Qwen only as an assistive parser if available, classify ticker-only rows as `needs_manual_review`, expose a Mapping Review Queue, and import only later from `confirmed` candidates after explicit approval. If the user rejects productive DOCX import or wants direct manual control, follow `references/manual-equity-etf-entry-wizard.md`: make the main path an audited portfolio-app-style search/add-position wizard with explicit candidate selection, no live API on render, no ticker-only auto-selection, hidden technical IDs in User Mode, cost-basis/FX quality alerts, and audit-log writes. When the user asks to make real dry-run results manually editable, follow `references/broker-review-queue-hardening.md`: add filters/detail views, auditable review-metadata actions, per-item/session import-readiness status, dry-run session management, and Data Quality Center counts while keeping productive portfolio writes disabled. For a guided manual-review pilot on real runtime items, follow `references/guided-manual-review-pilot.md`: select 1–3 clear ETF/equity items (prefer True Wealth), write only audited review metadata, correct only presence booleans if needed, derive `ready_for_import` via readiness logic, and verify productive tables remain unchanged. Before the first productive broker position import, follow `references/broker-import-execution-plan-mini-import.md`: create runtime-only execution plans from the ready review items, validate exact Decimal-text payloads from the runtime source, preserve missing FX/cost-basis quality flags, then import exactly one ledger `initial_position_snapshot` after a verified backup; do not write `positions_snapshot` as the source of truth. After the first mini-import and before broader imports, follow `references/broker-mini-import-regression-and-corrections.md`: verify import links/audit/Decimal handling/re-import blocking, add or test safe void/correction flows, run backup/restore-to-test-DB regression, and only then optionally import one more ready plan. When the user approves finishing a remaining small set, follow `references/broker-mini-import-completion-and-dq-consolidation.md`: first disambiguate active vs resolved stale crypto alerts with `check-data-quality --scope crypto --resolve-fixed`, then import exactly one remaining ready execution plan after backup/verify, and consolidate Review Queue/Data Quality counts without exposing values.
- Do not pivot into later analytics modules while the user has asked for import/mapping hardening. Monte Carlo, backtesting, rebalancing, scores, heatmaps and projections are later phases unless explicitly re-authorized.
- Use a canonical CSV format before broker-specific importers.
- Imports must be idempotent via external transaction ID or row hash.
- Importers must separate dry-run and commit modes, collect validation errors explicitly, and always create an `import_sessions` record even for dry runs or failed imports.
- Import results should classify rows as new, existing, duplicate, or failed; do not rely on `INSERT OR IGNORE` as the only duplicate-detection mechanism.
- Row hashes must be stable and deterministic: normalize key order, whitespace, and `None` versus empty strings while leaving domain-specific canonicalization to the importer.
- If a source file has only current holdings and no full history, import it as `initial_position_snapshot` / `initial_cash_snapshot`, not fake historical buys.
- Missing historic FX, fees, taxes, dates, investment case, target weights, or dividend details must be flagged as data-quality gaps.

## FX and return rules

For acceptance-mode dashboard fixes around manual position entry and valuation UX, follow `references/mvp-acceptance-dashboard-fx-valuation-cleanup.md`: hide internal FX status codes from User Mode, treat CHF as `not_needed`, resolve USD/EUR via cache/provider on explicit save, require a conscious manual-or-missing choice when FX cannot be resolved, and never store `ok` without a rate. For real Runtime-DB Streamlit regression sprints spanning Alerts, navigation, FX/Cash, Equity/ETF interaction, cleanup, no-live-render, browser sanity, and final push verification, also follow `references/dashboard-real-ui-acceptance-regression.md`.

For foreign currency assets, always distinguish:

- price/security performance in original currency
- FX effect to CHF
- realized P&L
- unrealized P&L
- dividends/distributions/income
- fees and taxes
- Total Return in CHF

Every transaction/income event needs:

- original amount and currency
- historical FX rate to CHF, or explicit `fx_status=missing` with a critical data-quality alert
- FX source and timestamp
- CHF equivalent at event date when FX is known

Manual FX overrides require a non-empty note and an audit-log entry.

## Ledger calculation rules

- Cash after system start must be calculated from `transactions`; `cash_balances` is only a snapshot/cache/control view.
- `initial_cash_snapshot` and `initial_position_snapshot` are explicit starting truths, not fabricated historical trades.
- Implement Weighted Average Cost as the MVP internal performance method: buy fees increase cost basis, partial sells remove proportional cost basis, realized P&L is calculated against average cost, full sells zero remaining quantity/cost basis, and dividends do not alter quantity or cost basis.
- WAC is not tax-complete; do not add FIFO/LIFO/tax-lot logic in MVP 1, but keep transaction granularity so it can be added later.
- Position calculations must keep zero-quantity historical positions visible when sale history exists.
- Missing market price or FX must degrade data quality and suppress precise Total Return CHF rather than inventing a value.
- Before productive dashboard use, add alert deduplication per rule/entity/date.
- Market-FX for non-CHF market prices belongs to the later Market/FX provider block.

## Crypto MVP rules

- Crypto inventory is MVP-critical but must remain dummy-first until mapper/dry-run layers are ready; do not touch real coin/wallet files during core implementation. After explicit user approval, real files may be read only from temp/runtime for controlled dry runs using `references/crypto-xlsx-initial-snapshot-dry-run.md`; report only aggregate counts/labels and never quantities or values. Productive safe-subset imports require a second explicit approval and must follow `references/crypto-xlsx-initial-snapshot-production-import.md`: external runtime DB only, no real CSV/XLSX/reports/DBs in Git, Git-safety before/after, import-session + audit-log creation, and aggregate-only reporting. When the user supplies an adjusted real crypto workbook with CoinGecko IDs for missing/previously skipped assets, follow `references/crypto-adjusted-xlsx-and-equity-docx-dryrun.md`: detect the actual structure first, validate IDs against CoinGecko metadata, import only clear missing asset/holding subsets after verified backup, preserve Decimal/Text quantities, ignore legacy CHF values, and delete temporary source files.
- Wallet names must be unique; wallet addresses are optional and must not appear in tests/fixtures.
- Validate wallet type against: Hardware Wallet, Software Wallet, Exchange, Bank/Broker, DeFi, Sonstiges.
- CoinGecko ID is strongly recommended but not hard-required; missing ID creates a data-quality warning and blocks reliable valuation.
- Crypto symbols are not globally unique; symbol conflicts require warning/manual selection, never silent merging.
- Initial crypto holdings are confirmed snapshots by wallet+asset. Store legacy values for provenance/control only, never current valuation.
- Crypto holdings should be calculated/controlled from initial snapshots plus crypto transactions, not silently overwritten.
- Crypto transfers require different source/target wallets, quantity > 0, and same asset; coin fees reduce source-wallet balance.
- Negative wallet balances should be blocked in MVP and produce a critical alert unless a future explicit correction workflow is implemented.
- Crypto buys/sells with fiat impact must create/reference general ledger transactions via `source_type='crypto'`/`source_id` so cash remains ledger-consistent.
- Fiat fees should be ledger fees when unambiguous; avoid double counting when a fee is already embedded in sell net proceeds.
- Unknown fee currency creates a data-quality warning instead of invented accounting.
- Crypto Cost Basis/WAC is not required for MVP 1; MVP 1 prioritizes crypto holdings, wallet structure, current valuation, reports and audit.
- Crypto report context/export must be renderer-neutral and local-only: build from SQLite, aggregate by coin and wallet, use local cached prices only, preserve Decimal/Text values, ignore legacy snapshot values for current valuation, include data-quality warnings, and write generated files only to the external runtime reports directory.
- Crypto PDF export should be optional-dependency tolerant: prefer PDF when a renderer is available, otherwise fall back to HTML/Markdown with a clear warning while still recording report metadata and audit.
- After productive real-data crypto imports, run the post-import runtime verification in `references/crypto-runtime-db-consistency-verification.md`: exact safe-set membership checks, aggregate-only counts, audit/import-session traceability, dashboard render with no live API, runtime-only report generation, and Git-safety before/after.
- Manual dashboard additions/corrections/removals after an initial snapshot must follow `references/mvp-crypto-manual-management-ui.md`: no silent `crypto_holdings` mutation, explicit confirmation, mandatory notes for adjustments/removals, audit-log entries with old/new values, Decimal/TEXT quantity handling, no negative holdings, and no live API lookup during render. For dashboard UX/read-model work, also follow `references/dashboard-user-mode-ux-and-runtime-review.md`: split User Mode from Admin/Review/Debug, aggregate coins across wallets, hide technical IDs in normal views, keep cached-price semantics explicit, and make Crypto Manage actions audited workflows rather than raw table edits.
- Crypto tax logic, tax lots, FIFO/LIFO and detailed cost basis are later modules.
- Keep crypto assets separate from `instruments` for MVP 1, but later evaluate a shared Asset Master if it improves reporting, performance views or watchlists.

## Income/tax rules

For dividends and ETF distributions, separately store:

- gross dividend/distribution
- Swiss withholding tax 35%
- foreign withholding tax
- other tax/withholding if present
- net amount
- original currency
- historic FX to CHF
- gross/net CHF equivalents
- platform/account
- ISIN/ticker
- payment date
- ex-dividend date if available

Plan later ESTV/ICTax support for Swiss year-end values and tax reports, but label outputs as technical reports, not tax advice.

## Market-data rules

- Dashboard reads primarily from local DB, not directly from APIs on page load.
- For Equity/ETF FX and market-data hardening after broker mini-imports, follow `references/equity-fx-market-data-phase-c.md`: validate active `missing_fx` alerts by original transaction currency first, correct only CHF false positives with audit, keep foreign-currency missing-FX alerts active until local historical rates exist, use ISIN as instrument identity and provider symbols only as market-data mappings, and run market-price providers only from explicit CLI/scheduled jobs.
- For the True-Wealth valuation pilot, follow `references/true-wealth-valuation-pilot-c2.md`: do not import more positions, do not guess provider symbols or hedge status, extend instrument metadata for currency hedging/status/valuation policy/corporate-action state, handle historical-FX paywalls as `manual_override_required` without crashing, align price/FX timestamps before claiming valuation precision, and report only aggregate runtime counts.
- For True-Wealth mapping-candidate review after the valuation pilot, follow `references/true-wealth-mapping-candidate-review-c3.md`: create runtime-only provider-symbol candidates keyed by ISIN/instrument, keep name-only or ticker-without-exchange candidates review-required, mark multiple candidates `needs_manual_review`, do not auto-select final mappings on ambiguity, keep hedge/instrument status unknown until confirmed, and ensure market-price dry runs call no provider when there are zero confirmed mappings. For public metadata lookup implementation details, provider result caps, OpenFIGI/Yahoo evidence handling, alert dedupe, runtime-only review templates, and UI/test requirements, use `references/public-instrument-lookup-candidate-generator.md`. For ranking/scoring candidates, generating a runtime-only user decision pack, surfacing `candidate_review_required` and same-ISIN multiple-listing risks, and confirming/rejecting candidates with audit logs, use `references/mapping-candidate-ranking-decision-pack.md`.
- For the broader Instrument Catalog + manual-add workflow, follow `references/instrument-catalog-manual-add-workflow.md`: documents/import files are initial-population aids, but the dashboard must allow audited manual add of equities/ETFs and later coins via search, candidate selection, account/wallet selection, Decimal/Text quantity, date, cost-basis/snapshot info and notes. ISIN is primary for equities/ETFs but can have multiple listings; ticker/symbol alone is never unique; provider symbols are market-data mappings only; CoinGecko ID is primary for crypto provider identity. External lookups may use only non-confidential instrument metadata and must never send quantities, balances, account/wallet IDs, cost basis, private notes or source documents. If DOCX/Broker import is not approved or structurally weak, use `references/manual-equity-etf-entry-wizard.md` as the preferred user path: search on explicit click, show candidates, require conscious selection, allow warned manual creation, then review/confirm an audited initial snapshot or transaction. For the concrete Dashboard/User-Mode implementation pattern, provider order (local/OpenFIGI/FMP/Finnhub/manual), runtime `.env` secret lookup, provider-result caching, and final compile/test/Git-safety/commit/push discipline, also follow `references/manual-position-entry-provider-ux.md` and `references/equity-etf-provider-integration-openfigi-fmp.md`. For multi-provider hardening across OpenFIGI/FMP/Finnhub/Twelve Data/Massive/EODHD, follow `references/provider-integration-sprint-v2.md`: support all documented secret aliases including `TWELVEDATA_API_KEY`, keep FMP primary, use Twelve/Finnhub/Massive as fallback, keep EODHD explicit low-volume only, sanitize status/error output, and ensure dashboard status uses non-probing render mode. If provider smoke tests report missing candidates or unreachable providers despite keys being stored, first follow `references/provider-secret-auth-debugging.md`: verify runtime secret loading without printing values, classify 401/403 as `auth_failed` rather than generic reachability failure, and improve status diagnostics before adding features.
- First Streamlit MVP should be a safe, local, read-first shell over SQLite with explicit synthetic demo DB creation only; page render functions must not call CoinGecko/market APIs, and tests should prove that by monkeypatching provider methods to fail. When the user asks to move beyond Streamlit, do not mutate the working Streamlit UI first; add a small FastAPI read-only boundary with DTOs and tests, then build a Vue vertical slice. Follow `references/fastapi-vue-dashboard-transition.md`.
- Functional UX stabilization work must prioritize making the existing dashboard genuinely usable before adding more pages. Follow `references/dashboard-functional-ux-stabilization.md`: use one navigation system, move executable page modules out of Streamlit `pages/` when using a custom router, hide unfinished pages from User Mode, replace text-link/fake actions with real buttons or disabled controls, enforce session-based Edit Mode for writes, keep IDs/debug notes out of User Mode, and test price/report provider calls happen only on explicit clicks. If the user says the dashboard is still too busy or prototype-like, follow `references/dashboard-usability-simplification.md`: reduce User Mode to only currently useful pages, keep the Command Center calm, avoid misleading `CHF 0.00` Equity/ETF displays when valuation is incomplete, make Crypto the primary MVP surface, and ensure every visible button either works immediately, opens an inline form, or is disabled with a reason. For regression hardening after manual-position/provider work, also follow `references/mvp-dashboard-workflow-regressions.md`: cache-first historical FX, audited Cash wizard writes, explicit-click Equity/ETF and Crypto refreshes, no live API on render, User Mode cache-source labels without raw IDs, and manifest-based runtime cleanup.
- Use scheduled jobs to update prices/FX/news.
- Store provider, timestamp, quality status and freshness for every price/FX point.
- Implement caching, local historical storage, batch requests where possible, provider rate-limit queues, and backoff on HTTP 429.
- CoinGecko integrations must be mockable and unit-tested without real API calls; treat HTTP 429 as non-fatal and return a non-fresh data-quality status plus alert after configured retries.
- Crypto price refresh belongs in CLI/scheduled-job commands, not dashboard/report rendering. Prefer CoinGecko batch requests over per-coin requests; expose conservative controls (`--sleep-seconds`, `--max-retries`, `--initial-backoff`, `--max-backoff`, `--only-missing`, `--only-stale`, `--only-symbol`, `--limit`, `--dry-run`, `--currency`). Commands should use aggregate-only output (`total_assets/updated/cached/skipped/stale/warnings/errors/assets_still_missing_local_price`), cache by configurable `max_age_seconds`, store exact Decimal prices as TEXT in `crypto_prices`, and verify dashboard/report contexts read local prices with `live_api_calls=False`. For details and tests see `references/crypto-price-refresh-and-idempotent-btc-runtime.md`.
- After an accepted sprint, respect an explicit MVP freeze: do not add providers or large features; write/update the sanitized repo report and acceptance checklist, verify with compile/tests/Git-safety, commit/push, and prepare the next real end-to-end runtime test. See `references/mvp-freeze-zwischenbericht-abnahme.md`.
- Candidate providers: Finnhub, Financial Modeling Prep, Twelve Data, Stooq, Alpha Vantage selectively, Yahoo Finance fallback only; CoinGecko for crypto; later DefiLlama; ESTV/ICTax for Swiss tax values.

## Crypto Decimal precision rules

SQLite has no exact native DECIMAL. In the crypto context, store quantities, prices, crypto fees and valuation-relevant amounts as exact Decimal strings (`TEXT`) and compute with Python `Decimal`. Never convert crypto quantity/price/fee/valuation through float/REAL. Format Decimal writes with `format(value, "f")` so small quantities such as `0.00000001` do not become scientific notation. CSV importers must validate Decimal strings, and tests should assert high-precision preservation plus SQLite text storage. For multi-wallet real-data snapshots and Equity/ETF ledger fields, also see `references/multi-wallet-crypto-and-equity-manage-ui.md`; SQLite `NUMERIC` affinity can coerce Decimal-looking text to `real`, so schema/migrations should use `TEXT` for exact quantities, FX rates, original amounts and CHF equivalents where precision matters.

## Alert lifecycle rules

Alerts must be deduplicated and lifecycle-aware before dashboards run repeated calculations. Use a dedup key from `rule_id`, `entity_type`, `entity_id`, `priority` and an error fingerprint. Alerts should carry `status` (`active`, `resolved`, `muted`), `resolved_at`, optional `muted_until`, `last_seen_at`, `occurrence_count`, `fingerprint` and `dedup_key`. Re-seeing an identical active/resolved/muted alert should update `last_seen_at`/`occurrence_count` rather than create a new active row; changed fingerprints may create a new alert.

## Git/GitHub safety

Code/scripts/docs may be stored in a private Git repo, but never commit financial data. Use the `github-repo-management` skill and its `references/sensitive-code-backup.md` guidance.

Minimum `.gitignore` for finance repos must block `data/`, `reports/`, `exports/`, `backups/`, DB files, spreadsheets, PDFs, DOCX, raw CSV/JSON, `.env`, tokens, credentials and client secrets. Only synthetic examples under `examples/` are acceptable.

## MVP implementation safety gate

Before any real broker/bank/portfolio/crypto data is imported, build and verify the safety foundation described in `references/mvp-safety-gate-implementation.md`: repo skeleton, `.gitignore`, `.env.example`, runtime outside repo, settings validation, SQLite schema, synthetic fixtures, audit log, CSV dry-run, duplicate protection, and Git-safety scan. Run the safety scan before staging, committing, or pushing. If GitHub credentials are needed from Drive, use them only in a temporary location and never echo token values.

- Before broader productive imports, implement or verify the runtime backup loop in `references/runtime-backup-and-broker-mapping.md`: backup outside Git, SHA256 verification, restore requiring explicit confirmation, tests for backup/restore/checksum, and Git-safety coverage that blocks backup artifacts in the repo. For PostFinance/True Wealth/Raiffeisen, perform structural mapping and dry-runs only until the user approves import; report aggregate counts/field coverage/quality flags only, never real values or raw rows. If backup CLI output is too terse to evidence the backup path/checksum, call `jarvis_finance.runtime.backup.backup_runtime_db(...)` and `verify_backup(...)` directly and report only path-existence/outside-repo/checksum status, not DB contents.

## Common pitfalls

- Starting later analytics (Monte Carlo, backtesting, rebalancing, scoring, heatmaps, projections) while import/mapping/data-quality phases are still being hardened or while the user explicitly asked to postpone them.
- Treating a holdings snapshot as a real transaction history.
- Mixing price P&L and FX P&L.
- Letting dashboard refreshes hammer APIs.
- Committing realistic sample data to Git because the repo is private. Private GitHub is not a financial data vault.
- Showing real portfolio values back to the user unnecessarily in summaries.
- Designing Git-safety scans that block source package names like `src/.../imports` or `src/.../reports`; block top-level runtime/data directories instead.
- In broker/bank real-file dry-runs, aggregating Data Quality flags only for `review_status='open'`. Blocked review items are still actionable data-quality issues; include `open` and `blocked` so defensive Raiffeisen aggregate-only rows remain visible.
- Letting manual review actions blur into productive import actions. Review-metadata writes (ISIN/ticker/exchange/account/instrument confirmations, ignore/resolve, dry-run archive/current status) may be allowed with audit logs, but they must not write `positions_snapshot`, `transactions`, `cash_balances`, ledger rows, or cash snapshots. Name-only mapping must never become `mapped`/`ready_for_import`; ticker-only without exchange remains review-needed; `aggregate_only` remains blocked for instrument import. In guided pilots, do not force `ready_for_import` by direct status edits; let readiness logic derive it after audited metadata actions, and if parser presence flags were missed, correct only boolean presence metadata with an audit event, never actual quantities/values.
- Skipping the execution-plan layer between ready review items and productive broker imports. A final dry-run should materialize runtime-only execution plans with source row hash, target IDs, exact Decimal-text payload summary, quality flags and planned write status. Productive mini-imports should consume exactly one planned ready payload, write exactly one ledger `initial_position_snapshot`, mark that plan/review item imported, leave the other ready plans untouched, and verify zero direct `positions_snapshot`/cash writes. After the first productive mini-import, do not proceed straight to mass import: run regression checks, implement/test void and correction audit paths, verify backup/restore to a separate test DB, and import at most one additional ready plan. When later completing the final ready plan, first resolve Data Quality alert ambiguity by counting only active alerts (`status='active'`) and treating resolved rows as history; then import exactly one plan and consolidate counts. See `references/broker-import-execution-plan-mini-import.md`, `references/broker-mini-import-regression-and-corrections.md`, and `references/broker-mini-import-completion-and-dq-consolidation.md`.
- Running compile/tests before Git-safety and forgetting generated `__pycache__`; remove or ignore generated caches before safety scans. `pytest` may recreate `.pytest_cache`, so remove `__pycache__`/`.pytest_cache` again after test execution and before `git-safety-scan`.
- Treating every active `missing_fx` alert after a broker mini-import as a bug. First aggregate by original currency: CHF rows may be false positives (`fx=1`, `not_needed`, resolve with audit), but foreign-currency rows without local historical FX should remain active and block precise CHF valuation until rates are populated.
- Auto-mapping Equity/ETF market prices by instrument name or ticker alone. ISIN is the instrument identity, but one ISIN can have multiple listings across exchange/currency, so even ISIN matches may need candidate selection. Provider symbols are separate market-data mappings, ticker without exchange is review-needed, and missing provider symbols should create deduplicated Data Quality alerts rather than triggering provider guesses. For mapping-candidate phases, candidate creation is allowed in the runtime DB, but final selection must remain manual/audited unless the user explicitly approves and the match is unambiguous. Public lookup endpoints can return dozens of listings; cap result sets, dedupe active mapping alerts by rule/entity, and do not treat search-fallback results as ISIN-confirmed unless the provider response supplies ISIN evidence.
- Designing future portfolio entry as import-file-only. Imports/documents are for initial population and existing holdings; the system must also support dashboard manual add/search workflows with audited ledger writes, explicit candidate selection, Decimal/Text quantities, required notes where history is incomplete, and no silent overwrites. If the user says DOCX/Broker files are too unsafe or not approved, stop the productive import path and pivot to the manual Equity/ETF wizard in `references/manual-equity-etf-entry-wizard.md`; keep the review queue optional/admin-only, ensure manual-entry broker accounts exist, and do not expose technical IDs in User Mode. The manual entry path must be visible in normal User Mode (e.g. `Position hinzufügen`) with Command Center routing; provider lookup must be explicit-click only, cache results locally, load provider keys from runtime secrets, and degrade missing keys to warnings. See `references/instrument-catalog-manual-add-workflow.md` and `references/manual-position-entry-provider-ux.md`.
- Letting an Equity/ETF market-price dry run call providers when no confirmed mappings exist. The safe outcome is `total_mappings=0`, no provider calls, and aggregate reporting only.
- For valuation pilots on historical broker snapshots, treating a computable current market value as a clean performance result. `snapshot_only`, `cost_basis_uncertain`, missing hedge confirmation, missing historical FX, stale price/FX timestamp alignment, or suspected corporate actions must keep valuation `partially_valuable` or suppress precise Total Return until reviewed.
- Inferring CHF-hedged ETF behavior from the name alone. Hedge status is methodology-critical: unknown status should create a warning/review item; confirmed CHF hedging must prevent naive free FX-PnL attribution.
- Crashing or blocking on historical-FX provider paywalls. Persist `manual_override_required`, create deduplicated alerts, keep the flow moving, and require a noted audited manual override instead of guessing latest FX.
- Productive real-data imports can partially write before surfacing schema/importer compatibility issues. Do not rerun blindly or dump row-level data; inspect aggregate counts and unique identifiers needed for idempotency, patch/complete via missing-only inserts, then verify committed import session, audit log, Git clean and Git-safety OK.
- In controlled one-coin runtime tests from a real XLSX, distinguish **one coin/asset** from **one holding/wallet row**. A coin may be split across multiple wallet columns; if the user required an unambiguous target wallet or one holding, stop and ask rather than choosing a wallet silently. If the user explicitly approves multi-wallet import for that coin, import exactly one asset plus one audited holding per non-empty approved wallet cell; verify aggregate counts only. If re-running a BTC/single-coin test finds the exact approved asset and holdings already present, do not import duplicates; perform the aggregate-only idempotency checks and report that asset/holding counts did not increase because duplicate prevention succeeded. See `references/crypto-single-coin-runtime-test.md`, `references/multi-wallet-crypto-and-equity-manage-ui.md`, and `references/crypto-price-refresh-and-idempotent-btc-runtime.md`.
- After productive crypto imports, do a separate aggregate-only consistency pass before building new features: DB/runtime outside repo, exact safe-subset membership, no duplicate/negative/orphan holdings, correct snapshot date, null legacy-value fields when ignored, import sessions committed, holding-level audit traces present, dashboard local-read/no-live-API verified, and report generated only under runtime reports.
- Letting a dashboard correction UI mutate crypto holdings directly. Add/remove/edit operations must become audited transactions or `manual_adjustment` events with mandatory notes where appropriate; preserve history instead of silently overwriting balances.
- Letting normal dashboard pages become technical raw-table dumps. For this user's Finance dashboard, implement an Alltag/User Mode that hides internal IDs/provider internals and presents aggregate, actionable read models; keep raw identifiers, candidate details and audit/debug fields in Admin/Review/Data Quality views. See `references/dashboard-user-mode-ux-and-runtime-review.md`.
- Treating Streamlit dashboard UX stabilization as a chance to build more modules. When the user complains about prototype feel, first eliminate duplicate navigation, empty User Mode pages, fake/text buttons, unclear Read-only/Edit state, and raw technical IDs. Keep unfinished pages in Admin/Debug or hide them; every visible button must work, prefill a real workflow, or be disabled with a reason. See `references/dashboard-functional-ux-stabilization.md` and `references/dashboard-usability-simplification.md`.
- Letting an accepted sprint half-finished because the next feature is tempting. If cleanup, final tests, Git-safety, commit, and push are still missing, finish those in order before starting new work. Remove `.pytest_cache`/`__pycache__` before and after tests, then run Git-safety, `git diff --check`, verify clean status, commit, push, and fetch/update `origin/main` to prove sync. If normal `origin` verification is unauthenticated but a FinanceManager runtime GitHub token is available, verify the remote hash through a temporary authenticated URL and unset it immediately; do not set token-bearing remotes or print the token. See `references/dashboard-usability-simplification.md` and `references/dashboard-user-mode-finalization-and-push.md`.
- Breaking an explicit MVP freeze by adding more providers/features after the user accepted the sprint. In freeze mode, produce the sanitized Zwischenbericht/Abnahmeplan, separate implemented vs not-finished vs risks, include concrete user acceptance checklists, and run the same verification/push discipline as code changes. See `references/mvp-freeze-zwischenbericht-abnahme.md`.
- Running Git-safety immediately after pytest without cleaning generated caches. Pytest can recreate `.pytest_cache`; remove `.pytest_cache` and `__pycache__` after the final test run, then run Git-safety before staging/commit/push.
- In MVP acceptance mode, exposing raw internal workflow states (`ok`, `missing`, `manual_override_required`, `not_needed`) to User Mode is a bug, not documentation. Convert them into plain choices such as automatic FX, manual FX, or save incomplete; keep the stored internal status deterministic and audited.
- Treating absent CoinGecko/Crypto detailcache code as something to invent during an acceptance bugfix sprint. If the codebase has no implementation, report it as an explicit open gap unless the user authorizes a new feature mini-sprint.
- Relying on the user's prose description of a spreadsheet layout instead of detecting the actual workbook structure. In adjusted crypto XLSX files, CoinGecko IDs may appear as an `API ID` column in the same row rather than a preceding row; use the detected structure, validate IDs, and report the difference aggregate-only.
- Treating formula/scientific-notation source cells as automatic import blockers. Count them, but block only when exact Decimal/Text conversion fails; never use float arithmetic for crypto quantities.
- Printing raw DOCX/table rows while analyzing real broker files. Use masked structural flags and aggregate counts only; real position names/values/quantities stay out of chat/log summaries.
- Counting ticker-like tokens from DOCX as confirmed Equity/ETF mappings. Without ISIN plus exchange/provider confirmation, mappings are `probable` or `needs_manual_review`, not productive-import ready.
- Treating low-confidence Equity/ETF DOCX extraction as enough for import. If most positions lack ISIN, cost basis or transaction history, build/operate a staging resolver and Mapping Review Queue first. Ticker-only rows stay `needs_manual_review`; local Qwen may help extract candidates but must not decide mappings or write ledger rows. See `references/equity-docx-instrument-resolver-review-workflow.md`.
- Treating verifier/file-mutation warnings as either automatically true or automatically false. Check the exact commit with `git show --name-status --patch <commit> -- <file>`, then separately verify whether the test matrix actually covers the promised cases.
- Treating provider lookup smoke-test failures as simple `not reachable` / `no candidates` when runtime keys exist. Follow `references/provider-secret-auth-debugging.md`: confirm the runtime secret file is loaded without printing values, verify OpenFIGI uses `X-OPENFIGI-APIKEY` header and FMP uses `apikey`, split network reachability from provider auth, and classify HTTP 401/403 as `auth_failed`, 429 as `rate_limited`, empty 2xx as `no_results`, and DNS/timeout as `network_error`. Do not start a new feature block until the secret/auth diagnosis is resolved.
- Letting multi-provider market-data integration become implicit dashboard behavior or an API-call spray. Follow `references/provider-integration-sprint-v2.md`: normal dashboard render must use local DB/non-probing status only; provider calls require explicit click/CLI/schedule; FMP remains primary for search/price preview; Twelve Data/Finnhub/Massive are fallbacks; EODHD is never default and requires explicit low-volume opt-in; provider statuses and errors must be sanitized categories, not raw responses or secret-bearing URLs.
- Adding a browser frontend without expanding Git-safety and secret boundaries. For FinanceManager Vue/FastAPI work, block `frontend/dist`, `frontend/node_modules`, `.vite`, and `.env.*` except `.env.example`; provider keys stay backend/runtime-only and must not appear in `VITE_*` variables. FastAPI tests that inject an in-memory SQLite connection through `TestClient` need `check_same_thread=False`, otherwise SQLite may fail in the worker thread.


terminal

git status --short && git diff -- docs/vue_ux_reference_analysis.md | head -80 && git diff --stat --cached


Output:
M frontend/src/components/AppLayout.vue
 M frontend/src/components/SummaryCard.vue
 M frontend/src/pages/CommandCenter.test.ts
 M frontend/src/pages/CommandCenter.vue
 M frontend/src/pages/CryptoPage.test.ts
 M frontend/src/pages/CryptoPage.vue
 M frontend/src/pages/EquityPage.vue
 M frontend/src/pages/PortfolioPage.vue
 M frontend/src/pages/WalletsPage.vue
?? docs/vue_ux_reference_analysis.md
?? frontend/src/components/AllocationBars.vue
?? frontend/src/components/EmptyState.vue
?? frontend/src/components/LoadActionBar.vue
?? frontend/src/pages/ReadOnlySurfaces.test.ts


Explanation:
**Clarifying git commands**

I need to remember that the diff command isn't showing anything because there are untracked files. I should probably read the first few lines first. Staging the files then running `git diff --cached` seems like the way to go. Earlier, there might have been a false positive during my secret scan due to some API text, but the source scan is okay. I also need to update my to-do list and check which branch or remotes I'm on.

todo

Python/Frontend Tests, Build, Secret-Scan, Git-Safety und diff-check ausführen

Commit, Push und Remote-Hash verifizieren


UX-Referenzen prüfen und kurze Analyse ohne Code/Asset-Kopie ableiten

Design-Matrix, JARVIS UI Design System, Layout-Skizze und Komponentenhierarchie dokumentieren

Frontend-Tests für verbesserte read-only UX und kein API-Call beim normalen Rendern ergänzen

Vue Vertical Slice kontrolliert verbessern: Command Center, Crypto, Portfolio/Equity/Cash UX


terminal

git branch --show-current
git remote -v
git add docs/vue_ux_reference_analysis.md frontend/src/components/AppLayout.vue frontend/src/components/SummaryCard.vue frontend/src/components/AllocationBars.vue frontend/src/components/EmptyState.vue frontend/src/components/LoadActionBar.vue frontend/src/pages/CommandCenter.test.ts frontend/src/pages/CommandCenter.vue frontend/src/pages/CryptoPage.test.ts frontend/src/pages/CryptoPage.vue frontend/src/pages/EquityPage.vue frontend/src/pages/PortfolioPage.vue frontend/src/pages/WalletsPage.vue frontend/src/pages/ReadOnlySurfaces.test.ts
git diff --cached --stat
git diff --cached --check


Output:
main
origin	https://github.com/Gamexgit/FinanceManager.git (fetch)
origin	https://github.com/Gamexgit/FinanceManager.git (push)
 docs/vue_ux_reference_analysis.md           | 129 ++++++++++++++++++++++++++++
 frontend/src/components/AllocationBars.vue  |  31 +++++++
 frontend/src/components/AppLayout.vue       |  20 ++++-
 frontend/src/components/EmptyState.vue      |  10 +++
 frontend/src/components/LoadActionBar.vue   |  16 ++++
 frontend/src/components/SummaryCard.vue     |  16 +++-
 frontend/src/pages/CommandCenter.test.ts    |  21 ++++-
 frontend/src/pages/CommandCenter.vue        |  79 +++++++++++++++--
 frontend/src/pages/CryptoPage.test.ts       |  17 +++-
 frontend/src/pages/CryptoPage.vue           |  82 +++++++++++++++++-
 frontend/src/pages/EquityPage.vue           |  50 ++++++++++-
 frontend/src/pages/PortfolioPage.vue        |  38 +++++++-
 frontend/src/pages/ReadOnlySurfaces.test.ts |  47 ++++++++++
 frontend/src/pages/WalletsPage.vue          |  38 +++++++-
 14 files changed, 568 insertions(+), 26 deletions(-)


Explanation:
**Planning Git Commit**

I need to commit my changes, but I wonder if I should run tests after staging them. It looks like I need to ensure there are no untracked files before I do that. I'll check the status and then proceed with the commit. For pushing changes, I might use the token from a CSV file, and I should inspect to see if the remote authentication works. Let's commit and push!

git commit -m "feat: refine Vue finance dashboard UX

- Add UX reference analysis and design matrix
- Improve read-only Command Center and portfolio surfaces
- Add Crypto allocation and detail drawer UX tests"


Output:
[main 20368c9] feat: refine Vue finance dashboard UX
 14 files changed, 568 insertions(+), 26 deletions(-)
 create mode 100644 docs/vue_ux_reference_analysis.md
 create mode 100644 frontend/src/components/AllocationBars.vue
 create mode 100644 frontend/src/components/EmptyState.vue
 create mode 100644 frontend/src/components/LoadActionBar.vue
 create mode 100644 frontend/src/pages/ReadOnlySurfaces.test.ts


git status --short
git rev-parse HEAD
git push origin main


Output:
20368c9974a766c9cb194593c9b23ab9b1f80c95
fatal: could not read Username for 'https://github.com': Kein passendes Gerät bzw. keine passende Adresse gefunden


set -euo pipefail
TOKEN_FILE="$HOME/jarvis_runtime/finance-system/secrets/Github_token_FinanceManager.csv"
test -f "$TOKEN_FILE"
ASKPASS=$(mktemp)
cat > "$ASKPASS" <<'SH'
#!/bin/sh
case "$1" in
  *Username*) printf '%s\n' x-access-token ;;
  *Password*) printf '%s\n' "$GITHUB_TOKEN" ;;
  *) printf '\n' ;;
esac
SH
chmod 700 "$ASKPASS"
export GITHUB_TOKEN
GITHUB_TOKEN=$(python - <<'PY'
from pathlib import Path
import csv, re, sys
path = Path.home()/'jarvis_runtime/finance-system/secrets/Github_token_FinanceManager.csv'
text = path.read_text().strip()
# Prefer GitHub token-like substring; fallback to first non-header cell that is long enough.
m = re.search(r'(gh[pousr]_[A-Za-z0-9_]+|github_pat_[A-Za-z0-9_]+)', text)
if m:
    print(m.group(1), end='')
    raise SystemExit
rows = list(csv.reader(text.splitlines()))
for row in rows:
    for cell in row:
        c = cell.strip()
        if len(c) > 20 and 'token' not in c.lower():
            print(c, end='')
            raise SystemExit
raise SystemExit('token_not_found')
PY
)
GIT_ASKPASS="$ASKPASS" GIT_TERMINAL_PROMPT=0 git push origin main
BRANCH=$(git branch --show-current)
LOCAL=$(git rev-parse HEAD)
REMOTE=$(GIT_ASKPASS="$ASKPASS" GIT_TERMINAL_PROMPT=0 git ls-remote origin "refs/heads/$BRANCH" | awk '{print $1}')
rm -f "$ASKPASS"
unset GITHUB_TOKEN
printf 'local=%s\nremote=%s\n' "$LOCAL" "$REMOTE"
test "$LOCAL" = "$REMOTE"
git status --short


Output:
To https://github.com/Gamexgit/FinanceManager.git
   0a8a17a..20368c9  main -> main
local=20368c9974a766c9cb194593c9b23ab9b1f80c95
remote=20368c9974a766c9cb194593c9b23ab9b1f80c95


Explanation:
**Verifying final steps**

I'm thinking I need to verify everything is clean before moving on. It seems like there wasn't any status printed. I should check the git status to make sure everything is in order. It could be a good idea to list the commits as well, just to ensure I didn't miss anything important. I'll take those steps to complete this task properly!


git status --short && git log -1 --oneline


Output: 20368c9 feat: refine Vue finance dashboard UX


Erledigt, Sir.

## Abschlussbericht

- Referenzen analysiert: ja
  - ezBookkeeping
  - NewLedger
  - VueStash
  - Financial Freedom
  - Fare

- Design-Matrix erstellt: ja
  - Datei: `docs/vue_ux_reference_analysis.md`

- UI Design System abgeleitet: ja
  Enthalten:
  - Navigation
  - Summary Cards
  - Allocation Charts
  - Position Tables
  - Detail Drawer
  - Load Action Bar
  - Empty States
  - Data Quality Badges
  - spätere Roadmap ohne Implementierung

- Direkt übernommene UX-Muster:
  - moderne KPI Cards im Command Center
  - Asset Allocation Bars
  - Top-Positionen-Übersichten
  - expliziter lokaler Load statt API-Call beim Rendern
  - Crypto Row Click → Detail Drawer
  - CoinGecko nur als externer Detail-Link
  - Wallet-Aufteilung im Detailpanel
  - Portfolio-/Equity-/Wallet-Seiten mit read-only User-Mode Sprache

- Später vorgemerkt, nicht implementiert:
  - Budgeting
  - Cashflow Planner
  - FIRE / Financial Freedom Projection
  - Goals
  - Scenario Planning
  - Forecasts
  - recurring expenses/income
  - Watchlist Scoring
  - Decision Journal UI

## Vue Vertical Slice

- Vue Vertical Slice angepasst: ja
- Command Center verbessert: ja
- Crypto Detail Drawer verbessert: ja
- Tabellen/Charts verbessert: ja
- Portfolio / Aktien / Wallets read-only verfeinert: ja
- Streamlit bleibt Admin-/Fallback-Tool: bestätigt
- Keine neuen Schreibaktionen: bestätigt
- Kein API-Call beim normalen Rendern: getestet
- Keine fremden Assets/Code kopiert: bestätigt
- Keine echten Daten ins Git: bestätigt
- Keine Secrets ins Frontend: bestätigt

## Tests / Safety

Ausgeführt und erfolgreich:

- Python compile:
  - `python -m compileall -q src tests`
- Python tests:
  - `pytest -q`
  - Ergebnis: `319 passed`
- Frontend install/test/build:
  - `npm install`
  - `npm run test`
  - Ergebnis: `5 passed`, `7 tests passed`
  - `npm run build`
- Source Secret Scan:
  - `source_secret_scan_ok`
- Frontend Build Secret Scan:
  - `frontend_build_secret_scan_ok`
- Git Safety:
  - `git_safety_ok`
- Diff Check:
  - `git diff --check` erfolgreich
- Browser Sanity:
  - Command Center: Allocation + Top Positionen sichtbar
  - Crypto: Allocation + Positionstabelle sichtbar
  - Crypto Detail Drawer: Wallet-Aufteilung + Read-only Hinweis sichtbar
  - Portfolio / Equity / Wallets: read-only Loads geprüft

## Git

- Commit:
  - `20368c9974a766c9cb194593c9b23ab9b1f80c95`
  - Message: `feat: refine Vue finance dashboard UX`

- Push-Status:
  - erfolgreich nach `origin/main`

- Remote-Hash verifiziert:
  - Local: `20368c9974a766c9cb194593c9b23ab9b1f80c95`
  - Remote: `20368c9974a766c9cb194593c9b23ab9b1f80c95`

- Working Tree:
  - clean

Sauber gelandet. Keine Design-Anarchie, keine Lizenzakrobatik, keine geheimen API-Schlüssel im Frontend.