chore: reactivate stale issue cleanup

[Hmbown]

Summary\n- create the missing GitHub stale-policy labels used by the workflow: needs-info, stale, keep-open, and pinned\n- let bug + needs-info issues age out unless they also carry release-blocker, security, keep-open, or pinned\n- document dry-run queries and the first manual cleanup pass for old duplicate/roadmap issues\n\n## Verification\n- git diff --check origin/main..HEAD\n- ruby -e 'require "yaml"; YAML.load_file(".github/workflows/stale.yml"); puts "stale.yml parsed"'\n- gh label list --repo Hmbown/CodeWhale --limit 200 | rg '^(needs-info|stale|keep-open|pinned)\b'\n- gh issue list --repo Hmbown/CodeWhale --state open --search 'label:needs-info' --limit 100 --json number,title,updatedAt,labels,url returned an empty list before automation would affect anything\n\nRefs #3089

[claude]

Claude finished @Hmbown's task in 59s —— View job

---

Code Review

• Read changed files and diff
• Analyze stale.yml logic
• Review ISSUE_TRIAGE.md
• Post findings

---

Summary: This is a clean, conservative change. The one-line workflow edit is correct and the doc does a good job explaining the intent. No correctness bugs or safety issues found. A few minor notes below.

---

.github/workflows/stale.yml — the key change

-  exempt-issue-labels: 'pinned,keep-open,bug,security'
+  exempt-issue-labels: 'pinned,keep-open,release-blocker,security'

Good call. bug should not have been in the exempt list. The only-labels: 'needs-info' filter already gates the action to issues a maintainer has explicitly flagged as waiting on the reporter — removing bug from the exemptions just closes the loophole where a bug+needs-info issue could sit indefinitely. The swap for release-blocker is the right protective label.

Minor notes:

1. No repo-token field. This defaults to ${{ github.token }}, which is fine given the explicit issues: write permission block at the top. Just worth being aware of if token scoping changes.

2. actions/stale@v10 not pinned to a SHA. For a cron workflow with issues: write it's a mild supply-chain surface. Pinning to a SHA (e.g. actions/stale@5bfe6af…) is a lower-risk posture. Not a blocker for this PR.

3. remove-stale-when-updated not set. Default in v10 is true (a reply removes the stale label), which is the right behavior here. Worth documenting explicitly in the doc if this ever gets revisited.

---

docs/ISSUE_TRIAGE.md

Well-structured. The protected-label list matches the workflow exactly. A couple of minor points:

