116 Commits
Author SHA1 Message Date
zeekayandHanzo Dev 5c5f80bd9f client: regenerate from hanzo-inc/cloud@7a3c9af7a5 (8.5.554)
Co-authored-by: Hanzo Dev <[email protected]>
2026-10-03 10:15:21 +00:00
zeekayandHanzo Dev 2426af558c client: regenerate from hanzo-inc/cloud@0d31b29c6f (8.5.553)
Co-authored-by: Hanzo Dev <[email protected]>
2026-10-03 10:01:28 +00:00
zeekayandHanzo Dev be5f1dff52 client: regenerate from hanzo-inc/cloud@470b2430b9 (8.5.550)
Co-authored-by: Hanzo Dev <[email protected]>
2026-10-03 09:46:59 +00:00
zeekayandHanzo Dev 8cfba6c51f client: regenerate from hanzo-inc/cloud@51c17eaeb5 (8.5.549)
Co-authored-by: Hanzo Dev <[email protected]>
2026-10-03 08:53:43 +00:00
zeekayandHanzo Dev e66aece713 client: regenerate from hanzo-inc/cloud@a61317fd93 (8.5.548)
Co-authored-by: Hanzo Dev <[email protected]>
2026-10-03 07:53:09 +00:00
zeekayandHanzo Dev 608ba2fd52 client: regenerate from hanzo-inc/cloud@1a819b53e3 (8.5.547)
Co-authored-by: Hanzo Dev <[email protected]>
2026-10-03 05:59:55 +00:00
zeekayandHanzo Dev 440b022036 client: regenerate from hanzo-inc/cloud@7936e46041 (8.5.544)
Co-authored-by: Hanzo Dev <[email protected]>
2026-10-03 01:53:21 +00:00
zeekayandHanzo Dev b898bf718e client: regenerate from hanzo-inc/cloud@ef4d66379c (8.5.542)
Co-authored-by: Hanzo Dev <[email protected]>
2026-10-03 01:20:03 +00:00
zeekayandHanzo Dev 2dd8c6f865 client: regenerate from hanzo-inc/cloud@d62601149e (8.5.539)
Co-authored-by: Hanzo Dev <[email protected]>
2026-10-03 00:41:54 +00:00
zeekayandHanzo Dev 21b5b15a44 client: regenerate from hanzo-inc/cloud@dfc8b040d3 (8.5.534)
Co-authored-by: Hanzo Dev <[email protected]>
2026-10-02 22:04:46 +00:00
zeekayandHanzo Dev e6d3482d1a client: regenerate from hanzo-inc/cloud@12a3344d6d (8.5.533)
Co-authored-by: Hanzo Dev <[email protected]>
2026-10-02 21:44:16 +00:00
zeekayandHanzo Dev 37cdf9313e client: regenerate from hanzo-inc/cloud@a5a00fba86 (8.5.532)
Co-authored-by: Hanzo Dev <[email protected]>
2026-10-02 21:06:59 +00:00
zeekayandHanzo Dev 1a9efbf822 client: regenerate from hanzo-inc/cloud@cabe3741ca (8.5.530)
Co-authored-by: Hanzo Dev <[email protected]>
2026-10-02 19:13:57 +00:00
zeekayandHanzo Dev 010e046347 client: regenerate from hanzo-inc/cloud@5075921e62 (8.5.528)
Co-authored-by: Hanzo Dev <[email protected]>
2026-10-02 18:48:48 +00:00
zeekayandHanzo Dev 890cc2f166 client: regenerate from hanzo-inc/cloud@1d09166a70 (8.5.516)
Co-authored-by: Hanzo Dev <[email protected]>
2026-10-02 08:28:27 +00:00
zeekayandHanzo Dev 7be95af3d4 client: regenerate from hanzo-inc/cloud@9ef824d8f9 (8.5.515)
Co-authored-by: Hanzo Dev <[email protected]>
2026-10-02 08:14:53 +00:00
zeekayandHanzo Dev 6ec90ecfca client: regenerate from hanzo-inc/cloud@ab687cefab (8.5.514)
Co-authored-by: Hanzo Dev <[email protected]>
2026-10-02 06:43:09 +00:00
zeekayandHanzo Dev de1d869fde client: regenerate from hanzo-inc/cloud@8307345627 (8.5.513)
Co-authored-by: Hanzo Dev <[email protected]>
2026-10-02 05:17:40 +00:00
zeekayandHanzo Dev 318f684d50 client: regenerate from hanzo-inc/cloud@0c2b14da5f (8.5.512)
Co-authored-by: Hanzo Dev <[email protected]>
2026-10-02 03:23:34 +00:00
zeekayandHanzo Dev 4b762d3a59 client: regenerate from hanzo-inc/cloud@9b7cbb92dc (8.5.511)
Co-authored-by: Hanzo Dev <[email protected]>
2026-10-02 02:25:10 +00:00
zeekayandHanzo Dev f6cc56fbc0 client: regenerate from hanzo-inc/cloud@fb00f045f9 (8.5.509)
Co-authored-by: Hanzo Dev <[email protected]>
2026-10-02 01:44:08 +00:00
zeekayandHanzo Dev 8dba6bb845 client: regenerate from hanzo-inc/cloud@c3b507ada2 (8.5.507)
Co-authored-by: Hanzo Dev <[email protected]>
2026-10-02 00:37:28 +00:00
zeekayandHanzo Dev 0d006d27b4 client: regenerate from hanzo-inc/cloud@b852e740ce (8.5.506)
Co-authored-by: Hanzo Dev <[email protected]>
2026-10-01 23:54:56 +00:00
zeekayandHanzo Dev c23f20cbaf client: regenerate from hanzo-inc/cloud@9b7f663b28 (8.5.505)
Co-authored-by: Hanzo Dev <[email protected]>
2026-10-01 23:08:56 +00:00
zeekayandHanzo Dev 3c485caf35 client: regenerate from hanzo-inc/cloud@b376f5505b (8.5.501)
Co-authored-by: Hanzo Dev <[email protected]>
2026-10-01 21:34:47 +00:00
zeekayandHanzo Dev d019bb67d4 client: regenerate from hanzo-inc/cloud@0a52a53e66 (8.5.500)
Co-authored-by: Hanzo Dev <[email protected]>
2026-10-01 19:39:01 +00:00
zeekay 379600adc8 client: regenerate from hanzo-inc/cloud@2774987ccc (8.5.164)
The client lane checks the committed client against the document
api.hanzo.ai serves now, not against the ref .spec-lock pins. Cloud
v1.833.257 (2774987c) went live after 8.5.163 was cut and rewrote the
POST /v1/decisions description (cad76e1a0: Jev by OpenRouter's vendor
ids), so the served document moved from 296b1f84 to 783f66a3 and every
push since has failed the check on ai_api.py's docstring. The drift
reproduces identically at e34ab7e1; nothing in this tree caused it.

