zeekayandHanzo AI d9eb4f38be Fetch secrets from the Hanzo KMS, not the Infisical API
The KMS fetch steps called `/api/v1/auth/universal-auth/login` and
`/api/v3/secrets/raw?workspaceSlug=...` — the Infisical surface. We do not run
Infisical; kms.hanzo.ai serves the Hanzo-native door and 404s those paths, so
every secret fetch failed and the build died at "KMS auth failed".

Rewritten to the canonical contract the working repos use:
`/v1/kms/auth/login` returning `.accessToken`, then
`/v1/kms/secrets/ci/<name>?env=prod` returning `.value`. The org is read from
the credential, so the `zoo-platform` workspace slug is gone.

Co-authored-by: Hanzo AI <[email protected]>
2026-09-07 21:45:04 -07:00
2026-07-26 10:16:32 -07:00
2026-09-03 11:04:58 -07:00
2026-02-14 05:27:03 -08:00
2026-09-03 21:32:55 -07:00
2026-03-26 22:45:36 -07:00

Zoo Universe — retired

Read-only from here. Canonical: https://git.hanzo.ai/zoo/universe

This tip is an ancestor of canonical main, so no commit reachable from this branch is unique to it — the canonical repo is a strict superset. Nothing was lost by stopping here.

Two universes for one org is a split brain: a push lands somewhere real, reports success, and never reaches a cluster, because CD reconciles the other one (deploy/applicationset.yaml names the canonical URL). One repo per org means that failure cannot happen.

S
Description
Declared state for the zoo fleet: one values file per service, one ApplicationSet
Readme
1.2 MiB
Languages
TypeScript 70.1%
Shell 21.5%
Makefile 8.4%