zeekayandHanzo Dev
d4c7dbd371
Each product below was probed on its OWN authored routes, at api.hanzo.ai and
at the hostname this repo claimed for it, and every one answered a route-level
404 — the router's plaintext "404 page not found", not an empty result from a
live handler. hanzoai/cloud's openapi.yaml does not own them either.
Authoring a route nothing serves is not a harmless placeholder. hanzoai/cli's
genspec refutes an authored operation only where the live route table OWNS its
product, so a product the router has never heard of is refuted by NOTHING: it
survives every gate and ships as a `hanzo` command, an SDK method, and a
SKILL.md under /.well-known/agent-skills telling an agent to call a dead
endpoint — skills.py has no liveness filter at all. Annotating the spec
UNSERVED was the previous answer; no generator reads a comment.
product paths ops source removed
chat 171 206 chat/
nexus 150 150 nexus/
flow 87 120 flow/
auto 50 69 auto/
console 43 67 console/
paas 28 42 paas/
mq 28 41 mq/
engine 22 35 engine/
db 17 30 db/
pubsub 19 29 pubsub/
registry 13 22 registry/
did 10 14 did/
stream 8 13 stream/
guard 5 7 guard/
chat-docs 1 1 path in cloud/
index-docs 1 1 path in cloud/
agent-bindings 1 1 path in visor/
sdk 1 1 /v1/sdk/secrets in kms/
TOTAL 655 849
paas is also a standing ruling: paas and platform were two names for one deploy
plane, and /v1/platform is the one that answers. It moves to `collapsed:` in
capabilities.yaml pointing at platform.
chat needed a scalpel rather than a verdict, because the GATEWAY serves
inference under /v1/chat/. All 157 /v1/chat/* paths in the master were probed
individually (GET for reads, POST + {} for writes); 180 of 181 requests
returned the plaintext route-miss. Exactly one answered: POST
/v1/chat/completions, 401 with a JSON body. That operation is authored by ai/,
not chat/ — so it survives untouched and chat/ goes whole. The 15 bare
/oauth/{provider} paths chat/ also authored return 200 HTML from the marketing
SPA catch-all (/__total_nonsense_xyz__ returns the same page), so they were
never API routes, and never under /v1/ either.
Removing /v1/sdk/secrets orphaned kms's entire components.schemas
(SdkEnvelope, SdkEnvelopeIdentity, Error — reachable from no surviving path), so
it goes with the operation instead of shipping as three dead models in every
SDK. kms itself is untouched and live: /v1/kms/secrets answers 403.
Unchanged and verified alive at the edge: audio, completions, embeddings,
images, messages, models, router, rerank, and /v1/chat/completions. The master
goes 1787 -> 1132 paths (2368 -> 1519 ops) and the removed set is exactly the
products above — no other path key moved. A product returns to this repo the
day it is actually served.
Co-authored-by: Hanzo Dev <[email protected]>
5.2 KiB
Hanzo Capability Manifest — V8 · Open Edition
GENERATED from capabilities.yaml, the ONE registry of Hanzo capabilities. Do NOT edit this file by hand — edit capabilities.yaml and run python3 merge.py. merge.py reads the same registry to emit hanzo.yaml's x-tagGroups, so this index and the unified never drift.
One canonical name per capability = one /v1/<name> route = one <name>/openapi.yaml. A ✓ marks a name with a present spec dir (live in hanzo.yaml); pending marks a listed name whose spec is not yet authored.
Identity & Trust
who you are · what you may touch · where secrets live
| Capability | Route | Spec |
|---|---|---|
iam |
/v1/iam |
✓ |
authz |
/v1/authz |
✓ |
kms |
/v1/kms |
✓ |
security |
/v1/security |
✓ |
zt |
/v1/zt |
✓ |
Intelligence
models · agents · evaluation — the mind of the cloud
| Capability | Route | Spec |
|---|---|---|
ai |
/v1/ai |
✓ |
ml |
/v1/ml |
✓ |
agents |
/v1/agents |
✓ |
evals |
/v1/evals |
✓ |
research |
/v1/research |
✓ |
prompts |
/v1/prompts |
✓ |
functions |
/v1/functions |
✓ |
exec |
/v1/exec |
✓ |
graph |
/v1/graph |
✓ |
Data
the stores every capability writes to and reads from
| Capability | Route | Spec |
|---|---|---|
storage |
/v1/storage |
pending |
s3 |
/v1/s3 |
✓ |
base |
/v1/base |
✓ |
kv |
/v1/kv |
✓ |
vector |
/v1/vector |
✓ |
Streams
messaging · durable tasks · async orchestration
| Capability | Route | Spec |
|---|---|---|
tasks |
/v1/tasks |
✓ |
notify |
/v1/notify |
✓ |
automations |
/v1/automations |
✓ |
Observability
see everything — telemetry · analytics · usage
| Capability | Route | Spec |
|---|---|---|
o11y |
/v1/o11y |
✓ |
observe |
/v1/observe |
✓ |
analytics |
/v1/analytics |
✓ |
Commerce
the economy — meter · price · bill · reward
| Capability | Route | Spec |
|---|---|---|
commerce |
/v1/commerce |
✓ |
billing |
/v1/billing |
✓ |
pricing |
/v1/pricing |
✓ |
plan |
/v1/plan |
✓ |
product |
/v1/product |
✓ |
crm |
/v1/crm |
✓ |
referrals |
/v1/referrals |
✓ |
affiliates |
/v1/affiliates |
✓ |
licensing |
/v1/licensing |
pending |
Platform
the cloud fabric — deploy · provision · route · host
| Capability | Route | Spec |
|---|---|---|
cloud |
/v1/cloud |
✓ |
platform |
/v1/platform |
✓ |
provisioning |
/v1/provisioning |
✓ |
gateway |
/v1/gateway |
✓ |
visor |
/v1/visor |
✓ |
edge |
/v1/edge |
✓ |
dns |
/v1/dns |
✓ |
do |
/v1/do |
✓ |
Applications
the user-facing surfaces built on all of the above
| Capability | Route | Spec |
|---|---|---|
projects |
/v1/projects |
✓ |
app |
/v1/app |
✓ |
git |
/v1/git |
✓ |
templates |
/v1/templates |
✓ |
integrations |
/v1/integrations |
✓ |
bot |
/v1/bot |
✓ |
kb |
/v1/kb |
✓ |
search |
/v1/search |
✓ |
websearch |
/v1/websearch |
✓ |
world |
/v1/world |
✓ |
authors |
/v1/authors |
✓ |
sites |
/v1/sites |
pending |
tracker |
/v1/tracker |
✓ |
framework |
/v1/framework |
✓ |
Core
| Capability | Route | Spec |
|---|---|---|
admin |
/v1/admin |
✓ |
plugin |
/v1/plugin |
✓ |
Collapsed
Resolved duplicates / consolidations — removed, no spec dir. The capability now lives where noted.
| Was | Now lives in |
|---|---|
eval |
evals |
operative |
bot + visor |
plans |
plan |
plugins |
plugin |
featuregate |
featureflags |
ads |
marketing |
cms |
content |
cron |
tasks |
connectorruntime |
automations |
gojabase |
goja |
paas |
platform |
Pending
Live surfaces missing a spec — author these to complete the set.
team, wallets, treasury, usage, fleet
Under review
Braids to verify before folding — grouped today (a spec dir exists), consolidation is a separate verified decision.
- app_vs_projects — app (hanzo.app builds/deploys, grouped→applications) vs projects (buildable/deployable sites) — likely ONE concern; fold app→projects?
- do_is_a_provider — do (DigitalOcean VPCs/LBs, grouped→platform) is a PROVIDER, not a capability — fold into provisioning/platform?
- s3_vs_storage — s3 (/v1/s3/*, grouped→data) is the present object store; storage is the canonical rename target (no dir yet) — fold s3→storage once the dir is renamed?
- observe_vs_o11y — observe (/v1/o11y/{logs,metrics,status} + /v1/settings, grouped→observability) is an o11y read-plane facet + a settings facet — fold observe→o11y once the routes migrate?
- retrieval_cluster — search vs kb (semantic) vs vector (store) — overlapping retrieval; is search distinct from kb?
Internal — NOT public capabilities
Trust boundaries and runtime hosts with no public API surface. Excluded from the unified, x-tagGroups, SDKs and docs.
principal, goja, mpc, controlplane, metrics, audit