feat(miner-hands): resolve the own-rejection-history trigger of rejectionSignaled

[jeffrey701]

What & why

Closes #5655.

iterate-policy.ts's doc comment has always defined rejectionSignaled as true when the repo has signaled it doesn't want automated contributions — either an explicit AI-usage-policy ban or a prior submission from this same miner that was closed/rejected on this exact repo. resolveRejectionSignaled only resolved the first trigger; its own header documented the second as a deliberate gap. This wires the two already-shipped modules that close it.

resolveOwnRejectionHistory(repoFullName, options) (new): reads this miner's own recorded submissions on the target repo (listRecentOwnSubmissions, #5134), fetches each one's live GET /pulls/{n} state, and runs it through resolveRejection (#4278) — returning true if any was closed without merge. It consumes both upstream modules without modifying either (out of scope per the issue).

• Bounded fetch count — only the most recent maxRejectionHistoryChecks (default 10) submissions with a real PR number are fetched, so a long history on one repo never triggers an unbounded API fan-out.
• Fail-open — a wholesale failure to read submissions resolves to false (never fabricated as a rejection, per the issue); any single PR fetch/parse failure is skipped so it never blocks the others.
• Combined — resolveRejectionSignaled now returns true if either trigger fires (the policy-doc ban short-circuits), and its header/comment are updated to reflect the closed gap.

Acceptance criteria

• A real own-rejection-history check backed by live GitHub PR state, not fabricated
• Bounded fetch count per call
• Fails open (never blocks/crashes) on individual or wholesale fetch failure
• rejectionSignaled now reflects both documented triggers
• No change to rejection-state-machine.js or governor-state.js's own logic

Tests

test/unit/miner-rejection-signal.test.ts (all pass; 100% of the changed lines/branches covered): real-rejection-detected, no-prior-submissions (no fetch), bounded-fetch-count, fail-open (individual PR failure + wholesale), a merged/non-2xx PR is not a rejection, auth-header wiring, and the combined-trigger cases (policy ban with clean history, and clean policy with a real rejection, each resolve true). tsc --noEmit and the existing suite stay green.

[superagent-security]

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

[loopover-orb]

Tip

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

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-13 21:36:33 UTC}

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

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This PR wires resolveOwnRejectionHistory (consuming the already-shipped listRecentOwnSubmissions and resolveRejection modules) into resolveRejectionSignaled, closing the documented second-trigger gap without modifying either upstream module. The implementation is bounded (default 10 checks), fail-open on both wholesale and per-item failures, and the new test suite exercises both triggers, the short-circuit, the bound, and per-item failure isolation with real assertions against the actual code paths. The one thing I'd want confirmed is whether resolveRejection's second parameter (passed as `undefined` here) is ever dereferenced without a guard, since that's the one upstream contract this PR relies on without being able to see its source in this diff.

Nits — 5 non-blocking

• packages/gittensory-miner/lib/rejection-signal.js: resolveOwnRejectionHistory passes `undefined` for resolveRejection's second arg (gate/duplicate context) — confirm resolveRejection.js handles a missing second argument since it's not shown in this diff.
• packages/gittensory-miner/lib/rejection-signal.js:22 hardcodes `https:​//api.github.com` as the default base URL; this matches the existing rawContentBaseUrl pattern in the file so it's consistent, but worth confirming there isn't a shared config constant for GitHub API base elsewhere in the codebase.
• The magic issue numbers (Check a miner's own prior-rejection history on a repo (rejectionSignaled's second documented trigger) #5655, feat(miner-manage): rejection state machine (closed/rejected → disengaged) #4278) embedded in comments are fine as historical breadcrumbs but add no runtime value — purely a style note.
• packages/gittensory-miner/lib/rejection-signal.js: resolveOwnRejectionHistory's cyclomatic complexity is a bit high (try/catch + filter + loop + nested try/catch); could extract the per-submission check into a small helper for readability, though it's not required.
• Consider extracting the per-submission try/catch loop body in resolveOwnRejectionHistory into a small `checkSubmission` helper to reduce nesting depth and ease future changes.

Signal	Result	Evidence
Code review	✅ No blockers	1 reviewer
Linked issue	✅ Linked	#5655
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: 117 registered-repo PR(s), 55 merged, 32 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	jeffrey701; Gittensor profile; 117 PR(s), 32 issue(s).
Gate result	✅ Passing	No configured blocker found.
Improvement	✅ Minor	risk: clean · value: minor — Code changes are accompanied by test evidence.

Review context

• Author: jeffrey701
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: not available
• Official Gittensor activity: 117 PR(s), 32 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Keep the PR focused and include validation evidence before maintainer review.

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.

[BETA] Chat with Gittensory

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

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

Full command reference: https://gittensory.aethereal.dev/docs/gittensory-commands

_{🟩 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

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.03%. Comparing base (0dfc40a) to head (dfd7448).
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5657   +/-   ##
=======================================
  Coverage   95.03%   95.03%           
=======================================
  Files         577      577           
  Lines       45920    45946   +26     
  Branches    14695    14695           
=======================================
+ Hits        43639    43666   +27     
+ Misses       1528     1527    -1     
  Partials      753      753           

Flag	Coverage Δ
shard-1	43.52% <0.00%> (-0.44%)	⬇️
shard-2	35.73% <7.40%> (+0.06%)	⬆️
shard-3	32.23% <100.00%> (+0.03%)	⬆️
shard-4	30.97% <0.00%> (-1.61%)	⬇️
shard-5	32.66% <7.40%> (+0.88%)	⬆️
shard-6	44.82% <7.40%> (+0.36%)	⬆️

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

Files with missing lines	Coverage Δ
packages/gittensory-miner/lib/rejection-signal.js	100.00% <100.00%> (ø)

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:

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