# Hermes-mcp upgrade to 0.6.0 :

## hermes-mcp - trader-mcp communication:

desired behaviour: 
- hermes-mcp only acivates and deactivates strategies on trader-mcp. no observe mode. it only switches to another stratgey. 
  therefode the mode parameter can be dropped for now from decision logic and dashboard and deision history, if hermes wants to suspend a strategy, it deactivates it.  
- investigate the back reporting from trader and minimize load or unnecessary communication.
- hermes does not need to care about passing parameters to strategies on trader or mess with the configuration, except for maybe reading it.

- Hermes supervises the trader by activating the new and deactivating old strategies if appropriate and receives minimal reports like wallet composition and balances from the strategy on trader.

## hermes-mcp decision logic

background:
we recently introduced playbooks. the current decision logic is mostly based on the grid-trend-rebalancer playbook. the trend-only playbook is here to have another playbbok while bootstrapping the app.

- the repo contains a directoy named decision_families, this is to be renamed to playbooks.
- and the **code needs to be refactored** so that the actual decision logic used by a playbook does really reside in the corresponding python code in the playbooks folder.

## playbooks

- i am ok with having json files in the repo for definition of each playbook eg grid-trend-rebalancer.json and trend-only.json
- a playbook defines 
  - a set of strategies and  
  - parameters as well as  
  - the logic  
 that allow hermes to make decisions to activate or deactivate strategies if decided appropriate on trader.

- a playbook defines roles and which strategy family or class, can be used to fill each role.
  eg for our grid-trend-rebalancer it would require those four roles :
  grid, buyer, seller, rebalancer
  we already have a playbooks endpoint in the dashboard that lets us assign strategies to roles.
  
- a playbook defines a set of parameters, that are used to fine tune the decision logic.
  these parameters are tunable via the dashboard 

- each playbook has a corresponding file in the playbooks folder, where most if not all of the logic used by that playbook is defined.
- the main decision_engine.py should only contain logic that can be used by all playbooks, eg general input data, utility functions ...  
- playbook specific functions should be moved to the playbooks specific python file.

- i dont know if we need a dispatcher.py !!?? imho, the main decision_engine.py should play the dispatcher for the playbooks.

- the dashboard and decision logic can use the playbook definitions to choose the right parameter set for processing, persisting and display.

## expectations and constraints

- define more clearly how playbooks are used throughout hermes-mcp, 
- clearly pack the decision logic and parameters of a playbook into its defilition and code file
- make the use of playbooks and their different parameters an decision logic code tock solid as a abse for further development
- clean out leftovers from old architectural mistakes or obsolete code, simplify where possible
- we need to use the term playbook in the code whenever appropriate and drop the other misleading terms like  decision_family and also maybe decision_configuration for the more appropriate idea of a playbook and its configuration parameters


- we do not need to validate if strategies fit the expected family to be used to fill a role. 
  we do not need to be able to edit playbooks in the dashboard. the current implementation is sufficient.
  
- we want to bring hermes-mcp to a point where fine tuning the deciding weights for transitions between strategies as defined by a playbook is solid and reliable.