4 Commits

Include renames

Author	SHA1	Message	Date
hanzo-dev	a361b88677	engine: an operation is named for its product, and its summary is for the caller ... An operation id is the generated SDK METHOD NAME and the CLI COMMAND, and a summary is what the MCP tool list shows a model choosing between tools. This plane stated neither, so both were defaults, and both defaults were wrong in a way only a caller sees. zip derives an unstated id from the path, so the four ops published `get_v1_engine_status`, `get_v1_engine_models`, `get_v1_engine_model`, `get_v1_engine_system` — path mangling where the rest of the fleet publishes the product and the noun. The risk product's thirty-one operations are `riskScore`, `riskState`, `riskDatasets`, `riskLabelCoverage`; these are now `engineStatus`, `engineModels`, `engineModel`, `engineSystem`, which is also the rule this package already applied to its own SCHEMA names and only to those. A summary defaults to the first sentence of the Go doc comment, and a Go doc comment opens with the Go IDENTIFIER — so the published summaries read "Status reports whether the engine deployment is reachable", "Models lists the models the engine serves", "Model reads one model's load state". A Go symbol name was the first word a CLI user, an SDK reader and a model picking a tool saw. Each op now states a summary written in the imperative for the person calling it, and the doc comment stays a Go doc comment that zipdoc still lifts as the description: two audiences, two sentences, one declaration. FORWARDS-ONLY, and it costs nothing: this plane has no customers on it. No alias, no redirect, no compat shim. Regenerating from source changes exactly four operation ids. No path is added or removed, no (path, method) pair moves, no schema changes, and openapi/floor.json is byte-identical because the operation count did not move. Co-authored-by: Hanzo Dev <dev@hanzo.ai>	2026-08-04 00:48:16 -07:00
hanzo-devandzeekay	7e3bb4af9b	describe: regenerate the woven document so the prose fix reaches the wire ... `make describe` — zipdoc lifts the doc comments, each app projects its own router, the weave composes them. Path count is unchanged at 1058: this moves prose, not surface. It also picks up drift nobody had regenerated: apps/git's zipdoc_gen.go was missing the import/inbound/mirror ops' prose entirely, and apps/admin's had gone stale. Both were invisible because the weave only proves the subsets compose with each other — the drift gate is what regenerates from source. Co-authored-by: Hanzo Dev <dev@hanzo.ai>	2026-08-01 10:25:03 -07:00
hanzo-dev	fe782d1bec	docs: the last seven openers, and none of them was about the customer ... These are the remainder of the rule 668c63ac, 55ef5731 and 4cfc10d0 established: openapi/synopsis.go lifts a package doc's FIRST SENTENCE verbatim into that app's own subset as info.description, the weave lands it on the product tag, and from there it is the MCP tool prose an agent reads and the line `hanzo <product> --help` prints. A sentence that opens "is the ... plane", names a /v1 path, or points at apps/pubsub answers a question no buyer asked. Six of the seven are products revived AFTER those passes ran — 9640ea2e mq, 6db519e9 pubsub, a31e0ec9 flow, eafc8a82 engine, 48004de8 registry, 34663c49 auto — so their docs were written to the register the rule replaced. share was simply missed. (analytics was the eighth and is not here: 5a781b8a landed it from another lane while this was building, and its opener already holds the rule, so this takes that one rather than restating it.) auto "…executed as durable runs on the hanzo tasks plane" → Hanzo Auto: build a flow from triggers and actions, publish it, and watch every run. engine "…what it serves and what it runs on, read through /v1/engine" → Hanzo Engine: which models the serving runtime has loaded, and the GPUs under it. flow "…run agent workflows on the unified /v1 plane" → Hanzo Flow: build an agent workflow on a visual canvas, run it, and read every run. mq "…served at /v1/mq over the broker apps/pubsub embeds" → queue and stream admin for your org: create them, watch them drain, ack what you pulled. pubsub "…served to tenants at /v1/pubsub over the embedded Hanzo PubSub (NATS + JetStream) node this same package runs" → your message bus: publish, subscribe, and durable streams your apps read at their own pace. registry "the management plane over the platform's artifact registries…on the unified /v1 plane" → your container and package registry: push images, pull them back, see what you store. share "…folded into the ONE cloud binary" → a public URL for a service on your own machine, and a list of what you have open. NOTHING IS DELETED. Every clause the old openers carried — the tasks plane, the /v1 mounts, the broker apps/pubsub embeds, the JetStream node this package runs, the management-plane framing, the ONE binary — is still in the doc, one sentence lower, where the engineer it was written for still finds it. Only the ORDER changed: what the product is, then how it is built. Each opener now clears the whole rule: ≤90 characters after the "Package <name> is" the projections strip (81–91); no mounts/surface/subsystem/plane/binary; no /v1 path, file name, app reference or HIP number; no shouting. And each ends sentence one with a period on its own paragraph, so go/doc's Synopsis publishes the SENTENCE and not the paragraph — the failure mode o11y hit. That is the last of them: all 91 described tags now lead with the product. apps/share/client.go was already gofmt-dirty on main (struct tag alignment in the zrok overview response) and is now clean, since it is a file this touches. Regenerated FROM SOURCE, not hand-edited. The artifact diff is seven description lines — 1058 paths, byte-identical to main; no path, operation, schema or tool name moves. Co-authored-by: Hanzo Dev <dev@hanzo.ai>	2026-07-31 09:28:57 -07:00
hanzo-dev	eafc8a8267	engine: revive the product at /v1/engine — typed passthrough to the hanzoai/engine runtime ... The product repo (hanzoai/engine, Rust — `hanzo serve`, the OpenAI- and Anthropic-compatible inference server) stays the one implementation; cloud mounts its MANAGEMENT plane over an HTTP seam, apps/flow's posture: four typed ops proxying what the server genuinely answers today — the model table with load state, one model's state (a GET here over the product's POST-read seam, since its ids carry slashes), the host/GPU inventory with build capabilities, and a reachability lens carrying the build revision — each proven against a live hanzo-server end to end (live_test.go re-proves the loop on demand against a real serving process; the fake upstream pins the measured wire, plain-text /health included). Inference is deliberately NOT here: the fleet's ONE metered inference door is the OpenAI-compatible /v1 surface (apps/ai + the zen claim); a second completion door under /v1/engine would split billing, and the ledger pins it. The deployment is ONE shared runtime with no per-org primitive, so every read is a platform fact behind the IAM gate (validated principal or 403, before any upstream byte) and every mutation the server exposes (models/unload, reload, tune, re_isq, system/doctor) is REFUSED: an org-scoped route onto a shared runtime hands each tenant every other tenant's availability. The rest of the 22-path authored intent (deleted unserved in openapi d86248f) stays refused: clusters/jobs/ray/pipelines/gpus/serve-endpoints described a GPU cluster manager this product never was — those families live on the cluster plane (/v1/clusters, /v1/train/jobs, /v1/ml/models) where they are real. The ledger is a measured gate (typed_wire_test.go intentRefused), not a comment. Co-authored-by: Hanzo Dev <dev@hanzo.ai>	2026-07-30 22:48:22 -07:00