# Broker Mini-Import Completion and Data-Quality Consolidation

Use after the first broker mini-import regression/void-correction phase when the user approves finishing the remaining small set of ready execution plans. This captures the Phase B6d pattern: complete the final True Wealth ready item one-at-a-time, clean stale crypto alert interpretation, and consolidate import/Data Quality status without exposing real values.

## Preconditions

- Productive broker imports are still **one-at-a-time**; no mass import.
- `broker_import_execution_plans` exists and ready plans have already passed manual review/readiness gates.
- Safe correction/void workflow is implemented or at least tested for imported initial snapshots.
- Runtime DB is outside Git and Git-safety is clean before/after.
- Reports to the user remain aggregate-only: no quantities, prices, balances, raw row labels, account details, or file contents.

## Crypto stale-alert cleanup before further broker imports

Before importing the next broker plan, resolve possible stale market-data alert confusion:

1. Count **active** crypto stale/missing price alerts by `status='active'`, not historical rows.
2. Count resolved historical stale alerts separately; do not report resolved rows as active problems.
3. Count active crypto assets with fresh local CHF prices using the data-quality helper/CLI semantics.
4. Run:

```bash
PYTHONPATH=src python -m jarvis_finance.cli.main check-data-quality --scope crypto --resolve-fixed --currency CHF
```

5. If active stale alerts remain because prices are actually missing/stale, run the conservative CLI price refresh job (not dashboard/report live calls) and rerun `check-data-quality --resolve-fixed`.
6. Report only aggregate counts:
   - active stale alerts before/after
   - newly resolved count
   - already-resolved historical count if relevant
   - active crypto assets
   - assets with fresh local CHF price
   - warnings/errors

### Pitfall

A query like `SELECT COUNT(*) FROM alerts WHERE rule_id='crypto_price_stale'` can count resolved alert history and falsely imply active stale alerts. Always filter by `status='active'` for current DQ problems.

## Final ready broker mini-import

For exactly one remaining ready plan:

1. Create runtime DB backup and verify checksum.
2. Record before-counts for:
   - broker reviewed snapshot transactions
   - `positions_snapshot`
   - `cash_balances`
   - remaining planned ready execution plans
3. Select exactly one plan:

```sql
SELECT execution_plan_id
FROM broker_import_execution_plans
WHERE source_platform='True Wealth'
  AND payload_status='ready'
  AND execution_status='planned'
ORDER BY created_at, execution_plan_id
LIMIT 1;
```

4. Execute through the reviewed execution-plan service, not ad-hoc SQL:
   - write one `transactions` row only
   - `transaction_type='initial_position_snapshot'`
   - `source_type='broker_import_reviewed_snapshot'`
   - mark execution plan imported
   - mark review item imported
   - write audit events
5. Verify exactly one transaction delta, zero `positions_snapshot` delta, zero cash delta, and no other platforms imported.

## Consolidated post-import checks

After the final ready mini-import, verify all imported rows in aggregate:

- all have `account_id`, `instrument_id`, Decimal-parseable `quantity`
- all have `source_type='broker_import_reviewed_snapshot'`
- all link to `execution_plan_id` and `review_item_id`
- all linked execution plans have `execution_status='imported'`
- all linked review items have `review_status='imported'`
- audit event count is at least two events per import if using execute + mark-review audit pattern
- duplicate counts are zero for:
  - execution plan/source ID
  - row hash
  - active `account_id + instrument_id + snapshot_date` tuple, where meaningful
- ledger position calculation returns expected imported position count
- Portfolio/Equity dashboard read-model sees the same count
- precise Total Return/Performance count remains zero when FX, prices, or cost basis are missing
- no direct rows in `positions_snapshot` or `cash_balances` unless explicitly approved for other workflows

## Review Queue / DQ consolidation

Summarize platform state in aggregate:

- True Wealth: imported count, ready/planned count, open/not_ready count, open/review_needed count
- PostFinance: confirm unchanged and not imported
- Raiffeisen: confirm aggregate-only/blocked items remain unimported
- Alerts: separate active vs resolved; expected active broker DQ warnings are usually `missing_fx` and `missing_market_price`; `cost_basis_uncertain` and `snapshot_only` may live in execution-plan/import-payload quality flags rather than active alert rows.

## Final safety commands

```bash
PYTHONPATH=src python -m compileall -q src tests
PYTHONPATH=src pytest -q
rm -rf .pytest_cache src/jarvis_finance/**/__pycache__ tests/**/__pycache__
PYTHONPATH=src python -m jarvis_finance.cli.main git-safety-scan .
git status --short --branch
```

If only runtime DB changed, do not commit. If code changed, commit and push after tests and Git-safety.

## Recommended next-phase choice

After three clean True Wealth mini-imports, prefer starting the Equity/ETF FX/Market-Data module before mapping/importing many more broker rows, because otherwise additional imports mainly increase `missing_fx`, `missing_market_price`, `cost_basis_uncertain`, and `snapshot_only` warnings without improving analytical usefulness.