docs(contributing): fix stale coverage figure and false no-issue exemption

.claude/skills/contributing-to-gittensory/SKILL.md

@@ -117,10 +117,11 @@ pasted JSON block will not work in Codex). You'll use these tools in Phases 1 an
   and (on scored repos) carries a point label**: linking an owner-assigned / maintainer-only /
   ineligible issue trips a **deterministic linked-issue hard rule that auto-closes your PR**. Verify
   with `gittensory_check_before_start` + `gittensory_validate_linked_issue`.
-- **Open an issue first** for anything risky: public behavior changes, auth/session/CORS changes, DB
-  schema/migrations, large dependency bumps, deploy/secret changes, or frontend architecture. For a
-  small, self-evident fix, a direct PR with a clear rationale is fine (this repo's
-  `linkedIssuePolicy` is `preferred`, not required).
+- **A linked, currently-open, unassigned, eligible issue is always required before opening a PR** —
+  there is no "small enough to skip it" exemption, no matter how self-evident the fix looks. This
+  holds regardless of what the committed root `.gittensory.yml`'s `linkedIssuePolicy` says: that
+  file is a non-representative **example** checked into the repo, not the live enforced rule. If no
+  suitable open issue exists, open one yourself first, then link it from the PR.
 - **Run the pre-start checks** via MCP: `gittensory_check_before_start` (is it claimed / a duplicate
   cluster / already solved?) and, if linking an issue, `gittensory_validate_linked_issue`.
 - **Stay in scope.** The gate's `wantedPaths` are `src/`, `packages/`, `test/`, `migrations/`,
@@ -244,8 +245,8 @@ Run the MCP predictor with your actual PR shape:
 - `gittensory_check_slop_risk` — keep slop **low**: fill the PR description, include tests, keep the
   diff focused (no lockfile/docs/generated noise dominating), real source ratio.
 - `gittensory_lint_pr_text` — your commit + PR body must read as **strong**: Conventional Commit
-  subject, traceability (linked issue or explicit no-issue rationale), and a body that says what
-  changed, why, and how it was validated.
+  subject, traceability (a linked, currently-open, eligible issue — no no-issue rationale accepted),
+  and a body that says what changed, why, and how it was validated.
 - `gittensory_predict_gate` — simulate the repo's public `.gittensory.yml` gate. Resolve any
   predicted blocker (the duplicate-PR blocker is the one that hard-fails here) before opening.
 
@@ -276,8 +277,8 @@ command list — only check what you actually ran), and `## Safety` (especially
 **negative-path tests** box and the no-secrets box). For any visible UI/frontend/docs change, fill the
 **`## UI Evidence`** table with captioned, clickable **JPG/PNG** thumbnails (`<a href><img></a>`) —
 SVG is not accepted, and review-only screenshots are never committed to the repo. A filled Summary +
-the Validation evidence + a linked issue (or an explicit no-issue rationale in the Summary) is exactly
-what makes `lint_pr_text` read *strong*.
+the Validation evidence + a linked, currently-open issue is exactly what makes `lint_pr_text` read
+*strong* — there is no no-issue-rationale substitute.
 
 ---
 

.claude/skills/contributing-to-gittensory/reference.md

@@ -83,7 +83,7 @@ automation bot), the disposition is one-shot:
 | CI `failed` (any check) | **CLOSE** (cites the failing check) |
 | gate `failure` | **CLOSE** |
 | base `dirty` (merge conflict) | **CLOSE** |
-| linked-issue **hard-rule** violation (issue owner-assigned / maintainer-only / missing point label) | **CLOSE** (deterministic — fires even on a guarded path; optional flag-then-close two-pass) |
+| linked-issue **hard-rule** violation (issue is closed / not open, owner-assigned, maintainer-only, or missing point label) | **CLOSE** (deterministic — fires even on a guarded path; optional flag-then-close two-pass) |
 | CI `pending` | **no action** — waits for the check-completion webhook |
 | CI `unverified` (fork Actions awaiting approval, unreadable checks) | **HELD** for review (never closed — fork false-close guard) |
 | changed path hits a **hard guardrail** (CI configs, the review engine, visual capture) | **HELD** for the owner — every would-merge/approve/close becomes a manual hold |
@@ -248,8 +248,9 @@ misc/…`); **no AI/Claude/agent mention**. Changelogs are generated by `git-cli
 edit `CHANGELOG.md` in a normal PR.**
 
 **PR body verdict** = traceability (30) + commit message (35) + body (35); aim **strong**:
-- **Traceability** ok: a linked issue, or an explicit no-issue rationale (`no issue because …`,
-  `docs only`, `maintenance`, `typo`, `chore`).
+- **Traceability** ok: a linked, currently-open, unassigned, eligible issue. There is no no-issue
+  rationale that satisfies this — a closed, missing, or ineligible issue link fails traceability
+  regardless of how the PR body explains the omission.
 - **Body** ok: real prose (≥40 chars, specific) **and/or** a validation note (mentions
   `test/tested/vitest/npm test/validated/verified/smoke`). Don't leave an unfilled template.
 - All evidence is run through the public-comment sanitizer — forbidden terms (`wallet, hotkey,

.github/pull_request_template.md

@@ -7,7 +7,7 @@
 - [ ] 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 an issue, or this is small enough that the summary explains why an issue is not needed.
+- [ ] I linked a currently open issue this PR resolves (e.g. `Closes #123`) — a linked open issue is required for every contributor PR.
 
 ## Validation
 

AGENTS.md

@@ -31,7 +31,8 @@ process evolves — edits to those files improve both Claude Code and Codex.
    check table for the complete list — `test:ci` runs more drift checks than these three).
 5. **House rules:** Conventional Commits, **no AI/Claude/agent attribution** in commits or PR text;
    no secrets / wallets / hotkeys / trust scores / reward values anywhere; stay inside `wantedPaths`
