Documentation
¶
Overview ¶
Command coverage measures, per API object, how many of its JSON-RPC methods the SDK implements, and writes a human-readable report to api-spec/COVERAGE.md.
Usage: go run ./api-spec/coverage
It reads the committed OpenRPC snapshot (api-spec/openrpc/*.json) for the set of objects and their method names, then inspects the SDK source to decide which methods are implemented.
Detection heuristic ¶
This is a heuristic, not a proof of behaviour. The SDK dispatches every JSON-RPC call through a single transport, s.c.call(ctx, <endpointConst>, "<method>", ...), where <endpointConst> is a package const such as vpsEndpoint = "/vps". The tool:
- maps each endpoint path to its const identifier by scanning the SDK for `<name>Endpoint = "/path"` declarations;
- finds every SDK .go file that references that const identifier (one object can span files — the /vps methods live in vps/vps.go and vps/config.go);
- collects the Go string literals in those files (via go/scanner, so comments and identifiers are excluded);
- counts a spec method as implemented when its exact name appears among those literals.
Scoping the literal search to the files that use the object's endpoint const (rather than the whole repo) is deliberate: it keeps generic wire names like "create" or "index" from matching across unrelated objects. The wire method name is always a literal somewhere in those files, even for methods dispatched through a helper that receives the name as a parameter (e.g. powerOn/powerOff/ reboot via VPSService.powerAction).
Known limitations:
- False positive: a method name that appears as a literal for an unrelated reason (a params key, an error string) in a file using the endpoint const would be counted as implemented.
- False negative: an object whose endpoint path has no const, or whose methods are dispatched from a file that never names the const, reads as 0%.
This is provenance/roadmap tooling; it is not part of the importable SDK.
Source Files