docs: review backlog after backtest ui sprint
This commit is contained in:
@@ -414,12 +414,66 @@ DATA-001 (Price Feed)
|
||||
|
||||
**Dependencies:** BT-003, BT-001A
|
||||
|
||||
### BT-001B: Backtest Defaults from Saved Portfolio [P1, S] **[depends: BT-001A, PORT-001A]**
|
||||
**As a** portfolio manager, **I want** the backtest forms to prefill from my saved portfolio settings **so that** I do not have to re-enter start value, start price, weight, and loan inputs across pages.
|
||||
|
||||
**Acceptance Criteria:**
|
||||
- `/backtests` defaults derive from the canonical saved portfolio/settings state
|
||||
- `/event-comparison` defaults derive from the same canonical saved portfolio/settings state
|
||||
- UI makes the implied starting position explicit (start value, start price, weight)
|
||||
- Changes in settings are reflected in both backtest pages on reload
|
||||
- Browser test verifies saved settings influence backtest defaults
|
||||
|
||||
**Technical Notes:**
|
||||
- Reuse the existing portfolio/settings persistence path
|
||||
- Avoid duplicating position-derivation logic between settings and backtest pages
|
||||
- Keep BT-001A/BT-003A read-only with respect to persistence; settings remains the source of truth
|
||||
|
||||
**Dependencies:** BT-001A, PORT-001A
|
||||
|
||||
### BT-003B: Event Comparison Drilldown [P1, M] **[depends: BT-003A]**
|
||||
**As a** portfolio manager, **I want** to inspect why one ranked strategy beat another **so that** the comparison page explains survival, cost, and path behavior instead of only showing a summary table.
|
||||
|
||||
**Acceptance Criteria:**
|
||||
- Selecting a ranked strategy shows its daily path details
|
||||
- UI exposes at least:
|
||||
- margin call days hedged/unhedged
|
||||
- total option payoff realized
|
||||
- total hedge cost
|
||||
- final equity
|
||||
- UI highlights the worst LTV point and any breach dates
|
||||
- User can compare the selected strategy path against the unhedged baseline and one other ranked strategy
|
||||
- Browser test verifies drilldown content updates when selecting a ranked result
|
||||
|
||||
**Technical Notes:**
|
||||
- Reuse existing `daily_path` and summary metrics from BT-001/BT-003 results
|
||||
- Keep this slice read-only; no saved reports required yet
|
||||
- Prefer progressive disclosure below the ranked table rather than a separate workflow
|
||||
|
||||
**Dependencies:** BT-003A
|
||||
|
||||
### BT-001C: Shared Historical Fixture/Test Provider Cleanup [P2, S] **[depends: BT-001A, BT-003A]**
|
||||
**As a** developer, **I want** one shared deterministic historical fixture provider for backtest UI paths **so that** seeded browser tests and demo scenarios stay consistent and do not duplicate historical-window logic.
|
||||
|
||||
**Acceptance Criteria:**
|
||||
- Deterministic historical fixture/provider logic is centralized instead of duplicated across page-specific services
|
||||
- Supported seeded windows are explicit and fail closed outside allowed ranges
|
||||
- Both `/backtests` and `/event-comparison` use the shared deterministic provider in browser-tested demo paths
|
||||
- Tests cover the supported-window contract and failure mode
|
||||
|
||||
**Technical Notes:**
|
||||
- Prefer a small shared test/demo provider abstraction over page-local fixture classes
|
||||
- Keep live providers separate from deterministic seeded UI/demo behavior
|
||||
|
||||
**Dependencies:** BT-001A, BT-003A
|
||||
|
||||
## Implementation Priority Queue
|
||||
|
||||
1. **BT-001A** - Put the synthetic backtest engine behind a thin product UI/read path
|
||||
2. **BT-003A** - Expose event preset comparisons in the UI
|
||||
1. **BT-001B** - Prefill backtest UIs from canonical saved portfolio settings
|
||||
2. **BT-003B** - Add event-comparison drilldown and explanation of ranking outcomes
|
||||
3. **PORT-003** - Historical LTV visibility and export groundwork
|
||||
4. **BT-002** - Upgrade backtests to real daily options snapshots
|
||||
5. **EXEC-001** - Core user workflow
|
||||
6. **EXEC-002** - Execution capability
|
||||
7. Remaining features
|
||||
5. **BT-001C** - Consolidate deterministic historical fixture/demo provider logic
|
||||
6. **EXEC-001** - Core user workflow
|
||||
7. **EXEC-002** - Execution capability
|
||||
8. Remaining features
|
||||
|
||||
Reference in New Issue
Block a user