This is the lane's own move, done by hand: .spec-lock names the served
revision and digest, the generator reruns over those bytes, uv.lock
takes what `uv run` wrote, and the version takes the next patch.
2026-09-29 13:53:29 -07:00
zeekayandHanzo Dev e34ab7e14c client: regenerate from hanzo-inc/cloud@efc1644bfe (8.5.163)
Co-authored-by: Hanzo Dev <[email protected]>
2026-09-29 17:17:07 +00:00
zeekayandHanzo Dev d044022152 client: regenerate from hanzo-inc/cloud@8eb2e12e26 (8.5.162)
Co-authored-by: Hanzo Dev <[email protected]>
2026-09-29 01:18:01 +00:00
zeekayandHanzo Dev 3335b2fa21 hanzoai 8.5.161: the import report runs under the interpreter its siblings fetch
Hanzo CI/CD / cicd (push) Successful in 2m21s
CI/CD / cicd (push) Successful in 2m21s
v8.5.160 regenerated the client and its release run passed the client check,
then stopped at declared-imports: the step called bare `python`, the runner has
none on its PATH, and exit 127 from a step that is report only ended the run
before anything was published. It now runs through uv like the three steps
beside it. Verified by running the whole test: block with no python on PATH.

Co-authored-by: Hanzo Dev <[email protected]>
2026-09-18 22:23:29 -07:00
zeekayandHanzo Dev 40cb597c2f client: regenerate from hanzo-inc/cloud@2314af8b90 (8.5.160)
Hanzo CI/CD / cicd (push) Failing after 2m6s
CI/CD / cicd (push) Failing after 2m7s
The committed client had fallen behind the API it projects: 116 modules the
document now names were missing, 13 it no longer names were still here, and
30 had moved. The release lane refuses to publish a projection that does not
match the document, so v8.5.158 and v8.5.159 were tagged and never reached
the index.

