hanzoai/cloud's release now sends `repository_dispatch: spec-update` carrying
(version, sha, spec_sha256). hanzoai/ci's `client:` lane fetches openapi.yaml AT
THAT SHA, REFUSES if the bytes hash to anything else, regenerates, writes
.spec-lock beside the code, and — only after this repo's own `test:` block has
passed over exactly those bytes — commits and cuts a patch.
NOTHING HAS EVER SENT THAT EVENT. The assumed sender was hanzoai/openapi, which
has zero workflows; where a generate.yml existed at all it had run twice in its
whole life, both failures, or never. That is the hole this closes, and closing
it is why the document moved: from hanzoai/openapi hanzo.yaml (hand-merged, 1742
paths, fed by nothing) to hanzoai/cloud openapi.yaml — smaller at 1058 paths,
emitted from the code by each app's own router, and gated on every cloud release
by a drift check that regenerates it from source. A smaller true document beats
a larger unverified one.
The lane is defined ONCE, in hanzoai/ci. What was hand-rolled per repo is
deleted with it.
Co-authored-by: Hanzo Dev <[email protected]>
pkg/hanzoai/cloud is generated, and until now this was the only client of the
seven with no in-repo way to produce or verify it. The driver lives in
hanzoai/openapi (generate.py + sdks.yaml), so a checkout of python-sdk alone
could not even ask whether its committed client matched the document.
scripts/generate.sh is a CALL SITE, not a second driver — the same eight lines
java-sdk and kotlin-sdk already run, ending in `generate.py python --repo $PWD`.
That distinction is the whole point: the previous scripts/generate.sh here was a
real second driver, it did `rm -rf pkg/hanzoai`, and it was deleted for that.
This one cannot, because generate.py owns exactly the one take path sdks.yaml
names.
Measured against hanzo.yaml@9781a56: +159 -110 ~135. That drift is what the gate
exists to refuse; it is reported here, not silently regenerated, because the
fleet's regeneration is one coordinated wave and not seven.
Co-authored-by: Hanzo Dev <[email protected]>
pkg/hanzoai/cloud/ (2163 files) has existed on disk untracked and never shipped.
This commits it, so the operator surface cloud already serves is finally callable:
AdminApi.plugin_admin_plugins / _enable_plugin / _disable_plugin / _reload_plugin
Generated by hanzoai/openapi `generate.py python` from hanzo.yaml (1885 paths,
69 merged per-service specs). Consumed: cloud 8143fc0e, openapi f581a0e.
One driver, so delete the second one. scripts/generate.sh fetched the spec itself
and then did `rm -rf pkg/hanzoai` + copied generator output over it — which would
have deleted the hand-written config/mcp/protocols/session/zap/api_response
modules AND the new cloud/ tree. Nothing referenced it. hanzoai/openapi's
generate.py + sdks.yaml is the only way now; LLM.md records the pipeline.
`import hanzoai.cloud` raised ImportError as generated. hanzo.yaml has 23 tag
groups differing only by case; openapi-generator maps both spellings to one
module, and for AI/ai, API Keys/api-keys and MCP/mcp it then emits imports for
classes it never wrote (AiApi vs AIApi). Stripped those 9 dead lines. The same
collision silently drops 127 of the 411 operations in those groups — that one is
upstream and only a single tag spelling per service fixes it; noted in LLM.md.
Version: 3.1.1 -> 3.1.2, patch only. pkg/hanzoai/__init__.py said 1.0.0 (the
generator default) — now resolved from the installed distribution, same pattern
as hanzo_cli/hanzo_iam in f453dae8. uv.lock refreshed to match committed pkg
versions. test_smoke.py locks the cloud import, the four plugin ops, and that
__version__ equals the distribution: 6 passed.
Co-authored-by: Hanzo Dev <[email protected]>
raw.githubusercontent.com/hanzoai/openapi/main/hanzo.yaml 404s (openapi is a
private repo), so every spec-update regen failed at the fetch. Fetch hanzo.yaml
through the GitHub Contents API with a SPEC_TOKEN (repo/contents:read on
hanzoai/openapi) instead. Local SPEC=... override unchanged.
Co-authored-by: zeekay <[email protected]>
zeekayandHanzo Dev