Propose CH-015: capture build/distribution/guide/downloader idea as a plan

.clue/id-ledger.yaml

@@ -140,6 +140,20 @@ events:
     - {id: OQ-005, kind: numeric, state: reserved, prefix: OQ, component: "5"}
     - {id: TASKS-007, kind: numeric, state: live, prefix: TASKS, component: "7"}
     - {id: OQ-005, kind: numeric, state: live, prefix: OQ, component: "5"}
+    - {id: CH-015, kind: numeric, state: reserved, prefix: CH, component: "15"}
+    - {id: G-003, kind: numeric, state: reserved, prefix: G, component: "3"}
+    - {id: P-002, kind: numeric, state: reserved, prefix: P, component: "2"}
+    - {id: M-001, kind: numeric, state: reserved, prefix: M, component: "1"}
+    - {id: M-002, kind: numeric, state: reserved, prefix: M, component: "2"}
+    - {id: M-003, kind: numeric, state: reserved, prefix: M, component: "3"}
+    - {id: M-004, kind: numeric, state: reserved, prefix: M, component: "4"}
+    - {id: G-003, kind: numeric, state: live, prefix: G, component: "3"}
+    - {id: P-002, kind: numeric, state: live, prefix: P, component: "2"}
+    - {id: CH-015, kind: numeric, state: live, prefix: CH, component: "15"}
+    - {id: TASKS-008, kind: numeric, state: reserved, prefix: TASKS, component: "8"}
+    - {id: OQ-006, kind: numeric, state: reserved, prefix: OQ, component: "6"}
+    - {id: TASKS-008, kind: numeric, state: live, prefix: TASKS, component: "8"}
+    - {id: OQ-006, kind: numeric, state: live, prefix: OQ, component: "6"}
 high-water:
     - {id: ADR-002, kind: numeric, state: reserved, prefix: ADR, component: "2"}
     - {id: AN-014, kind: numeric, state: reserved, prefix: AN, component: "14"}

docs/goals/G-003-legacy-robots-are-easy-to-obtain-wrap-and-run.md