Regenerated from the document production serves (sha256 aa1b79d0797704608e25a3898adb2ca69fec82a03f74c09671c372b63066cafe),
with the driver at hanzoai/openapi@88ea26b — the same inputs the lane reads,
and the same +116 -13 ~30 it reported. The repo's own gate ran over exactly
these bytes: 121 api and 2675 model modules import, no class declares a field
twice across 2804 modules, and every example flow resolves its method names.

Co-authored-by: Hanzo Dev <[email protected]>
2026-09-18 17:28:47 -07:00
zeekayandHanzo Dev ea1940e3e3 hanzoai 8.5.159
Co-authored-by: Hanzo Dev <[email protected]>
2026-09-11 13:44:15 -07:00
zeekayandHanzo Dev 7824191215 feat: budget, policy, audit, search, kb and graph on one credential
Six capabilities hang off the client as first-class methods rather than as
generated operations a caller assembles for itself: budget (allowance, wallet,
tier, charged ledger), policy (one authorization question), audit (the org's
trail, read-only by construction), search (one ranked set over every corpus),
kb (the corpus you write and the connectors that fill it), and graph
(assertions with provenance and time). The same six words, the same method
names and the same answer type as the Go and TypeScript clients.

A refused budget and a refused policy are answers. Answer is a union of three
frozen types with a discriminant — Ok, Denied, Held — so a caller reads
"denied, and here is why" without catching, and reading .value off a refusal
raises it rather than handing back a half-answer. One rule maps HTTP to an arm:
a 202 whose body says held is a hold, 402 and the four refusal codes on 403 are
refusals, and a status that decided nothing raises. Every arm carries the
x-request-id, which is the word audit.Event.request uses too — the join that
lets a caller find the row the server wrote for the call it just made.

Auth is IAM and nothing else. The client exchanges its own clientId and
clientSecret for a short-lived access token (client_credentials,
client_secret_basic, RFC 8707 resource), holds it until shortly before expiry,
and re-mints once on a 401. It no longer accepts a bearer, so HANZO_API_KEY,
Configuration(access_token=) construction and result() are gone rather than
deprecated: two ways to hold one credential is the defect this removes. as_
still scopes to a subject and now mints from the client's own token.

hanzoai resolves its public names on first use, and the capability layer is
written over the wire rather than over the generated client, so importing the
six costs milliseconds instead of 2,700 generated modules.

ruff and ruff format are clean, mypy is clean over the thirteen new and changed
modules, and 106 tests pass. The two failures in test_smoke are the ToolsApi
name the current document no longer carries, and they fail at HEAD too. The
mint was exercised against the live hanzo.id, which answers invalid_client for
a credential it does not know; the six were exercised against a stub asserting
the exact request and decoding the shapes cloud's own schemas declare.

examples/six runs the whole thing as a caller would.

Co-authored-by: Hanzo Dev <[email protected]>
2026-09-10 15:01:41 -07:00
zooqueenandzeekay 9492c358cc a uv source says where, not that anything depends on it
The hanzo-tools-core suite imports ten sibling tool distributions and
asserts an exact TOOLS count, but they were only ever named in
[tool.uv.sources]. A source resolves a package; it does not make anything
require one, so `uv sync --dev` uninstalled all ten and left the suite at
22 failed / 2 passed. Naming them in the dev dependency-group restores
24 passed, 12 skipped from a clean sync.

pkg/hanzo-dev-py never existed — the directory is pkg/hanzo-dev — so the
eight excludes and workspace members spelling it were inert. mypy.ini is
the config that actually loads, and with the name corrected it stops
type-checking a package it was written to skip (18 errors -> none).

cloud.py cited APIKeyPrefixes as the authority on key prefixes; no such
symbol exists. isAPIKey is the real gate and it admits hk-, sk-, pk-, fw_
and hz_, so NO_KEY was telling callers the wrong two.

(cherry picked from commit b2024662400895e456d4b3811fd286565e4e7109)
2026-09-03 23:39:20 -07:00
zeekay 25c5297839 Read the model catalogue as the typed object it now is
GET /v1/models declares a response schema, so the generator emits
AiApi.get_models() -> AiModelList and no longer emits ModelsApi at all.
The example imported the class that folded and failed at import, which is
the whole examples gate.

