# Crypto Runtime DB Consistency Verification

Use after a productive crypto initial-snapshot import or after any recovery from an importer/schema compatibility issue. The goal is to prove the external runtime SQLite DB is consistent without exposing real quantities, values, wallet addresses, CSV rows, or report contents.

## Non-negotiables

- Do not build new features during verification.
- Do not print real quantities, CHF values, wallet addresses, raw rows, generated report contents, or real file contents in chat.
- The productive DB and generated reports must be under the configured runtime path outside the Git repo.
- Remove generated `__pycache__` / `.pytest_cache` before Git-safety checks so generated cache files do not pollute results.
- Run `git status --short` and `PYTHONPATH=src python -m jarvis_finance.cli.main git-safety-scan .` before and after checks.

## Verification workflow

1. **Runtime/Git safety**
   - Resolve repo root, runtime base, DB path, and reports dir.
   - Assert runtime base, DB path, and reports dir are outside the repo.
   - Search the repo for non-synthetic `.csv`, `.xlsx`, `.xls`, `.pdf`, `.sqlite`, `.sqlite3`, `.db` files; allow only known synthetic/example/test fixtures.

2. **Import consistency**
   - Report aggregate counts only: wallets, crypto assets, holdings, safe-subset assets, safe-subset holdings.
   - For each approved safe coin, report only the number of holdings, never quantity/value.
   - Assert zero duplicate holdings for `(asset_id, wallet_id)`.
   - Assert zero negative holdings.
   - Assert zero holdings with null/blank quantity.
   - Assert zero holdings without wallet or without asset.
   - Assert zero imported holdings for ignored coins or manual-review coins.
   - Assert all initial snapshot rows have `legacy_snapshot_date` / verification date matching the confirmed snapshot date.
   - Assert legacy CHF/value fields are null when the user instructed legacy values to be ignored.
   - Assert every imported crypto asset has a CoinGecko ID.

3. **Safe-subset detection**
   - Prefer exact checks by approved `coingecko_id` and exact upper-case symbol, not broad substring scans.
   - Broad `LIKE '%term%'` scans can produce false positives (`POL` inside unrelated labels, legacy substrings in names, etc.). Use them only as an exploratory smoke test, then confirm with exact-ID/symbol queries before reporting a problem.

4. **Audit and import sessions**
   - Confirm committed wallet and holdings import sessions exist.
   - Confirm no `started`, `failed`, or `partial` sessions remain unless they are intentionally documented as technical intermediate artifacts.
   - Confirm audit log entries exist.
   - Confirm every imported holding has a matching `audit_log` entry for the initial snapshot action/entity.

5. **Dashboard local-read test**
   - Exercise the dashboard read model and crypto page against the real runtime DB.
   - Block network sockets or monkeypatch providers during render to prove no live API call is needed.
   - Report only aggregate row counts and whether rendering works.

6. **Report generation**
   - Generate the crypto inventory report only into the runtime reports directory.
   - Prefer PDF if the renderer exists; accept HTML fallback with a warning.
   - Record/report only: generated yes/no, format, reports directory, data-quality status, coin count, wallet count, and whether ignored/manual-review coins are absent.
   - Re-run Git-safety and Git status after generation.

## Expected aggregate final report shape

- Consistencyprüfung bestanden: ja/nein
- Anzahl Wallets / Assets / Holdings
- Probleme/Warnings count only
- Dashboard reads runtime DB: ja/nein
- Crypto report generated: ja/nein
- Report format and runtime reports directory only
- Git-safety result and Git status
- Open risks such as missing local prices or PDF-renderer fallback
- Whether the next feature step is safe to start

## Common pitfalls

- Reporting a broad substring scan as a real violation. Always confirm exact `coingecko_id`/symbol membership first.
- Treating missing local price data as import corruption. It is a data-quality warning unless current valuation was part of the import scope.
- Printing the generated report path with a unique filename is usually unnecessary; the runtime reports directory is enough for the chat summary.
- Letting the report/dashboard test call CoinGecko or market APIs during page load. Dashboard/report generation should use cached/local DB data only.