823 Commits
Author SHA1 Message Date
zeekayandHanzo Dev 39bc72bc09 Give the install check a form the wheel carries
The line under `pip install hanzoai` was `python -m examples.models`, and
examples/ is in the sdist only — hatch's wheel target is pkg/hanzoai. So
the first command in the README answered ModuleNotFoundError to everyone
who installed the package the way the line above told them to.

Co-authored-by: Hanzo Dev <[email protected]>
v8.5.158
2026-09-10 21:50:23 -07:00
zeekayandHanzo Dev 30a465e537 Release through the shared lane, not a copy of it
publish-pypi.yml was a per-repo spelling of a rule the whole estate
needs, and it was the estate's only one: a Python repo without a copy
of this file could not publish at all. `pypi:` in hanzo.yml now names
what ships and hanzoai/ci ships it, so the rule has one home.

The hardcoded package list goes with it. A glob over pkg/ cannot fail
to notice a package added beside it, and the tag is matched against
each pyproject's own name rather than against a case list, so all four
tag shapes already in this repo's history resolve to the same
distributions they did before.

Co-authored-by: Hanzo Dev <[email protected]>
2026-09-10 21:44:51 -07:00
zeekayandHanzo Dev 234c2d8cf1 Prefer tgrep where the tree carries an index
Trigram index prunes files a query cannot match: 23ms against ripgrep's 78ms
for an absent symbol, which is most of what a search asks. It loses where many
files match (128ms against 78ms), and with no index it scans everything and is
slower than plain grep — so the index is the condition, not the binary.

Co-authored-by: Hanzo Dev <[email protected]>
2026-09-10 17:24:51 -07:00
zeekayandHanzo Dev 2b0401db54 ci: confirm a push still schedules a run
Co-authored-by: Hanzo Dev <[email protected]>
2026-09-10 17:24:51 -07:00
zeekayandHanzo Dev 206be715d8 ci: verify the GitHub->forge inbound leg delivers
No file changes: this exercises the ingest path only, so the forge head
must advance to this commit without a build being cut.

Co-authored-by: Hanzo Dev <[email protected]>
2026-09-10 17:24:51 -07:00
zeekayandHanzo Dev 0da7a4185c fix(six): one word, one body, one shape across the three SDKs
Thirteen places where this SDK and the other two answered the same question
differently. Every one is now what the served handler reads, or what HIP-0044
says where the handler is silent.

Where this SDK was already right, the other two moved: search normalizes the
knowledge kind in both directions, `Page.total` stays the server's own count,
and `put` picks its method from the name. Where it was not:

- kb.Import carries what the handler answers. `/v1/knowledge/import` writes
  {format, imported, pages} (knowledge/import.go); this modelled `imported`
  alone, so a caller could not see which pages landed.
- Fact carries the server's three. `GET /v1/graph` serves twelve members
  (graph/typed.go, wireFact) and no other route hands back an assertion's
  content address, so projecting the nine an asserter states made a read lossy
  with nothing to recover it from. `id`, `by` and `knowable` arrive read-only
  and `write()` never sends them.
- graph.extract and graph.ingest take a Source. Both routes bind the same
  {source, subject, text, at} (graph/semantic.go, graphSourceIn), so it is one
  value — and the first positional argument is now the same thing here as it is
  in the other two.
- import_(format, data, project) — the order the contract writes and the other
  two take. It was (export, *, format).
- A body carries what somebody set. `send` dropped None from the query and left
  it in the body, so `search.find` posted {"index": null, "offset": null,
  "project": null} where the other two omit the key: three requests for one
  call, and cloud asked to read a value where there is none. Audit's pageSize
  and p go the same way — the route's own defaults are the same 100 and 1, so
  an unset term is one the route decides identically, and `all` pins the size it
  walks at because it needs to know the page length.
- A write body is field data and nothing else. `url` belongs to a source, and an
  empty title is left out so the doctype names the required field that is
  missing rather than being handed a blank one.
- kb.list takes order and kb.links takes a project. `/v1/framework/{doctype}`
  serves order_by and `/v1/knowledge/graph` serves ?project=.
