📊 @backtest-kit/ui

Each symbol gets a section of cards; every card is one closed signal showing position type (long/short), entry price, take-profit and stop-loss levels, and the realized PNL in both amount and percent. Where a position used dollar-cost averaging or partial closes, the card displays the DCA entry count and partial-close count. A Backtest/Live tab toggle switches the dataset; the list supports JSON export and manual refresh. Layout is a scrollable tabbed container with a decorative background.

Inside a breadcrumb header (KPI BACKTEST / KPI LIVE) the body is a declarative field grid (dashboard_fields) of live widgets fed by four aggregated measures pulled per-symbol and summed:

• Four revenue cards (SingleValueWidget) — Today / Yesterday / 7 days / 31 days, each showing profit in USDT with a trade-count caption, color-coded red (loss) / green (profit) / orange (flat).
• Trade-performance donut (SpeedDonutWidget) — Failed vs. Successful vs. Total signal counts.
• Daily-trades chart (ChartWidget) — a per-day series of total / resolved / rejected trades.
• Success-rate panel (SuccessRateWidget) — per symbol (icon + display name), broken into take-profit / stop-loss / close-resolved / close-rejected counts.
• Signal grid (SignalGridWidget) — the paginated signal table for the active mode.

The breadcrumb actions: Download (exports the raw signals as a timestamped JSON blob), Switch to LIVE / BACKTEST (jumps between modes), and Refresh manually (clears the signal cache and reloads). A modal loader covers the board while it recomputes.

Each entry is a row with a type badge (Debug / Info / Warn / Log), the log topic, a timestamp, and the raw JSON arguments rendered in monospace. A search prompt filters by keyword or regex. The whole log exports as a JSON file. Virtualized so it stays smooth over very long histories.

Color-coded cards, one per event — opens, closes, schedules, errors — each showing symbol, position, PNL, and the entry / exit / TP / SL prices. Infinite-scroll pagination loads more as you go; clicking a card opens a detailed modal for that event. Manual refresh pulls the latest activity. The same notifications drive the bell badge in the app bar.

List (/status) — active signals grouped by strategy, rendered as a grid of strategy buttons; click one to inspect it.

