Stop telling contributors to apply a label that was deleted

target/v10 no longer exists, but five places still instructed contributors and
agents to put it on legacy maintenance work. Routing for the support/v10 line is
unchanged — it is described by branch rather than by a label that isn't there.

ADR-0004 still names it, correctly: it records what was decided at the time and
already carries the superseding note.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: ChrisonSimtian

AGENTS.md

@@ -49,7 +49,7 @@ To restructure an existing PR's commit history into focused commits, use the `/r
 
 ## Critical rules (read this every session)
 
-1. **At PR-creation time, follow the [PR-creation flow](docs/agents/release-and-versioning.md#pr-creation-flow) in `docs/agents/release-and-versioning.md`.** That flow covers working from a fork (branch off `upstream/main`, push to `origin`, PR against `upstream`), creating the PR as a draft by default, and labelling. Every PR gets a `target/vCurrent` label (or `target/vNext` for work held to next year's major; legacy v10 work uses `target/v10`) and a changelog-category label — [`.github/release.yml`](.github/release.yml) is the source of truth for the label taxonomy and AI applies the matching one whenever it raises a PR. Breaking changes additionally get a `breaking-change` label and a `⚠️ Breaking change` callout in the PR description naming the migration path — the label is what carries them into the generated release notes, and they are held for the **next yearly major** (breaking changes are batched to the year cut, not shipped mid-year). A breaking-change PR targets **`main`** with the breaking surface gated behind `[Experimental("FALLOUT0xx")]` (or, when it can't be gated, on a short-lived topic branch off `main` held for the year cut) — **never** a `release/YYYY` production train. This is non-negotiable — review will block. (Before [ADR-0008](docs/adr/0008-collapse-experimental-into-main.md) breaking work targeted the `experimental` branch; that branch is gone.)
+1. **At PR-creation time, follow the [PR-creation flow](docs/agents/release-and-versioning.md#pr-creation-flow) in `docs/agents/release-and-versioning.md`.** That flow covers working from a fork (branch off `upstream/main`, push to `origin`, PR against `upstream`), creating the PR as a draft by default, and labelling. Every PR gets a `target/vCurrent` label (or `target/vNext` for work held to next year's major) and a changelog-category label — [`.github/release.yml`](.github/release.yml) is the source of truth for the label taxonomy and AI applies the matching one whenever it raises a PR. Breaking changes additionally get a `breaking-change` label and a `⚠️ Breaking change` callout in the PR description naming the migration path — the label is what carries them into the generated release notes, and they are held for the **next yearly major** (breaking changes are batched to the year cut, not shipped mid-year). A breaking-change PR targets **`main`** with the breaking surface gated behind `[Experimental("FALLOUT0xx")]` (or, when it can't be gated, on a short-lived topic branch off `main` held for the year cut) — **never** a `release/YYYY` production train. This is non-negotiable — review will block. (Before [ADR-0008](docs/adr/0008-collapse-experimental-into-main.md) breaking work targeted the `experimental` branch; that branch is gone.)
 2. **Default to backwards compatibility.** Prefer additive over breaking changes. Before changing a public signature, removing an API, renaming a package, or altering an on-disk format, ask: can this be additive instead? `[Obsolete]` markers, transition shims (see `src/Shims/` + `Fallout.SourceGenerators.TransitionShimGenerator`), the `[Experimental("FALLOUT0xx")]` opt-in escape hatch for not-yet-stable surface, feature flags, and overload-based extension are all preferred to a hard break. When a breaking change is genuinely unavoidable, it lands on `main` (gated behind `[Experimental("FALLOUT0xx")]`, or held on a short-lived topic branch for the next yearly major), and follows rule #1's flow — the break must be deliberate, named, and migration-pathed in the PR description. See [#262](https://github.com/Fallout-build/Fallout/issues/262) for the broader discussion. The `[Experimental]` convention (diagnostic-ID scheme + registry) is documented in [docs/agents/conventions.md](docs/agents/conventions.md#experimental-for-opt-in-unstable-apis) and [docs/experimental-apis.md](docs/experimental-apis.md). Deprecations use `[Obsolete]` with a `FALLOUTOBS0xx` `DiagnosticId` so `TreatWarningsAsErrors` consumers can suppress a single deprecation — see [docs/agents/conventions.md](docs/agents/conventions.md#obsolete-for-deprecating-public-apis) and the [docs/obsolete_apis.md](docs/obsolete_apis.md) registry.
 3. **Central package versions only** — add to `Directory.Packages.props`, never `Version=` inline.
 4. **Tests next to code** — every `src/Foo` has a `tests/Foo.Tests` sibling. Mirror namespaces.

CONTRIBUTING.md

@@ -55,7 +55,7 @@ Fallout welcomes contributions. As a community, we want to help each other, prov
 - There's no committed `.editorconfig` or ReSharper/`*.DotSettings` file — they were removed during the takeover. Rely on `dotnet format` defaults and review; don't reintroduce them without a maintainer-level decision.
 - Add tests when meaningful — every `Foo` project has a sibling `Foo.Tests`.
 - Commit the regenerated `.cs` output alongside the `.json` spec — `VerifyGeneratedTools` fails CI if they drift.
-- **Label the PR `target/vCurrent`** for the current release line (use `target/vNext` for work held to next year's major). Legacy `support/v10` maintenance work uses `target/v10`. **Breaking changes are batched to the yearly major cut**: they land on `main` gated behind `[Experimental("FALLOUT0xx")]` (or, when they can't be gated, on a short-lived topic branch off `main`) — never on a `release/YYYY` production train — are held for next year's `YYYY+1.0.0`, and additionally get a `breaking-change` label plus a `⚠️ Breaking change` callout in the PR description naming the migration path. Surface that isn't ready to commit to can ship behind `[Experimental("FALLOUT0xx")]` instead of being held back. See the [PR-creation flow](docs/agents/release-and-versioning.md#pr-creation-flow) for the full procedure.
+- **Label the PR `target/vCurrent`** for the current release line (use `target/vNext` for work held to next year's major). **Breaking changes are batched to the yearly major cut**: they land on `main` gated behind `[Experimental("FALLOUT0xx")]` (or, when they can't be gated, on a short-lived topic branch off `main`) — never on a `release/YYYY` production train — are held for next year's `YYYY+1.0.0`, and additionally get a `breaking-change` label plus a `⚠️ Breaking change` callout in the PR description naming the migration path. Surface that isn't ready to commit to can ship behind `[Experimental("FALLOUT0xx")]` instead of being held back. See the [PR-creation flow](docs/agents/release-and-versioning.md#pr-creation-flow) for the full procedure.
 
 ### Tool wrappers
 
@@ -99,4 +99,4 @@ Merging to `main` publishes a **preview prerelease** (`2026.MINOR.PATCH-preview.
 - Promotion + hotfix flow (forward-only `main → release/YYYY`; the legacy `support/v10` line takes security/critical fixes directly)
 - When to cut a new year
 
-Contributors don't usually need to do any of this — releases are maintainer-driven. But if you're filing a PR labelled `target/v10` (legacy maintenance) or one that carries a breaking change held for next year's major, expect the maintainer to route it accordingly.
+Contributors don't usually need to do any of this — releases are maintainer-driven. But if you're filing a fix for the legacy `support/v10` line, or one that carries a breaking change held for next year's major, expect the maintainer to route it accordingly.

docs/agents/release-and-versioning.md

@@ -75,7 +75,7 @@ A "breaking change" is any of:
 
 ## Milestones and version targeting
 
-Milestones are **theme-based** (e.g. "Plugin Architecture Foundation & Rebrand Completion", "Public Plugin SDK", "Continuous Delivery Vision") and carry across releases; version targeting uses **evergreen `target/vCurrent` / `target/vNext`** labels — `target/vCurrent` is the current release line, `target/vNext` is next year's major. Legacy v10 maintenance work uses `target/v10`. A breaking change is held for the next yearly major — so its PR carries `target/vNext`.
+Milestones are **theme-based** (e.g. "Plugin Architecture Foundation & Rebrand Completion", "Public Plugin SDK", "Continuous Delivery Vision") and carry across releases; version targeting uses **evergreen `target/vCurrent` / `target/vNext`** labels — `target/vCurrent` is the current release line, `target/vNext` is next year's major. A breaking change is held for the next yearly major — so its PR carries `target/vNext`.
 
 ## PR-creation flow
 
@@ -85,7 +85,7 @@ not as a follow-up — every PR gets:
 
 0. **Working from a fork? Branch from `upstream/main`, push to `origin`, PR against `upstream`.** If `git remote -v` shows both an `origin` (a personal fork, e.g. `<you>/Fallout`) and an `upstream` remote pointing at `Fallout-build/Fallout`, treat `upstream` as the core repo: `git fetch upstream main` and branch from `upstream/main` (never `origin/main`, which can be arbitrarily stale relative to the core repo and will produce huge, spurious merge conflicts), push the new branch to `origin`, and open the PR against `upstream` — `gh pr create --repo Fallout-build/Fallout --draft ...`. Do this by default unless the user explicitly asks to branch off the fork's own `main` instead. Doesn't apply to a plain single-remote clone.
 1. **Create the PR as a draft** — `gh pr create --draft` (see [issue-and-pr-style.md](issue-and-pr-style.md#pr-description-shape)) unless the user explicitly asks for a ready-for-review PR. This is easy to miss because it's a small flag on the same `gh pr create` call as the labels below — don't drop it.
-2. **A `target/vCurrent` or `target/vNext` label** matching where it will release. Default to `target/vCurrent` (the current release line). If the PR carries a breaking change, it's held for the next yearly major — use `target/vNext`. Legacy v10 maintenance work uses `target/v10`. Pass via `--label target/vCurrent` to `gh pr create`.
+2. **A `target/vCurrent` or `target/vNext` label** matching where it will release. Default to `target/vCurrent` (the current release line). If the PR carries a breaking change, it's held for the next yearly major — use `target/vNext`. Pass via `--label target/vCurrent` to `gh pr create`.
 3. **A changelog-category label** describing the change, from [`.github/release.yml`](../../.github/release.yml) — that file is the source of truth for the taxonomy and carries a one-line blurb on each label. Apply the one category the PR belongs under (`enhancement`, `bug`, `security`, `documentation`; `breaking-change` when it applies — see below), or `skip-changelog` for housekeeping with no release note. Pass it in the same `gh pr create --label …` call. Don't leave a PR uncategorized — it falls through to "Other Changes". This is the labelling AI applies on the user's behalf whenever it raises a PR.
 
 If the PR includes a **breaking change** (any commit uses `!`, has a `BREAKING CHANGE:` footer, or otherwise meets the breaking-change definition above), additionally: