groombook/org
13
0
Fork 1
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(devops): fix-forward-in-git rule — ban escalating reconcilable changes as manual/board actions (GRO-2536) #15

Closed
Scrubs McBarkley wants to merge 0 commits from scrubs/gro-2536-gitops-fix-forward-rule into main
pull from: scrubs/gro-2536-gitops-fix-forward-rule
merge into: groombook:main
Conversation 0 Commits - Files Changed -
Scrubs McBarkley commented 2026-06-25 11:48:14 +00:00
Owner
Copy Link
Copy Source

Why

GRO-2536 (board): agents repeatedly requested board approval and hand-run kubectl to fix a Flux-managed cluster — unfillable on a GitOps cluster, and the root cause of a multi-day stall where the whole board sat "blocked" waiting on a human to run commands that should have been PRs.

The devops skill already prohibited kubectl apply to prod but never stated the corollary: the resolution of any reconcilable breakage is a PR to groombook/infra, never a human-run command. Agents learned the prohibition and drew the wrong conclusion ("I can't kubectl → escalate to a human to kubectl").

What

Adds one section to skills/devops/SKILL.md — "When a cluster is broken: fix forward in git — never escalate a manual action" — stating the contract:

  • Anything a controller (Flux / OpenTofu / Sealed Secrets) can reconcile must be a PR to groombook/infra — not a board approval, not a hand-run kubectl/kubeseal/tofu.
  • A reconcile blocked on a pre-existing in-cluster object is solved declaratively (fix ownership/annotations in git); a one-time imperative step is a single reviewed exception with a stated reason, never a multi-day approval queue.
  • Board approval is reserved for genuinely irreversible / out-of-band actions no controller reconciles.
  • The missing-GitRepository case is a PR to the externally-managed cluster-config repo — still a PR.

Doc-only governance change; no infra behavior change. Prevents the recurrence the board called out.

Note

The first commit of this change accidentally landed directly on main (Gitea new_branch_name was ignored). I reverted main to baseline and re-routed the change through this PR so it gets the review it should have had. Flagging it openly rather than leaving an unreviewed direct-to-main commit.

Review

CTO review please — per coding-standards I am not self-merging.

cc @cpfarhood

## Why GRO-2536 (board): agents repeatedly requested **board approval** and **hand-run `kubectl`** to fix a Flux-managed cluster — unfillable on a GitOps cluster, and the root cause of a multi-day stall where the whole board sat "blocked" waiting on a human to run commands that should have been PRs. The `devops` skill already prohibited `kubectl apply` to prod but never stated the **corollary**: the resolution of any reconcilable breakage is a PR to `groombook/infra`, never a human-run command. Agents learned the prohibition and drew the wrong conclusion ("I can't kubectl → escalate to a human to kubectl"). ## What Adds one section to `skills/devops/SKILL.md` — **"When a cluster is broken: fix forward in git — never escalate a manual action"** — stating the contract: - Anything a controller (Flux / OpenTofu / Sealed Secrets) can reconcile **must** be a PR to `groombook/infra` — not a board approval, not a hand-run `kubectl`/`kubeseal`/`tofu`. - A reconcile blocked on a pre-existing in-cluster object is solved **declaratively** (fix ownership/annotations in git); a one-time imperative step is a single reviewed exception with a stated reason, never a multi-day approval queue. - Board approval is reserved for genuinely irreversible / out-of-band actions no controller reconciles. - The missing-`GitRepository` case is a PR to the externally-managed cluster-config repo — still a PR. Doc-only governance change; no infra behavior change. Prevents the recurrence the board called out. ## Note The first commit of this change accidentally landed directly on `main` (Gitea `new_branch_name` was ignored). I reverted `main` to baseline and re-routed the change through this PR so it gets the review it should have had. Flagging it openly rather than leaving an unreviewed direct-to-main commit. ## Review CTO review please — per `coding-standards` I am not self-merging. cc @cpfarhood
Scrubs McBarkley closed this pull request 2026-06-25 11:49:09 +00:00

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
Clear labels
bug
Something isn't working
 documentation
Improvements or additions to documentation
 duplicate
This issue or pull request already exists
 enhancement
New feature or request
 good first issue
Good for newcomers
 help wanted
Extra attention is needed
 invalid
This doesn't seem right
 question
Further information is requested
 wontfix
This will not be worked on
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
ai-review (AI Review) gb_barkley (Barkley Trimsworth) cpfarhood (Chris Farhood) ci (Continuous Integration [bot]) gb_flea (Flea Flicker) flux (Flux CD) admin (Gitea Admin) gb_lint (Lint Roller) renovate (Mend Renovate) gb_pawla (Pawla Abdul) gb_scrubs (Scrubs McBarkley) gb_shedward (Shedward Scissorhands) gb_dogfather (The Dogfather)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: groombook/org#15
Delete Branch "scrubs/gro-2536-gitops-fix-forward-rule"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?