work-items open-linked-PR filter: closing-keyword regex matches fenced-code-block examples

[kyle-sexton]

Context

Surfaced by a Codex P2 review thread on PR #643 (thread PRRT_kwDOTCGFQM6SLf9b, plugins/work-items/tools/work-item-tracker/adapters/github/README.md). Filed per the triage rule as a design question rather than fixed inline.

Problem

The "Open linked PRs" filter (new in #643) runs its closing-keyword jq test(...) over the raw PR body:

"(?i)(?<!\w)(?:close|closes|closed|fix|fixes|fixed|resolve|resolves|resolved):?[ \t]+#\($n)(?![0-9])"

GitHub treats fenced code blocks as inert for auto-close linkage — documented in this same repo at plugins/source-control/skills/pull-request/reference/create.md ("Fenced code blocks ARE inert, so example snippets are safe"). The raw-body regex does not share that awareness: an open PR whose body contains a fenced example such as

```text
Closes #<N>
```

matches true and drops the still-ready issue #<N> from the pickable frontier, even though GitHub will not auto-close it on merge.

Why this is a design question, not a small inline fix

Making the match fence-aware in a jq/shell one-liner is not small or bounded: it requires tracking fence state (opening/closing fences, variable backtick counts, ~~~ fences, indented fences) before the keyword test. That is a real complexity-vs-precision tradeoff on a comparatively rare edge case (an open PR body carrying a fenced Closes #<specific-N> for the exact issue under test), so it does not qualify as a VALID-small-own-path inline fix under the triage rule.

Root-cause candidate to evaluate (do not assume)

Rather than layering fence-stripping onto a raw-body heuristic, the authoritative signal may be GitHub's own computed linkage: the GraphQL PullRequest.closingIssuesReferences connection returns the issues GitHub will auto-close from the body. To verify: confirm whether closingIssuesReferences honors fence-inertness (and HTML-comment behavior) as expected; if so, it sidesteps both the fenced-block and the word-boundary heuristics entirely. This would be a design change to the filter, out of scope for the #643 triage.

Related

• Note the same fence-blindness pattern also exists in the pre-create gate's line-anchored KEYWORD_REGEX (create.md); worth considering whether any chosen approach should be applied consistently across both matchers.

[kyle-sexton]

This was generated by AI during triage.

Triage — needs-human, wayfind: research.

Genuinely open, not a single clear fork: the reporter explicitly asks to first verify whether GitHub's own PullRequest.closingIssuesReferences GraphQL field already honors fence-inertness (and HTML-comment behavior), which — if true — sidesteps the fence-blindness problem entirely rather than requiring hand-rolled fence-state tracking layered onto the current raw-body regex. That verification step has to happen before any design commitment, and the reporter explicitly says "do not assume." Also flags the same fence-blindness pattern exists in the pre-create gate's KEYWORD_REGEX (create.md) — worth a consistent resolution across both matchers once the GraphQL question is answered.

[kyle-sexton]

Scope extension from a follow-up Codex P2 on PR #643 (thread PRRT_kwDOTCGFQM6SMDvX): whatever fence-aware approach lands here must parse fences with their ACTUAL delimiter length — a four-backtick block legitimately contains triple-backtick lines (CommonMark: closing fence must be at least as long as the opener), so naive triple-backtick toggling misparses nested examples. Further weight for the closingIssuesReferences root-cause fix over regex/fence heuristics.

[kyle-sexton]

Premise correction (control tower, post-digest): PR #643's head 828669a landed an inline fence-stripping gsub, so the original problem statement ('regex runs over the RAW PR body') is now stale — standard triple-backtick/~~~ fences ARE stripped before the closing-keyword scan. The residual scope of this issue is ONLY the nested/longer-delimiter fence case (four-backtick block containing triple-backtick lines, per the CommonMark note above) plus the structural preference for GraphQL closingIssuesReferences over body heuristics. Empirical exposure: digest sampled ~120 recent PRs — 21 carry fences, exactly 1 had a fenced closing keyword, and it was a standard fence the gsub now strips; zero occurrences of the nested case.

[kyle-sexton]

This was generated by AI during triage.

Re-triage (2026-07-20, premise corrected) — ready with noted decision, downgraded to priority:low.

Control tower's post-digest correction changed the facts: PR #643's head 828669a already shipped an inline fence-stripping gsub, so the original raw-body-regex problem is fixed for standard triple-backtick/~~~ fences. Empirical digest sample (~120 recent PRs, 21 carrying fences): exactly 1 had a fenced closing keyword, and it was a standard fence the gsub already strips — zero occurrences of the residual nested/longer-delimiter case (a four-backtick block legitimately containing triple-backtick lines per CommonMark, which naive triple-backtick toggling would still misparse).

Decision defaulted: no fence-state-tracking hardening for the nested case — veto before merge. Zero empirical occurrences across the sampled PRs doesn't justify the real complexity (tracking fence delimiter length, multiple fence styles) that a correct nested-fence parser requires. The structural preference for GitHub's own PullRequest.closingIssuesReferences GraphQL field over any body-regex heuristic remains a valid future idea — worth revisiting only if someone wants to remove regex heuristics entirely, not as urgent work. Downgrading from needs-human to status: ready + priority: low since the active bug is fixed and the residual scope is optional, well-understood hardening rather than an open design question.