fix(review): re-check live review-thread state before executing a thread-only close

[JSONbored]

Summary

• A contributor PR that is auto-closed solely because of an unresolved GitHub review thread had zero live re-check of that fact before the close actually executed, at either of the two actuation checkpoints in this codebase. This is the same staleness pattern Review latency can create a merge-conflict close window an author didn't cause #3863 already fixed for base-conflict closes (re-checking mergeable_state live right before acting, since a slow review pass can let the underlying fact change between planning and actuation) -- but Review latency can create a merge-conflict close window an author didn't cause #3863's fix only covers a conflict-justified close (closeRequiresMergeableState: true). A review-thread-only close is planned with closeRequiresMergeableState: false, the same bucket the code explicitly exempts from a CI recheck. A contributor resolving the thread on GitHub between planning and actuation is exactly the kind of live-changeable fact that needs its own recheck, mirroring Review latency can create a merge-conflict close window an author didn't cause #3863's reasoning.
• Tag a review-thread-justified close with a new closeRequiresThreadResolved marker at planning time, then extend both actuation checkpoints (the approval-queue's accept-time recheck, and the executor's step-8 pre-mutation live-recheck) to call the already-existing fetchLiveReviewThreadBlockers helper and deny/supersede the close if the threads have since all resolved.
• Fixes Review-thread-only heuristic closes have no live re-check before actuation #3919.

Scope

• The PR title follows type(scope): short summary Conventional Commit format, for example fix(api): restore profile access checks.
• This PR is focused and does not mix unrelated backend, UI, MCP, docs, dependency, and deploy changes.
• This follows CONTRIBUTING.md and does not reintroduce GitHub Pages, VitePress, site/, or CNAME.
• I linked an issue, or this is small enough that the summary explains why an issue is not needed.

Validation

• git diff --check
• npm run actionlint
• npm run typecheck
• npm run test:coverage locally; codecov/patch requires ≥99% coverage of the lines AND branches you changed (aim for 100% on your diff so CI variance does not fail near the threshold). Global coverage is a non-blocking trend with a loose 90% backstop, not the gate.
• npm run test:workers
• npm run build:mcp
• npm run test:mcp-pack
• npm run ui:openapi:check
• npm run ui:lint
• npm run ui:typecheck
• npm run ui:build
• npm audit --audit-level=moderate
• New or changed behavior has unit/integration tests for new branches, fallback paths, and sanitizer boundaries

Safety

• No secrets, wallet details, hotkeys, coldkeys, user PATs, private keys, raw trust scores, private rankings, or private maintainer evidence are exposed.
• Public GitHub text stays sanitized, low-noise, and does not imply compensation guarantees or optimization tactics.
• Auth, cookie, CORS, GitHub App, Cloudflare, or session changes include negative-path tests.
• API/OpenAPI/MCP behavior is updated and tested where needed.
• UI changes use live API data or real empty/error/loading states, not production mock/demo fallbacks.
• Visible UI changes include a UI Evidence section below with JPG/JPEG or PNG screenshots -- N/A, this is a backend-only logic fix with no UI surface.
• Public docs/changelogs are updated where needed; changelogs are only edited for release-prep PRs.

Notes

• This is a backend-only change (src/settings/agent-actions.ts, src/services/agent-approval-queue.ts, src/services/agent-action-executor.ts, src/types.ts) plus matching unit tests; no schema, OpenAPI, wrangler binding, or migration changes are needed.

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[loopover-orb]

Tip

🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩

✅ Gittensory review result - approve/merge recommended

_{Review updated: 2026-07-07 07:14:24 UTC}

7 files · 1 AI reviewer · no blockers · readiness 100/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This PR extends the #3863 live-recheck pattern to review-thread-justified heuristic closes: it adds a closeRequiresThreadResolved marker at planning time (agent-actions.ts) and wires a live fetchLiveReviewThreadBlockers recheck into both actuation checkpoints (agent-approval-queue.ts accept path and agent-action-executor.ts step-8 pre-mutation path), correctly round-tripping the field through actionParams/pendingActionToPlanned. The fail-open semantics (rejected promise vs. genuinely-fulfilled-empty-array) are handled carefully and mirror the existing mergeable-state recheck's discipline, with extensive matching tests for each branch. One real semantic gap: in agent-approval-queue.ts the staleReason ladder picks mergeableNowCleared before threadsNowResolved (and analogously in agent-action-executor.ts, ciStaleReason ?? mergeableStaleReason ?? threadStaleReason), so a close justified by BOTH an unresolved conflict and an unresolved thread gets superseded as soon as either axis alone clears, even though the other still independently justifies the close — though this may be an intentional extension of the codebase's existing 'fail toward not-closing' conservatism rather than a new defect.

Nits — 6 non-blocking

• src/services/agent-approval-queue.ts and src/services/agent-action-executor.ts: when a close is justified by both an unresolved conflict AND an unresolved review thread (closeRequiresMergeableState and closeRequiresThreadResolved both true), the staleReason logic supersedes the close as soon as EITHER axis clears rather than requiring BOTH to clear — confirm this OR-of-independent-signals is intentional (consistent with the codebase's fail-toward-revalidate bias) rather than an oversight.
• External brief notes 'blacklist' terminology at agent-action-executor.ts:368, though this predates the diff and isn't introduced by it.
• The long-file size flags on agent-action-executor.ts/agent-actions.ts/types.ts are pre-existing file sizes, not something this diff meaningfully worsens structurally.
• Consider whether staleReason should require all applicable recheckable justifications (mergeable + thread) to clear before superseding a mixed-justification close, rather than either one alone.
• The doc comments are thorough; consider consolidating the near-duplicate 'ALWAYS set, never omitted' discipline explanation that's repeated across types.ts, agent-actions.ts, and agent-approval-queue.ts into one canonical location referenced by the others.
• PR author also opened the linked issue — Link an issue that was opened by a different contributor, or provide a rationale for why this self-authored issue represents genuine discovery work.

Signal	Result	Evidence
Code review	✅ No blockers	1 reviewer
Linked issue	✅ Linked	#3919
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 51 registered-repo PR(s), 43 merged, 343 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 51 PR(s), 343 issue(s).
Gate result	✅ Passing	No configured blocker found.

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Python, TypeScript, JavaScript, Ruby, Go, Kotlin, MDX, Shell
• Official Gittensor activity: 51 PR(s), 343 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Treat this as maintainer-lane context rather than normal contributor-lane activity.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers.

• Re-run Gittensory review

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.58%. Comparing base (61109fe) to head (b0336f2).
⚠️ Report is 5 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3931   +/-   ##
=======================================
  Coverage   93.58%   93.58%           
=======================================
  Files         358      358           
  Lines       34342    34358   +16     
  Branches    12570    12585   +15     
=======================================
+ Hits        32138    32154   +16     
  Misses       1580     1580           
  Partials      624      624           

Files with missing lines	Coverage Δ
src/services/agent-action-executor.ts	97.02% <100.00%> (+0.04%)	⬆️
src/services/agent-approval-queue.ts	100.00% <100.00%> (ø)
src/settings/agent-actions.ts	97.70% <100.00%> (+0.01%)	⬆️

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[loopover-orb]

Gittensory approves — the gate is satisfied and CI is green.