zeekayandGitHub
5659db6574
Three hand-maintained capability registries drifted (8 vs 9 vs hardcoded) — a
one-and-one-way violation. Collapse to ONE machine-readable source, everything
else derived.
Before: 3 sources
- capabilities.yaml (structured manifest, read by nothing)
- CAPABILITIES.md (10KB hand-written index, wrongly called canonical)
- merge.py GROUPS dict (hardcoded, "mirrors CAPABILITIES.md by hand" — the
only one that actually drove x-tagGroups)
After: 1 source + 2 derivations
- capabilities.yaml is the ONE source of truth
- merge.py READS it (GROUPS dict deleted) → hanzo.yaml x-tagGroups (domain
titles + Core) AND generates CAPABILITIES.md (now GENERATED — DO NOT EDIT)
Build invariant enforced (fail loud, was only promised): every present
<svc>/openapi.yaml dir maps to exactly one entry across domains∪core (orphan /
unlisted / double-listed → sys.exit); collapsed name must have no spec dir;
internal excluded from master + x-tagGroups.
Reconciled capabilities.yaml so the build PASSES without losing capability,
grounded in `ls */openapi.yaml`:
- app → applications, do → platform (grouped, not folded; review notes kept)
- world → applications (dir exists, was unlisted)
- s3 → data, observe → observability (dirs exist → moved out of `collapsed`,
which requires no dir; fold-later intent preserved in `review`)
- team/wallets/treasury: no spec dir → dropped from domains, kept in `pending`
hanzo.yaml aggregation unchanged in substance: 1793 paths / 999 schemas / 150
responses / 39 params / 68 tags — zero added, zero removed. Only x-tagGroups
names change (8 → 9 groups, using domain titles).
Also: gitignore __pycache__/ (was polluting the tree).
5.6 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 master 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 |
✓ |
did |
/v1/did |
✓ |
zt |
/v1/zt |
✓ |
guard |
/v1/guard |
✓ |
Intelligence
models · agents · evaluation — the mind of the cloud
| Capability | Route | Spec |
|---|---|---|
ai |
/v1/ai |
✓ |
ml |
/v1/ml |
✓ |
engine |
/v1/engine |
✓ |
agents |
/v1/agents |
✓ |
evals |
/v1/evals |
✓ |
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 |
✓ |
db |
/v1/db |
✓ |
kv |
/v1/kv |
✓ |
vector |
/v1/vector |
✓ |
Streams
messaging · durable tasks · async orchestration
| Capability | Route | Spec |
|---|---|---|
pubsub |
/v1/pubsub |
✓ |
mq |
/v1/mq |
✓ |
stream |
/v1/stream |
✓ |
tasks |
/v1/tasks |
✓ |
notify |
/v1/notify |
✓ |
automations |
/v1/automations |
✓ |
flow |
/v1/flow |
✓ |
auto |
/v1/auto |
✓ |
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 |
✓ |
paas |
/v1/paas |
✓ |
provisioning |
/v1/provisioning |
✓ |
gateway |
/v1/gateway |
✓ |
visor |
/v1/visor |
✓ |
edge |
/v1/edge |
✓ |
dns |
/v1/dns |
✓ |
registry |
/v1/registry |
✓ |
nexus |
/v1/nexus |
✓ |
do |
/v1/do |
✓ |
Applications
the user-facing surfaces built on all of the above
| Capability | Route | Spec |
|---|---|---|
console |
/v1/console |
✓ |
projects |
/v1/projects |
✓ |
app |
/v1/app |
✓ |
git |
/v1/git |
✓ |
templates |
/v1/templates |
✓ |
integrations |
/v1/integrations |
✓ |
bot |
/v1/bot |
✓ |
chat |
/v1/chat |
✓ |
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 |
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 console settings facet — fold observe→o11y (+ console) once the routes migrate?
- workflow_cluster — auto (Hanzo Auto engine) · automations (connector pieces) · flow — three workflow surfaces; decomplect to one?
- 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 master, x-tagGroups, SDKs and docs.
principal, goja, mpc, controlplane, metrics, audit