- policy_denied and entitlement_required do not exist. Neither string appears
  anywhere in hanzoai/cloud, so REFUSED is the two codes it does emit. A 403
  read as denied on an invented code would hand an unauthenticated caller a cure
  for a refusal nobody made.
- One refusal reader, by named fallback: code from `code` else `error`, reason
  from `detail` else `message`, cures from `cure`. The gate's own `reason` —
  "unpaid", "unresolved" — names the admit leg that failed rather than
  explaining anything, so it is dropped, and `title` is not a refusal member.
- Money counts minor units, not cents: hundredths for USD, whole yen for JPY,
  thousandths for KWD.
- Balance.reserved, not held. The wire says `holds`; `held` is an arm.
- Vocabulary.rules, because it is a list. The wire member stays `rule`.
- The fourth outcome is Fault, not the generated client's ApiException. It is
  the one shared concept whose name a reader could not carry between languages,
  and an exception from the generated layer is not this layer's vocabulary.
- A client with no credential builds. It raised at construction, which is a
  process that cannot start where the other two are a process whose first call
  fails — and the first call is where the credential is actually needed.

HIP-0044 is amended where the code was right and the document was not.

ruff check, ruff format --check and mypy clean on every changed file; 109
passed. The two test_smoke failures are pre-existing (ToolsApi is absent from
the generated tree) and reproduce on a stashed working copy.

Co-authored-by: Hanzo Dev <[email protected]>
2026-09-10 16:26:15 -07:00
zeekayandHanzo Dev c2c8b8fd11 fix(six): ask the policy question about an org-rooted object, as the other two do
The example asked about "graph:hanzoai/python-sdk". The route parses `path` and
refuses one whose first segment is not the caller's own org, so that question
could only ever come back refused. It now reads the org off the wallet account
the budget step already named — the same construction go-sdk and js-sdk use —
and asks about "<org>/graph".

Co-authored-by: Hanzo Dev <[email protected]>
2026-09-10 15:31:43 -07:00
zeekayandHanzo Dev 0a8e3272a0 fix(six): send the body /v1/authz/check reads, and stop stamping instants nobody set
policy.check was built from the route's OpenAPI description, which is stale.
The handler cloud pins — hanzoai/authz v1.10.37, serve/use.go — binds
{subject, verb, path} and answers {allow, subject, verb, path}; a body of
{sub, obj, act} gets 400 "subject, verb, path required". go-sdk and js-sdk both
send the served spelling. The caller-facing surface is unchanged: check(sub,
act, obj) -> Decision{allow, sub, act, obj, reason}.

graph left an unset instant on the body as "". Cloud reads an absent `seen` as
`at` and an absent `as_of` as now, but reads "" as a timestamp it refuses:
POST /v1/graph/ingest with at:"" answers 400 timestamp "" is not RFC 3339. An
instant nobody set is now left off.

kb.Edge takes PEP 8's keyword escape, from_ and to, rather than renaming the
pair to source and target — the word is `from`, which is what the other two
spell it. Document names and connector providers are escaped into their path
segment, as they already are in Go and TypeScript.

Co-authored-by: Hanzo Dev <[email protected]>
2026-09-10 15:28:12 -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
zeekayandHanzo Dev e450125523 Drop the sync workflow that never ran
It has produced no run on the forge or on GitHub since it was added.
A workflow file that never fires still evaluates on every replayed
ref, so it is a hazard rather than a lane.

Co-authored-by: Hanzo Dev <[email protected]>
2026-09-09 00:27:03 -07:00
zeekayandHanzo Dev 792933d473 Move the workflows to .github/workflows
The forge reads .github/workflows natively and github.com reads nothing else,
so one directory serves both planes instead of two conventions that disagree
about which one is live. The reusable in hanzoai/ci already lives there, so a
caller naming that path now resolves to a file that exists.

Co-authored-by: Hanzo Dev <[email protected]>
2026-09-08 19:01:40 -07:00
zeekayandHanzo Dev d291f0f321 ci: a runner label names the platform, not the org
hanzo-build-linux-amd64, lux-build-linux-amd64, zoo-build-linux-amd64 and
every other org-prefixed spelling all meant the same machine. Which org a
job belongs to does not change which host can build it, so the org bought
one pool name per org per arch and each could go stale on its own -- the
evo host alone answered to fourteen names for one label.

