[self-audit] gardener-managed clones' restricted fetch refspec breaks gh pr create after git push -u

[dmccoystephenson]

Gap found during Phase 9 self-audit (create-dev-loop-dev-loop cycle, PR #86)

In a gardener-managed dedicated clone, origin's fetch refspec is restricted to only main:

$ git config --get-all remote.origin.fetch
+refs/heads/main:refs/remotes/origin/main

Following the template's normal Phase 4 sequence (git push -u origin <branch> then gh pr create --title ... --body ...) failed even though the push succeeded and the remote branch existed (confirmed via gh api repos/.../git/refs/heads/<branch>):

$ gh pr create --title "..." --body "..."
aborted: you must first push the current branch to a remote, or use the --head flag

gh pr create apparently relies on a local remote-tracking ref (origin/<branch>) existing to detect the pushed branch, and the restricted fetch refspec means git fetch never populates one for feature branches, even though git push -u set the upstream config. git branch --set-upstream-to=origin/<branch> also fails for the same reason (the requested upstream branch ... does not exist).

Workaround used this cycle: gh pr create --head <branch> ... (explicit --head bypasses the remote-tracking-ref lookup).

Suggested action

Add this as a named workaround in create-dev-loop.md's Phase 4 (near the git push -u / gh pr create block) or Edge cases, since it will recur on every gardener-dispatched cycle for every generated skill, not just this repo:

If gh pr create fails with "you must first push the current branch to a remote" despite a successful git push -u, the clone's fetch refspec may be restricted to the default branch only (common in gardener-managed dedicated checkouts) — pass --head <branch> explicitly rather than relying on remote-tracking-ref auto-detection.

Provenance

Found during the 2026-07-30 gardener-dispatched cycle that produced PR #86 in this repo.