29 lines
1.3 KiB
Markdown
29 lines
1.3 KiB
Markdown
# Proposal
|
|
|
|
## Why
|
|
|
|
The owner needs to distinguish ongoing Phoenix TWAP execution from the current position size in EMC. Issue #101 requests progress and the estimated wait until the next child without changing refresh frequency or exposing unfilled orders.
|
|
|
|
## What Changes
|
|
|
|
- Read Phoenix TWAP snapshots alongside existing account observations and attach only filled orders to matching existing positions.
|
|
- Add a ninth TWAP column with child-count progress, elapsed-hour duration text and detailed estimated timing/quantity tooltips.
|
|
- Reuse Phoenix mark prices, preserving quantities when a valid response has no mark price and propagating unknown valuations.
|
|
- Preserve whole-venue observations on TWAP errors; document periodic timing and nominal slot estimates.
|
|
|
|
## Capabilities
|
|
|
|
### New Capabilities
|
|
|
|
None.
|
|
|
|
### Modified Capabilities
|
|
|
|
- `phoenix-perps-service`: precise TWAP quantities, identities, optional mark prices and read failure behavior.
|
|
- `evelyn-perps-service`: immutable TWAP observations on existing positions, with retained venue status.
|
|
- `evelyn-perps-overview`: TWAP progress, long durations and detailed tooltips.
|
|
|
|
## Impact
|
|
|
|
Phoenix DTOs/reader, Evelyn snapshot/mapping, JavaFX Perps cells and relevant existing project/shared documentation. No trading, new dependencies, faster polling, commits or pushes.
|