# Command dashboard read-only trader preflight gates

Use this when a sensitive command dashboard (FinanceManager/JARVIS-style) sits above a specialist trading executor and needs to show live-readiness without ever executing.

## Pattern

- Add a dedicated read-only endpoint such as `GET /api/finance/trader-desk/preflight` separate from the signal snapshot and scorecard.
- Keep the dashboard endpoint safe even when the upstream bot has no preflight export yet:
  - derive conservative gates from the existing bridge snapshot + shadow scorecard,
  - set `status=not_configured` or `degraded`,
  - force `preflight_status=fail`,
  - include explicit blockers such as `shadow_sample`, `shadow_winrate`, and `final_bot_preflight`.
- Treat any upstream “pass” as display-only. The dashboard must always force:
  - `execution_allowed=false`
  - `live_order_allowed=false`
  - `mainnet_signed_action=false`
  - `dashboard_executes_orders=false`
- The specialist bot must later re-read approvals/preflight and re-run its own gates before any exchange action.

## Backend contract

Recommended response shape:

```text
schema_version: trader_desk_tiny_live_preflight.v1
status: ok | not_configured | degraded
preflight_status: pass | fail
readiness_label
current_intent: { coin, side, signal, score, status, setup, blockers } | null
gates: [{ key, label, status: pass|fail|warn|unknown, reason, severity }]
blockers: string[]
reason
safety_boundary
execution_allowed=false
live_order_allowed=false
mainnet_signed_action=false
```

## Sanitization

- Never pass through upstream runtime paths, token names, secret labels, private-key labels, or raw credential gate names.
- Redact or normalize upstream gate keys/labels containing `credential`, `token`, `secret`, `private_key`, or `api_key` before calling the project safety/redaction guard.
- If a reason contains a local path or secret-like term, replace it with generic text such as `CryptoTrader muss alle Gates erneut prüfen.`
- Add tests that deliberately feed unsafe upstream flags (`execution_allowed=true`, `mainnet_signed_action=true`) and unsafe text, then assert the API response is safe and forced false.

## Frontend UX

- Show the preflight as a readiness gate, not an order terminal.
- Use copy like `preflight fail · blocked` / `preflight pass · no execution`.
- Show current intent, blockers, reason, and first gates.
- Keep existing scorecard and intent cards below/nearby so the operator sees evidence and blockers together.

## Verification checklist

- Backend endpoint tests for missing file, degraded file, sanitized runtime export, and forced false execution flags.
- API client/types updated and `API_PATHS` includes the endpoint.
- OpenAPI export/check updated.
- Frontend test confirms the preflight panel renders blockers and read-only copy.
- Full `make verify` plus runtime smoke against real bridge/scorecard files: confirm `contains_path=false` and all execution flags remain false.
- If repo safety scans fail on literal sensitive field names in helper scripts, prefer neutral string construction in code over weakening the scanner.