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

Adds G-003 (proposed goal: legacy robots easy to obtain, wrap, and run)
and P-002 (draft plan serving it, four milestones: Gradle version-catalog
cleanup, artifact distribution, a usage guide pointing to
rumble.robowiki.net, and bot-acquisition tooling with feasibility left
open). Regenerates the goals and plans README indexes.

Flags an M-prefix identity-ledger gap in open-questions.md: P-001's
existing milestone IDs were never registered with clue id, so `next M`
offers colliding numbers; this plan's milestones continue P-001's
sequence directly instead.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01A6pPpd8gWaqE3w1PWYr4qn

Author: flemming-n-larsen

.clue/id-ledger.yaml

@@ -140,6 +140,15 @@ 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"}
 high-water:
     - {id: ADR-002, kind: numeric, state: reserved, prefix: ADR, component: "2"}
     - {id: AN-014, kind: numeric, state: reserved, prefix: AN, component: "14"}

changes/CH-015-build-distribution-guide-plan/open-questions.md

@@ -0,0 +1,9 @@
+# Open questions
+
+## Milestone-ID (`M-xxx`) ledger gap
+
+`clue id next M` returned `M-001` through `M-004` as the next free milestone identities, but `docs/plans/P-001-bridge-parity-campaign.md` already declares `M-001` through `M-007` and `M-101` through `M-143` in its milestone tables — confirmed live by `clue context M-001` resolving to `P-001`. The `.clue/id-ledger.yaml` had zero prior entries for the `M` prefix, so the allocator has no record of `P-001`'s existing milestone IDs and offered ones that would collide if used.
+
+This change did not use the allocator's output for milestones. Instead, `P-002`'s four milestones are numbered `M-144`–`M-147`, continuing `P-001`'s existing sequence directly in the plan file, matching how `P-001`'s own milestones appear to have been authored (not through `clue id next M`, since the ledger had no trace of them). The four colliding reservations the allocator produced (`M-001`–`M-004`) were not released — the ledger is append-only and hand-editing it is out of scope here — so they sit unused in `.clue/id-ledger.yaml`.
+
+This is not blocking for this change (`clue validate` passes cleanly with `M-144`–`M-147` used directly in prose), but it means the `M` prefix in this repository's identity ledger is out of sync with the corpus and `clue id next M` cannot currently be trusted for milestone allocation. Flagging for a human decision: whether to backfill the ledger with `P-001`'s existing milestone IDs (so future `next M` calls resume correctly at `M-148`), or whether milestone IDs are intentionally kept outside ledger tracking and numbered by direct inspection as done here.

changes/CH-015-build-distribution-guide-plan/proposal.md

@@ -0,0 +1,15 @@
+---
+links: [G-003]
+---
+
+# CH-015 — Record the build/distribution/guide/downloader idea as a plan
+
+## What
+
+Adds `G-003` (a new, `proposed` goal: legacy robots should be easy to obtain, wrap, and run) and `P-002` (a `draft` plan serving it, with four milestones: Gradle version-catalog cleanup, artifact build & distribution, a usage guide pointing to https://rumble.robowiki.net/, and bot-acquisition tooling whose mechanism is left open pending feasibility investigation). Regenerates the `docs/goals/README.md` and `docs/plans/README.md` indexes.
+
+## Why
+
+The user asked, in a prior conversation, to capture a future improvement idea — better Gradle/version-catalog hygiene for `robocode-api` and `robots-wrapper`, publishable artifacts, a usage guide linking to the rumble bot archive, and eventually a tool to download bots and run `robots-wrapper` on them — as a durable corpus artifact rather than a private note. This change creates that plan. No implementation work against the plan's own milestones is in scope here; the plan is deliberately `draft`/`todo` throughout, recording intent for later pickup.
+
+This change is not plan-less: it exists to create `P-002`, so it links the goal (`G-003`) that plan serves rather than a pre-existing plan item.

changes/CH-015-build-distribution-guide-plan/tasks.md

@@ -0,0 +1,8 @@
+# Tasks
+
+- [x] Check `clue validate --intent` for a stated corpus vision before proposing new goal/plan content
+- [x] Allocate `G-003` and draft the goal artifact (`docs/goals/G-003-legacy-robots-are-easy-to-obtain-wrap-and-run.md`), `status: proposed`
+- [x] Allocate `P-002` and draft the plan artifact (`docs/plans/P-002-build-distribution-and-bot-acquisition.md`), `status: draft`, linking `G-003`, with four milestones (build/catalog cleanup, artifact distribution, usage guide, bot-acquisition tooling)
+- [x] Regenerate `docs/goals/README.md` and `docs/plans/README.md` indexes with `clue scaffold`
+- [x] Mark `G-003` and `P-002` live in the identity ledger and confirm `clue validate` passes
+- [ ] Record the stray off-ledger milestone-ID numbering convention (`M-144`..`M-147` chosen by continuing P-001's sequence rather than via `clue id next M`, since that prefix has no prior ledger entries despite P-001 already using `M-001`..`M-143` in prose) as an open question for the human to confirm or correct

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