One vocabulary now: linux-amd64, linux-arm64, macos-arm64, win-amd64. The
generic labels every plain workflow uses (ubuntu-latest, self-hosted) are
untouched, so naive CI keeps working.

Co-authored-by: Hanzo Dev <[email protected]>
2026-09-08 12:08:07 -07:00
zeekayandHanzo Dev 4ba314672d fix: call the pipeline at the address it actually lives
hanzoai/ci keeps the reusable at .github/workflows/build.yml — the one path
both planes resolve, since github.com reads a reusable only from there and the
forge reads it too. The v1 tag moved with it, so a caller still naming
.hanzo/workflows/build.yml asks for a blob that is not in the tree:

  InsertRun: read hanzoai/ci@v1:.hanzo/workflows/build.yml: object does not exist

The caller itself stays at .hanzo/workflows/cicd.yml on purpose: github.com has
no runner for these labels, so a caller placed there could never be scheduled.

Co-authored-by: Hanzo Dev <[email protected]>
2026-09-08 01:14:30 -07:00
zeekay 9e93ffbeb2 Name the rest of the stack without importing it
`import hanzo` ran the CLI's module body, so it needed click, rich, httpx and
everything else in the list before it could tell you its own version — on a
bare interpreter it did not import at all. It also read `__version__` back off
this module from `cli`, a cycle that only worked because the assignment
happened to sit above the import.

Both go away by naming things instead of importing them. `__getattr__`
(PEP 562) resolves a member on first touch and caches it, so `hanzo.cloud`
costs nothing until somebody wants the cloud client, and the second touch is a
dict lookup. A member that is not installed says which distribution to install
rather than raising ModuleNotFoundError from somewhere inside us.

This is the shape the npm package and the Rust crate already had: one front
door, everything behind it, nothing loaded that was not asked for. One table
maps a name to its distribution, so adding a member is one line.
2026-09-05 18:15:02 -07:00
zeekay 7f4e176d57 Regenerate against the document the deployment answers for
The projection these were generated from was a month old and predated the
compute migration, so every one of them described /v1/visor — which the API
serves at zero paths now. That is why a hand-written console client and a
generated one had drifted the same way at the same time.

No /v1/visor path survives here. The word still appears as a source-plane
value and inside gvisor and supervisor, which are not this rename.
2026-09-05 18:07:44 -07:00
zeekayandHanzo Dev eb953b9fd5 test_smoke: billing takes the seat crm no longer holds
The document at the pinned ref names no `crm` tag and serves no /v1/crm,
so `hanzoai.cloud.api.crm_api` is a module the generator had nothing to
write — the import has raised ModuleNotFoundError since the emission that
dropped it.

This is the document's call, not a generation defect. The client emits one
module per tag and its 120 modules are exactly the 120 tags api.hanzo.ai
declares, with no difference in either direction; cli's spec/cloud.json,
projected from this same ref and digest, likewise carries neither the tag
nor the routes. So the expectation moves to the spec rather than the
client moving to the expectation.

Unlike tracker, analytics and chat before it, crm did not fold into
another product: contacts, companies, opportunities and applications have
no successor address anywhere in the document. billing replaces it because
it has been in every emission since the first generated client, which is
the property the test is really asserting — that whole products, not just
the AI routes, reach the SDK.

Co-authored-by: Hanzo Dev <[email protected]>
2026-09-04 00:09:01 -07:00
zeekayandHanzo Dev e740bb318b test_tenant: the keys operation lives on IamApi now
The regenerated client folded KeysApi into IamApi, so the tenant test
serializes `_get_iam_keys_serialize` to read the Authorization header it
asserts on. Same path under test — mint, cache, auth_settings — one class
name later.

Co-authored-by: Hanzo Dev <[email protected]>
2026-09-03 23:49:01 -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
zooqueenandzeekay a9330efb5c one credential, one subject: the scope rides the key, not the argument
An operator holds one key and serves N customers. Until now every call it made
on a customer's behalf was indistinguishable from every other, and nothing in
the SDK could tell them apart.

`Client.as_(subject)` binds a client to one of them. IAM mints a short-lived
token for that subject — POST hanzo.id/v1/iam/tokens/issue?id=…, on IAM's own
host, the subject in the query, the grant read off the key — and the scoped
client sends it on every call, holds it until it nears expiry, and re-mints once
on a 401. No operation takes a user id, so there is none to pass wrongly.

