feat(miner): read loop-cli convergence history from the persisted portfolio queue

[lourincedaging0-commits]

Closes #5677.

Problem

loop-cli.js kept its own in-memory convergenceHistory Map for the run-loop-boundary gate — redundant with, and less durable than, the SQLite-persisted attempt-history portfolio-queue.js's getAttemptHistory already provides (#5654). A loop-daemon restart (crash/deploy/systemd bounce) silently reset every in-flight item's convergence/consecutive-failure counters, so a genuinely stuck item read "fresh" and got re-attempted from zero — weakening the non-convergence detector exactly when it matters.

Change

• The run-loop-boundary gate now reads convergence from portfolioQueue.getAttemptHistory(...) — the same real source attempt-cli.js's buildAttemptGovernorContext already consumes (Track real per-issue attempt-history on the portfolio queue, feed the Governor's convergenceInput #5654), so the loop daemon and a one-shot attempt share one source of truth.
• The dequeueNext claim + markDone/markFailed calls already maintain those persisted counters, so the in-memory Map, its per-cycle increments, and the now-unused convergenceKey/zeroConvergence helpers are removed, along with the stale DOCUMENTED GAP header comment.
• Out of scope (unchanged): the boundary gate's own convergenceThresholds — only the data source changes.

Validation

• New regression test in test/unit/miner-loop-cli.test.ts: an item taken to the re-enqueue threshold, then a fresh loop process (new handles to the same on-disk files, no in-memory Map) halts before its first attempt — proving the convergence streak survives a restart. Pre-change, a reset in-memory Map read zero and re-attempted the stuck item.
• The existing in-run non-convergence test is preserved: re-enqueues still progress 0→1→2→3 and the 4th cycle halts (only the counter's data source moved, at the same read-point).
• node --check clean; getAttemptHistory counter semantics independently exercised via node:test.

[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 95.04%. Comparing base (b579eb6) to head (4193947).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5679      +/-   ##
==========================================
- Coverage   95.04%   95.04%   -0.01%     
==========================================
  Files         577      577              
  Lines       45987    45973      -14     
  Branches    14708    14708              
==========================================
- Hits        43707    43693      -14     
  Misses       1527     1527              
  Partials      753      753              

Flag	Coverage Δ
shard-1	43.57% <0.00%> (-0.41%)	⬇️
shard-2	35.77% <0.00%> (+0.08%)	⬆️
shard-3	32.23% <0.00%> (-0.16%)	⬇️
shard-4	30.99% <0.00%> (-1.58%)	⬇️
shard-5	32.68% <0.00%> (+0.90%)	⬆️
shard-6	44.80% <100.00%> (+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/loop-cli.js	96.61% <100.00%> (-0.22%)	⬇️

🚀 New features to boost your workflow:

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

[loopover-orb]

Tip

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

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-14 02:19:24 UTC}

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

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This diff replaces loop-cli.js's in-memory convergenceHistory Map with a read from portfolioQueue.getAttemptHistory, which is already persisted by the dequeueNext/markDone/markFailed calls the loop makes on every cycle — so the convergence counters now survive a restart instead of resetting. The `submitted || permanentBlock` merge into a single markDone branch is a correct simplification since both previously called markDone identically. The included regression test plausibly exercises the real restart scenario (fresh loop process, on-disk-only state) rather than fabricating an unreachable condition.

Nits — 4 non-blocking

• loop-cli.js is now ~424 lines per the size-smell flag, slightly over the file's own 400-line convention threshold, though this diff is a net negative on line count so it's a pre-existing/marginal concern rather than one this PR introduces.
• The new module-header comment block (loop-cli.js:16-24) is fairly long for a rationale that's already explained inline at the getAttemptHistory call site (loop-cli.js:342-345) — consider trimming one of the two to avoid duplicated exposition.
• Confirm getAttemptHistory's returned shape (attempts/consecutiveFailures/reenqueues/reachedDone) exactly matches evaluateRunLoopBoundaryGate's expected `convergence` input now that it's sourced from SQLite instead of the old zeroConvergence() literal — worth a one-line type/shape assertion in the test if not already covered.
• The old code incremented `convergenceInput.attempts` locally before calling the boundary gate; verify dequeueNext's persisted `attempts` counter reflects the claim that just happened by the time getAttemptHistory is read on the same cycle, so the gate sees the up-to-date count rather than a one-cycle-stale value.

Signal	Result	Evidence
Code review	✅ No blockers	1 reviewer
Linked issue	✅ Linked	#5677
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: 0 registered-repo PR(s), 0 merged, 0 issue(s).
Contributor context	❌ No public Gittensor match	lourincedaging0-commits; not a blocker.
Gate result	✅ Passing	No configured blocker found.
Improvement	✅ Minor	risk: clean · value: minor — Code changes are accompanied by test evidence.

Review context

• Author: lourincedaging0-commits
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: HTML
• Contributor context: Public profile only; not a blocker.
• 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