jschoubben
9eddcdb0a0
The per-node process that makes a module's tools serve on the mesh: - broker-amqp.ts: a concrete AMQP implementation of the sdk's Broker contract (request/reply over a reply queue + correlation id, publish/ subscribe over a topic exchange). Kept here, not in the sdk, so a broker-client change never rebuilds a module (ADR 0044). - runtime.ts: bind the broker, import the assigned modules' tool entrypoints (each registers as it loads), serveTools. The thin wrapper. - main.ts: the entrypoint, configured by MESH_BROKER_URL + MESH_TOOL_MODULES. - Dockerfile: the container a node runs it as. Verified over a REAL broker: the test spins LavinMQ (the mesh's broker), the runtime serves a registered tool, a separate connection invokes it by name over AMQP and gets the result, and an unknown tool is refused over the wire. So 'modules can serve' is now running-on-the-mesh, not just proven in a mock. Claude-Session: https://claude.ai/code/session_01LrgweAeERJYBg88c5cKDzF
23 lines
553 B
JSON
23 lines
553 B
JSON
{
|
|
"name": "@novox/mesh-tools",
|
|
"version": "0.1.0",
|
|
"description": "The Novox Mesh tool runtime — binds the mesh broker and serves the assigned modules' tools.",
|
|
"type": "module",
|
|
"bin": {
|
|
"mesh-tools": "./dist/main.js"
|
|
},
|
|
"scripts": {
|
|
"build": "tsc",
|
|
"test": "node --test --experimental-strip-types 'test/*.test.ts'"
|
|
},
|
|
"dependencies": {
|
|
"@novox/mesh-sdk": "^0.1.0",
|
|
"amqplib": "^0.10.9"
|
|
},
|
|
"devDependencies": {
|
|
"@types/amqplib": "^0.10.8",
|
|
"@types/node": "^22.20.1",
|
|
"typescript": "^5.9.3"
|
|
}
|
|
}
|