# Contributor pipeline gardening — reference (metagraphed)

## Scope boundary — registry enrichment is a separate automation (see SKILL.md)

Don't file, triage, or fix anything under `registry/subnets/*.json` from this pipeline — not just the
Enrich-SNxx new-subnet-intake family, but registry data work of any kind (accuracy passes,
probe-config gaps, curation fields, etc). See SKILL.md's "Scope boundary" section for the 2026-07-19
incident that established this.

This is about not _authoring_ registry content, not about ignoring issue-state hygiene for an issue
whose deliverable happens to touch `registry/`. The MCP execute "verify + wire SN\*" family is the
one exception where Pass 1's normal stale-sweep verification still applies — see SKILL.md's dedicated
subsection under Pass 1 and the milestone-table row below.

## Docs architecture migration — RESOLVED 2026-07-16, fully shipped

metagraphed's website docs migrated off hand-built TanStack Router route files (one full React
component per page — the old `docs.*.tsx` pattern) onto a shared MDX pipeline. **#6225** (the port
issue, filed 2026-07-16 after loopover's own spike/rollout — JSONbored/loopover#6037 + #6271) closed
the same day as **superseded**: the pipeline shipped via a native `fumadocs-mdx` + `fumadocs-ui` +
`fumadocs-openapi` integration (not the originally-proposed Scalar `@scalar/api-reference`) — content
now lives in `content/docs/*.mdx` behind a single `docs.$.tsx` catch-all route, and the API-reference
half is generated straight from `openapi.json` via `fumadocs-openapi` (#6210) rather than an embedded
Scalar component.

**All 10 previously-paused "Docs page: X" issues (#3504-#3511, #3514, #3516) plus the earlier
#3512/#3513/#3515 are written and closed (#6232).** This family is fully drained — don't look here
for Pass 2 top-up material, and don't re-open or re-triage any of these issues; they're done.

## Product shape

metagraphed is a Bittensor subnet registry + block-explorer product: `registry/subnets/<slug>.json`
(one file per subnet, community-contributed surfaces), a Worker API (`workers/`, OpenAPI-schema-driven,
`schemas/` is the contract), and `apps/ui` (the explorer frontend). See `.claude/skills/metagraphed/`
for the full contribution model — that skill is authoritative for how a PR gets merged here; this
skill only covers issue-pipeline hygiene, not PR review mechanics.

## Milestone taxonomy (re-check every run — this repo's hygiene and counts drift faster than gittensory's)

**2026-07-31 correction — still zero contributor-available, and both 2026-07-25 "productive veins" are now
fully drained.** Total open issues: 42 at run start, 38 after Pass 1's stale-sweep closed 4 (three
epics whose full native-sub-issue set had shipped without closing the tracker itself — #8606 API access
GA, #8701 upgrade radar, #8350 PWA/T9 — plus one superseded design-spike, #6646, whose own ask was
fully answered by ADR 0022 + epic #8606's implementation). All 38 remaining open issues are
`maintainer-only` and assigned to the maintainer; contributor-available count was 0 before this run and
stayed 0 after — the second consecutive run to observe the floor at literally zero (first was
2026-07-25). Confirmed exhausted this run, so don't re-derive from scratch next time unless a run finds
otherwise:

- **Design-token lint-ratchet**: `src/hooks/**`, `src/lib/**`, `src/components/**` are now ratcheted in
  both `apps/ui` and `packages/ui-kit` (the 2026-07-25 batches #8167-8172 did it). The one remaining
  un-ratcheted directory, `apps/ui/src/routes/**`, was grep-swept this run (approximating the actual
  `no-restricted-syntax` selectors — palette colors, `font-bold`, anchored raw hex, `rounded-sm/lg/3xl`,
  raw `z-*`, `shadow-[`, `bg-card/NN`) and came back near-zero real hits (most naive hex matches were the
  same `#nnnn`-issue-reference false positive the eslint config itself warns about). Not a productive
  vein anymore — don't re-check without a `git diff` signal that new drift landed in `routes/**`.
- **Generated-types epic follow-on**: batches D1-D9 (#8158-8166) all closed 2026-07-25/26. Tri-surface
  parity (REST/GraphQL/MCP) for newly-shipped fields is now codegen-enforced by `npm run build` +
  `validate:contract-drift`, not a manual gap — spot-checked this run against the just-shipped v440
  emission-gate fields (`emission_gate_bar`/`emission_bar_quantile`/`emission_gate_exponent`/
  `emission_gate_exponent_effective`, epic #8739): present and in sync across `public/metagraph/openapi.json`,
  `generated/graphql/types.ts`, and the resolver map, same day the REST route shipped. Don't expect a
  manual parity-gap vein here again unless codegen itself breaks.
- **Also checked and empty**: a repo-wide `TODO`/`FIXME`/`HACK:` grep across `src/`, `workers/`,
  `apps/ui/src/` found exactly one hit (`apps/ui/src/lib/metagraphed/partners.ts:22`, a real partner
  hotkey placeholder — needs the maintainer's own wallet data, not contributor-fileable). Every active
  epic's own "Sub-issues" section names concrete near-term work, but on inspection every one either (a)
  already has its named sub-issues filed and closed (epic bodies don't self-update, so read the epic's
  actual `subIssues` via GraphQL, not just its prose — #8350/T9 looked like a 2-issue gap from its body
  text alone and was actually fully shipped, #8384/#8385/#8527 all closed) or (b) is genuinely blocked on
  a maintainer-only prerequisite (archive node reaching chain tip for #8345/T4's #8368; a design decision
  or backend groundwork not yet merged for the SN74/#8617, TAO/USD/#8600-8603, and v440/#8739 epic
  families' UI-layer sub-issues).
- **Net takeaway for the next run**: don't assume zero-yield is a script bug — verify fresh, but if the
  same drought shows up a third consecutive time, that's a real signal worth raising to the maintainer
  directly (parked design-spikes resolving, or the "what's safe to unleash" bar needing a second look)
  rather than something to keep silently re-deriving.

**2026-07-25 correction — the entire prior snapshot below is obsolete, not just drifted.** Between
roughly 2026-07-20 and 2026-07-25 the maintainer (plus a small number of very active contributors)
drained essentially the entire historical backlog this table used to describe: all four `Wave 1-4`
milestones (49 + 6 + 411 + 39 = 505 issues) closed out completely, the ~120-issue "MCP execute:
verify + wire SN\*" family fully closed (verified anti-pattern-free — see SKILL.md's dedicated
subsection), the entire REST/GraphQL/MCP tri-surface parity effort essentially finished (spot-checked
2026-07-25: 174 MCP tools / 177 REST routes / 178 GraphQL Query fields, all near-complete parity), and
the generated-types epic (#7858, Zod/OpenAPI/Postgres/GraphQL/MCP codegen, batches lettered A-F) closed
the same day this correction was written. **Total open issues dropped to 28, of which zero were
contributor-available** (unassigned, no `maintainer-only`, carrying a `gittensor:*` label) at the start
of the 2026-07-25 run — the first time this pipeline has observed the floor at literally zero. Do not
trust any milestone count below as anything but a historical snapshot; re-derive fresh every run via
`gh api graphql` `milestones(states:[OPEN,CLOSED])` with per-milestone `issues(states:OPEN)`/
`issues(states:CLOSED)` counts, exactly as this correction did.

| Milestone                                                    | Open (as of 2026-07-25)                           | Nature                                                                                                                                                                                                                                                                                                |
| ------------------------------------------------------------ | ------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `Foundations & Infra` (#11)                                  | 6 open / 480 closed                               | General backend/infra work, mixed maintainer/contributor. Also the default home for well-precedented REST/GraphQL/MCP parity issues and (as of 2026-07-25) the design-token lint-ratchet-completion batch (#8167-8172) — no dedicated frontend-cleanup milestone exists yet.                          |
| `Wave 1 — Backend (CSV · Events · Correctness · Tests)` (#7) | 0 open / 49 closed — **milestone itself CLOSED**  | Fully drained. Don't source here.                                                                                                                                                                                                                                                                     |
| `Wave 2 — Backend Data (Validators & Economics)` (#8)        | 0 open / 6 closed — **milestone itself CLOSED**   | Fully drained. Don't source here.                                                                                                                                                                                                                                                                     |
| `Wave 3 — Frontend (post-consolidation)` (#9)                | 0 open / 411 closed — **milestone itself CLOSED** | Fully drained as of 2026-07-25 (was 11 open on 2026-07-15 — do not trust that older snapshot either; re-verify every run, this repo's counts move fast in both directions).                                                                                                                           |
| `Wave 4 — Docs & Dev Surface` (#10)                          | 0 open / 39 closed — **milestone itself CLOSED**  | Fully drained. The fumadocs-mdx port (#6225) landed 2026-07-16 and all "Docs page: X" issues shipped and closed by #6232 — don't look here for top-up material, per SKILL.md.                                                                                                                         |
| `Partner Flywheel Hardening` (#13)                           | 1 open / 18 closed                                | Small, check individually                                                                                                                                                                                                                                                                             |
| `MCP Platform — Unified Subnet Access` (#14)                 | 4 open / 138 closed                               | The "MCP execute: verify + wire SN\*" family (#7017-#7136) fully closed 2026-07-22 and re-verified anti-pattern-free 2026-07-25 (see SKILL.md). The 4 remaining open issues are a _different_ sub-effort (#6893/6895/6896/6897, "publish a metagraphed Agent Skill") — don't generate more of either. |
| `iOS App (TestFlight)` (#15)                                 | 6 open / 0 closed                                 | Brand-new epic (#6910), all 6 sub-issues are design-spikes/account-setup/scaffolding — genuinely too early-stage for any contributor unlock yet (tech stack and v1 scope aren't decided). All correctly `maintainer-only`.                                                                            |
| `PostHog Consolidation` (#17)                                | 4 open / 10 closed                                | Active epic (#7757). Remaining open items (#7765 insights/dashboards buildout, #7767 Umami decommission, #7803 data-warehouse spike) are PostHog-console/business-gated work, not code a contributor PR naturally fits — correctly `maintainer-only` as of 2026-07-25.                                |
| `Frontend - Lovable Design Enhancements` (#16)               | 0 open / 18 closed — **milestone CLOSED**         | Fully drained.                                                                                                                                                                                                                                                                                        |
| Unmilestoned                                                 | re-verify fresh every run                         | The Enrich-SNxx rolling-intake family + the bot-managed Dependency Dashboard are correctly standalone; anything else unmilestoned is a real hygiene gap.                                                                                                                                              |

**Every gardening-generated issue gets a milestone — none ship unmilestoned** (reinforced by the
maintainer, 2026-07-15) — **except the established `types-epic <letter> batch N` precedent** (see
"Reuse-existing-pattern" below), which the maintainer's own issues in this exact family (#8055-8064,
#8065-8076, and the D-batches filed 2026-07-25) consistently ship with `milestone: null`; mirror that
precedent exactly for that one issue family rather than force-fitting a milestone onto it. Default to
the closest-fitting existing one from the table above for everything else. A new milestone is
warranted only when nothing existing fits AND the work is either a genuinely major initiative or a
recurring category that will keep needing a home — see gittensory/loopover's own `reference.md` for the
`Miner Wave 4.5` precedent of the latter case. A one-off oddity alone isn't enough justification; when
genuinely unsure on a high-stakes call like this, propose 1-2 options, but default to deciding and
documenting the reasoning rather than blocking a run on confirmation.

## Where contributor-available issues actually come from, now that Wave 1-4 are gone (added 2026-07-25)

With the entire Wave 1-4 backlog and the tri-surface parity effort drained, the two productive veins
found on 2026-07-25 were:

- **Design-token lint-ratchet completion** (`apps/ui/src/components/metagraphed/**`,
  `packages/ui-kit/src/components/**`): PR #8101 (closing #7851) introduced a one-way
  `RATCHETED_DIRS` eslint mechanism and promoted every _already-clean_ directory to error-tier, but
  explicitly left the two components directories un-ratcheted (81 + 19 files still had
  `no-restricted-syntax` violations) as follow-up work. Filed as #8167-8172 (6 issues, `gittensor:bug`
  - `help wanted` + `frontend`, milestone `Foundations & Infra`) — genuinely contributor-safe (a
    contributor-authored PR already closed the analogous #7912 refactor), mechanical (each violation's
    own eslint message names the exact token/component fix), and independently batchable per file group.
    Note: any apps/ui-touching PR still needs the before/after screenshot table and is still always held
    for manual review per CLAUDE.md's own frontend rule — that doesn't change contributor-eligibility of
    the issue, just how its PR gets reviewed.
- **Generated-types epic follow-on batches** (types-epic D, GraphQL resolver typing): epic #7858
  closed with sub-issues A/C/E fully complete but B and D each landing as a 5-field/route pilot with
  the remaining fields explicitly deferred to a batch decomposition (exactly B's own established
  precedent, which the maintainer worked through directly as batches 1-10 on 2026-07-25 while this
  gardening run was in progress). D's ~150-field batch decomposition was still unfiled as of this run
  — filed as #8158-8166 (9 issues) mirroring B/E's exact batch precedent. **These are `maintainer-only`
  by precedent** (every prior B/E batch issue was `maintainer-only`/assigned-JSONbored even after a
  contributor ended up merging the PR) — they do NOT count toward the contributor-available target,
  but are legitimate Pass 3 epic-health forward-looking work.

Both REST/GraphQL/MCP parity (dozens of PRs merged 2026-07-20 through 2026-07-25) and the Postgres/DB
row-type codegen (types-epic C) are now essentially fully mined — don't expect more low-hanging fruit
there without a fresh code change creating new drift. If a future run also finds the contributor-
available count stuck near zero, the next things worth checking (not yet tried as of this run): a
targeted eslint sweep for the OTHER Bone & Ink sub-rules beyond `no-restricted-syntax`, a fresh
`npm run test:coverage` read for any file that dipped below the repo's ~98%/~90% norm, and whatever new
surface area the PostHog Consolidation / iOS App epics open up once their current design-spike/business
-gated issues resolve into buildable scope.

## Labels — this repo's own convention, don't force gittensory's onto it

- `gittensor:bug` (0.05x), `gittensor:feature` (0.25x), `gittensor:priority` (1.5x) — same point
  values as gittensory, **but `gittensor:priority` is used far more liberally here** (historically
  roughly a third of all open issues, often standalone with no `gittensor:feature`/`gittensor:bug`
  pairing — re-verify the ratio fresh each run, since the 2026-07-25 backlog drain reset the open-issue
  population this stat is drawn from to a tiny N). Follow this repo's existing density, don't
  artificially scarce it down to match gittensory.
- `help wanted` — paired with points labels, same as gittensory.
- `backend` / `frontend` — apply when the work is clearly one or the other; skip when it's genuinely
  both or neither (e.g. a pure docs/data issue).
- `maintainer-only` — historically used on the majority of open issues (~57%, 81/142 as of 2026-07-14).
  As of the 2026-07-25 backlog drain, it's **all 28** of the (much smaller) surviving open-issue
  population — re-derive the ratio fresh each run rather than trusting either number, this repo's
  denominator can now swing an order of magnitude between runs. Only ~14 of the historical 81 also
  carried `roadmap`, so **don't assume the `roadmap`+`maintainer-only` pairing convention from
  gittensory applies here** — in this repo `maintainer-only` alone is a complete, sufficient signal.
- `good first issue` is **not** a real convention here — the label doesn't exist in this repo
  (confirmed 2026-07-14) and the maintainer doesn't want it added. Only `gittensor:*` + `help wanted`
  (+ `backend`/`frontend` where clearly applicable) matter for contributor-available issues.
- Never add anything beyond the above to a gardening-generated issue.

## What's safe to unleash

Same underlying test as gittensory's copy of this skill (clear precedent to follow, no business/product
decision required, doesn't touch security-sensitive surfaces without a maintainer design pass first,
doesn't require access a contributor can't have). metagraphed-specific instances of the boundary:

- **Docs pages for already-shipped API endpoints** (the Wave 4 "Docs page: X" family) — writing
  accurate docs for an existing, stable endpoint is mechanical and low-risk. Good unlock candidates.
- **Native-staking feature work** (real stake movement, commission/take management, re-delegation,
  the pre-launch security review, phishing-resistance/subdomain work) — stays `maintainer-only`.
  This is live financial functionality; don't unlock any of it without an explicit ask.
- **Registry/surface data contributions** are a distinct category from code issues — they're the
  community's main contribution path (one file per subnet) and don't need the same
  maintainer-vs-contributor gating a code change does, since the gate's own AI-reviewer +
  ownership-proof verification is the real safety net there, not issue labeling.

## Reuse-existing-pattern is mandatory, not implied, whenever a real precedent exists

Maintainer's own words, 2026-07-21: "gittensor miners are lazy and don't care, so we need to be
extremely clear about what's wanted/needed." Applies here exactly as it does on gittensory/loopover's
own copy of this skill (see that repo's `reference.md` for the full incident writeup) — a contributor's
AI-harness agent reads only the issue text, not this skill file, not either repo's CLAUDE.md, and not
"the obviously right way to do it."

**What this broke on the sibling repo already:** a batch of issues had their labels flipped to
contributor-eligible, but the body text was left saying `maintainer-only` verbatim in the footer, and
one issue's Deliverables left the actual artifact ambiguous between three different plausible shapes
with no pick. Caught only because the maintainer asked for the whole body to be reread end-to-end
rather than trusting each edit in isolation.

**How to apply here:** whenever an issue's fix has a real existing precedent to follow — an existing
route/endpoint's shape, an existing schema pattern, an existing Worker handler, a comparable already-
merged PR — name the _exact_ file/PR to mirror as a leading, standalone callout (not buried in prose
Context), and state explicitly what does **not** satisfy the issue (a differently-shaped
implementation, an unspecified choice among multiple plausible artifacts, a new parallel mechanism
instead of extending the cited one). Applies to code issues under the template below; for
registry/surface-data issues, the equivalent is naming the exact sibling subnet file whose surface
shape/format should be mirrored, per `.claude/skills/metagraphed/reference.md`'s own conventions.

Before publishing any batch, reread each finished issue body end-to-end — not just the diff of what
changed — to catch exactly this class of self-contradiction.

## Full-scope completeness is mandatory — no partial-credit issues (reinforced 2026-07-25)

Maintainer's own words, 2026-07-25: "contributors will throw their AI tools at this for the least
path of resistance and submit the shittiest / lowest quality stuff possible to get it completed as
fast as possible unless we are extremely explicit on exactly what we expect... I expect the entire
issue done flawlessly start to finish, not broken up into smaller pieces and nothing skipped."

This extends the "Reuse-existing-pattern is mandatory" rule above from _which shape to follow_ to
_how much of it must ship_. Every generated issue must leave zero room for a contributor's AI-harness
agent to rationally conclude that implementing a subset of the Deliverables checklist, or the
laziest-possible interpretation of a Requirement, satisfies the issue.

**How to apply when authoring a new issue:**

- **Requirements must be concrete and testable, never open to interpretation.** Not "add filters to
  X" — name every filter param, its type, its validation behavior, and cite the exact sibling
  route/field whose parameter-handling to mirror (per the precedent-callout rule above).
- **Every item in the Deliverables checklist ships together, in one PR, or the issue is not done.**
  Say this explicitly in the issue body (a fixed closing line, see the template below) — don't rely on
  the checklist format alone to imply it. A PR that completes 2 of 4 checklist items and asks to land
  is a partial delivery, not a done issue.
- **Expected Outcome must be a falsifiable end-state, not a vague direction.** Someone (or an
  automated reviewer) must be able to check yes/no from the PR diff alone — "the field now supports a
  `sort` and `order` param, matching `<sibling route>`'s validation" is falsifiable; "the field is
  improved" is not.
- **Don't under-scope a coherent unit of work just to make the issue look more approachable** — an
  issue whose own Requirements are incomplete, or whose Deliverables can be half-satisfied and still
  plausibly read as "done," invites exactly the shortcut-taking this section exists to prevent. This is
  separate from splitting a genuinely large epic into multiple _sequential, individually-complete_
  issues (e.g. the `types-epic B batch N` family) — each batch issue is itself fully scoped and
  independently completable end to end, and that decomposition is fine. What's not fine is a single
  issue that itself ships incomplete or half-satisfiable.
- Before publishing, reread the finished issue body and ask: "if a contributor did the least possible
  work that could arguably satisfy this text, would that match what the maintainer actually wants
  shipped?" If there's daylight between those two, tighten the text until there isn't.

Applies to every new issue from Pass 2 and Pass 3, and to any existing issue's body that Pass 1
rewrites for clarity — this is a standing authoring bar, not a one-time pass.

## Issue body template

```md
## Context

<what exists today, cite real file/schema/route paths, why this matters>

## Requirements

<concrete, testable requirements>

## Deliverables

- [ ] <concrete artifact 1>
- [ ] <concrete artifact 2>

All of the above ship together in one PR — a PR that completes only some of these items does not
satisfy this issue.

## Expected Outcome

<what's true after this ships that wasn't true before — falsifiable from the PR diff alone>

## Links & Resources

<related issues, files to anchor on>
```

For a registry/surface-data issue (asking a contributor to add a subnet's surfaces), follow the
surface-contribution shape in `.claude/skills/metagraphed/reference.md` instead — do not use the
code-issue template above for that kind of ask.

## Native relationship linking (GraphQL — confirmed available on this repo, 2026-07-14)

**Check every new batch of issues for a real dependency before moving on — required, not optional**
(reinforced by the maintainer, 2026-07-15). Most batches of independent bug-fixes or parity additions
(e.g. a set of REST/GraphQL-mirror issues, each adding one unrelated field) genuinely have no
dependency on each other — the correct outcome of the check is then "no links needed." Reserve
`addBlockedBy` for a real case where working an issue out of order would waste a contributor's time,
and `addSubIssue` for anything genuinely part of a parent epic/tracker.

```graphql
mutation {
  addSubIssue(
    input: { issueId: "<parent node id>", subIssueId: "<child node id>" }
  ) {
    issue {
      number
    }
  }
}
mutation {
  addBlockedBy(
    input: {
      issueId: "<blocked node id>"
      blockingIssueId: "<blocker node id>"
    }
  ) {
    issue {
      number
    }
  }
}
```

**Field name gotcha:** the mutation's second input field is `blockingIssueId`, not `blockedById` —
`blockedById` fails with `argumentNotAccepted`. Confirmed live 2026-07-16 linking #3504-3511/3514/3516
as blocked by #6225.

Get a node ID: `gh api graphql -f query='query { repository(owner:"JSONbored", name:"metagraphed") { issue(number: N) { id } } }'`.

## gh CLI gotchas

- `gh api graphql -f query=@file.txt` does **not** read the file — `-f` treats `@file` as a literal
  string and the request fails with a GraphQL parse error on the `@`. Use **`-F query=@file.txt`**
  (capital F) whenever the query is large enough to be worth writing to a file first.
- `gh issue close` has no `--comment-file` flag — write the comment to a file, then pass
  `-c "$(cat file.md)"` (double-quoted around the whole substitution) so any backticks in the comment
  text are treated as literal characters, not re-parsed by bash as command substitution.
- Never embed a body/comment string containing backticks directly inside a `python3 -c "..."`
  double-quoted bash argument for the same reason — write it to a file first.

---
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<netuid> ..." 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: <endpoint>" 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 `fumadocs-mdx` + `fumadocs-ui` + `fumadocs-openapi` 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.
4. **Every new issue gets a real milestone — no issue ships unmilestoned.** A `gittensor:bug`/
   `gittensor:feature`/`gittensor:priority` label (this repo's own convention — priority isn't scarce
   here the way it is in gittensory, but still means "the maintainer actually wants this soon," don't
   apply it reflexively to everything), and `help wanted` (paired convention here too). Do NOT apply
   `good first issue` — it isn't a real convention in this repo (the label doesn't exist here,
   confirmed 2026-07-14) and the maintainer doesn't want it introduced. Only `gittensor:*` +
   `help wanted` matter for contributor-available issues.
5. Full body template — Context, Requirements, Deliverables, Expected Outcome, Links & Resources (see
   `reference.md`). Registry/surface-data contributions have their own distinct shape (one file per
   subnet, `registry/subnets/<slug>.json`) — don't template a data-contribution issue the same as a
   code/schema issue; see the `metagraphed` skill's own reference.md for the surface model if
   generating that kind of issue.
6. **Check every new batch for a real dependency, then link it with GitHub's native
   `addSubIssue`/`addBlockedBy` mutations** (confirmed available on this repo, same as gittensory) —
   never a markdown checklist. This is a required check, not optional: most batches of independent
   bug-fixes or REST/GraphQL/MCP-parity additions genuinely have no dependency on each other, and the
   correct outcome of the check is then "no links needed" — don't force one just to look thorough.
   Reserve the links for a real case where working out of order would waste a contributor's time.
7. Quality over the number in what gets filed — don't pad with weak/duplicate/vague issues. This is
   not license to stop early: see point 1's "if under floor" note.

**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.