2.2 KiB
Prompt
The session-initiating instruction, verbatim (this doc IS its “mega detailed plan” deliverable):
ok i want you to become the distributed runtime and concurrency expert for this project - namely acquire a deep understanding of tractor and how it’s used. then i want you to atttempt to factor our current brokerd service daemon into 2 daemons:
- a brokerd which only hosts live/paper trading endoint tasks as defined namely within all piker/brokers//broker.py mods
- a new
datadsubdaemon which in a separate subactor serves all the data feed service tasks namely delivered by endpoints in piker/brokers//feed.py (or similar for less mature backends) and as more rigorously defined by the validation machinery in piker.data.validate.give me a mega detailed plan on how to approach this, and a staged approach for the implementation.
Plan-shaping user decisions (in-session Q&A): sibling topology under pikerd; hard cutover staged by layer; trading-only EMS-lazy-spawned brokerd. The human staged the doc copy into ai/claude-code/plans/ and requested this commit after the 7 implementation commits landed.
Response summary
The staged design doc for the brokerd -> (datad + brokerd) split: context, target supervision topology, load-bearing verified facts, per-stage file-level changes with gates, risk register and an end-to-end verification matrix. Produced via 3 parallel explore agents + 1 architect agent + human Q&A before any code was written; all 7 implementation commits in this branch reference its stages in their provenance entries.
Files changed
ai/claude-code/plans/datad_service.md— the design plan doc (human-staged copy of the AI-authored plan)
Human edits
None to the doc content — committed as generated. NB: the implementation deviated from the plan-as-written in 4 places, see the raw file’s deviation log.