Status field operation pattern - by design or evolution?

[tatehanawalt]

I'm studying Argo Rollouts' architecture and trying to understand a design decision that surprised me.

The pattern: Operations like promote and abort are triggered by the CLI/UI patching status fields.

My understanding: The Kubernetes API conventions describe status as representing "observed state" - what the controller has observed about the current state of the system.

My question: Was this pattern an explicit design choice, or did it evolve from practical constraints? I'm curious about the reasoning behind using status fields for operations given that status is intended to reflect observed state rather than serve as a control mechanism.

I found #839 from 2020 asking about this - is there design documentation about this decision?