[kfeofantov]

ADR 0030 scoped revisions to Deployments. What made a Deployment special was
that the agent knew the name of its revision annotation — not anything about the
object graph. An Argo Rollout creates and scales ordinary ReplicaSets, which the
agent already lists, already resolves, and already reports as workload_kind.
The only thing between those sets and the payload was a kind check.

Measured on kind (Kubernetes 1.36.1) against Argo Rollouts v1.10.0, mid-canary
with setWeight: 25 on four replicas:

payments-7bd58f4db4  rev 2  desired 1  current 1  ready 1  pause:3.10
payments-f47dc5486   rev 1  desired 3  current 3  ready 3  pause:3.9

That is the shape ADR 0030 §2 already describes — two revisions with non-zero
counts is a rollout in flight, and the split is the weight it runs at. No new
field was needed to say it; it was never emitted.

What changed

• Any ReplicaSet whose controller is a collected workload is reported. Scope
  is still inherited from the admitted pod index, so exclusions reach this
  payload unchanged.
• A bare ReplicaSet is not a revision. It is the workload rather than one
  version of one, and its pods already resolve to the set itself.
• The revision number is read for Deployments and no one else. Other
  controllers number under their own keys (rollout.argoproj.io/revision for
  Argo). No finding needs the number: deploy frequency needs ordering, which
  created_at gives; which revision is live needs the replica counts, which
  ship; "this revision is that build" needs the image and the instant, which
  ship. A table of vendor keys would be a second list to keep in step with other
  people's releases.
• deployment_revisions → workload_revisions, spool file with it. The old
  name would be false the moment the first record arrived under another kind,
  and a payload kind whose name contradicts its contents is what ADR 0022
  exists to prevent. Free today, a protocol migration once a backend exists —
  the reasoning ADR 0019 used to rename go_dependencies.

No new RBAC, no new field, no new payload kind. StatefulSet and DaemonSet
revisions stay uncollected (controllerrevisions, declined by ADR 0030), and
the custom resource itself stays unread.

What this does not reach

Stated in the ADR so the widening is not read as more than it is: a Rollout
paused at a step and one degraded look identical from the ReplicaSets.
status.phase and pauseConditions are on the custom resource. This closes the
revisions gap for Argo-managed workloads, not the rollout-state one.

The e2e needs no Argo

The fixture is a ReplicaSet under a Widget kind that has no CRD in the
cluster. A dangling owner reference survives the garbage collector — verified —
and produces exactly the shape the code must handle, with no third-party
controller in the test matrix and no vendor name in the assertion.

Evidence

make test, make lint, make chart-lint: green. policy-e2e on kind:

revision 1 of .../web runs registry.k8s.io/pause:3.9
revision of .../payments (kind Widget) runs registry.k8s.io/pause:3.9, unnumbered

revisionHistoryLimit defaults to 10 on a Rollout as on a Deployment, so the
bound ADR 0030 leaned on to keep the snapshot small holds: with the limit set to
3, the cluster retained three historical sets plus the stable one plus the one
in flight.

🤖 Generated with Claude Code

https://claude.ai/code/session_011YRKuL97KRndaopfpixrhp