-   and out of `site/`, `CNAME`, `**/lovable/**`; never edit `CHANGELOG.md` in a normal PR.
+   and out of `site/`, `CNAME`, `**/lovable/**`; never edit `CHANGELOG.md` in a normal PR. Contributors
+   are also capped at **2 open PRs at a time** — close or wait for one to resolve before opening a third.
 
 The full procedure, the gate disposition matrix, test patterns, the MCP pre-submit predictors
 (`@jsonbored/gittensory-mcp`), and the PR template are all in the skill files above — use them.

CONTRIBUTING.md

@@ -39,19 +39,23 @@ observations, not commitments or a service-level guarantee — reviews happen wh
 **One-shot, merge-ready as-is.** We do not request changes or iterate on contributor PRs — a PR is
 merged exactly as it stands or it is closed; there is no "changes requested" back-and-forth. Before CI
 we rebase your branch onto `main` with a **merge commit**, then review **after** CI completes — so a
-rebase conflict, or any red CI (including **~97% patch coverage, branch-counted, enforced by Codecov**),
+rebase conflict, or any red CI (including **99% patch coverage, branch-counted, enforced by Codecov**),
 closes the PR. Recover by opening a **fresh, corrected PR**. PRs touching guarded paths (CI config, the
 review engine, migrations, and similar — the set varies) are held for manual review rather than
 auto-acted.
 
 **If we close your PR by mistake, that's on us.** We may reopen or re-review at our discretion as time
 permits — there is no fixed window, and opening a fresh PR is usually fastest.
 
-**Don't ask for or chase reviews.** The queue is automated and best-effort, and the gate posts its own
-status and reasoning on your PR — read that first. Do **not** DM, @-mention, or comment asking for a
-review or status: it will not speed anything up and **will deprioritize your PR — expect at least 5 days
-added to its place in the manual queue.** Persistent pestering (here, Discord, or elsewhere) is a
-conduct violation and may get the PR closed and the account blocked.
+**Don't ask for or chase reviews.** The queue is automated and best-effort, and every auto-merge or
+auto-close comes with a detailed bot comment on your PR explaining exactly what passed or what was
+wrong — read that first. Do **not** DM, @-mention, or comment asking for a review or status: it will
+not speed anything up and **will deprioritize your PR — expect at least 5 days added to its place in
+the manual queue.** Persistent pestering (here, Discord, or elsewhere) is a conduct violation and may
+get the PR closed and the account blocked.
+
+**Contributors are limited to 2 open PRs at a time.** Close or wait for one to resolve before opening
+a third.
 
 **Scoring and rewards are not ours to grant.** Contribution scoring and any Gittensor rewards are set by
 the subnet's on-chain hyperparameters and validators, not by this repo. Merging a PR is not a promise of
@@ -98,13 +102,14 @@ Do not open PRs for:
   farm Gittensor rewards is a hard violation and results in a **permanent block from contributing
   across all of our repositories**. See [`CODE_OF_CONDUCT.md`](CODE_OF_CONDUCT.md).
 
-Filing your own issue and then opening a PR that resolves it is welcome, and a PR with no linked
-issue is fine — neither is farming. What is against policy is **using more than one account you
-control (alt / sock-puppet accounts) — e.g. one account opening issues for another to "resolve" —
-to inflate contribution credit**, along with manufacturing low-value/slop issues and bulk
-point-chasing PRs. Farmed work earns no linked-issue bonus, and repeat or any confirmed
-multi-account farming is closed on sight and blocked. Enforcement is proportional; the full ladder
-is in [`CODE_OF_CONDUCT.md`](CODE_OF_CONDUCT.md).
+Filing your own issue and then opening a PR that resolves it is welcome — that is not farming. A
+linked, currently open issue is required on every PR regardless; there is no exemption for opening
+one yourself first. What is against policy is **using more than one account you control (alt /
+sock-puppet accounts) — e.g. one account opening issues for another to "resolve" — to inflate
+contribution credit**, along with manufacturing low-value/slop issues and bulk point-chasing PRs.
+Farmed work earns no linked-issue bonus, and repeat or any confirmed multi-account farming is
+closed on sight and blocked. Enforcement is proportional; the full ladder is in
+[`CODE_OF_CONDUCT.md`](CODE_OF_CONDUCT.md).
 
 ## Before Opening A PR
 
@@ -122,7 +127,8 @@ Every PR should include:
 
 - A Conventional Commit-style title in the form `type(scope): short summary`.
 - A clear summary of what changed and why.
-- A linked issue or a short explanation for why no issue is needed.
+- A link to a currently open issue this PR resolves (e.g. `Closes #123`) — there is no exemption
+  for explaining why an issue isn't needed.
 - The exact validation commands run from the repo root.
 - JPG/JPEG or PNG screenshot evidence for visible UI, frontend, docs, or extension changes,
   attached in the PR description as organized, captioned, clickable thumbnails. SVG screenshots
@@ -157,7 +163,7 @@ npm audit --audit-level=moderate
 ```
 
 `npm run test:ci` runs the normal combined gate. The coverage requirement is **patch coverage**:
-every line your PR adds or changes must be **97%+ covered** (statements, branches, functions, lines).
+every line your PR adds or changes must be **99%+ covered** (statements, branches, functions, lines).
 This is enforced by Codecov's `codecov/patch` status check, which looks only at your diff — so it
 depends solely on your own changes and is unaffected by what else merges. Run `npm run test:coverage`
 locally when you change behavior and make sure your new branches, fallback paths, and sanitizer rules