Trader-MCP Hermes Compatibility Plan
This file turns TODO.md into a stepwise upgrade path toward hermes-mcp compatibility.
Goal
Prepare trader-mcp so Hermes can supervise strategy selection, risk posture, and switching without collapsing Trader into a monolith.
Trader should remain:
- strategy runtime
- execution feedback surface
- operator dashboard
- persistence owner for strategy state
Hermes should remain:
- selector
- supervisor
- regime interpreter
- switch/risk controller
Core design principles
- Small interfaces.
- Explicit ownership.
- Human-readable strategy names.
- Structured state over vibes.
- Stable switch semantics.
- Contract-first development.
- Tests before expansion.
Canonical strategy set
Start with a small orthogonal registry:
idle
defensive
trend_following
mean_reversion
grid
breakout
event_driven
Strategy ordering priority
idle
defensive
trend_following
mean_reversion
grid
breakout
event_driven
This is not a quality ranking. It is a sequencing plan for implementation and testing.
Ownership boundaries
Strategy owns
- its local logic
- its local state
- its local config
- its own render output
- its own explanation string
Trader runtime owns
- lifecycle
- persistence
- snapshots
- reconciliation
- dashboard presentation
- execution plumbing
Human observer owns
- inspection
- approval where configured
- operational overrides where explicitly allowed
- debugging and review
Hermes owns
- strategy enable/disable/switch decisions
- risk-mode changes
- uncertainty and confidence weighting
- regime interpretation
- execution-degradation-driven downranking
Upgrade phases
Phase 0, document the contract
Deliverables:
Hermes_Trader_Contract_v0.1.md
- agreed strategy taxonomy
- agreed state and decision fields
- agreed control verbs
Acceptance criteria:
- every strategy has
expects, avoids, and risk_profile
- Hermes request and Trader response shapes are machine readable
- no contract depends on hidden state
Phase 1, normalize the strategy registry
Deliverables:
- fold redundant names into the canonical set
- mark parameter variants as modes
- ensure strategy labels are stable and human-readable
Acceptance criteria:
- each strategy name maps to one conceptual regime
- no micro-strategy sprawl
- old names can be redirected or deprecated cleanly
Phase 2, expose Hermes-facing inspection tools
Deliverables:
list_strategies
get_strategy
get_runtime_state
get_recent_changes
get_decision_history
get_execution_state
Acceptance criteria:
- Hermes can inspect state without knowing internals
- dashboard and API show the same truth
- every response is structured and auditable
Phase 3, add control tools for Hermes
Deliverables:
apply_control_decision
switch_strategy
set_risk_mode
pause_strategy
resume_strategy
reconcile_state
Acceptance criteria:
- Hermes can control Trader through explicit verbs
- invalid or unsafe requests are rejected cleanly
- every transition records a reason and decision id
Phase 4, implement switching safety
Deliverables:
- confidence threshold
- minimum hold time
- hysteresis
- explicit emergency override path
- degraded execution fallback
Acceptance criteria:
- strategies do not flap on minor noise
- switching reasons are deterministic and testable
defensive and idle are valid safe exits
Phase 5, implement initial strategies
Deliverables:
idle
defensive
trend_following
mean_reversion
Acceptance criteria:
- each one has metadata and tests
- each one returns clear state/explanation data
- each one can be selected by Hermes-compatible contract shapes
Phase 6, add structure strategies
Deliverables:
Acceptance criteria:
- grid is clearly structure-based, not signal-based
- breakout is separated from trend-following
- tests cover the distinction
Phase 7, add event-aware behavior
Deliverables:
event_driven
- event-risk metadata
- event-pressure aware selection logic
Acceptance criteria:
- Hermes can downrank normal strategies during event risk
- event handling remains temporary and explicit
Phase 8, feed back execution quality
Deliverables:
- fills
- slippage
- latency
- rejections
- stress
- degraded connectivity
Acceptance criteria:
- execution quality affects strategy selection
- Trader surfaces the feedback clearly
- Hermes can see why a strategy was penalized
Phase 9, tighten dashboards and audit trails
Deliverables:
- current strategy view
- why-active view
- recent changes timeline
- Hermes decision trace
- execution state panel
Acceptance criteria:
- a human can understand the system without reading code
- transitions are explainable from the UI
Tests to add
Contract tests
- strategy metadata validation
- Hermes request schema validation
- Trader response schema validation
- control verb validation
Runtime tests
- load/unload/switch transitions
- state snapshot and restore
- minimum hold enforcement
- hysteresis enforcement
- defensive fallback on degraded execution
Strategy tests
- expected regime matching
- avoided regime rejection
- deterministic state transitions
- readable explanation output
Integration tests
- Hermes decision to Trader control path
- Trader response parsing
- execution feedback influencing future selection
Suggested first implementation order
- lock the contract paper
- canonicalize the strategy registry
- add metadata to current strategies
- add validation tests
- implement the inspection tools
- implement the control tools
- add switching safety
- implement
idle and defensive
- implement
trend_following and mean_reversion
- add
grid, breakout, and event_driven
- wire execution feedback into selection
- polish dashboard and traceability
Notes on ownership and scope
Trader should not become a second Hermes.
If a feature answers "what should the world do?", it belongs to Hermes.
If a feature answers "how do we run the chosen strategy safely?", it belongs to Trader.
If a feature answers "what happened and why?", it belongs to both through a shared contract.
Output philosophy
The end state should make Trader useful to Hermes, useful to humans, and still simple enough to debug.