Skip to content

docs(miner): fix stale header comment in submission-freshness-check#6200

Merged
JSONbored merged 1 commit into
JSONbored:mainfrom
dhgoal:docs/freshness-check-stale-header
Jul 15, 2026
Merged

docs(miner): fix stale header comment in submission-freshness-check#6200
JSONbored merged 1 commit into
JSONbored:mainfrom
dhgoal:docs/freshness-check-stale-header

Conversation

@dhgoal

@dhgoal dhgoal commented Jul 15, 2026

Copy link
Copy Markdown
Contributor

Summary

Closes #6163

  • submission-freshness-check.js's header said the freshness → prepareOpenPrSubmission → Governor composition was something "a future real call site wires them together in that order". That call site already exists, so the comment was misleading a reader into thinking the module isn't wired in yet.
  • attempt-runner.js is that call site: its own module comment (lines 8-13) documents composing runIterateLoop → checkSubmissionFreshness → prepareOpenPrSubmission → the Governor chokepoint, and it calls checkSubmissionFreshness directly before prepareOpenPrSubmission (lines 148-156).
  • Comment-only: 1 file, 1 line, no behavior change.

Scope

  • The PR title follows type(scope): short summary Conventional Commit format, for example fix(api): restore profile access checks.
  • 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 (e.g. Closes #123) — a linked open issue is required for every contributor PR.

Validation

  • git diff --check
  • npm run actionlint
  • npm run typecheck
  • npm run test:coverage locally; codecov/patch requires ≥99% coverage of the lines AND branches you changed (aim for 100% on your diff so CI variance does not fail near the threshold). Global coverage is a non-blocking trend with a loose 90% backstop, not the gate.
  • npm run test:workers
  • npm run build:mcp
  • npm run test:mcp-pack
  • 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 for new branches, fallback paths, and sanitizer boundaries

If any required check was skipped, explain why:

  • Verified the issue's premise directly against main before changing anything, rather than trusting the description: attempt-runner.js:8-13 documents the exact ordering and :148-156 performs it.
  • Ran the directly affected suites with vitest, unmodified and green: miner-submission-freshness-check + miner-attempt-runner (44 tests).
  • This diff changes one comment line and no executable code, so there is nothing for codecov/patch to measure and no behavior to test. UI/MCP/workers surfaces are untouched; leaving them to CI.

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.
  • Auth, cookie, CORS, GitHub App, Cloudflare, or session changes include negative-path tests.
  • API/OpenAPI/MCP behavior is updated and tested where needed.
  • UI changes use live API data or real empty/error/loading states, not production mock/demo fallbacks.
  • Visible UI changes include a UI Evidence section below with JPG/JPEG or PNG screenshots arranged as organized, captioned, clickable thumbnails. SVG screenshots are not used as review evidence. Review-only screenshots or recordings are not committed to the repository.
  • Public docs/changelogs are updated where needed; changelogs are only edited for release-prep PRs.

No code, auth, API, or UI surface is touched — this corrects a single stale comment.

Notes

Closes #6163

The header described the freshness -> prepareOpenPrSubmission -> Governor
composition as something "a future real call site" would wire together.
That call site already exists: attempt-runner.js composes runIterateLoop ->
checkSubmissionFreshness -> prepareOpenPrSubmission ->
evaluateGovernorChokepointGatePersisted in exactly that order (its own
module comment documents the same ordering, and it calls
checkSubmissionFreshness directly before prepareOpenPrSubmission).

Comment-only; no behavior change.

Closes JSONbored#6163
@dhgoal dhgoal requested a review from JSONbored as a code owner July 15, 2026 21:16
@superagent-security superagent-security Bot added the contributor:flagged Contributor flagged for review by trust analysis. label Jul 15, 2026
@superagent-security

Copy link
Copy Markdown
Contributor

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

@superagent-security

Copy link
Copy Markdown
Contributor

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

@loopover-orb loopover-orb Bot added the gittensor:bug Gittensor-scored bug fix — scores a 0.05x multiplier. label Jul 15, 2026
@loopover-orb

loopover-orb Bot commented Jul 15, 2026

Copy link
Copy Markdown

Warning

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

⏸️ LoopOver review result - manual review recommended

Review updated: 2026-07-15 23:13:54 UTC

1 file · 1 AI reviewer · no blockers · readiness 80/100 · CI green · unstable

⏸️ Suggested Action - Manual Review

Review summary
This is a comment-only fix to submission-freshness-check.js:8, updating a stale header note that said a call site wiring together freshness -> prepareOpenPrSubmission -> Governor 'does not yet exist' to instead name attempt-runner.js (#2337) as that real call site. The provided attempt-runner.js excerpt confirms it does exactly what the updated comment claims: it imports checkSubmissionFreshness and prepareOpenPrSubmission and calls them in that sequence before the Governor chokepoint. No behavior changes, and no issue is linked in the description despite the checklist claiming one is required.

Nits — 4 non-blocking
  • No `Closes #NNN` issue link appears in the description despite the PR's own checklist stating a linked open issue is required for every contributor PR.
  • Most validation checkboxes (typecheck, coverage, lint, etc.) are unchecked with no explanation given, though for a comment-only change this is low-risk.
  • Add the issue link (or confirm none is required for doc/comment-only fixes per maintainer policy) since the PR's own scope checklist claims it's linked.
  • Code changes lack test evidence — Add focused regression tests or explain why existing coverage is sufficient.
Flagged checks (non-blocking)
  • Contributor trust — Contributor flagged for review
Signal Result Evidence
Code review ✅ No blockers 1 reviewer
Linked issue ✅ Linked #6163
Related work ⚠️ 2 scoped overlaps Top overlaps are listed below; lower-confidence bulk is hidden.
Change scope ❌ 8/20 High 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: 110 registered-repo PR(s), 57 merged, 34 issue(s).
Contributor context ✅ Confirmed Gittensor contributor dhgoal; Gittensor profile; 110 PR(s), 34 issue(s).
Gate result ✅ Passing No configured blocker found.
Improvement ℹ️ None detected risk: low · value: none
Review context
Contributor next steps
  • Start here: Review top overlaps.
  • Then work through the remaining 2 steps in the Signals table above.
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.
🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

  • @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
  • @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
  • A plain-language @loopover 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/loopover-commands

🧪 Experimental — new and may change.

🟩 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

@loopover-orb loopover-orb Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LoopOver approves — the gate is satisfied and CI is green.

@JSONbored JSONbored merged commit 1c034a5 into JSONbored:main Jul 15, 2026
8 of 9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

contributor:flagged Contributor flagged for review by trust analysis. gittensor:bug Gittensor-scored bug fix — scores a 0.05x multiplier.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

docs(miner): fix stale header comment in submission-freshness-check.js — the "future" wiring it describes already exists

2 participants