contributor-pipeline-gardening

name

contributor-pipeline-gardening

description

Maintenance of the contributor issue pipeline for JSONbored/metagraphed — closing issues that are already done but not marked so, and keeping the contributor-available backlog at its 50-100+ steady-state floor with well-scoped new issues. Runs every ~8h via the scheduled task (raised from daily on 2026-07-15 so the floor is maintained continuously, not caught up once a day). Invoke for "run the issue gardening", "audit open issues for stale/complete ones", "generate new contributor issues", or any recurring/scheduled run of this process. `reference.md` (next to this file) has the exhaustive label/milestone/template detail — read it before doing real work, not just this file. This is the metagraphed-specific instance; JSONbored/gittensory (loopover) has its own separate copy with different conventions — do not cross-apply either repo's specifics to the other without being asked.

Contributor pipeline gardening — metagraphed

Scope boundary — no registry enrichment (reinforced 2026-07-19)

This pipeline covers code/feature/bug work only. Registry surface/subnet data work of any kind — new-subnet intake (Enrich-SNxx), accuracy passes, probe-config fixes, or any other edit to registry/subnets/<slug>.json content — is out of scope entirely, not just the already-documented Enrich-SNxx exclusion below. A separate, dedicated automation owns registry enrichment end to end. This was reinforced by the maintainer 2026-07-19 after this pipeline generated 34 registry probe-config issues (decomposing #5932) that had to be reverted mid-run. If Pass 1's stale-sweep or Pass 2's top-up work surfaces a real registry data gap, name it in the digest for the dedicated registry automation to pick up — do not file issues or PRs against registry/ from this pipeline.

This boundary is about not authoring registry content or filing new registry-data issues from this pipeline — it is not license to skip normal issue-state hygiene for an existing issue whose deliverable happens to touch registry/subnets/<slug>.json. The "MCP execute: verify + wire SN*" family (see the dedicated subsection under Pass 1 below) is exactly this case: those ~120 issues were filed by a different process (the MCP-execute epic, #7013/#7014), not by this pipeline, and Pass 1's stale-sweep still applies to them like any other issue — read-only verification of whether a closing PR actually delivered, not authorship. Don't treat this family as untouchable just because its deliverable is a registry file edit.

metagraphed is a Bittensor subnet registry / block-explorer product. Unlike gittensory/loopover, a linked issue is optional here — the gate judges a PR on its own merit when nothing is linked, it only auto-closes for a missing link if a linked issue was claimed and doesn't hold up (see .claude/skills/metagraphed/SKILL.md). So the existential pressure to keep a full pipeline is lower than in gittensory, but it's still the main way to (a) direct contributor effort at what actually matters instead of ad-hoc surface PRs, and (b) hand out gittensor:* points fairly. Do both passes below; treat the top-up target as "keep good, well-directed work available," not "prevent PRs from being rejected."

Pass 1 — stale-issue sweep (do this first, every run)

Same method as gittensory's copy of this skill (see that repo's reference.md if you need the full GraphQL walkthrough) — for every open issue, query timelineItems(itemTypes: [CROSS_REFERENCED_EVENT]) for merged PRs that referenced it, then read the actual PR body for any hit where willCloseTarget was false. Close what's genuinely done (with a comment naming the shipping PR and, ideally, a direct grep confirming the described code/route/page exists); leave partial work open, optionally with a scope-clarifying comment.

Verify against synced upstream, not a stale local checkout. Before treating any local grep/read as evidence that an issue's described work does or doesn't exist, confirm the code you're reading matches the default branch's current tip — fetch and fast-forward the checkout (or use a disposable worktree off origin/main if the primary checkout is dirty or has unpushed work on another branch) before doing any verification. A checkout that's merely clean isn't the same as current — a stale-but-clean checkout silently produced false "already done"/"not done" conclusions here and in a sibling repo's gardening run on 2026-07-17/18, causing duplicate issues to be filed for already-shipped work. Confirm sync every run; never assume a previous run's freshness carried over.

metagraphed-specific things to check while doing this:

• 2026-07-25: total open issues dropped to 28 (from ~94-142 historically), and Wave 1-4 all closed as milestones — see reference.md's milestone-taxonomy correction for the full picture. Milestone #9 "Wave 3 — Frontend (post-consolidation)" went from 11 open (2026-07-15) to 0 open / milestone itself CLOSED (2026-07-25) in the space of 10 days — this repo's milestones can drain completely between runs just as easily as they can fill back up. Re-verify every run via gh api graphql milestones(states:[OPEN,CLOSED]), never trust a cached count here.
• Unmilestoned-issue count: 7 of 28 open issues as of 2026-07-25 (#507 Dependency Dashboard, plus 6 standalone maintainer explorations/design-spikes: #6646, #6971, #7002, #7003, #7007, #8133) — the Enrich-SNxx family currently has zero open issues (its own separate automation's queue is temporarily empty, not evidence of a hygiene gap). Re-verify fresh each run; if genuine orphans turn up (a real code/schema/data issue with no milestone, not Enrich-SNxx or the Dependency Dashboard), fold them into the closest fit (Foundations & Infra, Partner Flywheel Hardening) same as before.
• The native-staking feature work (epic #5229, "take/commission management," "move/re-delegate stake flow," "risk disclosure copy") fully closed as of 2026-07-25 — no open low-5200s native-staking issues remain. If new native-staking work reopens (a v2/follow-on epic), treat anything touching real stake movement, phishing surface, or a pre-launch security review as maintainer-only by default; don't second-guess that boundary.

MCP execute "verify + wire SN*" family — special stale-sweep rule (added 2026-07-21)

~120 issues, titled "MCP execute: verify + wire SN<n> (<name>) once Phase 1 ships", one per subnet, tracked under the epic at #7013/#7014 (issue numbers #7017-#7136). They ask a contributor to verify a subnet's registered surfaces work via the call_subnet_surface MCP tool (Phase 1, shipped) and add whatever's missing to registry/subnets/<slug>.json. Treat this family as an exception to the general "don't touch registry-adjacent issues" instinct — see the Scope boundary section above for why Pass 1's normal read-only verification still applies here.

The completeness bar is full subnet API parity, not just what the issue's original checklist named. A 2026-07-21 audit of all 120 subnets found that most subnets expose real API surface the original issue never listed — the registry is meant to catalog everything a subnet's real API exposes, not just what's currently callable by the anonymous Phase-1 tool. This explicitly includes: fixed no-auth endpoints (register with probe.enabled:true), query-param-only endpoints (register with the fixed base URL, probe.enabled:false — already callable today via the tool's query arg), path-param endpoints (register with the literal {param} template, probe.enabled:false — needs Phase 2, not built yet), and auth-gated endpoints (register anyway, with auth_required:true, probe.enabled:false — needs Phase 3, not built yet, but the registry should still document them for future Phase 3 and for maintainers/developers who bring their own credentials). Do not treat "not currently callable by Phase 1" as a reason to leave something unregistered. If an issue body has a ## Additional surface(s) found during review section (added during the 2026-07-21 audit pass), that content is just as much the deliverable as the issue's original ## Surface(s) to verify (N) list — check both when deciding whether the issue is actually satisfied.

Known anti-pattern — confirmed live 2026-07-21, check for it every time: many contributor PRs against this family add only a tests/*.test.mjs file, with zero changes to registry/subnets/*.json, and the merge gate has been auto-merging them and closing the issue anyway — even against issues carrying an explicit, itemized list of missing surfaces. A passing verification test is not the deliverable; the registry file entry is. When Pass 1 finds one of these issues closed via a merged PR, do not accept "a PR merged and referenced this issue" as sufficient on its own — pull the PR's changed-files list (gh pr view <n> --json files) and confirm it actually touches registry/subnets/<slug>.json with a real diff. If the merging PR only added a test file (or any other non-registry file) and the issue's surfaces genuinely aren't in the registry, reopen it:

gh issue reopen <n> --repo JSONbored/metagraphed --comment "Reopening — the PR that just closed this (test-only, no \`registry/subnets/*.json\` changes) did not add any of the surfaces this issue asks for, including the gap findings documented in the **\"Additional surface(s) found during review\"** section above. A verification test alone doesn't satisfy this issue — the registry file itself needs the actual surface entries added. Please open a new PR that adds the missing surfaces (not just a test)."

This is read-only issue-state hygiene (checking a PR's file list, reopening if it didn't deliver) — it is not "registry enrichment" in the sense the Scope boundary above forbids. Don't author registry content yourself or open a PR against registry/ from this pipeline; just don't let a closed-but- undelivered issue sit unflagged.

Pass 2 — backlog top-up

1. Compute this repo's own contributor-available count (unassigned, no maintainer-only, carries a gittensor:* label) before deciding how much to generate here — the target is 50-100+ open contributor-available issues, independently per repo, maintained AT ALL TIMES (reinforced by the maintainer 2026-07-15 — this is a steady-state floor to keep continuously, not a one-time catch-up; the scheduled task's cadence was raised from daily to every 8h the same day specifically so this gets re-checked well within a day). This is NOT a combined/shared pool with gittensory/loopover; each repo is judged on its own backlog and must clear the bar on its own merits, focused on that repo's actual goals (corrected by the maintainer 2026-07-14 — an earlier version of this doc wrongly said "combined total, not per-repo"). Exclude the "Enrich SNxxx" family (see below) from this count — it's a separately-automated queue, not this skill's backlog. Don't just aim for the floor (50) — push toward the top of the range (closer to 100) whenever real, non-padded gaps are still findable (reinforced by the maintainer 2026-07-15: more well-scoped available issues is straightforwardly good for the project, since it's more real work contributors can pick up). If the count is under ~100, keep sourcing issues until it's close to 100 (or a pass genuinely turns up no more real, non-duplicate gaps) — don't stop at a modest first batch just because "quality over volume" (point 7 below) was satisfied, and don't declare victory the moment 50 is cleared. 1a. The "Enrich SN ..." family (tracked via #427, ~20-30 issues at any time) is handled by a separate automation, not this skill. Don't count them toward the 50-100 top-up target (filter out any issue whose title matches "Enrich SN" before comparing against the target), and don't generate more of them yourselves — that automation owns that queue. Pass 1's stale-sweep/hygiene work (closing genuinely-done ones, fixing stale checkboxes) still applies to them like any other issue; the exclusion is specifically about Pass 2's top-up math (confirmed by the maintainer 2026-07-14).
2. This repo's contributor-availability query needs gittensor:priority counted alongside gittensor:feature/gittensor:bug — unlike gittensory, metagraphed frequently uses gittensor:priority as a standalone points label (54 of 59 gittensor:priority issues here carry no gittensor:feature/gittensor:bug pairing, as of 2026-07-14). Don't "fix" this to match gittensory's scarcer convention unless asked — it's this repo's own established norm.
3. The "Docs page: " family is fully resolved as of 2026-07-19 — don't look here anymore. #6225 (the fumadocs-mdx port issue) closed as superseded 2026-07-16: the docs pipeline shipped via a native + + integration (not Scalar as originally proposed), and all 10 paused issues (#3504-#3511, #3514, #3516) plus #3512/#3513/#3515 are written and closed. This bullet previously pointed here as a top-up source; it no longer applies — source Pass 2 issues elsewhere.

Every new issue must clear the full-scope completeness bar in reference.md (reinforced by the maintainer, 2026-07-25): concrete/testable Requirements, a Deliverables checklist that explicitly ships together in one PR (not partial credit for a subset), and a falsifiable Expected Outcome. Contributors' AI-harness agents read only the issue text and default to the least-effort interpretation that could plausibly close the checklist — an issue that leaves any of that ambiguous gets exactly that outcome. This is required on every issue this pass files, not just the ones with an existing precedent to name.

Pass 3 — Strategic epic/milestone health (once-per-day cadence)

Beyond Pass 1/2's issue-level hygiene, this skill also runs a lighter, once-per-day strategic pass over active epics/roadmap issues — a roadmap label, "Epic:" in the title, or any issue with a - [ ]/- [x] child-issue checklist or native GitHub sub-issues. The scheduling automation gates this to at most once per day independent of how often the outer job itself fires (an external cadence tracker in the scheduling layer handles that gate — not part of this file).

When it runs:

1. Verify every active epic's claimed children are actually filed and in the right state — same GraphQL cross-reference method as Pass 1, not text search. Surface now-unblocked follow-on work when a previously-blocking issue closes.
2. Source real forward-looking work, not just verify. Read each active epic/milestone's own stated scope, the current shipped surface (registry/, workers/, apps/ui), and repo docs to find concrete, buildable feature or milestone-scoped work that hasn't been filed yet — grounded in the product as it exists and the milestone's documented direction, not speculative ideas untethered from evidence.
3. Pass 3 shares Pass 2's own 50-100+ (push toward 100+) contributor-available target — one combined per-run volume goal, not a separate small quota (revised 2026-07-17; an earlier version of this pass capped itself at "0-2 issues/day, zero is fine," which under-delivered). If Pass 2's own top-up already reached the target, Pass 3 doesn't need to force more just to hit a number; if the count is still under-target after Pass 2, Pass 3 should actively help close the gap with real feature/milestone issues instead of sitting in verify-only mode. Quality still matters — don't pad with weak/duplicate/vague issues — but that's not license to under-deliver: a pass that can't find enough real work should say so explicitly in the digest (what was tried, why nothing else was fileable), not quietly file 1-2 and call it done.
4. Respect the same "what's safe to unleash" boundary as Pass 2 (native-staking/real-money work stays maintainer-only by default — don't second-guess it).
5. Anything that's genuinely business/monetization/competitive-strategy thinking (pricing, positioning, hosted-product business strategy) stays out of public issues entirely — flag it in the digest for the maintainer's private roadmap instead of filing it here. This repo's issue tracker is contributor-facing; vague vision issues aren't actionable by a contributor anyway.
6. Link every new issue as a native sub-issue of its parent epic via addSubIssue where a real parent exists; give it a real milestone, same discipline as Pass 2.
7. Same full-scope completeness bar as Pass 2 (see above and reference.md) — no exceptions for epic-sourced issues.

Daily digest

Same shape as gittensory's: issues closed + why, milestones/checklists fixed, new issues filed with milestone/label (Pass 2 and Pass 3 combined), before/after contributor-available count, whether Pass 3 ran this cycle, anything left alone on purpose.