Files
base/cmd/cli
zeekayandHanzo Dev 02731f68e9 the CLI's remote targeting points nowhere, and now the file says so
Two claims in the CLI section were wrong, both about how a host gets named.

EnvURLs over Env.DomainSuffix was described as "the one way the CLI names a
host". It names none — nothing calls it outside its own test — and it could not
name a real one if it did: DomainSuffix is hard-coded to example.com with no
env, config or flag behind it. Having no caller is the only reason a URL builder
that resolves to a domain nobody owns has never surfaced.

Env.K8sContext DOES have callers, eleven of them across operator, cluster and
status, and it returns the bare literals gke_mainnet / gke_testnet / gke_devnet
— not the gke_<project>-<env>_<region>_<suffix> map this section printed.
Neither shape exists here: Hanzo runs on DOKS, so kubectl --context gke_mainnet
finds nothing and every remote CLI command fails at its first call. Loudly, at
least. Local is unaffected: K8sContext returns "" and statuscmd keys on that to
skip the cluster.

Both are pinned now, so replacing the literals with real contexts is a
deliberate edit in two places rather than something discovered mid-incident.

Coverage while there: AddNetworkFlags was 0% and carries the property the skip
exists for — Base registers its own --dev, so re-registering would panic and
rebinding would leave Base's variable permanently false. Asserted by setting the
flag and checking the ORIGINAL variable receives it. cmd/cli 24.7% -> 25.8%.

Co-authored-by: Hanzo Dev <[email protected]>
2026-08-24 10:43:37 -07:00
..