Hanzo AIandClaude Fable 5.1
ace46f80af
zoo.vote was declared in lux/universe deploy/zoo-mainnet/zoo-vote.yaml. zoo-fleet's generator reads THIS repository (hanzo/universe infra/k8s/hanzo-cd/project-zoo.yaml, path deploy/*/*.yaml), so the workload had a declaration in a fleet that does not serve it and none in the one that does. Declared here, deleted there. The image is ghcr.io/zooai/vote, built by luxfi/vote's Image workflow: one source builds lux.vote, zoo.vote and hanzo.vote, each into its own org's registry, so this pod pulls with Zoo's credential and no other org's access can strand it. The tenant is a build-arg and the host settles it again at runtime, which is why the ingress names zoo.vote and www.zoo.vote — the app reads the hostname to know which DAO it is, so what is routed here is part of its behaviour. The tag is what the live Deployment runs, with a TODO to pin the first tag the workflow prints. It could not be verified from a workstation, so it stays a tag rather than becoming a digest that was guessed. Co-Authored-By: Claude Fable 5.1 <[email protected]> Claude-Session: https://claude.ai/code/session_015g5a1mCWuuSQTBZZywNnET
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.