mirror of
https://github.com/luxfi/cli.git
synced 2026-10-30 17:01:20 +00:00
zeekay
8619f3ac59
Two commands, neither of which contains a list of anything. lux call fetches the OpenAPI document a node derives from its own typed-op registry and projects it back into a command tree. A service is a word in the document, an operation is a route, and an operation's flags are the fields of its input, so an op registered on the node this morning is a command this afternoon with nothing rebuilt and no release of this binary. It cannot address an operation the node does not serve, which is exactly how the SDK came to send exchangevm.getBlock to a node that registers the X-chain under xvm. lux mcp relays MCP between an agent on stdio and the node's door on ZAP. Frames on a socket: no HTTP listener, no request, no status code. A frame renders as both the ZAP wire and the JSON-RPC 2.0 message, so this is a relay and not a translation. It does not read inside what it carries, and it holds no tool list, because the tools are the node's own ops and a copy of them here would be one more thing to fall behind them. A node with no typed ops serves no document at all, so lux call reads a 404 as "nothing to derive from" rather than "wrong address". That is the state every node is in until its handlers are typed, and it is the first thing anyone running this will hit. Verified against a live zip service over a unix socket: tools/list offers a registered op, tools/call runs it and brings the value back, a dead door answers rather than hanging the agent, and call runs an op and binds a flag onto its input. This module cannot compile any of it today, because go.sum records bytes that are no longer served for luxfi/evm v1.104.10 and luxfi/consensus v1.36.2 and that blocks graph loading for every package here. The proof therefore ran in a module holding only these two packages, cobra, zip and zapmcp. go.sum still needs the tidy the same breakage blocks.