hanzo-dev
c04cf21fa7
/v1/world 404'd. The prefix has one cloud owner (apps/world) and five
operations, but nothing at the prefix itself, so the one address a caller
reaches for first answered "not found".
It answers now, as a typed op: one registry entry, so the schema, the prose,
the OpenAPI operation, the MCP tool, the CLI command and every generated SDK
method all follow from it. Fleet document 1058 -> 1059 paths; the world subset
4 paths/5 ops -> 5/6.
What it carries that nothing else could. /v1/world/mcp and /v1/world/zap are
real, live and PUBLIC — the ingress (routes.yaml api-hanzo-ai-world-gw,
priority 100) carves them off the cloud catch-all to world-gw:9999. Measured:
MCP initialize answers 200 unauthenticated (serverInfo hanzo-world), tools/list
is fail-closed JSON-RPC -32001, /v1/world/zap is 401 missing_token. Cloud does
not route either one, and openapi.Describe renders prose ONLY for a route the
router actually serves — the property that stops the document claiming an
operation nothing answers. So the document cannot declare them and must not.
Until now the only way to learn they existed was to read the ingress config.
The front door names them, and TestIndexNamesEveryWireCompletely keeps them
named. It does NOT restate the REST operation list: GET /v1/openapi.json stays
the one enumeration of those.
Declared absolute on the app, not on a group: an op that IS the prefix has no
leaf, and zip.Get(g, "") composes to "/v1/world/", a different route. Same
reason and same form as apps/pricing and apps/plan; a group for the leaves plus
an app-level exception for the one bare op would be two idioms for one job.
manifest/mcp_test.go: apps/world/index.go joins foreignDoors. The gate reads
source for /mcp literals, and this one is an address in a data value, not a
second JSON-RPC envelope — world-gw owns that engine's tools. Reason recorded
there, including the distinction from apps/tasks: cloud names this door, it
never serves it.
NOT done, deliberately, and recorded in LLM.md: hanzoai/world is a Go module
(150 Go files) whose routes.go registers 117 routes, including the AI-plane
read surface handlers_worldgw.go names (events, conflicts, infra, vessel, news,
markets, feeds). Those are deployed NOWHERE — world.hanzo.ai runs v2.4.37 while
that surface landed after it (main is 2.4.60), and world.hanzo.ai/v1/world/events
returns that server's own catch-all, {"error":"Not found: /v1/world/events"}.
Declaring cloud ops that forward there would publish operations into
openapi.yaml, every SDK and every MCP tool list that 404 in production — the
same dark hole api-hanzo-ai-catalog opened under /v1/models and /v1/pricing,
which cost 17 documented-but-uncallable operations. Re-home that surface after
the upstream ships it, not before.
Gates: apps/world ok (3 new + the projection gate), manifest ok, openapi ok
(weave proves the subsets compose to openapi.yaml), go vet ok, gen-app-cmds
bijection intact. Proven on the real binary: GET /v1/world -> 200 with the
wire list, and the binary's own /v1/openapi.json carries the path and both
schemas.
Co-authored-by: Hanzo Dev <dev@hanzo.ai>
16 KiB
16 KiB