docs(gardening): require a Definition-of-Done callout on every generated issue

.claude/skills/contributor-pipeline-gardening/SKILL.md

@@ -67,7 +67,7 @@ work. Confirm sync every run; never assume a previous run's freshness carried ov
    - Genuine gaps found by reading the current codebase against a shipped feature's own stated acceptance criteria (the same technique Pass 1 uses to verify closure — used here in reverse, to find what's NOT yet done).
    - AMS selfhost hardening is a named standing priority — see `reference.md`. The unified AMS+ORB selfhost harness is now scoped and issue-backed (#5996, epic #6012) as of 2026-07-15 — check its sub-issues' completion state before assuming this still needs fresh scoping.
 3. **Every new issue gets a real milestone — no issue ships unmilestoned.** Default to the correct existing milestone (see `reference.md`'s milestone taxonomy). Creating a new one requires a genuinely-unfitting body of work AND is a much higher bar than it sounds — see `reference.md`'s milestone-discipline note; when in doubt, fold into the closest existing bucket and say so. A new milestone is justified when nothing existing fits AND the work is either a real major initiative or a recurring category that will keep needing a home (e.g. `Miner Wave 4.5 — AMS Hardening Round 2`, created 2026-07-15 for the recurring post-Wave-4 gap-audit rounds this skill files each run) — a one-off oddity alone isn't enough. Also apply a `gittensor:bug` (0.05x), `gittensor:feature` (0.25x), or `gittensor:priority` (1.5x, reserved for mission-critical/time-sensitive work only — this repo uses it sparingly, unlike metagraphed's looser convention, see `reference.md`) label, plus `help wanted` (the maintainer confirmed this stays as a visibility signal alongside the points label, not a replacement for one).
-4. Every new issue body follows the template in `reference.md` — Context, Requirements, Deliverables, Test Coverage Requirements (this repo's Codecov patch gate is 99%+, hard — every new issue implicitly inherits this unless it's `apps/**`-only UI work), Expected Outcome. No "left to interpretation" scope — the maintainer's own stated preference is that thin/ambiguous issue bodies are worse than fewer, complete ones. **The review gate only enforces what the issue text explicitly says** — see `reference.md`'s dedicated section on this; any deliverable with a file-type/path/format constraint (docs as website pages vs. markdown, native relationships vs. checklists, etc.) needs that constraint stated as an explicit, standalone rule, not left implied by Context.
+4. Every new issue body follows the template in `reference.md` — a leading `> ⚠️ Definition of Done` callout, then Context, Requirements, Deliverables, Test Coverage Requirements (this repo's Codecov patch gate is 99%+, hard — every new issue implicitly inherits this unless it's `apps/**`-only UI work), Expected Outcome. No "left to interpretation" scope — the maintainer's own stated preference is that thin/ambiguous issue bodies are worse than fewer, complete ones. **The review gate only enforces what the issue text explicitly says** — see `reference.md`'s dedicated section on this; any deliverable with a file-type/path/format constraint (docs as website pages vs. markdown, native relationships vs. checklists, etc.) needs that constraint stated as an explicit, standalone rule, not left implied by Context. **Assume contributors run their own AI agents against the issue looking for the fastest way to close it** — see `reference.md`'s "Completion standard: no partial credit, no shortcuts" section: every Deliverable must be mechanically verifiable, scope-splitting/deferral must be explicitly forbidden unless the issue is deliberately narrow, and no requirement gets soft/optional phrasing.
 5. **Check every new batch for real relationships, then link them with GitHub's native features, not prose or a checklist:** `addSubIssue` to attach a new issue under its parent epic, `addBlockedBy` when an issue genuinely cannot start before another lands. The check itself is the discipline — most independent bug-fix/feature-parity issues (e.g. a batch of REST/GraphQL-mirror additions) genuinely have no dependency on each other, and forcing a link where none exists is worse than no link. Only connect issues where a contributor would actually be blocked or misled by working them out of order.
 6. Quality over the number in what gets filed — don't pad with weak, duplicate, or vaguely-scoped issues just to hit a count. This is NOT license to stop early: if the repo is meaningfully under the 50-100 floor, keep sourcing real, well-scoped issues (see the "if under floor" note above) until it clears or a pass genuinely turns up nothing left to scope — only then note a shortfall in the digest.
 

.claude/skills/contributor-pipeline-gardening/reference.md

@@ -232,6 +232,51 @@ Every contributor-facing issue's _entire_ body — not just its labels — has t
 consistent and unambiguous, checked by rereading the finished body end-to-end before publishing, not
 assumed correct because the individual edits each seemed right in isolation.
 
+## Completion standard: no partial credit, no shortcuts — write for the laziest passing path
+
+**The maintainer's own words (2026-07-24):** "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."
+
+Assume every contributor-facing issue is picked up by an AI coding agent optimizing to close the loop
+fast, not a careful human reading for nuance. That agent will take whichever interpretation lets it
+stop soonest: implementing one Deliverable and calling the rest "follow-up work," splitting an issue
+across two PRs, stubbing a test instead of writing the real one, or doing the mechanical 80% and
+skipping the hard 20% the issue didn't explicitly forbid skipping. This is the same failure mode "The
+gate only enforces what the issue explicitly says" (above) already documents for file-type/pattern
+ambiguity — this section extends it to **scope completeness**, not just shape.
+
+**Every gardening-generated contributor issue must therefore:**
+
+- Open with a leading `> ⚠️ Definition of Done` callout (see the updated template below) that states,
+  in words this explicit: _"This issue must be completed in full, in a single PR. Do not split this
+  work across multiple PRs. Do not defer any Deliverable below to a follow-up issue. A PR that
+  satisfies only some of the Deliverables, stubs a required test, or leaves a checkbox
+  partially-done does NOT resolve this issue and will be closed."_
+- Make every Deliverable checkbox **mechanically verifiable**, not a vague artifact description a
+  shortcut could plausibly satisfy. Prefer "function `X` in `path/to/file.ts` returns `null` (not
+  `undefined`) when `<condition>`, verified by a new test at `path/to/file.test.ts` asserting exactly
+  that" over "fix the null-handling bug." If a requirement can be satisfied 80% of the way and still
+  look done to a fast skim, rewrite it until it can't.
+- Never use soft/optional language for anything actually required — no "as time permits," "where
+  feasible," "ideally," "at least one of," or "consider also." Every Requirements/Deliverables bullet is
+  mandatory as written, or it doesn't belong in the issue at all (move it to Context as background, or
+  drop it).
+- State explicitly, per issue, what an incomplete/shortcut submission looks like and that it does not
+  count — mirror the existing anti-pattern-naming convention used for file-type mistakes (see "The
+  gate only enforces what the issue explicitly says" above) but aimed at partial-completion, e.g. "a
+  PR that only adds the test coverage from Deliverable 1 without also fixing the underlying bug in
+  Deliverable 2 does not resolve this issue."
+- When an issue has multiple Deliverables, say explicitly whether they're all required in one PR
+  (the default — always required unless you have an explicit, stated reason to scope narrower) or
+  whether the issue is intentionally narrow with a named follow-up issue for the rest. Never leave this
+  ambiguous by omission.
+
+This is a completion-standard check, not a new template section to skip past — reread every generated
+issue body asking "could an AI agent do 60% of this, technically satisfy the literal words, and get a
+PR through the gate?" If yes, tighten it before filing.
+
 ## Labels
 
 - `gittensor:bug` — 0.05x multiplier. Bug fixes.
@@ -252,19 +297,30 @@ assumed correct because the individual edits each seemed right in isolation.
 ## Issue body template (Wave-4-batch house style — use for new feature/bug work)
 
 ```md
+> ⚠️ Definition of Done: this issue must be completed in full, in a single PR. Do not split this
+> work across multiple PRs, and do not defer any Deliverable below to a follow-up issue. A PR that
+> satisfies only some of the Deliverables, stubs a required test, or leaves a checkbox
+> partially-done does NOT resolve this issue and will be closed.
+
 ## Context
 
 <what exists today, cite real file paths / function names, why this matters>
 
 ## Requirements
 
-<concrete, testable requirements — no "TBD" or "explore options" for anything actually decidable now>
+<concrete, testable requirements — no "TBD" or "explore options" for anything actually decidable now.
+No soft/optional language ("as time permits," "where feasible," "ideally") for anything actually
+required — if it's not mandatory as written, it doesn't belong here.>
 
 ## Deliverables
 
-- [ ] <concrete artifact 1>
+- [ ] <concrete artifact 1 — phrased so it's mechanically verifiable, not satisfiable by a shortcut>
 - [ ] <concrete artifact 2>
 
+<if there's more than one Deliverable, state explicitly here whether a PR must satisfy ALL of them
+(the default) or whether the issue is intentionally narrower with a named follow-up issue for the
+rest — never leave this ambiguous by omission>
+
 ## Test Coverage Requirements
 
 <explicit 99%+ Codecov patch target / 100% target including invariants + a regression test for any
@@ -280,6 +336,9 @@ reader isn't confused about why Codecov doesn't gate it>
 <related issues, the files to anchor on>
 ```
 
+See "Completion standard: no partial credit, no shortcuts" above for the full rationale and how to
+phrase Deliverables so they can't be technically-satisfied by a fast, incomplete pass.
+
 For pure architecture/design/spec issues (the kind that stay `maintainer-only`), use the lighter
 Problem/Area/Proposal/Deliverables/Resources/Boundaries shape instead — see any `AMS Cloud Readiness`
 issue (e.g. #5215-5230) for the exact pattern. Gardening-generated contributor issues should almost