# Read-only Finance sprint code inventory

Use this workflow before designing a bounded finance sprint involving market data, FX, valuation snapshots, performance, policy benchmarks, risk, or scheduled refreshes.

## Scope and safety

- Confirm the exact repository/worktree and commit first; finish by proving the tree is unchanged.
- Inspect source, migrations, tests, docs, and frontend contracts only. Do not open runtime databases, reports, imports, credential files, or provider responses.
- Report schema and synthetic fixtures structurally; never reproduce production financial values, account identifiers, paths, tokens, or secrets.
- Distinguish implemented code from roadmap/docs language. A statement that scheduling is a responsibility is not evidence that a scheduler exists.

## Inventory matrix

Trace each capability end to end and name exact paths plus functions/classes:

1. **Market quotes:** provider protocol/classes, provider-selection order, refresh/store functions, cache/time-series tables, CLI commands, API routes, frontend clients, focused tests.
2. **FX:** primary/fallback order, historical-date behavior, cache lookup, manual override, persistence constraints, valuation consumers, CLI/API/UI triggers, tests. Call out Frankfurter explicitly when present.
3. **Snapshots:** all similarly named tables separately (instrument prices, FX, position snapshots, account totals, canonical versioned valuations, chart points). Identify writers, readers, uniqueness, immutability, supersession, and whether a table is canonical or legacy.
4. **Scheduler/jobs/locking:** search implementation and deployment surfaces for schedulers, timers, run tables, leases, lock files, and DB transaction locks. Do not infer a scheduler from CLI commands. Separate write-workflow `BEGIN IMMEDIATE` from a cross-process job lock.
5. **Performance:** trace pure math primitives through loaders/services, version constants, quality/reason codes, API schemas/routes, frontend rendering, and deterministic tests. Verify live providers are not called during calculation.
6. **Policy benchmark:** trace request/schema, validation, persistence, immutability/version lineage, API, editor/detail UI, and tests. Distinguish a policy benchmark from an instrument metadata `benchmark` field.
7. **Risk:** search for actual quantitative implementation (volatility, drawdown, Sharpe/Sortino, VaR, tracking error), not merely advisor risk labels. If absent, state the gap.

## Reuse assessment

For every area, classify findings as:

- **Reuse directly** — stable provider/store/math/API contract already exists.
- **Reuse with boundary fix** — useful implementation has side effects, mutability, or incomplete idempotency. Example: a valuation calculator that creates alerts and commits is not yet a pure scheduled-job primitive.
- **Gap** — no implementation exists.

Prefer one canonical pipeline:

- daily instrument quotes in the existing quote store;
- FX in the existing dated FX store;
- CHF valuation through the existing as-of price/FX logic;
- portfolio history in the existing immutable/versioned valuation model;
- benchmark and risk calculations on the same stored time series, `data_cutoff`, quality contract, and input fingerprint as TWR/MWR.

Do not recommend a second market, FX, valuation, or performance engine merely because the sprint needs orchestration.

## Important pitfalls

- A table named `positions_snapshot` may be mutable or written with `INSERT OR REPLACE`; do not equate it with an immutable performance snapshot without checking writers and triggers.
- Append-only crypto quote history may lack a canonical business-date uniqueness key even when equity/FX stores have one.
- Policy `benchmarks_json` may be versioned while still allowing multiple references, lacking provider-symbol/currency mapping, or having no editor input.
- Cache/chart tables are not automatically canonical daily valuation inputs.
- A CLI suite is not scheduler, run-state, retry, lease, or locking infrastructure.
- SQLite transaction locks around confirmation flows do not provide job-level single-flight semantics.

## Deliverable format

Return:

1. repository/commit and unchanged-tree statement;
2. concise executive conclusion;
3. sections for providers, FX, snapshots/migrations, scheduler/locking, TWR/MWR, policy benchmark, risk, and API/UI;
4. exact relative paths and symbols;
5. direct reuse vs reuse-with-fix vs gap recommendations;
6. likely existing tests to extend and narrowly named new tests;
7. explicit statement that no production values or secrets were inspected or disclosed.

Do not run the full suite for a source-only inventory unless requested. Structural searches and a final clean-tree check are the verification evidence.