The other half is the answer a policy holds for a human. It arrives as 202, and
202 is a 2xx: a caller who only checks for a raise reads a queued call as one
that completed and returned nothing, because no operation declares a schema for
it. `Client` raises `Held` instead, carrying the approval that gates it, and
`result()` hands the same outcome back as a value whose two arms share no member
— an `Approval` has no `value`, a `Done` has no `id`. Discrimination is on the
body, not the status: the dozen long-running operations whose 202 means
"accepted" carry their own schema and pass straight through.

`Client` is the generated `ApiClient` plus those two behaviours, so all 196
generated API classes take it unchanged and there is one client, not two.

25 tests against a stub with `RESTClientObject`'s signature — the only thing the
mint and the client ever call — pin the mint URL and query, the camelCase
response, the cache and its skew, the re-mint on 401, and that a hold raises.

(cherry picked from commit cda66ab6a5e9f51d50e161bbb3dfe96648688fa2)
2026-09-03 23:39:08 -07:00
zeekay f91d612e2c Regenerate against the current cloud document 2026-09-03 16:15:52 -07:00
zeekay fae213a6c0 Follow the cloud surface through the git rename 2026-09-03 16:15:51 -07:00
zeekay 85ad519b16 every Hanzo dependency is the version npm serves
Ranges drift once nothing moves them: a caret that has not been rewritten
since it was written pins whatever was current that day, and an exact pin
cannot even take a patch. Both are updated here.

One line per package, so a surface reads the same components, the same
tokens and the same face as every other one.
2026-09-02 02:01:33 -07:00
zeekay f43d8ae283 every Hanzo dependency is the version npm serves
Ranges drift once nothing moves them: a caret that has not been rewritten
since it was written pins whatever was current that day, and an exact pin
cannot even take a patch. Both are updated here.

One line per package, so a surface reads the same components, the same
tokens and the same face as every other one.
2026-09-01 16:13:48 -07:00
zeekayandHanzo Dev 7c2cd20df4 Merge branch 'tasks/native-http-sdk' into main
Co-authored-by: Hanzo Dev <[email protected]>
2026-09-01 10:16:41 -07:00
zeekayandHanzo Dev 1b0b40fe34 Merge branch 'fix/zap-read-what-luxd-emits'
Co-authored-by: Hanzo Dev <[email protected]>
2026-09-01 10:12:22 -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
zeekayandHanzo Dev 39017ee7a1 hanzo-tasks: the client is the /v1/tasks contract, not a Temporal wrapper
The package dialed Temporal over gRPC, a transport hanzoai/tasks removed in
v3, so nothing it did could reach the engine. It is now the HTTP contract the
engine serves under /v1/tasks/namespaces/{ns}: start, signal-with-start, list,
describe, signal, query, cancel, terminate, reset, history, and schedules — one
method per route, IAM bearer, tested against the request shapes. A workflow's
body still runs in a Go or TypeScript worker.

Co-authored-by: Hanzo Dev <[email protected]>
2026-09-01 07:58:30 -07:00
zeekay 588a790b4b Regenerate against the current cloud document
The lock sat at 574d1f1d while the product moved on. The team surface
stopped at rooms — no messages path, no way to open one — so anything
built on this client had to reach past it with its own HTTP calls, which
is the duplication a generated client exists to prevent.
2026-09-01 02:21:39 -07:00
zeekay c7355b81fe Take the catalog cloud now writes 2026-08-31 23:42:47 -07:00
zeekay eab5541a89 Stop handing a model the secrets the fleet withholds
Nine per-service packages registered a hanzo.tools entry point and sat in
hanzo-mcp's default dependencies, so installing it put them in a model's tool
list beside the unified tool and without its filter.

hanzo-tools-kms offered inject, which lists a path and reads every secret at it.
hanzo-tools-iam offered create_user, delete_user and the token and session reads.
cloud withholds all of them from an agent; these were a second way to the same
API, so the rule held on one path and not the other.

The auto-registration is withdrawn, not the packages: they stay importable for a
human at a CLI, which is where reading a secret is a legitimate act. An agent
reaches all eight through the unified tool, verified against the live document.

