v0.13.0

Feature 2.3: management cluster GitOps lifecycle (butleradm)

butleradm can now manage the management cluster's GitOps lifecycle end to end, closing the management-scope half of the CLI/console capability gap (Feature #4 in the gap audit). This follows Feature 2.2, which did the same for tenant clusters in butlerctl.

butleradm gitops <verb>

Verb	What it does
status	Whether GitOps is enabled on the management cluster, and the provider, repository, branch, and sync status
discover	Helm releases and GitOps engine state on the management cluster
preview	Render the GitOps layout that would be written (non-mutating)
export	Write the management cluster inventory to a repository (direct push, or --create-pr)
enable	Bootstrap Flux on the management cluster against a repository
disable	Uninstall Flux from the management cluster

Full console parity for the management scope. Commands are thin HTTP clients over butler-server's /api/management/gitops/* endpoints, consistent with ADR-016.

The disable guard

Management disable is the highest-blast-radius operation in the set: it uninstalls the management cluster's own Flux, which manages the platform's components (butler-controller, butler-console) and the image automation that deploys releases. It has no --yes shortcut. To proceed, the operator must supply the exact typed phrase uninstall-management-flux, by flag or interactive prompt, so a habitual --yes cannot fire it. The guard's help and prompt name what it tears down.

Validation

Read verbs (status, discover, preview, export) are validated live against the beta management cluster.

enable and disable are implemented and unit-tested, with live validation deferred by design. Running either against a live management cluster would re-point or tear down the platform's own Flux, so they are covered by unit tests (request shape, error handling, and the confirm guards) rather than a live run. The disable guard's refuse path is mutation-checked.