Phase 8 doesn't state whether operator merge pre-authorization outranks a required-but-unrunnable anchor

[dmccoystephenson]

Gap found during Phase 9 self-audit (cycle that continued PR #113)

Filed here rather than on dmccoystephenson/create-dev-loop-dev-loop, which does not resolve — see #87.

What was observed

Two consecutive Gardener dispatches against this repository have each independently derived, from scratch, the answer to the same question: when a run carries explicit operator merge pre-authorization, but Phase 4's anchor gate has marked the PR UNVERIFIED because the anchor is unrunnable, which of the two wins?

The template supplies both halves of the collision and no precedence rule between them:

• Phase 4 states that when anchor-relevant files are changed and the anchor cannot run, the PR is marked UNVERIFIED and handed to a human — "do not auto-merge."
• Phase 8 states that a do-not-auto-merge path match blocks autonomous merge only, and that the hold is satisfied when "the human codeowner explicitly authorizes the merge after being shown which protected path matched."

Neither passage addresses the case where authorization arrives before the PR exists, as a blanket run-level flag, rather than after a specific protected path has been surfaced. Nor does either passage say whether merge authorization can stand in for missing validation, which is a different thing from missing permission.

Why this is a template gap rather than a one-repo quirk

The collision is not specific to create-dev-loop. Any repository whose generated skill has both (a) a do-not-auto-merge path list and (b) an anchor that a headless run cannot always execute will reproduce it the first time a dispatch is given standing merge authority. The reasoning that resolves it is short, but it has to be reconstructed each time because it is written down nowhere.

The answer both cycles reached

Recorded here so the reasoning survives even if this issue is closed as answered rather than fixed:

1. Merge pre-authorization grants permission, not evidence. An operator authorizing a merge has not thereby run the validation the anchor exists to perform, so an UNVERIFIED anchor on anchor-relevant files still blocks.
2. Phase 8's codeowner exception is retrospective by construction — "after being shown which protected path matched" — so a flag passed before the PR was written does not satisfy it.

Consequence: the merge is withheld, and the terminal state is open + CI green + self-review posted + awaiting a human, which Phase 8 already declares a valid terminal state rather than a failed cycle.

Suggested instruction text

A sentence added to Phase 8, adjacent to the existing codeowner-exception clause, along the lines of:

Standing merge authorization does not satisfy the anchor gate. A run-level merge pre-authorization granted before this PR existed conveys permission, not validation — where Phase 4 has marked the PR UNVERIFIED on anchor-relevant files, the hand-off stands regardless of merge authority. The codeowner exception above is retrospective: it applies only to authorization given after the specific protected path has been surfaced to the codeowner.

Relationship to #109

#109 is adjacent but distinct. It reports that this repository has no headlessly runnable behavioral anchor at all, and asks the maintainer to choose among four remedies. The gap reported here is narrower and lives in the template rather than in this repository's validation policy: whatever #109 is resolved to, a precedence rule between merge authority and anchor status is still owed to every skill generated from create-dev-loop.md. Resolving #109 in favor of its fourth direction would make this repository's hand-offs expected, but would not tell a different repo's loop what to do when the same two rules collide.

Self-audit rubric result for this cycle

• Identity drift: PASS — no template invariant was disturbed; the cycle changed no files, and placeholder parity, Step-to-README parity, and fence escaping were re-verified green on the PR head via scripts/check_docs.py.
• Instruction clarity: FAIL — the subject of this issue.
• Edge case coverage: PASS — the orphaned-PR continuation path worked as written. Phase 1's instruction to confirm a Phase 4 self-review was actually posted located the prior cycle's completed review and merge-withheld comment in two commands, so no duplicate branch or PR was opened.
• Phase friction: PASS with a note — Phases 2 through 7 collapsed to nothing, correctly, because the continued PR was already complete. A cycle whose entire content is "assess an inherited PR and confirm it is parked" is a legitimate shape the template accommodates without special-casing.
• Drift candidates: the precedence rule above.
• External-signal quality: FAIL, already tracked by [self-audit] The repo's own validation anchor is structurally unrunnable in a headless dispatch, so template changes can never merge autonomously #109 — scripts/check_docs.py and pytest both pass on PR Constrain where a worktree may live and skip it under headless dispatch #113's head, and neither can observe the class of defect that PR fixes.

Still unresolved from the prior cycle

#114 could not be answered this run either, for the identical reason: reads outside the dispatch's own checkout were refused, so Stephenson-Software/gardener's refresh path remains unread. Both a local-filesystem search for a gardener clone and a gh api search/code query were denied.

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