Repository navigation
Bug: parallel-run-merge-gate-misparses-pr-number #691
Description
Activity
Routed upstream (2026-09-11)
The parser at fault lives in
.claude/hooks/hook-command-invocation.ps1, which is push-down owned from the drm-copilot repository (last overwritten by the harness 1.1.11 push-down, commit 8cf89a2 on 2026-09-11). A fix made here would be reverted by the next push-down. A prompt artifact for the upstream fix is committed atartifacts/drm-copilot-merge-gate-pr-number-parse-prompt.md. This issue stays open as the TaskMaster-side tracker and closes when the corrected hook arrives by push-down and the reproduction in the issue body no longer denies the merge.Interim mitigation already in force: this repository's Bash allowlist does not permit
cd-prefixed compound commands, so the triggering command shape is not issued by agents here.Verified fixed. The PR number is now read only from the
gh pr mergesegment itself:Get-EpicMergeGateCommandPrNumberin.claude/hooks/enforce-epic-merge-gate.ps1:146-190takes the positional operand or the--mergevalue and fails closed otherwise. The fix came from drm-copilot commit fdf1c84c (v1.1.11) and arrived here with the harness 1.1.11 push-down 8cf89a2. The current copy is byte-identical to upstream. Closing.
Summary
The parallel-orchestrator's PR-merge gate extracts the PR number by scanning the entire shell command text for the first standalone digit run, instead of parsing it from the
gh pr mergeargument specifically. A command prefixed withcdinto a worktree path that itself contains a standalone 4-digit number (e.g. a year-prefixed worktree directory) gets its PR number misread from the path, and the merge is denied.Environment
cd C:\Users\DanMoisan\repos\TaskMaster-wt\2026-08-29T00-11 && gh pr merge --merge 688bugs-635-440, section "Corrections to things I told you earlier"Steps to Reproduce
...\TaskMaster-wt\2026-08-29T00-11).cdinto that path, e.g.cd C:\Users\DanMoisan\repos\TaskMaster-wt\2026-08-29T00-11 && gh pr merge --merge 688.2026(the first standalone digit run in the full command text) rather than688.2026is not the expected/pinned PR for the run.Expected Behavior
The gate should parse the PR number from the
gh pr mergeinvocation specifically (e.g. the argument following--merge, or the PR number/URL argument), regardless of what other digit runs appear earlier in the command line.Actual Behavior
A bare
gh pr merge --merge 688(nocdprefix) is accepted; the same command prefixed withcdinto a path containing a standalone digit run is denied because the gate parsed the wrong number.Logs / Screenshots
cd .../2026-08-29T00-11 && gh pr merge --merge 688was read as PR2026and denied. The checkpoint was correct throughout. Bare commands work."Impact / Severity
Source
From: docs/features/potential/2026-08-29-parallel-run-merge-gate-misparses-pr-number.md