mpc keeps its registration because the fleet has no equivalent, and auth keeps
its because it reads the caller's own claims rather than another identity's.
2026-08-30 20:08:02 -07:00
zeekay 42139d1849 Offer what the fleet offers, not what the contract lists
The unified tool derived its surface from /v1/openapi.json, which describes the
API rather than what a model may be handed. cloud keeps an operation off the
agent surface when its name discloses a bearer secret or when a mutating verb
acts on identity — post_iam_users is in the contract and refused at /v1/mcp, so
this tool offered an identity mutation the fleet declines.

The document still supplies each operation's method and path, which a caller
needs to make the request; the generated catalog supplies which are offered. Two
facts, one source each, and the rule is asked of cloud rather than restated. An
unreadable catalog offers nothing, because failing open widens the surface
silently.

Two aliases pointed at names the fleet had left behind, mapping callers off the
live surface. A synonym may only point at a name it serves.

A fixture naming no operations is not exercising the offer rule and now says so,
rather than the default being weakened to keep it green.
2026-08-30 19:52:51 -07:00
zeekay badff3db49 Read the fleet from the same catalog the other runtimes do
Python addressed the cloud through ten hand-written packages while TypeScript and
Rust read a generated catalog, and the hand-written ones had drifted: paas is
platform, storage is s3, auth folded into iam, and commerce asked for plurals the
fleet does not publish.

hanzo-tools-cloud embeds the file those two already embed, so the three cannot
disagree about what the API offers — a test compares them by digest. One routing
tool over 114 subsystems rather than 114 tools, for the reason the fleet groups
its own.

Naming a subsystem the fleet does not serve is answered before the credential
check: demanding a key for something that does not exist sends the caller to fix
the wrong thing.
2026-08-30 17:05:32 -07:00
zeekay b4b0f3bf67 Ask commerce for what commerce serves
The base was api.hanzo.ai/api/v1 and then /v1; both 404. The surface is under
/v1/commerce, and the fleet names each resource in the singular — product,
collection, store, discount, webhook — so every read here asked for a plural that
does not exist.

Orders and users have no address at all: an order is reached through the store
that holds it, and a user is IAM's. Both now say which, because a 404 reads to an
agent as an empty result rather than as a wrong question.
2026-08-30 16:42:08 -07:00
zeekay 9194042947 Merge remote-tracking branch 'origin/main' 2026-08-30 16:29:35 -07:00
zeekay b1ab1198c1 Address the estate at /v1, not /api/v1
Two defaults carried an /api/ prefix this estate does not serve: the commerce
base and the DNS endpoint.

Neither resource answers at either spelling today — api.hanzo.ai serves commerce
carts under /v1/commerce and none of the products or orders this tool asks for,
and dns.hanzo.ai answers nothing at all. The prefix is the part that was wrong
either way; what those tools reach is a separate question.
2026-08-30 16:29:33 -07:00
zeekay 90e00d9bb7 State a version once
A version written into a manifest is written into every manifest that wants it,
which is how eslint came to exist in a hundred and four forms across this estate
and how a package came to resolve twice at run time. The catalog moves the number
out of the manifest: a manifest names the package, the workspace names the
version.

Four are held below their latest because the newer release cannot be used, and
the reason is recorded rather than the version alone: @noble/hashes 2 renamed
every subpath the web3 stack imports, @splinetool/runtime 2 depends on a package
that was never published, @dynamic-labs 5.4.1 the same, and react-resizable-panels
3 points its types condition at the bundle.
2026-08-29 13:46:58 -07:00
zeekayandHanzo Dev 38c2c0eb74 Read both wire versions, the way the canonical parser does
zap.wire.parse admits versions 1 and 2, which is the set Go's zap.Parse admits;
this layer admitted only the one it emits, so a frame from luxd — which emits 2 —
was refused by a reader sitting on top of a parser that would have taken it. A
reader that refuses what the network sends is a different protocol.

Accepting both changes nothing about what this layer emits.