1. Hardcoded dates in dry-run queries (2026-05-11, 2026-05-28). These will silently become misleading as time passes. Consider commenting the intent instead (e.g. # issues inactive for 45+ days) so whoever runs the query knows what to substitute.

2. "A bug issue is not protected just because it is a bug." — This paragraph is exactly the right thing to document. It's the non-obvious behavior.

---

Overall: Ready to merge. The workflow logic is correct, the safety exemptions (release-blocker, security, keep-open, pinned) are the right set, and the operations-per-run: 60 cap prevents runaway automation. The two minor notes above are optional follow-ups, not blockers.

[claude]

Claude finished @Hmbown's task in 56s —— View job

---

Code Review

• Read changed files and diff
• Analyze stale.yml logic
• Review ISSUE_TRIAGE.md
• Post findings

---

Summary: Clean, conservative change. No correctness bugs or safety issues. The one-line workflow edit is correct and the new doc is well-structured. A few minor notes:

---

.github/workflows/stale.yml

-  exempt-issue-labels: 'pinned,keep-open,bug,security'
+  exempt-issue-labels: 'pinned,keep-open,release-blocker,security'

Good call. Dropping bug from the exempt list closes the loophole where a bug+needs-info issue could sit indefinitely. The only-labels: 'needs-info' gate already limits scope to issues a maintainer has explicitly flagged as waiting on the reporter. Swapping in release-blocker is the right protective label.

Two minor observations (neither is a blocker):

1. actions/stale@v10 is not SHA-pinned. For a cron workflow with issues: write this is a mild supply-chain surface. Pinning to a commit SHA (actions/stale@<sha>) is lower-risk. Fix this →

2. remove-stale-when-updated not set. Defaults to true in v10 (a new comment removes the stale label), which is the desired behavior here. Worth an explicit comment in the YAML if this ever gets revisited.

---

docs/ISSUE_TRIAGE.md

Well-structured; the protected-label list matches the workflow exactly. One note:

• Hardcoded dates in dry-run queries (2026-05-11, 2026-05-28) will silently become misleading as time passes. Consider replacing with a comment explaining the intent (e.g. # issues inactive for 45+ days) so future maintainers know what window to substitute. Fix this →

---

Overall: Ready to merge. The only-labels: 'needs-info' + operations-per-run: 60 combination makes this conservatively scoped. The safety exemptions (release-blocker, security, keep-open, pinned) are the right set. The two notes above are optional follow-ups, not blockers.

[claude]

Claude finished @Hmbown's task in 1m 9s —— View job

---

Code Review

• Read changed files and diff
• Analyze stale.yml logic
• Review ISSUE_TRIAGE.md
• Post findings

---

Summary: Still clean. No new issues introduced by the sync. The one-line workflow edit is correct and the doc matches the workflow exactly. This is ready to merge.

---

.github/workflows/stale.yml

-  exempt-issue-labels: 'pinned,keep-open,bug,security'
+  exempt-issue-labels: 'pinned,keep-open,release-blocker,security'

Correct. The only-labels: 'needs-info' gate already limits scope to issues a maintainer has explicitly flagged — dropping bug from exemptions closes the loophole where a bug+needs-info issue could sit indefinitely without anyone noticing. release-blocker is the right replacement.

A couple of low-priority notes (neither blocks the merge, both carried over from prior passes):

1. actions/stale@v10 not SHA-pinned. Cron job with issues: write — minor supply-chain surface. Fix this →

2. pull-requests: write declared but PRs are effectively disabled (days-before-pr-stale: -1, days-before-pr-close: -1). Not a bug — the action requires the permission at declaration time even if unused. Just an observation.

---

docs/ISSUE_TRIAGE.md

Well-structured. Protected label list matches the workflow exactly. The bug paragraph is exactly the right thing to document — it captures the non-obvious behavior.

One carry-over note: hardcoded dates (2026-05-11, 2026-05-28) in the dry-run queries will silently become misleading. Consider replacing them with shell date expressions or comments explaining the intended window (e.g. # issues inactive for 45+ days). Fix this →

---

Overall: Ready to merge. The only-labels: 'needs-info' + operations-per-run: 60 combination keeps automation conservatively scoped — only issues a maintainer has already flagged are touched, and at most 60 per run. Safety exemptions (release-blocker, security, keep-open, pinned) are the right set.

[Hmbown]

Release-watch pass: holding this until after 0.8.65 rather than merging it quietly during the release lane. The change looks conservative and reviewed, but it reactivates an issue-closing workflow with write permissions, so it is operationally bigger than a docs/runtime polish merge. Best fit: land right after the 0.8.65 tag or in the 0.8.66 cleanup lane.

[claude]

Claude finished @Hmbown's task in 54s —— View job

---

Code Review

• Read changed files and diff
• Analyze stale.yml logic
• Review ISSUE_TRIAGE.md
• Post findings

---

Summary: Still clean after the sync. No new issues introduced. The two-file change is correct and ready to land whenever Hmbown lifts the 0.8.65 hold.

---

.github/workflows/stale.yml

-  exempt-issue-labels: 'pinned,keep-open,bug,security'
+  exempt-issue-labels: 'pinned,keep-open,release-blocker,security'

Correct. The only-labels: 'needs-info' gate already scopes the action to issues a maintainer has explicitly flagged — dropping bug from exemptions closes the loophole where a bug+needs-info issue could sit indefinitely. release-blocker is the right replacement.

Two low-priority notes (neither blocks the merge, both carried over from prior passes):

1. actions/stale@v10 not SHA-pinned. Cron job with issues: write — minor supply-chain surface. Pinning to a commit SHA is lower-risk but not urgent.

2. pull-requests: write declared but PRs are effectively disabled (days-before-pr-stale: -1, days-before-pr-close: -1). Not a bug — the action requires the permission at declaration time even if unused.

---

docs/ISSUE_TRIAGE.md

Well-structured; protected-label list matches the workflow exactly. The bug paragraph captures the non-obvious behavior correctly.

One carry-over note: hardcoded dates (2026-05-11, 2026-05-28) in the dry-run queries will silently become misleading. Consider replacing with comments explaining the intended window (e.g. # issues inactive for 45+ days) so future maintainers know what date to substitute. Fix this →

---

Overall: No new concerns from the sync. The only-labels: 'needs-info' + operations-per-run: 60 combination keeps automation conservatively scoped. Safety exemptions (release-blocker, security, keep-open, pinned) are the right set. Ready to land after the 0.8.65 hold.

[Hmbown]

Thanks again for the careful reviews here. I folded in the two follow-up hardening notes: actions/stale is now pinned to the current v10 commit, and the dry-run issue queries use generated cutoff dates instead of stale absolute dates.

[claude]

Claude finished @Hmbown's task in 57s —— View job

---

Code Review

• Read changed files and diff
• Verify SHA pin for actions/stale
• Verify dynamic date queries in ISSUE_TRIAGE.md
• Post findings

---

Summary: Both follow-up notes from prior passes are addressed correctly. No new issues introduced. This is clean and ready to land whenever the 0.8.65 hold lifts.

---

.github/workflows/stale.yml — SHA pin

-      - uses: actions/stale@v10
+      # Pinned from actions/stale@v10; update deliberately when refreshing the policy.
+      - uses: actions/stale@eb5cf3af3ac0a1aa4c9c45633dd1ae542a27a899

Done correctly. The inline comment makes the intent clear — this isn't accidental, it's a deliberate pinning point. Worth verifying the SHA matches the actual v10 release commit if you have a moment (gh release view v10 --repo actions/stale), but the form is correct and the supply-chain concern is resolved.

---

docs/ISSUE_TRIAGE.md — dynamic cutoff dates

STALE_CUTOFF=$(python3 -c 'from datetime import date, timedelta; print(date.today() - timedelta(days=45))')
NEEDS_INFO_CUTOFF=$(python3 -c 'from datetime import date, timedelta; print(date.today() - timedelta(days=30))')

Good implementation. python3 is reliably available on any platform these would run on, the date arithmetic is idiomatic, and the variable names match their use sites throughout the queries. The two-threshold design (45 days for general staleness, 30 days for needs-info) makes sense as conservatively-scoped dry-run windows relative to the workflow's 21-day effective window (14 stale + 7 close).

---

Overall: All prior review notes resolved. Workflow logic remains correct; automation scope unchanged. Ready to merge.

[Hmbown]

Release-watch update: this is now hardened and green. I added commit 6771558 to pin actions/stale and make the dry-run dates generated, then confirmed CodeQL, DCO, Claude review, Version drift, Change detection, and GitGuardian are passing. GitHub still refuses a normal merge because the base branch policy blocks it, and auto-merge is disabled for the repo, so this needs a maintainer/admin merge path rather than more code work.

[Hmbown]

Rechecked this during the 0.8.66 PR sweep. The diff is still focused and conservative, local diff --check/merge-tree against current main were clean, and the relevant GitHub checks are green.

I tried the normal merge path, but GitHub still blocks it with branch policy, and --auto is unavailable because repository auto-merge is disabled (enablePullRequestAutoMerge). I am continuing to avoid an admin bypass here. This remains ready once a maintainer/admin merge path is available.

Thanks to everyone who reviewed and hardened this one, especially around pinning the action SHA and making the dry-run guidance less date-stale.

[claude]

Claude finished @Hmbown's task in 57s —— View job

---

Code Review

• Read changed files and diff
• Analyze stale.yml logic and SHA pin
• Review ISSUE_TRIAGE.md for dynamic dates
• Post findings

---

Summary: Both follow-up items from prior review passes are correctly implemented. No new issues found. This is clean and ready to land.

---

.github/workflows/stale.yml

Two changes from main:

1. SHA pin:

# Pinned from actions/stale@v10; update deliberately when refreshing the policy.
- uses: actions/stale@eb5cf3af3ac0a1aa4c9c45633dd1ae542a27a899

Correct form. The inline comment makes the intent explicit so nobody removes it thinking it's a mistake. This closes the supply-chain surface noted in earlier passes.

2. Exempt label swap:

-  exempt-issue-labels: 'pinned,keep-open,bug,security'
+  exempt-issue-labels: 'pinned,keep-open,release-blocker,security'

Still correct. only-labels: 'needs-info' already gates the action to issues a maintainer has explicitly flagged — bug should never have been an automatic exemption since it created a loophole for indefinitely-open bug+needs-info issues. release-blocker is the right replacement.

Remaining low-priority observation (not a blocker): pull-requests: write is declared but PRs are effectively disabled via days-before-pr-stale: -1 / days-before-pr-close: -1. This is not a bug — actions/stale requires the permission declaration even when unused.

---

docs/ISSUE_TRIAGE.md

Dynamic cutoffs are implemented correctly:

STALE_CUTOFF=$(python3 -c 'from datetime import date, timedelta; print(date.today() - timedelta(days=45))')
NEEDS_INFO_CUTOFF=$(python3 -c 'from datetime import date, timedelta; print(date.today() - timedelta(days=30))')

date.today() - timedelta(days=N) produces a date object; print() formats it as YYYY-MM-DD, which is exactly what GitHub search expects. The 45/30-day dry-run windows are more conservative than the workflow's 21-day effective window (14 stale + 7 close) — the right posture for manual pre-checks. Protected-label list matches the workflow exactly.

---

Overall: All prior notes resolved. The automation scope is conservatively bounded (only-labels: 'needs-info' + operations-per-run: 60), safety exemptions are correct, and the doc accurately captures the non-obvious behavior (a bug issue isn't exempt just because it's a bug). Ready to merge once the branch-policy hold lifts.