It reads the typed object now instead of the raw body and its own JSON —
the change its docstring said would arrive the day the schema landed.
2026-09-01 10:11:09 -07:00
zeekay 301f737b45 release 8.5.156
One product, one number: the API and every client cut from it answer to the
version cloud's release train mints, so a reader holding 8.5.156 can name the
release it came from. The clients had drifted to their own counters -- 8.5.89,
8.5.91, 0.1.0, 0.1.0-alpha.5 -- because the fanout that carries the number can
only run in check mode on this forge and never writes.
2026-08-28 08:55:51 -07:00
zeekayandHanzo Dev accd79d1c4 release: 8.5.89 — the V8 launch version
Hanzo 8 is one product on one number. The API, the six generated clients, the
CLI and the console all answer to 8.5.89, so a client version names the API it
was cut from without a compatibility table.

8.5.89 is the first cut past the highest 8.x anyone had reached (@hanzo/console
8.5.88). Every register moves FORWARD into it; nothing is renumbered backwards.

Co-authored-by: Hanzo Dev <[email protected]>
2026-08-20 14:08:18 -07:00
zeekayandHanzo Dev 78f4af1e1f release: 3.2.14 — the client regenerated onto cloud@dd98c965
Co-authored-by: Hanzo Dev <[email protected]>
2026-08-20 10:25:44 -07:00
zeekay 0f5676c200 one release path, and the docs say the one that runs
RELEASE.md described GitHub Actions, GitHub secrets and three bin/ scripts
that each took a PyPI token off the environment. None of that publishes this
repo — .hanzo/workflows/publish-pypi.yml does, reading the token from KMS —
so the scripts are gone and the page describes the lane, its tag mapping, and
what to check before a tag makes a version permanent.

LLM.md carries the published state: hanzoai 3.2.13 with get_keys/get_tools,
and the KMS route that a 404 will otherwise misreport as a missing secret.
2026-08-14 17:51:02 -07:00
zeekay 80c31f3534 publish-pypi: read KMS at the route KMS serves
The job asked for /v1/kms/orgs/hanzo/secrets/<path>/<key> and parsed
.secret.value. KMS serves GET /v1/kms/secrets/<path>/<key>?env=<env> and
answers {"env","name","value"}, taking the org from the token's own claim,
so every read 404'd and every release reported the credential unseeded —
including hanzo/prod/python-sdk-publish/PYPI_TOKEN, which is there.

Root to 3.2.13, README install line names it. hanzo-research declares its
readme, license and authors, so its page carries them.
2026-08-14 17:42:58 -07:00
zeekay 4998a916fd the client sends the credential the document now declares
hanzoai/cloud@113cf7d6 declares components.securitySchemes.bearer and applies it
document-wide, so regenerating writes a populated Configuration.auth_settings()
and auth_settings=['bearer'] into 2498 call sites; ApiClient._apply_auth_params
sets Authorization: Bearer <token> from access_token, which was read by nothing
before. Four call sites carry an empty list — exactly the operations the document
marks security: [] (get_models, get_models_providers, get_commands,
get_openapi_json) — so the public routes still go out with no credential.

examples/client.py drops the header_name/header_value compensation and passes
access_token. examples/models is a new flow on the public catalog: it runs before
a reader has a key, which makes the install checkable in one command.

Proven on api.hanzo.ai, not by reading: examples.models prints 112 models with no
credential; examples.hello returns the caller's keys with a real sk- and 403
"sign in to manage API keys" with a bogus one.
2026-08-14 17:22:30 -07:00
zeekay 241ca6dc59 the front door tells the truth about the client behind it
README: PyPI serves 3.2.1 and this tree is 3.2.11, so the install line is the
git one. Between the two the default version left the operation ids — 3.2.1
carries get_v1_keys/get_v1_tools (182 api modules, 2172 models) and this carries
get_keys/get_tools — so `pip install hanzoai` above a `get_keys()` quickstart
hands the reader a client that cannot run it. Counts are measured off the pinned
document: 1814 paths, 2479 operations, 191 tags + default_api = 192 API classes
over 2460 models, 2659 importable modules.

