feat(miner-governor): add self-reputation throttle from own outcome history (#2346)

[dhgoal]

Adds the self-reputation throttle (Closes #2346) — a self-correcting slowdown driven by the miner's OWN local merge/close history, distinct from the fixed rate limit.

New packages/gittensory-engine/src/miner/self-reputation-throttle.ts:

• selfReputationThrottle(outcomes, thresholds?) → a cadence multiplier from the miner's own {merged, closed} on one repo:
  • sample < minSample ⇒ 1.0 (fails open) — a new miner / new repo is never falsely throttled (documented).
  • closeRatio <= healthyCloseRatio ⇒ 1.0; >= criticalCloseRatio ⇒ the floor; linear interpolation between.
  • Not a permanent ban — an improving ratio recovers cadence on the next call.
• Conservative built-in DEFAULT_SELF_REPUTATION_THRESHOLDS, fully configurable (a .gittensory-miner.yml overrides).
• Validates inputs (rejects negative / non-finite counts and inverted/out-of-range thresholds) rather than silently coercing — matching the discipline just added to the attempt-metering module.

Pure, no IO, local-only. The Governor chokepoint consults this before an open_pr/file_issue action and records the verdict + triggering ratio to the ledger — that consultation + ledger write is separate, maintainer-owned enforcement wiring.

Test

test/unit/miner-self-reputation-throttle.test.ts — insufficient-sample fail-open, healthy full cadence, critical floor, linear degradation (exact midpoint), monotonic recovery as the ratio improves, custom thresholds, and input-validation rejections. 7 tests pass (engine src imported via vitest, mirroring the worktree-allocator test).

• Conventional Commit; focused; Closes feat(miner-governor): self-reputation throttle from own outcome history #2346. No site//CNAME/**/lovable/**; no CHANGELOG.md. New engine module + test + one entrypoint export; no secrets.

[superagent-security]

🚨 Contributor flagged. Click here for more info: Superagent Dashboard

[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 94.11%. Comparing base (efcd25d) to head (62fee83).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4632   +/-   ##
=======================================
  Coverage   94.11%   94.11%           
=======================================
  Files         432      433    +1     
  Lines       38348    38373   +25     
  Branches    13979    13986    +7     
=======================================
+ Hits        36091    36116   +25     
  Misses       1600     1600           
  Partials      657      657           

Files with missing lines	Coverage Δ
...nsory-engine/src/miner/self-reputation-throttle.ts	100.00% <100.00%> (ø)

🚀 New features to boost your workflow:

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

[gittensory-orb]

Tip

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

✅ Gittensory review result - approve/merge recommended

_{Review updated: 2026-07-10 08:38:16 UTC}

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

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
Adds a small, pure `selfReputationThrottle` function plus a barrel export and a matching test file — no wiring into the Governor chokepoint happens in this diff, which matches the PR description's explicit statement that the consultation + ledger write is separate, maintainer-owned work. The interpolation math checks out (verified the 0.55 midpoint by hand: fraction=(0.4-0.2)/(0.6-0.2)=0.5, 1-0.5*(1-0.1)=0.55) and input validation rejects negative/non-finite counts and inverted thresholds as claimed. The one real gap is an unguarded divide-by-zero: if a caller supplies `minSample: 0` via custom thresholds (which passes validation, since `nonNegativeInt` only rejects negative/non-finite) and outcomes are `{merged: 0, closed: 0}`, `sample` is `0`, the `sample < minSample` fail-open check is `0 < 0` (false), and `closeRatio = closed / sample` becomes `NaN`, producing a `NaN` cadenceMultiplier under a `"degrading"` reason — untested and unguarded.

Nits — 5 non-blocking

• packages/gittensory-engine/src/miner/self-reputation-throttle.ts:88-90 — with a custom `minSample: 0` and `outcomes: {merged: 0, closed: 0}`, `sample < minSample` is `0 < 0` (false) so the fail-open guard is skipped, and `closeRatio = closed / sample` divides 0/0 to `NaN`, propagating a `NaN` cadenceMultiplier under `reason: "degrading"`; worth an explicit `sample === 0` guard or requiring `minSample >= 1`.
• The magic-number constants (4, 0.2, 0.6, 0.1) flagged by the external brief are already named via `DEFAULT_SELF_REPUTATION_THRESHOLDS` and documented inline, so this is low-value as raised — no action needed.
• `nonNegativeInt` accepts fractional counts (e.g. `merged: 2.5`) since it only checks finite and >=0, not integer; unlikely to matter for real outcome counts but could tighten with `Number.isInteger`.
• No test exercises the `minSample: 0` / zero-outcome edge case described above — add one alongside the existing validation tests once the guard is in.
• Add `if (sample === 0) return { cadenceMultiplier: 1, closeRatio: null, sample, reason: "insufficient_sample" };` before computing `closeRatio` in packages/gittensory-engine/src/miner/self-reputation-throttle.ts:87 to close the NaN path regardless of configured `minSample`.

Flagged checks (non-blocking)

• Contributor trust — Contributor flagged for review

Signal	Result	Evidence
Code review	✅ No blockers	1 reviewer
Linked issue	✅ Linked	#2346
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: 85 registered-repo PR(s), 52 merged, 7 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	dhgoal; Gittensor profile; 85 PR(s), 7 issue(s).
Gate result	✅ Passing	No configured blocker found.

Linked issue satisfaction

Partially addressed
The PR delivers the pure `selfReputationThrottle` function with degrading/recovering cadence, fail-open on insufficient sample, configurable thresholds with conservative defaults, and thorough unit tests matching the issue's acceptance criteria, but it explicitly defers the Governor chokepoint consultation and the governor ledger recording of throttle decisions (both stated deliverables) to separa

Review context

• Author: dhgoal
• 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: 85 PR(s), 7 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.

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

[gittensory-orb]

Gittensory is closing this pull request on the maintainer's behalf (Linked issue #2346 is assigned to the maintainer (@JSONbored) — that work is reserved for the maintainer, so this PR cannot be auto-accepted.). This is an automated maintenance action — to pursue this change, please open a new pull request with the issues resolved. Closed PRs may be analyzed later to improve review accuracy, but they are not automatically reopened or re-reviewed.