feat(miner): build the autonomous supervising loop

[JSONbored]

Summary

• Builds gittensory-miner loop, the final piece of Wave 3.5's Miner AMS epic (Epic: Miner Wave 3.5 — Wire the autonomous loop end-to-end #5130): a real discover → claim → attempt → observe → re-enter loop composing every existing primitive (runDiscover, runAttempt, the run-loop boundary gate, loop-reentry, loop-closure) into an actual repeat-until-halted CLI command. No daemon/watch pattern existed anywhere in this package before this change.
• Adds pr-disposition-poller.js: polls a PR's real merge/close disposition (distinct from ci-poller.js's check-run polling) and classifies it into loop-reentry's merged/disengaged/other vocabulary — the missing piece pr-outcome.js's store had no real caller for.
• Extends attempt-cli.js to surface runMinerAttempt's real loopResult turn usage (totalTurnsUsed/iterationsUsed) through options.onResult, so the loop can save genuine GovernorCapUsage via governor-state.js's saveCapUsage — previously uncalled anywhere in the codebase — instead of a fabricated number.

Acceptance criteria (#5135)

• A dry-run loop completes multiple full cycles unattended, with no manual step between them (--max-cycles/--cycle-delay-ms for bounded/paced runs).
• The kill switch halts the loop within one iteration boundary when tripped mid-loop (checked at the top of every cycle).
• The loop refuses to start (fails closed) if governor state cannot be loaded — never silently falls back to a fresh/zeroed counter state.

Design notes

• A permanent AI-usage-policy block marks its item done instead of re-queuing it forever; any other non-submitted outcome requeues, and a genuinely stuck item halts the whole run via real non-convergence detection rather than looping forever.
• attemptLoopReentry's own dequeue is the authoritative claim for every cycle after the first (its own doc: "if allowed -- dequeues the next candidate") — the loop does not also call portfolioQueue.dequeueNext() on a successful reentry, which would silently double-claim.
• Documented, deliberate gaps (not silently papered over): convergence and cap-usage history are scoped to this loop process's own lifetime (cap usage itself persists across restarts via governor-state.js; per-issue convergence counters do not — a durable version needs attempt-log.js to grow a repo+issue index, a separate schema change); the loop's kill-switch and boundary checks are global-scope only, matching runAttempt's own existing gap (a per-repo .gittensory-miner.yml pause resolver now exists via feat(miner): resolve the real per-repo MinerGoalSpec from a cloned worktree (#5132) #5255 but isn't wired into either call site yet).

Test plan

• npx vitest run test/unit — 733 files / 14,538 tests pass
• npx tsc --noEmit -p . --incremental false (fresh, no cache) — clean
• npm run test:engine-parity — pass
• npm run --prefix packages/gittensory-miner build (all node --check entries, including the two new files) — pass
• git diff --check — clean

[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	9c4d41f	Commit Preview URL Branch Preview URL	Jul 12 2026, 01:38 PM

[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.37%. Comparing base (6f05c31) to head (9c4d41f).
⚠️ Report is 2 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5303   +/-   ##
=======================================
  Coverage   94.37%   94.37%           
=======================================
  Files         474      474           
  Lines       40128    40128           
  Branches    14631    14631           
=======================================
+ Hits        37869    37871    +2     
+ Misses       1583     1582    -1     
+ Partials      676      675    -1     

Flag	Coverage Δ
shard-1	46.28% <ø> (-0.28%)	⬇️
shard-2	34.74% <ø> (+0.06%)	⬆️
shard-3	32.17% <ø> (+0.07%)	⬆️
shard-4	32.09% <ø> (+0.01%)	⬆️
shard-5	33.38% <ø> (-0.21%)	⬇️
shard-6	45.14% <ø> (+0.30%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.
see 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.

[gittensory-orb]

Warning

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

⏸️ Gittensory review result - manual review recommended

_{Review updated: 2026-07-12 13:45:23 UTC}

12 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 `gittensory-miner loop`, wiring the existing discover/attempt/boundary-gate/reentry primitives into a real repeat-until-halted CLI command, plus a new `pr-disposition-poller.js` and an `onResult` hook on `attempt-cli.js` that threads real `loopResult.totalTurnsUsed`/`iterationsUsed` into genuine `saveCapUsage` calls. The wiring is coherent: `attemptLoopReentry`'s own dequeue is correctly treated as authoritative after the first cycle (no double-claim), the kill switch is checked before any work, governor state load failure fails closed, and the end-to-end regression test actually reopens fresh DB connections post-run to verify real persisted state (pr_outcome events, queue status, cap usage, reentry events) rather than asserting against mocked internals. The most notable gap is that `usage.budgetSpent` is carried through unchanged every cycle (`budgetSpent: usage.budgetSpent`) while only `turnsTaken`/`elapsedMs` accumulate, so any dollar-budget cap dimension in `capLimits` can never trigger from this loop's own spend — worth a direct answer from the author on whether that's an intentional, already-documented gap or a live enforcement hole.

Blockers

• packages/gittensory-miner/lib/loop-cli.js:370 calls `pollPrDispositionFn(claimed.repoFullName, prNumber, options.prDispositionOptions ?? {})`, so the production `loop` command never passes `githubToken` or `apiBaseUrl` into the new PR-disposition poller; change this to merge the top-level loop options into the poller options, e.g. `await pollPrDispositionFn(claimed.repoFullName, prNumber, { githubToken: options.githubToken ?? env.GITHUB_TOKEN, apiBaseUrl: options.apiBaseUrl, ...(options.prDispositionOptions ?? {}) })`, or explain why PR disposition polling must intentionally ignore the same GitHub credentials discovery uses.

Nits — 5 non-blocking

• packages/gittensory-miner/lib/loop-cli.js: `usage.budgetSpent` is never incremented across cycles (only `turnsTaken`/`elapsedMs` are) — confirm whether the budget-cap dimension of `evaluateRunLoopBoundaryGate` is meant to be inert here or whether cost tracking is simply not wired in yet.
• packages/gittensory-miner/lib/loop-cli.js:204 `runLoop` is a ~250-line function with cyclomatic complexity well above the repo's usual threshold — consider extracting the per-cycle body (claim → boundary check → attempt → disposition → reentry) into a helper for readability, even though behavior is correct.
• packages/gittensory-miner/lib/pr-disposition-poller.js: several backoff/attempt-count magic numbers (`60_000`, `5 * 60_000`, clamp bounds `20`/`60`) could be named constants for clarity, matching `ci-poller.js`'s conventions if it does the same.
• packages/gittensory-miner/lib/loop-cli.js: `parseLoopArgs` has fairly deep nested `if` chains for flag parsing — a small option-table dispatch (as some other CLI parsers in this package likely use) would flatten it, though functionally it's fine.
• test/unit/miner-attempt-cli.test.ts: the new `onResult` regression test's `loopResult: {}` mock leaves `totalTurnsUsed`/`iterationsUsed` undefined in the asserted result — harmless since it uses `objectContaining`, but worth tightening to assert the real shape now that `attempt-cli.js` surfaces those fields.

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, 476 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 44 PR(s), 476 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: not available
• Official Gittensor activity: 44 PR(s), 476 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