@@ -0,0 +1,27 @@
+---
+id: G-003
+type: goal
+status: proposed
+links: []
+title: Legacy robots are easy to obtain, wrap, and run on Tank Royale
+provenance: inferred
+reversal-cost: low
+---
+
+# G-003 — Legacy robots are easy to obtain, wrap, and run on Tank Royale
+
+## Who wants it
+
+Everyone `G-001` promises fidelity to, once they try to actually reach it: newcomers trying the bridge for the first time, anyone running a personal or club rumble, and the project itself. The parity campaign (`P-001`, milestone `M-006`) already depends on a local rumble jar collection existing on disk; there is no documented or automated way to build one today.
+
+## What they want
+
+To go from "here is a directory of classic Robocode robot jars" — or from nothing at all — to "these robots are running as Tank Royale bots." That means a build that produces artifacts someone can download rather than compile from source, and a guide that says where bots come from (https://rumble.robowiki.net/) and how to wrap them, replacing the current undocumented manual steps.
+
+## Why it matters
+
+Fidelity work has no audience if nobody can practically reach it. Today, using `robocode-api` and `robots-wrapper` means building from source with per-module hardcoded dependency versions and no shared catalog, no published jars, and a module README that stops at "copy this jar into a `lib` folder you create yourself." A user who cannot get the bridge running cannot benefit from anything `G-001` or `G-002` prove about it.
+
+## What this does not commit to
+
+Redistributing rumble bot jars itself, or guaranteeing that any particular automation against rumble.robowiki.net (scraping, or otherwise) is feasible or welcome there — that feasibility is explicitly open and belongs to whichever plan work picks it up. Nor does it commit to a specific artifact-publishing mechanism (Maven Central vs. GitHub Releases); that is an implementation choice, not a goal-level one.

docs/goals/README.md

@@ -7,4 +7,5 @@ A goal artifact answers three questions: who wants it, what they want, and why i
 <!-- clue:index:start -->
 - [G-001 — Legacy Robocode robots run unmodified on Tank Royale and behave as they do on classic Robocode](G-001-legacy-robots-behave-the-same-on-tank-royale.md) · `accepted` — The people who wrote the robots, and the people who still compete with them.
 - [G-002 — Every test proves the criterion its name claims](G-002-conformance-evidence-proves-the-criterion-it-names.md) · `proposed` — Anyone reading the corpus to find out what is proven — a maintainer deciding whether a milestone can close, a reviewer deciding whether a criterion may leave `@draft`, the next agent picking up the…
+- [G-003 — Legacy robots are easy to obtain, wrap, and run on Tank Royale](G-003-legacy-robots-are-easy-to-obtain-wrap-and-run.md) · `proposed` — Everyone `G-001` promises fidelity to, once they try to actually reach it: newcomers trying the bridge for the first time, anyone running a personal or club rumble, and the project itself.
 <!-- clue:index:end -->

docs/plans/P-002-build-distribution-and-bot-acquisition.md

@@ -0,0 +1,38 @@
+---
+id: P-002
+type: plan
+status: draft
+links: [G-003]
+title: Make the bridge buildable, distributable, and easy to point at real robots
+provenance: inferred
+reversal-cost: low
+---
+
+# P-002 — Make the bridge buildable, distributable, and easy to point at real robots
+
+## The campaign
+
+`G-003` asks for an easy path from "I want to run legacy robots on Tank Royale" to "I have them running." This campaign is that path, sequenced so each milestone gives the next one something to build on: a fat jar isn't worth publishing until its dependency versions are deliberate rather than accidental, a guide isn't worth writing until there's something a reader can download, and a downloader isn't worth building until the wrapper it drives has a stable, documented way to run.
+
+`M-147`'s exit criterion is deliberately open on mechanism. Rumble.robowiki.net has no documented bulk-download API, and whether a scraper against its live pages is feasible or welcome there is unknown; forcing that choice at plan time would commit the campaign to an approach nobody has yet checked is viable.
+
+## Milestones
+
+| ID | Milestone | Exit criterion | Status |
+|---|---|---|---|
+| M-144 | build cleanup + version catalog | `robocode-api`, `robots-wrapper`, and `conformance-test` share a Gradle version catalog (`gradle/libs.versions.toml`) for their dependency and plugin versions, and use a consistent Java target declaration style. `./gradlew build` succeeds across all modules from the catalog-sourced versions. | todo |
+| M-145 | artifact build & distribution | A tagged build produces downloadable `robocode-api` and `robots-wrapper` jars (via `maven-publish`, GitHub Releases, or an equivalent mechanism) that a fresh clone can fetch and run without building from source. | todo |
+| M-146 | usage guide | A guide documents the end-to-end flow from an existing robot jar to a running Tank Royale bot, replaces or removes the current undocumented manual `lib`-folder step, and points readers to https://rumble.robowiki.net/ as a source of robot jars. | todo |
+| M-147 | bot acquisition tooling | A documented, feasible acquisition path exists for building a local bot collection — either scripted downloading or a documented pointer to an existing bundle, whichever investigation at implementation time finds workable — and running it against `robots-wrapper` produces correctly wrapped bot directories for a sample set of bots. | todo |
+
+## Why this order
+
+`M-144` comes first because `M-145`'s published artifacts are only worth having if their dependency versions were chosen deliberately; publishing first would just make the current accidental version drift (`robocode-api` and `conformance-test` at `0.5.0`, `robots-wrapper` independently at `0.3.1`, every dependency version hardcoded per module) a public commitment instead of an internal one.
+
+`M-146` follows `M-145` because a guide that tells someone to download an artifact that doesn't exist yet is worse than no guide — it would need to be rewritten once publishing lands anyway.
+
+`M-147` is last because it is the only milestone whose mechanism is not yet known to be feasible, and because it depends on `robots-wrapper` already having the stable, documented invocation that `M-146` establishes. Automating a step that isn't yet reliably documented for a human would just automate the wrong thing.
+
+## What would change this plan
+
+If investigation for `M-147` finds that rumble.robowiki.net cannot be scraped (technically or by its own terms) and no equivalent bundle exists to point to instead, that milestone's exit criterion would need to be revised to something narrower than "acquisition tooling" — for example, a curated instructions page rather than a tool. That is a semantic change to the milestone's promise and needs the same human-accepted revision any other plan-promise change does.

docs/plans/README.md

@@ -10,4 +10,5 @@ Every full change proposal names the plan item it serves, or explicitly declares
 
 <!-- clue:index:start -->
 - [P-001 — Make the bridge's parity claims measurable, then close the gaps it measures](P-001-bridge-parity-campaign.md) · `active` — The campaign, sequenced so the instrument is built before the gaps it finds are closed.
+- [P-002 — Make the bridge buildable, distributable, and easy to point at real robots](P-002-build-distribution-and-bot-acquisition.md) · `draft` — `G-003` asks for an easy path from "I want to run legacy robots on Tank Royale" to "I have them running." This campaign is that path, sequenced so each milestone gives the next one something to build…
 <!-- clue:index:end -->