Question: How to handle gitops repo changes outside of base manifests from app repo?

I'm attempting to implement my gitops deployment pipeline using this repo as an example. I'm considering what should occur process wise when an ops person might need to update some variable of an environment. They don't interact with the app repo, only the gitops repo I would assume, so fall outside of the app's CI/CD pipeline flow. This presumable then requires CI/CD for the gitops repo itself? But if so, then how does that tie in with the existing flow?

1. Dev pushes changes to app repo. CI runs and completes merge to main.
2. CD triggers, manifests generated, branch created, PR for branch created.
3. Some time may pass...

5. In the meantime, an Ops person pushes changes to gitops repo (via a PR for approval) to change say the component variant overlay "non-prod" replica count, a variant that may be consumed by several environments. I'm assuming for now that this must use some gitops PR pipeline to generate all manifests for all environment/stage variations, as the single change may affect more than one generated file.
6. The ops change PR gets approved and changes merged to gitops main. Gitops operator starts deployment. There's no CD flow here though to integrate some deployment state back to run tests etc.

There appears to be some friction with this, or is the assumption that ALL changes to the gitops repo only occur via the app's CD pipeline? And if so, that means ALL stage/environment variations must be defined with the app repo, correct?

I appreciate any help discussing this.

Review the GitOps deployment flow described in the issue, including app-repository CD, generated manifests, and direct GitOps repository changes. Clarify whether operator changes are supported, how their pull requests and generated manifests should be handled, and how deployment state or tests fit into the process; done means the workflow and ownership boundaries are documented.

Written by the indexing model from the issue text.