Co-authored-by: Hanzo Dev <[email protected]>
2026-08-29 13:09:36 -07:00
zeekayandHanzo Dev 95df0efbcf Read the wire version the network actually sends
luxfi/zap v1.2.6 — the version luxfi/node ships — emits wire version 2 by
default, and Go's Parse accepts 1 and 2 alike. This layer accepted only 1, so
every frame luxd sends was refused at the header.

The module header already says the codec constants come from zap.wire "so they
can never drift", and the canonical zap.wire had this right: VERSION1,
VERSION2, and a parse that admits both. The drift was here — the guard was
re-implemented locally against the single emitted VERSION instead of the
accepted pair. Source both constants from the canonical wire and admit what it
admits, so the claim in the header is true rather than aspirational.

Add the vectors that would have caught it. The suite round-tripped this layer
against itself; these are bytes captured from github.com/luxfi/zap v1.2.6 by
calling EncodeNodeIDHandshake, so they fail if this layer and the Go module
ever disagree. They also pin the accepted set exactly — 0 and 3 refused —
because admitting a frame the network refuses is as wrong as refusing one it
accepts, and pin that our handshake equals Go's in every byte but the version.

Co-authored-by: Hanzo Dev <[email protected]>
2026-08-28 23:38:41 -07:00
zeekay 4662534cd9 Regenerate: the AI surface says what it answers
288 of hanzoai/ai's 294 operations now declare a response, against 1 before.
GET /v1/models, POST /v1/chat/completions, /v1/embeddings, /v1/messages —
every address a client actually calls — used to reach this client untyped,
because cloud's relay carried an operation's sentence and dropped the shapes
it named. It carries both now.

Fleet-wide the document goes from 69% to 81% of operations declaring what
comes back, which is where the ~208 new models here come from.
2026-08-28 15:53:34 -07:00
zeekay 6b5e0734e7 One version per package, on the current release
Every dependency on a @hanzo/@luxfi/@zooai package names the same version across
the repo: a catalog entry where pnpm supports one, an exact pin where it does
not, and a range only where a peer genuinely means one.

pnpm itself is pinned too — the estate ran eighteen different versions, five of
them too old to read a catalog.
2026-08-28 15:53:27 -07:00
zeekay 074facbba5 Name Zen in the hero card's font stack
The social card asked for Inter first. That is not a face this estate
licenses, ships or ever drew, so a renderer with Inter installed painted
the wrong face and one without it silently fell through to system-ui.
Zen leads now; the same tail follows it.
2026-08-28 11:59:32 -07:00
zeekay 9c18306471 fix(type): the file named Zen contained Geist
The name table of Zen-Variable.woff2 read "Geist" and ZenMono-Variable.woff2
read "Geist Mono". The filename, the @font-face and the licence beside them all
said Zen; only the bytes disagreed, so every grep passed and the surface
rendered Vercel's face.

This is the fourth instance in the estate — @hanzo/design shipped the same thing
under the same filename, zoo's foundation declared Zen over inter-var-latin,
and hanzo.sh had Zen declared over a Geist file. A filename proves nothing; the
check is the name table:

  python3 -c "from fontTools.ttLib import TTFont; print(TTFont(P)[\"name\"].getDebugName(1))"

The bytes are @hanzo/font 1.9.2's now, verified that way: family Zen and Zen
Mono. LICENSE-Zen.txt beside them already carried both copyright holders, which
is what OFL §2 asks of the copy that travels.
2026-08-28 11:48:44 -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.
v8.5.156
2026-08-28 08:55:51 -07:00
zeekay 145e9f1c68 regenerate from cloud 529be4ccb9 2026-08-28 08:10:42 -07:00
zeekay c0e89d2ad6 regenerate from cloud 92604dd76f 2026-08-27 20:41:31 -07:00
zeekay e31dd96f46 regenerate from cloud a48ddfb315 2026-08-27 19:44:26 -07:00
zeekay 8d99a341b9 regenerate from cloud 16e3b9cef1 2026-08-27 17:24:00 -07:00
zeekay a303b73f19 regenerate from cloud 03cd1b9b10 2026-08-27 17:04:47 -07:00
zeekay 8e4669c68e regenerate from cloud 733acc2f6d 2026-08-27 16:09:11 -07:00
zeekay 2a55a3e2c8 regenerate from cloud 3f82fe0da0 2026-08-27 15:19:38 -07:00