[bmscomp]

PR 1 of the deploy plan (plans/deploy-enhancement.md, three-PR cut): detection, installed versions for every chart, --upgrade.

What changes

Platform detection (pkg/detect/collector.go, platformOf). Strongest signal first, and the report says which one decided (ProviderBasis). kates detect and deploy's pre-flight phase print it, e.g. Platform: kind (node providerID kind://).

1. The config.openshift.io API group (kubectl api-versions) → openshift.

2. The server gitVersion:

   • -eks- on aws:// nodes → eks
   • -gke. on gce:// nodes → gke
   • +k3s → k3s
   • +rke2 → rke2

   EKS Anywhere and Google Distributed Cloud run the same builds off AWS and GCP, so the suffix alone names nothing.

3. A node providerID: kind://, k3s://, or an AKS scale set (AKS has no version suffix).

4. The context name, last, now labelled "guessed". Until now, the context name was the only signal.

openshift, k3s and rke2 fall into valuesgen's generic branches. Admin-less deploys still skip the collector, so their provider stays unknown. Detecting it there would switch them onto the kind overlays, so that waits for PR 3's cluster summary.

Installed rows (cmd/deploy_installed.go).

• One helm list -A replaces the per-release lookups: --filter ^(<this deploy's releases>)$, with a 10 s budget of its own. When the account may not list every namespace, it falls back to one helm list -n per namespace.
• Every installed component gets a line: its chart beside the one this deploy ships, and what deploy does with it. The lines appear in the wizard's "Already installed" screen, the review, and the --dry-run preview, under a new "Already installed" section.
• Components with lines now: cert-manager, Kyverno, the Kafka cluster and chaos (kept, with "this deploy ships X"), PostgreSQL, Kates, and the 5 upgradable releases.
• A release in another namespace is shown as "installed in X; this deploy installs another one into Y".
• A Kafka whose CR is not Ready is shown as reapplied, which is what deployGroupB does.
• Connect and monitoring are shown as "kept, unless deploy finds it broken", because their reconcile checks need the introspection that the review runs before.
• Strimzi stays on its version screen.

--upgrade name,…|all. It fills deployUpgradeReleases, the same map the wizard's ticks fill, and with -i the wizard preselects those names. It refuses a name deploy doesn't upgrade, and one this deploy doesn't include (--upgrade mm2: this deploy does not include it; add --with-mirror-maker2, …), instead of ignoring it.

Also: the --strimzi-version help said "the repository pin"; it now says "this release's pin".

Checks

• Tests:
  • TestPlatformOf: 12 cases, including EKS Anywhere and GDC.
  • TestDeployedReleases_FallsBackToTheEntriesNamespaces
  • TestInstalledRows: other namespace, Kafka not Ready, Connect, a ticked and an unticked upgrade.
  • TestApplyUpgradeFlag, TestCheckUpgradeInDeploy, TestDeployDryRunListsInstalled.
• go test ./... in cli/ passes. golangci-lint run --new-from-rev=origin/main reports 0 issues. scripts/check-cli-style.sh passes.
• Live on kind-panda: kates deploy --dry-run --yes through a copied kubeconfig (read-only).
  • It printed Platform: kind (node providerID kind://), and "Kafka UI 0.3.2 → 0.3.2 in kafka (same chart; reapply): kept", or "applied" with --upgrade kafka-ui.
  • --upgrade mm2 and --upgrade kafka were both refused.
• An independent review, with each finding checked by a second agent, found 4 defects. All are fixed here:
  • the EKS Anywhere/GDC suffix false positive;
  • --upgrade silently ignoring a component outside the deploy;
  • "kept" claimed for a Kafka that deploy reapplies;
  • -A sharing its timeout with the fallback.

Not in this PR

• Turning Kafka UI and Apicurio on in release.yml's published-smoke, which the plan listed here. That job only runs on a tag and gates the GitHub Release, so a failure could only show up at a release. It needs its own PR.
• The wizard's interactive screens were not driven in a TTY. The rows they show are the ones the review and the dry run print.