Repository navigation
Bug: pr-context-harvests-closing-keywords-from-prose #886
Description
Activity
The following sections were present and filled in the promoted potential-bug entry (
docs/features/potential/promoted/2026-09-13-pr-context-harvests-closing-keywords-from-prose.md) but were dropped bypotential_to_issuewhen this issue was created. Reposting them here per the known promotion-fidelity defect tracked in issue #887.Suspected Cause / Notes
The harvester most likely applies a
#\d+-style (or similarly permissive) regular expression across the full text of every additional context file, including featurespec.md/issue.md/research documents, without regard to sentence structure or closing-keyword phrasing (closes,fixes,resolves). The#ISO-8601token suggests the pattern is not even anchored to digits, since it matched a non-numeric string. The false "GitHub CLI unavailable" report and the reported vacuous zero-diff context (workspace root on the wrong branch) both point at the same tool's environment-detection and ref-resolution logic being unreliable, independent of the closing-keyword defect.Proposed Fix / Validation Ideas
- Unit coverage areas: a closing-keyword extractor that requires an adjacent closing verb (
closes,fixes,resolves) immediately before the#<number>token, scoped to the PR body/commit messages the tool is actually meant to scan rather than arbitrary feature-document prose; reject non-numeric tokens after#. - Integration scenario to retest: re-run
collect_pr_contextagainst item 871's actual worktree/branch and confirm the "author asserted" list is empty or contains only#871; separately verifyghdetection against an environment whereghis confirmed installed and authenticated. - Manual verification notes: state plainly, wherever this tool's output is consumed (e.g. by
pr-author), that safety currently depends on thegh-unavailable fallback rather than on any closing-intent validation, so the fallback must not be "fixed away" without first fixing the harvester.
Next Step
- Promote to GitHub issue (bug-report template)
- Move to active fix folder / branch
- Unit coverage areas: a closing-keyword extractor that requires an adjacent closing verb (
Verified fixed upstream in drm-copilot v1.1.12 (drm-copilot PR #703, merge b6745383; gh detection fixed in 58b93e12 and a27d1513).
collector-core.ts:204-207no longer builds the author-asserted autoclose list from prose. Closing targets now come only from GitHubclosingIssuesReferences, or from the feature's own open primary issue. TaskMaster's.mcp.jsonruns the published package throughnpx -y, and the 1.1.12 harness is pushed down (7ed1975). Closing.
Summary
mcp__drm-copilot__collect_pr_contextproduces an "author-asserted autoclose issues" list by scraping#<number>tokens out of prose inside a feature's own documents, without distinguishing a citation/reference from a closure intent. On item 871 this produced seven unrelated issue numbers plus one nonsense token, none of which item 871's pull request closes. It did not fire only because GitHub CLI validation was reported unavailable and the pr-author skill'sNonefallback applied - a fallback, not a control.Environment
drm-copilotMCPcollect_pr_contexttoolmcp__drm-copilot__collect_pr_contextinvoked for item 871 (bug/qfcqueue-enqueue-path-lacks-injectable-seams-871), basemaindocs/features/active/2026-09-11-qfcqueue-enqueue-path-lacks-injectable-seams-871/artifacts/pr_context.summary.txtSteps to Reproduce
artifacts/pr_context.summary.txt.===== Close candidates =====section,Auto-close issues (author asserted):subsection.#620, #678, #724, #727, #731, #781, #784, #871, #ISO-8601.spec.md,issue.md, and research document for each of those numbers (excluding Bug: qfcqueue-enqueue-path-lacks-injectable-seams #871 itself): every one of Bug: quickfiler-emailmovemonitor-instances-not-shared #620, Bug: quickfiler-carry-folder-predictor-to-item-controller #678, fix(quickfiler): carry the initialised folder predictor to the item controller (#678) #724, Bug: quickfiler-coverage-filesize-evidence-debt #727, Bug: quickfiler-controller-lifecycle-disposal-defects #731, Bug: breadcrumb-ui-boundary-guard-rejects-dispatcher-built-viewers #781, Bug: uithread-synccontext-awaiter-always-posts-for-dispatcher-built-viewers #784 appears only as a prose citation - e.g.spec.md:771: "the move-monitor per-owner invariant issues Bug: quickfiler-controller-lifecycle-disposal-defects #731 and Bug: quickfiler-emailmovemonitor-instances-not-shared #620; the dispatcher synchronization-context hazard issues Bug: breadcrumb-ui-boundary-guard-rejects-dispatcher-built-viewers #781 and Bug: uithread-synccontext-awaiter-always-posts-for-dispatcher-built-viewers #784, which this item neither introduces nor mitigates" - never as a stated closing target.#ISO-8601entry has no issue-number form at all; it is a scraping artifact, most likely from a timestamp-shaped string in the source text being matched by the same#-prefixed pattern.===== GitHub CLI status =====section reports "GitHub CLI unavailable: GitHub CLI (gh) is not installed." - whileghwas independently confirmed working in the same environment during this filing (gh issue view,gh pr viewboth succeeded againstdrmoisan/TaskMaster).Expected Behavior
The context-collection tool should distinguish a genuine closing-intent statement (e.g. "Closes #871", "Fixes #871") from an ordinary citation or cross-reference appearing in prose (e.g. "issue #731 finding 1", "the dispatcher synchronization-context hazard issues #781 and #784"). It should not include cited-but-not-closed issue numbers in an "author-asserted autoclose" list, and it should not emit a malformed non-numeric token like
#ISO-8601. It should also correctly detect an installed, workingghCLI rather than reporting it unavailable.Actual Behavior
The tool's "author-asserted autoclose issues" list for item 871 contained:
#620, #678, #724, #727, #731, #781, #784, #871, #ISO-8601. Only#871is the issue this PR addresses. The other seven are unrelated issues referenced only as citations inside item 871's own spec/issue/research documents, and#ISO-8601is not a valid issue reference at all. Had these been emitted as actual GitHub closing keywords in the PR body and had GitHub validation been available, merging the pull request would have closed seven unrelated issues. Thepr-authorskill's body for PR #883 states explicitly: "GitHub CLI validation was unavailable when this body was generated, so no closing keyword is emitted... The context bundle's author-asserted list also harvested several unrelated issue numbers from prose inside the feature documents; emitting closing keywords from that list would have closed issues this PR does not address." Additionally,artifacts/pr_context.summary.txtreports "GitHub CLI unavailable: GitHub CLI (gh) is not installed," which is false in this environment:gh issue view 882andgh pr view 883both succeeded during this same filing session. A further defect, reported by the delegating coordinator and not independently reproduced in this filing, is thatcollect_pr_contextcan produce a vacuous zero-diff context when invoked against a workspace root whose checked-out branch is not the target branch; this is recorded here for completeness and should be verified independently before being treated as confirmed.Logs / Screenshots
artifacts/pr_context.summary.txt(item 871), lines 38-47:GitHub CLI unavailable: GitHub CLI (gh) is not installed. Install from https://cli.github.com/.Impact / Severity
High: the mechanism can cause a merge to close unrelated, unaddressed issues with no warning to the author. It did not fire on item 871 only because of an unrelated tool-availability fallback, which is not a designed safety control.
Source
From: docs/features/potential/2026-09-13-pr-context-harvests-closing-keywords-from-prose.md