docs: add simulation controller SDK spec, replace spatial topology
The mesh is the communication fabric, not the simulation engine. SimController pattern: external controller drives tick loop, computes visibility, sends observations to peers, collects actions. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
@@ -69,10 +69,19 @@ Per-mesh compute sandboxes. Peers request: `execute_code(lang: "python", code: "
|
||||
|
||||
**Effort:** 2-3 days (E2B), 1-2 weeks (self-hosted).
|
||||
|
||||
### Spatial topology (proximity-based visibility)
|
||||
Extend visibility with `(x, y)` coordinates and visibility radius. Peers only see others within range. Combined with sim clock, enables spatial simulations (customer walks into store zone, sees sales reps).
|
||||
### Simulation controller SDK (`@claudemesh/sim`)
|
||||
Replaces the "spatial topology" item. Instead of baking simulation features into the broker, build a framework on top of the mesh.
|
||||
|
||||
**Effort:** 1 day.
|
||||
- **SimController class** — connects as a peer, drives tick loop, computes visibility, sends observations, collects actions
|
||||
- **World state** — entity system, zone graph, state namespacing (`sim:domain:key`)
|
||||
- **Visibility modes** — zone-based, radius, custom function (bring your own physics)
|
||||
- **Multi-controller** — federated domains (floor, inventory, queue) with orchestrator merge
|
||||
- **Dashboard integration** — reads world state from mesh, human input flows back via messages
|
||||
- **The mesh stays simple** — messaging + state. All simulation logic lives in the controller.
|
||||
|
||||
Full spec: [`simulation-sdk-spec.md`](./simulation-sdk-spec.md)
|
||||
|
||||
**Effort:** 5-6 days.
|
||||
|
||||
### Semantic peer search
|
||||
`search_peers(query, filters?)` — multi-field matching across names, groups, roles, summaries, profile capabilities, skills. Ranked results. For meshes with 50+ peers.
|
||||
|
||||
Reference in New Issue
Block a user