docs(gittensor): add impact badge, CI card job, and contributing disclosure

[JSONbored]

Summary

• Gittensory is itself a Gittensor-listed repo (SN74 whitelisted). Adds the live api.gittensor.io impact badge to the top README badge row, linking to the repo's Gittensor dashboard.
• Adds a short disclosure to CONTRIBUTING.md noting the repo is Gittensor-listed and that scoring/rewards are Gittensor's, not ours (mirrors the existing "Scoring and rewards are not ours to grant" paragraph right above it).
• Adds .github/workflows/gittensor-impact.yml, a weekly + manually-dispatchable job that publishes a fuller SVG contributor-impact card (Gittensor vs. non-Gittensor PR/LOC share) via matthewevans/gittensor-impact-action, pinned to commit SHA 397fd470899cba47367458289a374eea9cb0d76a (not a floating tag) with contents: write scoped to just that job.

Security review of the action (all 4 of its Python scripts): zero third-party pip deps, no shell-injection-prone subprocess calls (list-form args throughout), one outbound GET to api.gittensor.io wrapped in try/except with graceful degradation, HTML-escaped SVG text output, tokens never logged, gh release create ... --latest=false so it never hijacks the repo's real "Latest release". Caveat: the action repo is ~1.5 days old (7 commits, 2 contributors) — young, but the code itself is clean and narrowly scoped.

The bigger rendered picture-card is intentionally not wired into the README yet — its release assets don't exist until the workflow runs once post-merge, and a dead image link is worse than not having it yet. Planned as a fast-follow once the first scheduled/dispatched run is confirmed to have published the SVGs.

Scope

• The PR title follows type(scope): short summary Conventional Commit format.
• 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 a currently open issue this PR resolves — no linked issue: this is an owner-initiated docs/CI change made in direct response to the Gittensor ecosystem's own badge announcement, not tracked as a GitHub issue.

Validation

• git diff --check
• npm run actionlint
• npm run typecheck
• npm run test:coverage — not applicable, no src/** lines changed (README/CONTRIBUTING/workflow only, not Codecov-measured)
• npm run test:workers — not applicable, no worker code changed
• npm run build:mcp / npm run test:mcp-pack — not applicable, no MCP code changed
• 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 — not applicable, no testable logic added (docs + declarative CI workflow only)

Full npm run test:ci ran green once already on this branch before rebasing onto latest main (which only moved by unrelated fix(review): ... commits); re-ran actionlint + typecheck after the rebase to confirm.

If any required check was skipped, explain why:

• Coverage/worker/MCP/miner test steps skipped as genuinely not applicable — this diff touches only README.md, CONTRIBUTING.md, and one new declarative GitHub Actions workflow file, no src/**/packages/** code.

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 (the badge reports only aggregate merged-PR/line counts, matching the existing "scoring and rewards are not ours to grant" framing).
• Auth, cookie, CORS, GitHub App, Cloudflare, or session changes include negative-path tests. — not applicable, no such changes.
• API/OpenAPI/MCP behavior is updated and tested where needed. — not applicable.
• UI changes use live API data or real empty/error/loading states — not applicable, no UI changes.
• Visible UI changes include a UI Evidence section — not applicable; the only visible change is a new badge image in README.md (a static markdown link, not an app UI surface).
• Public docs/changelogs are updated where needed; changelogs are only edited for release-prep PRs (not touched here).

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.64%. Comparing base (b69ff2a) to head (c582d1a).
⚠️ Report is 6 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4086   +/-   ##
=======================================
  Coverage   93.64%   93.64%           
=======================================
  Files         384      384           
  Lines       35835    35835           
  Branches    13150    13150           
=======================================
  Hits        33556    33556           
  Misses       1618     1618           
  Partials      661      661           

🚀 New features to boost your workflow:

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

[superagent-security]

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

[gittensory-orb]

Warning

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

⏸️ Gittensory review result - manual review recommended

_{Review updated: 2026-07-08 00:30:43 UTC}

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

⏸️ Suggested Action - Manual Review

• No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.
• AI reviewers agree on a likely critical defect: No linked open issue: the PR's own scope checklist has 'I linked a currently open issue this PR resolves' unchecked, and per CONTRIBUTING.md every PR needs one — this adds new CI surface, a new external badge dependency, and a policy-disclosure paragraph, which is exactly the kind of unsolicited feature/infra expansion the repo requires an issue for. — Resolve the flagged defect, or override if the AI reviewers are mistaken, then re-run the gate.

Review summary
This adds a Gittensor-impact GitHub badge to README, a matching disclosure paragraph to CONTRIBUTING.md, and a new weekly/manual-dispatch workflow (gittensor-impact.yml) that publishes an SVG impact card via a pinned third-party action. The workflow itself is well-built: permissions are read-only at the workflow level with write scoped only to the publish job, the action is pinned to a commit SHA (not a floating tag), and an `environment:` gate requires manual approval given the action repo's youth. The PR's own checklist shows no linked issue, which per this repo's contribution policy should block merge-readiness regardless of code quality.

Blockers

• No linked open issue: the PR's own scope checklist has 'I linked a currently open issue this PR resolves' unchecked, and per CONTRIBUTING.md every PR needs one — this adds new CI surface, a new external badge dependency, and a policy-disclosure paragraph, which is exactly the kind of unsolicited feature/infra expansion the repo requires an issue for.

Nits — 5 non-blocking

• gittensor-impact.yml has no `actions/checkout` step before invoking the action (.github/workflows/gittensor-impact.yml:27) — confirm the action fetches everything it needs via the GitHub API rather than local git state, since PR/LOC diffing usually implies repo history.
• The action step passes no `github-token`/`token` input in its `with:` block (.github/workflows/gittensor-impact.yml:28-30) despite the job granting `contents: write` for a `gh release create` call — confirm the action auto-picks up the ambient `GITHUB_TOKEN`, or the publish step will fail on auth.
• Confirm the `gittensor-impact` GitHub Environment referenced at .github/workflows/gittensor-impact.yml:24 actually exists with protection rules configured in repo settings — an environment name typo or missing config will make the job hang/fail with no clear diff-visible signal.
• The CONTRIBUTING.md addition (CONTRIBUTING.md:64-67) says PRs merged here 'may earn TAO' without any figure or link beyond the badge — consider linking directly to the Gittensor dashboard URL used in the badge for a one-click destination, matching the README link target.
• Add or link an issue number to satisfy the repo's linked-issue requirement before this is merge-ready.

Concerns raised — review before merging

• No linked open issue: the PR's own scope checklist has 'I linked a currently open issue this PR resolves' unchecked, and per CONTRIBUTING.md every PR needs one — this adds new CI surface, a new external badge dependency, and a policy-disclosure paragraph, which is exactly the kind of unsolicited feature/infra expansion the repo requires an issue for.
• No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.

Signal	Result	Evidence
Code review	❌ 2 blockers	1 reviewer
Linked issue	✅ No-issue rationale	PR body explains why no issue is linked.
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: 51 registered-repo PR(s), 43 merged, 496 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 51 PR(s), 496 issue(s).
Gate result	❌ Blocking	Repo-configured hard 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), 496 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