Detail (/status/:id) — the full state of one pending signal as a structured field view (status_fields): entry, exit, effective (blended) price, DCA entry count and partial-close count, and live PnL. Header actions: Manual Control, Print (renders the signal's fields to a downloadable PDF/markdown), Download (JSON), Refresh. Empty states read "Loading…" or "No pending signal."

Manual Control (/status/:id/control) — an operator panel (RecordView, expand-all) where you intervene in a live position by hand through four multi-step wizard modals: Open Pending, Average Buy, Close Pending, and Breakeven. Each is launched from the panel via an emitter, walks you through Briefing → Input → Submit, fires the commit, and reloads the record. Export to JSON is available. (See The modal system below for how these are built.)

A grid of strategy buttons, grouped by type and sorted by signal volume; selecting one renders its markdown report inline. Each report downloads as markdown, PDF, or raw JSON. Manual refresh regenerates the content. This is the human-facing view of the engine's analytics (strategy / breakeven / risk / partial / drawdown / schedule / performance / sync reports).

You navigate by symbol, then by interval (1m / 15m / 1h) to view price history. The chart overlays the active signal's lines: entry, take-profit (green), and stop-loss (red). Supports chart-image export and clicking through to signal detail. Built on the shared ChartWidget.

Cells are colored by performance; each shows win rate, profit factor, Sharpe ratio and other aggregated metrics per symbol. The whole heatmap exports as JSON, markdown report, or PDF, with manual refresh to recalculate the statistics. (The same heat report download lives on the home screen's action bar.)

A tree-structured browser of backtest output and artifact files. Icons mark file type — image, JSON, plain text, or generic. Clicking a file opens a full-screen preview modal. Keyword search filters the tree; manual refresh rebuilds it. Backed by the FileTreeWidget.

• ChartWidget — Lightweight Charts candlestick/line rendering with signal overlays (Price Charts, signal detail).
• SignalGridWidget — the paginated signal table (offset pagination + async item iterator).
• StatusWidget — live workload status tiles.
• SuccessRateWidget / SpeedDonutWidget — donut gauges for win-rate and throughput.
• SingleValueWidget / IndicatorValueWidget — single-KPI and indicator-value cards.
• AveragingWidget — DCA-ladder / effective-price visualization.
• PartialWidget — partial-close breakdown.
• FileTreeWidget — the dump-explorer tree.

Shared chrome lives in components/common/: AppHeader, a Markdown renderer, the CodeEditor, NotificationView, Tooltip, IconPhoto, ErrorView, decorative Background / BottomImage. Providers (AlertProvider, ErrorProvider, LayoutModalProvider, StatusInfo, Translate) wrap the app for alerts, error boundaries, modal stacking, the status banner, and i18n.

Each hook below is a pick* opener subscribed to its layoutService.pick*Subject; the hook renders a modal that displays the event's DTO through its assets/*_fields.tsx schema, inside the tabbed shell + <ActionMenu /> title bar described above:

These are the modals that open when you click a notification card, a signal in a grid, or a risk event — every point in a position's life has a dedicated, fielded modal, each with the same Back / Print / Search / Copy / ActionMenu / Close title bar.

Folders: useOpenPendingModal, useAverageBuyModal, useClosePendingModal, useBreakevenModal. Each contains useXModal.tsx (the useWizardModal config — title, fullscreen size request, close button, onSubmit → reload), routes.tsx (three IWizardModal routes), steps.ts (the stepper labels), view/{BriefView,FormView,SubmitView}.tsx, and components/StatusCard.tsx. The page (ControlView) subscribes to four emitters (commitOpenPendingEmitter, commitAverageBuyEmitter, commitClosePendingEmitter, commitBreakevenEmitter) and calls pickData() to launch the matching wizard.

The three steps (Open Position example):

1. Brief — fetches and shows the symbol + current effective price (controlViewService.getAveragePrice) with a "verify the symbol AND the price" warning. Next → /form, Close dismisses.
2. Form — collects direction (long/short), amount in USDT, and a note; live-computes coin quantity = amount ÷ price as a read-only field; warns that the position opens immediately. Back → /brief, Next → /submit.
3. Submit — fires the commit (controlViewService.commitOpenPending / commitAverageBuy / commitClosePending / commitBreakeven) and shows a StatusCard in loading → success / error state; Close finalizes (beginSave) and the underlying record reloads.

Average Buy, Close Pending, and Breakeven follow the same Brief→Form→Submit shape with operation-specific form fields and StatusCard copy.

• dashboard_fields (→ DashboardPage) — not a text form but a widget grid: revenue cards, donut, daily-trades chart, success-rate panel, signal grid (see PNL Performance above).
• signal_fields (→ StatusView detail + print, useSignalView) and status_fields (→ StatusView) — the full pending/closed signal record.
• risk_fields (→ useRiskView), setup_fields (→ About/Setup view).
• Lifecycle/commit schemas (each → its use*View hook in the global registry): signal_opened_fields, signal_closed_fields, signal_scheduled_fields, signal_cancelled_fields, signal_notify_fields, signal_sync_open_fields, signal_sync_close_fields, activate_scheduled_fields, average_buy_commit_fields, close_pending_commit_fields, cancel_scheduled_commit_fields, breakeven_available_fields, breakeven_commit_fields, partial_profit_available_fields, partial_profit_commit_fields, partial_loss_available_fields, partial_loss_commit_fields, trailing_stop_fields, trailing_take_fields.

These are the largest source files in the package (most 27–37 KB) precisely because they describe every field of every lifecycle DTO — the schemas are the UI's knowledge of the engine's data model.