Show Argo's own per-resource verdicts from argocd-server on Argo CD 3, with or without a token

docs/gitops.md

@@ -74,11 +74,12 @@ While an operation is running, the page polls every 2s; otherwise on-demand.
 The health chip on each managed resource (tree node, Resources table, per-resource Issues) comes from one of two places, and Radar tells you which:
 
 - **Argo CD's own verdict.** Argo evaluates every managed resource it has a health check for (built-in checks for core kinds and many CRDs, plus your `resource.customizations`) and rolls the results up into the Application's health. Up to Argo CD 2.x this per-resource result was also written into the Application object (`status.resources[].health`), and that is what Radar reads.
-- **Radar's own read.** Argo CD 3.0 changed the default: the controller no longer persists per-resource health into the Application (`status.resourceHealthSource: appTree`, controlled by `controller.resource.health.persist` in `argocd-cmd-params-cm`). The app-level health still rolls up, but every managed resource in the object is left without one. When Radar sees that, it reads the live resources itself through its issues engine (crash loops, image pulls, failed `Ready` conditions and so on) and reports what it finds. Those rows carry a **Radar** marker, and a notice above the Issues band says that the problems listed are Radar's findings. Radar only reports problems this way; it never marks a resource Healthy on Argo's behalf, and a resource it has nothing on is shown without a health value.
+- **Argo CD's verdict, read from its API server.** Argo CD 3.0 changed the default: the controller no longer persists per-resource health into the Application (`status.resourceHealthSource: appTree`, controlled by `controller.resource.health.persist` in `argocd-cmd-params-cm`). The app-level health still rolls up, but every managed resource in the object is left without one. When Radar sees that and can reach argocd-server, it asks the server for the same per-resource verdicts (the Application's `resource-tree`, which the server keeps in its own cache) and shows those. This works with the Argo CD integration connected (Settings → Argo CD), and, without any setup, on installs that allow anonymous read (`users.anonymous.enabled`); the credential-free read accepts argocd-server's default self-signed certificate, since it sends nothing that needs protecting. Once an anonymous read has succeeded, the connection counts as the integration: Settings shows it as connected with no token needed, and the Git-rendered diff works over it too. A reachable server that refuses the read (the default) stays "not connected" — reachability alone is not an integration. The answer is accepted only when it is about the same Application (matching UID) and the Application deploys to the connected cluster. With the integration configured and no usable answer (token rejected, server unreachable, a different install answering), the notice says so and why instead of quietly showing Radar's read.
+- **Radar's own read.** When Argo's verdicts are not in the object and cannot be fetched, Radar reads the live resources itself through its issues engine (crash loops, image pulls, failed `Ready` conditions and so on) and reports what it finds. Those rows carry a **Found by Radar** marker, and a notice above the Issues band says that the problems listed are Radar's findings. Radar only reports problems this way; it never marks a resource Healthy on Argo's behalf, and a resource it has nothing on is shown without a health value.
 
 Two things follow from that. A resource Argo has no health check for (so Argo ignores it) can still show a Radar finding if it is unhealthy: that is Radar's read, not a change in Argo's verdict, and the marker says so. And an Application that deploys to another cluster gets neither: Radar can only read the cluster it is connected to, so it derives nothing and says why.
 
-If you want Argo's per-resource verdicts back in the object, set `controller.resource.health.persist: "true"` in `argocd-cmd-params-cm` and restart the application controller. Radar switches back to Argo's values automatically.
+To see Argo's per-resource verdicts instead of Radar's read, connect Radar to your Argo CD server in Settings (the notice links there), or set `controller.resource.health.persist: "true"` in `argocd-cmd-params-cm` and restart the application controller. Radar switches to Argo's values automatically either way.
 
 ## Lifecycle awareness