Auth was wrong everywhere and it was the same root cause: the document declares
no securityScheme, so every operation got an empty auth_settings and
Configuration(access_token=…) is read by nothing. Serializing get_keys from such
a Configuration produces a request with no Authorization header at all — the
five flows have been calling anonymously and reading the refusal as a bad key.
examples/client.py now passes the bearer through ApiClient's header_name/value
pair, verified against a local server that echoes what it received, and a smoke
test pins both halves so the day cloud emits the scheme, the test fails and the
header moves back into Configuration.

The examples gate resolved class names and stopped there, which is how `money`
and `tools` once passed it while every call in them named a method that no
longer existed. It now walks the syntax tree for attribute accesses on anything
bound to a *Api and asks the class: ten names resolve, and a stale get_v1_tools
fails in the same second the import passes.

Deleted five example scripts that imported hanzoai.Hanzo, hanzoai.cluster,
hanzoai.agents and hanzoai.completion — none of which exist — or were dict
literals captioned "in practice this would be called through the MCP interface";
compileall passed all five, because syntax is not a claim. Deleted three docs
that were fabrication rather than drift and that nothing rendered: FEATURES.md,
QUICKSTART.md, GPT5_ORCHESTRATION.md.

pkg/hanzo-agent said `pip install hanzoai` and `from hanzoai import Agent,
Runner`; the client has no Agent. Its own `full` extra resolved to
hanzoai[web3,tee,marketplace,cli], extras the client does not declare, so it
installed the client and none of the extensions. pyproject said BSD-3-Clause
while LICENSE is the Apache 2.0 text. test_smoke imported tracker_api and no
/v1/tracker path is emitted any more, so the suite carried a failing test naming
a module the client does not have; it reads analytics_api now, off the client.
2026-08-14 14:31:08 -07:00
zeekay 1137336b67 3.2.11 — 3.2.10 was already taken
A regeneration on 2026-08-09 claimed v3.2.10 and tagged it, but that commit
never reached main, so main went on declaring 3.2.10 too and I bumped onto
the same number. Two trees cannot share a version: the tag names the other
one.

The next free patch is what the version should have been. Read the TAGS, not
just pyproject.toml — the tag is where a version is claimed.
2026-08-14 11:56:22 -07:00
zeekay d1fa0676d1 3.2.10 — the client says what the wire says
Regenerated from hanzoai/cloud@6a719cdc (.spec-lock carries the ref and the
digest). 3.2.9 was a projection of a document 343 commits old, and in between
the operationId stopped carrying the default version: 5196 method names the
client published — `get_v1_tools`, `post_v1_agent`, every one of them — name
operations the document no longer declares. None remain.

The id is one identity, not four. An operationId is the SDK method, the MCP
tool name, the CLI spelling and the by-name key, so a client that keeps the
old spelling does not merely look stale — it teaches a name nothing answers to.

Shape: 1813 paths / 2479 operations -> 192 api modules + 2460 model modules,
all 2659 importable.
2026-08-14 11:01:13 -07:00
zeekay 9cd2d37717 3.2.9 — the version the client regenerated at
The regeneration onto hanzoai/[email protected] landed without moving this, because
the bump it carried named a version two releases behind: another line had already
cut 3.2.7 and 3.2.8 while it was in flight. The tree is right and the number was
not.
2026-08-08 22:50:10 -07:00
zeekay 110c5525c0 client: regenerate from hanzoai/[email protected] (3.2.8) 2026-08-09 02:58:18 +00:00
zeekay d8bcab71a7 client: regenerate from hanzoai/[email protected] (3.2.7) 2026-08-08 23:08:20 +00:00
zeekay 8974dc7af2 client: regenerate from hanzoai/[email protected] (3.2.6) 2026-08-08 21:22:09 +00:00
zeekay cafae37f4e client: regenerate from hanzoai/[email protected] (3.2.5)
The document types 1495 of its 2459 operations, up from 1242. 87 new model
modules carry the response shapes ai, eval, functions, domain, experiments,
security and benchmark now declare, so those calls return a typed object
instead of a dict. 2524 generated modules import clean.

.spec-lock moves from v1.801.497 to @ffbc86064, which is v1.801.498.
2026-08-08 14:20:07 -07:00
zeekay fcec4c3d80 client: regenerate from hanzoai/[email protected] (3.2.4) 2026-08-08 20:05:59 +00:00