feat(miner): resolve rejectionSignaled's AI-usage-policy-ban trigger (#5132)

[JSONbored]

Summary

Advances #5132

IterateLoopInput.rejectionSignaled has two documented triggers per iterate-policy.ts's own doc comment: an explicit AI-usage-policy ban on the target repo, or a prior submission from this miner closed/rejected on that exact repo. This adds resolveRejectionSignaled(repoFullName, options), which fetches AI-USAGE.md/CONTRIBUTING.md live from raw.githubusercontent.com (falling through to CONTRIBUTING.md only when AI-USAGE.md is absent/empty) and runs them through the engine's existing resolveAiPolicyVerdict -- the same check opportunity-fanout.js already runs during discovery, applied here at attempt time.

The second trigger (a prior submission from this same miner was closed/rejected on this exact repo) is deliberately not resolved here: it needs each of this miner's recorded own-submissions (governor-state.js's listRecentOwnSubmissions, #5134) cross-checked against their live PR outcome via rejection-state-machine.js's resolveRejection -- a second, separately-scoped fetch-and-classify pipeline. Left as a documented follow-up rather than fabricated as "no rejection history."

Test plan

• npx vitest run test/unit/miner-rejection-signal.test.ts -- 8/8 passing (ban match, no ban, AI-USAGE.md-empty fallthrough to CONTRIBUTING.md, both-404 fail-open, network-error fail-open, malformed repoFullName, custom rawContentBaseUrl, default global fetch)
• node --check packages/gittensory-miner/lib/rejection-signal.js
• npm run --prefix packages/gittensory-miner build (added rejection-signal.js to the check list)
• npm run test:engine-parity

[superagent-security]

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

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	gittensory-ui	8237ede	Commit Preview URL Branch Preview URL	Jul 12 2026, 11:27 AM

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.34%. Comparing base (69e8d81) to head (8237ede).
⚠️ Report is 2 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5241   +/-   ##
=======================================
  Coverage   94.34%   94.34%           
=======================================
  Files         473      473           
  Lines       39982    39982           
  Branches    14576    14576           
=======================================
  Hits        37722    37722           
  Misses       1585     1585           
  Partials      675      675           

Flag	Coverage Δ
shard-1	46.29% <ø> (-0.15%)	⬇️
shard-2	34.60% <ø> (+0.01%)	⬆️
shard-3	31.02% <ø> (-1.14%)	⬇️
shard-4	32.93% <ø> (+0.91%)	⬆️
shard-5	33.58% <ø> (-0.16%)	⬇️
shard-6	45.18% <ø> (+0.30%)	⬆️

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

🚀 New features to boost your workflow:

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

[loopover-orb]

Warning

🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨

⏸️ Gittensory review result - manual review recommended

_{Review updated: 2026-07-12 11:30:16 UTC}

7 files · 1 AI reviewer · 2 blockers · readiness 93/100 · CI green · unstable

⏸️ Suggested Action - Manual Review

• No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.
• Maintainer requires a linked issue — Link the relevant issue (for example Closes #123) before opening the PR.

Review summary
This PR adds `resolveRejectionSignaled(repoFullName, options)` in packages/gittensory-miner/lib/rejection-signal.js, which fetches AI-USAGE.md/CONTRIBUTING.md from raw.githubusercontent.com and reuses the engine's existing `resolveAiPolicyVerdict` to resolve the first of `rejectionSignaled`'s two documented triggers (explicit AI-usage-policy ban), fails open to `false` on any fetch/parse error, and is wired into the build's `node --check` list. The second trigger (prior same-miner rejection on the exact repo) is explicitly left unresolved with a clear doc-comment rationale rather than being faked as 'no rejection history', which matches the stated discipline from prior PRs. The change is well-scoped, has 8 unit tests covering ban/no-ban/empty-fallthrough/404/network-error/malformed-input/custom-base-url/default-fetch paths, and correctly guards `repoFullName` parsing before making any network calls.

Blockers

• packages/gittensory-miner/lib/rejection-signal.js:60 adds `resolveRejectionSignaled`, but no changed caller imports or invokes it, so the real attempt-time `IterateLoopInput.rejectionSignaled` path remains unchanged; wire the resolver into the code that constructs the iterate input, for example by assigning `rejectionSignaled: await resolveRejectionSignaled(repoFullName, { fetchImpl })`, or explain where an existing caller already does that.

Nits — 5 non-blocking

• packages/gittensory-miner/lib/rejection-signal.js:29-33 sends `accept: application/json` when fetching a Markdown file from raw.githubusercontent.com — harmless since raw.githubusercontent.com ignores Accept and serves raw bytes regardless, but it reads as a copy-paste leftover from a JSON-fetching helper; consider `text/plain` or dropping the header.
• packages/gittensory-miner/lib/rejection-signal.js:37-45 collapses a 404 (repo genuinely has no policy doc) and a network/DNS failure into the same `null`/fail-open path, so a transient outage silently behaves like 'no ban' rather than surfacing for retry/logging — acceptable given the documented fail-open default, but worth a comment or metric if this becomes a hot path.
• packages/gittensory-miner/lib/rejection-signal.js:19 hardcodes `raw.githubusercontent.com` as the default host; it's overridable via `rawContentBaseUrl` so this is minor, but a shared constant module (if one already exists for GitHub hosts elsewhere in the miner) would avoid drift.
• Consider logging (even at debug level) when both `AI-USAGE.md` and `CONTRIBUTING.md` fetches fail with a non-404 status, to distinguish 'repo has no policy doc' from 'we couldn't reach GitHub' during later triage of the second-trigger follow-up work.
• The `.d.ts` re-exports `SelfReviewContextFetch` from self-review-context.js for the `fetchImpl` option type — worth confirming that type is still exported there since it's not shown in this diff (per the file's own JSDoc reference).

Concerns raised — review before merging

• No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.
• Maintainer requires a linked issue — Link the relevant issue (for example Closes #123) before opening the PR.

Signal	Result	Evidence
Code review	❌ 2 blockers	1 reviewer
Linked issue	⚠️ Missing	No linked issue or no-issue rationale found.
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 (no linked issue context).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 44 registered-repo PR(s), 36 merged, 470 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 44 PR(s), 470 issue(s).
Gate result	❌ Blocking	Repo-configured hard blocker found.
Improvement	✅ Minor	risk: clean · value: minor — Code changes are accompanied by test evidence.

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, Ruby, Go, JavaScript, MDX, Shell, Solidity
• Official Gittensor activity: 44 PR(s), 470 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Treat this as maintainer-lane context rather than normal contributor-lane activity.
• Explain no-issue PR.
• Link the issue being solved, or explicitly explain why this is a no-issue PR.

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 Gittensory, a quiet PR intelligence layer for OSS maintainers.

• Re-run Gittensory review