fix(settings): thread unstableExplainedByIgnoredChecks into isCommentMergeStateHeld

[bitfathers94]

fix(settings): thread unstableExplainedByIgnoredChecks into isCommentMergeStateHeld

isCommentMergeStateHeld re-derived unstable-holds from the raw mergeable_state
string alone, so it stayed true even when the planner's derivePrDisposition had
already stopped holding an unstable state fully explained by an ignored check.
The comment surface's only production caller now resolves the same formula
buildPrDispositionInput uses from its own live-CI inputs and passes it through,
restoring the "equal by construction" invariant the module's JSDoc claims.

Closes #10055

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-31 07:48:20 UTC}

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

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This PR closes the real bug behind #10055: isCommentMergeStateHeld re-derived 'unstable' from the raw mergeable_state string alone, so the comment surface kept holding a PR the planner's derivePrDisposition had already released via unstableExplainedByIgnoredChecks. The fix adds an optional second parameter to isCommentMergeStateHeld with the identical unstableHolds formula used in derivePrDisposition, and processors.ts's derivePublicCommentMergeFacts recomputes the same ignored-checks resolution from its own live-CI inputs (ignoredCheckDetails) rather than trusting a second source. Backward compatibility is preserved via the optional param defaulting to undefined (treated as false), and the invariant test now iterates all three flag values per state instead of only the absent-flag arm, closing the exact gap that let the two functions silently diverge before.

Nits — 5 non-blocking

• src/queue/processors.ts:2163-2168 — the new `ignoredCheckDetails` field is typed optional on a `Pick<LiveCiAggregate,...>` intersection; worth double-checking no other non-production caller of `derivePublicCommentMergeFacts` passes a `liveCi` object typed without this field in a way that would silently opt into 'nothing ignored' when it shouldn't.
• src/settings/pr-disposition.ts — the JSDoc comment above `isCommentMergeStateHeld` is now quite long (5+ lines); consider trimming to the load-bearing invariant line once the historical explanation is captured in the module-level comment.
• The external brief's 'magic number 10055' flag is a false positive — it's just the issue reference in a comment, not a literal used in logic.
• src/queue/processors.ts:2189 — the `ignoredCheckNonPassing` filter recomputation duplicates the exact formula in agent-actions.ts's buildPrDispositionInput; a shared helper (e.g., exported from pr-disposition.ts or ci-resolution.ts) would remove the drift risk this PR itself is fixing, since the JSDoc's 'equal by construction' claim currently relies on two independently-maintained implementations of the same predicate.
• Readiness score is below the configured threshold — Use the readiness panel as advisory maintainer context; the score does not block this PR.

Decision drivers

• ✅ Code review — No blockers (1 reviewer)
• ✅ Gate result — Passing (No configured blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ Linked	#10055
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	❌ 8/20	High review scope from cached public metadata (1 linked issue).
Validation posture	⚠️ 12/25	Preflight needs author follow-up before maintainer review.
Contributor workload	✅ 10/10	Author activity: 98 registered-repo PR(s), 67 merged, 3 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	bitfathers94; Gittensor profile; 98 PR(s), 3 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: moderate

Linked issue satisfaction

Addressed
The PR adds a second optional parameter to isCommentMergeStateHeld using the identical unstableHolds expression from derivePrDisposition, updates the invariant test to iterate over all three flag values (proving equal-by-construction rather than just pinning it), and threads a matching ignored-check resolution into the processors.ts call site sourced from the same LiveCiAggregate ignoredCheckDetai

Review context

• Author: bitfathers94
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: TypeScript
• Official Gittensor activity: 98 PR(s), 3 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Add a concise scope and risk note.
• Then work through the remaining 2 steps in the Signals table above.

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.

🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

_{🟩 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 LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review

[superagent-security]

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

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.62%. Comparing base (3295614) to head (a2076b3).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #10110      +/-   ##
==========================================
+ Coverage   79.79%   80.62%   +0.83%     
==========================================
  Files         282      284       +2     
  Lines       58690    62182    +3492     
  Branches     6892     8177    +1285     
==========================================
+ Hits        46832    50137    +3305     
- Misses      11570    11636      +66     
- Partials      288      409     +121     

Flag	Coverage Δ
backend	94.64% <100.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/queue/processors.ts	94.61% <100.00%> (ø)
src/settings/pr-disposition.ts	100.00% <100.00%> (ø)

[loopover-orb]

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