Tracker: `.agents/skills/drive-pr/SKILL.md`

[ptr727]

Tracker for .agents/skills/drive-pr/SKILL.md. Filed under #1315's roll-up of the open prose backlog: every finding a bundle issue enumerated against this unit is listed here once, one line each, naming the issue it came from, and the bundle is closed as a duplicate of this tracker so the finding is not lost and the bundle stops being a unit of work. A new pre-existing finding on this unit gathers here per pr-review-conduct's Merge Gate, numbering continuing this list. This tracker closes when the unit is rewritten and each line below is settled or superseded.

1. Branch deletion in drive-pr and merge-and-release runs git push origin --delete with no expected object id, so a push landing after the tip check deletes unmerged work. (19 Carried-Content Defects From Downstream PR Reviews (guard, resync, drive-pr, git-commit, pr-review, promotion recipe, AUDIT.md, GOVERNANCE.md, merge-bot stub) #1113)
2. The how-far answer is treated as merge authorization: choosing a target says where work goes, not that the feature-to-develop squash merge may happen now. (19 Carried-Content Defects From Downstream PR Reviews (guard, resync, drive-pr, git-commit, pr-review, promotion recipe, AUDIT.md, GOVERNANCE.md, merge-bot stub) #1113)
3. The grant requires naming the skill AND answering its how-far question, yet an explicit target is acted on without asking, so the recommended invocation grants nothing. [.agents/skills/drive-pr/SKILL.md > What Invoking This Skill Authorizes] (drive-pr: the authorization conjunction is unsatisfiable and the grant states no lifetime #1282)
4. The grant states no lifetime, so a resumed session can read an earlier session's naming as still standing, which GOVERNANCE.md's authorization rules forbid. [.agents/skills/drive-pr/SKILL.md > What Invoking This Skill Authorizes] (drive-pr: the authorization conjunction is unsatisfiable and the grant states no lifetime #1282)
5. drive-pr's frontmatter drops the stop, saying escalate to whoever dispatched the drive where the body and source both say the seat stops that unit of work; "that seat" has no antecedent. [.agents/skills/drive-pr/SKILL.md > Disposing of Every Finding] (The escalation route's gate is wider than its remedy: a seat with no dispatcher and no reachable maintainer #1287)

[ptr727]

Seven further pre-existing findings from the whole-unit read the #1317 class 3 pull request (#1383) ran over "The Drive Loop", gathered here per the tracker's rule. That pull request changes only step 8 of the unit, and every git claim in step 4 was tested in a throwaway repository on git 2.47.3 and held except the one item 9 names. Item 5 above is half settled by the same pull request: the frontmatter now names the seat ("where the drive's own seat cannot reach the maintainer"), and it still does not say that seat stops.

6. Step 2 opens "Commit the work, then run local-strict-review" and then places the carried-content record before that commit, so followed literally in the carried-content case the commit is already made before the pass runs, the state the sibling's refusal table names. The sibling's order is carried-content pass and record, commit, digest read, diff pass, receipt, push. [.agents/skills/drive-pr/SKILL.md > The Drive Loop]
7. Same sentence, "because that ledger is tracked": no ledger is named anywhere in the unit, and "moves a carried canonical unit" reads as relocates to a first-time reader, who then skips the record for an in-place edit. [.agents/skills/drive-pr/SKILL.md > The Drive Loop]
8. "that skill's refusal table" in step 2 has three intervening nouns (the hook, the hub, a repository) between it and local-strict-review, and "which the hub carries" uses the fleet's word for distributed content where the sense is that the hub has one itself, contradicting "a repository has only if it adds one" under that reading. [.agents/skills/drive-pr/SKILL.md > The Drive Loop]
9. "since gh pr merge itself reports the resulting squash commit on develop, not the PR's headRefOid" is a false tool claim: gh pr merge prints a success line naming the pull request and no commit id, and headRefOid is a stored field gh pr view still returns after the merge, so capturing it first is harmless but the reason given is wrong. [.agents/skills/drive-pr/SKILL.md > The Drive Loop]
10. "Both remote commands resolve origin" and "neither command applies to it" refer to the two remote commands before either has been given, so at the point of reading there is nothing for "both" or "neither" to bind to. [.agents/skills/drive-pr/SKILL.md > The Drive Loop]
11. "The object id in git ls-remote ... matches the headRefOid captured above, -- before origin and the fully-qualified ref" is a declarative sentence rather than the instruction to compare the step depends on, and its tail is a verbless fragment whose role has to be guessed. [.agents/skills/drive-pr/SKILL.md > The Drive Loop]
12. "(to protect develop and main from it, GitHub has no per-branch exception)" is false: GitHub documents that branch protection rules and repository rules prevent a branch from being automatically deleted, which is a per-branch exception the two rulesets already provide. The setting is off fleet-wide, so the conclusion stands and the reason does not. [.agents/skills/drive-pr/SKILL.md > The Drive Loop]