A blanket merge pre-authorization does not resolve a do-not-auto-merge path match, and Phase 8 does not say so #142

Promoted from kingdom-community/kfe-docs-dev-loop#44, which is being retired. That loop served three repos from one file; it has been split into one loop per repo (kfe-staff-dev-loop, kfe-server-ops-dev-loop, kfe-player-guide-dev-loop), so a rule that belongs in the template no longer has a single loop to live in.

Labelled template-rule there: the finding is general, and the fix belongs in create-dev-loop.md rather than in any one loop.

What happened

A cycle run under a headless gardener tend dispatch produced a clean, anchor-green PR whose only modified file was infrastructure/deployment.md — an entry on Phase 8's repo-specific do-not-auto-merge list. The same dispatch had also been given a blanket merge pre-authorization: --allow-merge was passed and the repository was present in the operator's merge allow-list.

Phase 8 covers two states and not the third:

1. No protected path matches → merge.
2. A protected path matches and a human codeowner authorizes after being shown which path matched → merge, stating the override and whose authorization it rested on.
3. A protected path matches and a blanket, path-blind pre-authorization exists → not addressed.

The cycle resolved state 3 conservatively — the PR was left open with a comment naming the matched path and the decision needed — but that was a judgment call made without instruction, and a different run could as easily read --allow-merge as satisfying the hold. The two readings produce opposite outcomes on identical inputs, which is exactly what an instruction should be preventing.

Why the conservative reading looks correct

The do-not-auto-merge list exists so that a human sees which sensitive path is being touched before the change lands. A flag passed at dispatch time is granted before the diff exists, so it cannot carry that knowledge. Phase 8's own wording is already close to saying this — "after being shown which protected path matched" — it just never contemplates an authorization that predates the diff.

Suggested instruction text

Add to Phase 8, after the do-not-auto-merge path check:

A blanket merge authorization granted before the diff existed does not satisfy a protected-path hold. A dispatch-time flag (e.g. gardener tend --allow-merge, or a repository sitting on a merge allow-list) authorizes merging in general; it cannot authorize a specific protected path, because the path was not known when it was granted. When a protected path matches, leave the PR open regardless of such a flag, post a comment naming the matched path and the rationale on record for its being protected, and hand the decision back. Only an authorization given with sight of the matched path clears the hold.

Suggested Edge cases entry

A protected path matches while a blanket merge pre-authorization is in force: the pre-authorization does not clear the hold — it was granted before the diff existed. Leave the PR open, name the matched path in a comment, and hand back the decision.

This issue was drafted during a Gardener session (https://github.com/Stephenson-Software/gardener).

drafted by Claude on behalf of Daniel Stephenson