Shipped Issues

Shipped Issues

Cross-reference open GitHub issues against closed GUS work items and the shipped release notes to identify issues that were fixed and released, but never closed on GitHub.

Inputs

• Repo: forcedotcom/apex-language-support
• Shipped release notes: GitHub Releases on the repo. ALS has no tracked CHANGELOG.md; it ships via semantic-release and the release bodies on GitHub are the source of truth for what shipped. Aggregate recent release notes (stable + nightly) before cross-referencing.
• GUS alias: gus (see .claude/skills/gus-cli/SKILL.md)

Workflow

1. Gather shipped release notes

# List recent releases (stable + pre-release/nightly) and dump their bodies.
gh release list --repo forcedotcom/apex-language-support --limit 100 \
  --json tagName,name,isPrerelease,publishedAt > /tmp/shipped-releases.json

# Concatenate the bodies of recent releases into one searchable file.
for tag in $(gh release list --repo forcedotcom/apex-language-support --limit 100 --json tagName --jq '.[].tagName'); do
  echo "===== $tag ====="
  gh release view "$tag" --repo forcedotcom/apex-language-support --json body --jq '.body'
done > /tmp/shipped-changelog.md

Do not switch branches; run from wherever the user is. Adjust --limit if older releases need to be covered.

2. List open issues with W- references

gh issue list --repo forcedotcom/apex-language-support --state open --limit 500 --search "W in:body" --json number,title,body,url > /tmp/shipped-issues.json

The W in:body filter narrows to issues that contain the letter W — overly broad but cheap. Locally extract W-\d{6,9} matches per issue (regex; multiple W- per issue is allowed). Drop issues with no match.

3. Query GUS for status of each W-

Batch in chunks of ~50 W- names per query to stay under SOQL limits:

sf data query --query "SELECT Id, Name, Status__c, Last_Modified_Internal_Closed_Date__c FROM ADM_Work__c WHERE Name IN ('W-1234567','W-2345678', ...)" -o gus --json

Closed terminal statuses (any of these counts as closed): see .claude/skills/gus-cli/SKILL.md § Status__c values "Closed (terminal)". Note: git2gus on this repo uses statusWhenClosed=CLOSED, so a shipped/closed WI lands on a Closed* status.

Quick check: Status__c LIKE 'Closed%' OR Status__c IN ('Completed','Fixed').

4. Filter to candidates

Keep an issue only when every W- on the issue resolves to a Closed/Completed status in GUS. If any linked W- is still open, skip the issue (work isn't all done).

5. Cross-reference shipped release notes

For each candidate issue number N, search the aggregated release notes in /tmp/shipped-changelog.md for any of:

• ISSUE #N (case-insensitive)
• issues/N (link form)
• #N only when the surrounding line clearly references an issue, not a PR

Semantic-release notes typically reference the PR that landed the fix rather than the issue. If a candidate's issue # has no direct hit, also resolve the PR(s) that mention the issue and confirm the PR appears in a release. Record the matched release tag + line for the closing comment.

If matched → issue is shipped. Record the matched release note line (and the release tag it came from) for the closing comment.

6. Present the report

Show a table to the user before closing anything:

Also list any near-miss rows separately so the user can review:

• Issues where WIs are all closed but the issue # isn't in any release notes (maybe under-the-hood / not customer-facing)
• Issues where some W- are still open

7. Close issues — only after explicit user confirmation

For each confirmed issue, post a comment then close:

gh issue close <number> --repo forcedotcom/apex-language-support --comment "Closing — shipped in <release tag>. See release note: <verbatim line>. (Linked work item <W-XXXXXXXX> is closed.)"

Do not loop-close without user confirmation. If many issues, present the full list and ask "Close all N?" once.

Edge cases

• Multiple W- per issue, mixed status: skip until all W- close.
• Issue body mentions W- in a quoted error or unrelated context: rare; surface as candidate anyway, the user reviews the table.
• Release note hit on an internal/"under the hood" line: still counts as shipped — user can opt out per-row.
• Issue # shows up in release notes only as [PR #N]: not a match by itself. Only ISSUE #N / issues/N indicate the issue. A PR reference can still confirm shipping if you've already tied that PR back to the issue (see step 5).
• No release-note match but WI closed long ago: list as near-miss, don't auto-close.
• Nightly vs stable: a fix may appear in a nightly/pre-release before a stable tag. Note which when reporting; the user decides whether nightly-only counts as shipped.

Output format

End with a one-line summary: Closed N issues; M near-misses for review.