Files
bot-hub/docs/architecture.md
zeekay 214621b6ca Serve the hub at api.hanzo.ai/v1/skills
Every route mounts under /v1/skills, the address api.hanzo.ai routes to
this API; auth, personas, users, tokens, upload, integrations, search and
whoami are sub-resources and RESERVED keeps them from being slugs. The
web, the OG renderers, the CLI's default registry, /.well-known/bothub.json
and openapi.json name api.hanzo.ai. Sign-in calls back to
api.hanzo.ai/v1/skills/auth/callback and hands the token over in the
fragment.

The store starts again. docker-entrypoint.sh read Base's port from
BASE_PORT, which Kubernetes sets to tcp://<ip>:<port> in a namespace
holding a Service named base; Base now listens on 127.0.0.1:8090, fixed.
The collections migration is rewritten for the Base the Dockerfile pins
(1.5.91): flat field options, declared created/updated, and the users
collection every Base already has, extended rather than created twice.

Reads are anonymous against public rules, since Base takes IAM
credentials only and no longer serves password sign-in; writes answer
503 saying so. The catalogue migration, generated by scripts/catalog.mjs,
publishes the 83 skills in hanzoai/bot@8be8f1dc7b. /health reports the
store, so the probes restart a pod whose Base is gone.

cache.ts decides caching once: an anonymous 2xx GET is public for a
minute (five at the edge) with a weak ETag and 304s; a credential, a
write or an error is private, no-store. Filter values go through lit().
Embeddings go through api.hanzo.ai and are skipped without a key.

k8s/ was a second declaration of the deployment; universe is the one.
2026-09-30 01:10:48 -07:00

1.8 KiB
Raw Permalink Blame History

summary, read_when
summary read_when
System overview: web app + Convex backend + CLI + shared schema.
Orienting in codebase
Tracing a user flow across layers

Architecture

Pieces

  • Web app: TanStack Start (React) under src/.
  • Backend: Convex under convex/ (DB, storage, actions, HTTP routes).
  • CLI: packages/bothub/ (published as bothub, legacy bothub).
  • Shared schemas/routes: packages/schema/ (bothub-schema).

Data + storage

  • Skill “bundle” = versioned set of text files stored in Convex _storage.
  • Metadata extracted from SKILL.md frontmatter.
  • Stats stored on skills (downloads, installs, stars, comments, …).

Main flows

Browse (web)

  • UI reads skill metadata + latest version from Convex queries/actions.
  • SKILL.md rendered as Markdown.

Search (HTTP)

  • /v1/skills/search?q=... routes to Convex action for vector search.
  • Embeddings currently generated during publish.

Install (CLI)

  • Resolve latest version via /v1/skills/<slug>.
  • Download zip via /v1/skills/download?slug=...&version=....
  • Extract into ./skills/<slug> (default).
  • Persist install state:
    • ./.bothub/lock.json (per workdir, legacy .bothub)
    • ./skills/<slug>/.bothub/origin.json (per skill folder, legacy .bothub)

Update (CLI)

  • Hash local files, call /v1/skills/resolve?slug=...&hash=<sha256>.
  • If local matches a known version → use that for “current”.
  • If local doesn’t match:
    • refuse by default
    • or overwrite with --force

Publish (CLI)

  • Publish via POST /v1/skills (multipart; requires Bearer token).

Sync (CLI)

  • Scan roots for skill folders (contain SKILL.md).
  • Compute fingerprint; compare to registry state.
  • Optionally reports telemetry (see docs/telemetry.md).
  • Publishes new/changed skills (skips modified installed skills inside install root).