docs: allow local Rumble development before release

Permit M-008 development against a local Runner build while retaining a released-artifact gate for ranked distribution. Require releases to provide end-user value except for corrective releases.

Cliewen-Route: simple

Full-Route-Recommendation: Recommended because this changes accepted decisions, a plan promise, and release policy.

Full-Route-Risk: This bypasses the Cliewen proposal and full-change review trail for semantic governance changes.
Authorized-Push: maintainer explicitly authorized this direct push to main in the Codex conversation of 2026-08-30

Author: flemming-n-larsen

AGENTS.md

@@ -4,7 +4,7 @@
 
 **Start at [`docs/README.md`](docs/README.md)** — the corpus is the permanent truth about this system (Cliewen conventions since CH-001; see [AN-001](docs/analysis/AN-001-openspec-extraction.md)). Requirements live as Gherkin acceptance criteria under `docs/capabilities/*/criteria.md`. Before editing, recommend `simple` when the accepted contract remains unchanged or `full` when acceptance-criterion, capability, decision, policy, plan-promise, methodology, or uncovered-behavior meaning changes; paths and diff size never decide the route. Simple work uses no Cliewen workspace; chosen full work runs the change loop (`clue-delta` skill): branch → `/changes/CH-xxx-slug/` proposal → implement → digest → PR. Reassess when semantic scope grows, and if the user declines a full recommendation, record the route, recommendation, and risk in the final commit trailers. `clue validate` judges the corpus; markdown prose is never hard-wrapped (one line per paragraph). A full change never reaches `main` except through a human-merged PR; simple work may be committed and pushed to `main` directly only when the maintainer explicitly authorizes that push for that specific change, and such commits carry an `Authorized-Push:` trailer naming the authorization. Agents never merge their own PRs. See [C-002](docs/constraints/C-002-review-boundary.md).
 
-Before your first tool call, run `clue latest --quiet`; if it reports that this repository is behind, ask whether to run the coordinated `clue-upgrade` workflow. Releases are repository-owned administrative work, not a Cliewen route.
+Before your first tool call, run `clue latest --quiet`; if it reports that this repository is behind, ask whether to run the coordinated `clue-upgrade` workflow. Releases are repository-owned administrative work, not a Cliewen route. A release must provide clear end-user value; corrective releases for defects, security, compatibility, or urgent operational problems may ship without a new user-facing capability. Never release solely to unblock internal or downstream development; use local builds until a value-bearing or corrective release is warranted.
 
 AC IDs are namespaced per capability via `ac-prefix` frontmatter (registry in `docs/README.md`); the corpus is the registry, IDs are meaning-immutable. Test purpose tags (every test carries exactly one AC ID or Unit/Sanity/Arch tag) are being introduced capability by capability — see P-001/M-002; extracted criteria sit at `status: draft` until their tests are wired.
 

docs/decisions/ADR-046-runner-behavior-version-precondition.md

@@ -22,4 +22,4 @@ The default remains unpinned for backward compatibility. The API does not expose
 
 ## Consequences
 
-Rumble Client can delegate fail-closed compatibility enforcement to the component that owns the server connection. Existing Runner callers retain their current behavior, while callers that require an epoch must opt in explicitly. The API must ship in a released Runner artifact before the external client can depend on it.
+Rumble Client can delegate fail-closed compatibility enforcement to the component that owns the server connection. Existing Runner callers retain their current behavior, while callers that require an epoch must opt in explicitly. The merged API may be consumed from a local build during client development, but it must ship in a released Runner artifact before the external client is distributed for ranked use.

docs/decisions/IDR-004-rumble-client-battle-runner-dependency.md

@@ -16,8 +16,8 @@ CAP-016 requires the Rumble client to execute pinned battles through the Battle
 
 ## Decision
 
-`robocode-dev/rumble-client` depends on the first released `dev.robocode.tankroyale:robocode-tank-royale-runner` version that provides the BR-049 behavior-version precondition. The client pins that concrete release rather than consuming an unreleased local or snapshot build.
+During development, `robocode-dev/rumble-client` may consume the merged BR-049 implementation from a local Tank Royale build. Before the client is distributed for ranked use, it pins the first released `dev.robocode.tankroyale:robocode-tank-royale-runner` version that provides the BR-049 behavior-version precondition.
 
 ## Consequences
 
-The client uses the released public API for server lifecycle, bot processes, compatibility enforcement, full-round execution, results, and replay recording. Runner upgrades become explicit client dependency updates and ranked compatibility remains governed by the synchronized behavior version rather than inferred from the dependency version.
+Local end-to-end development can continue without forcing a Tank Royale release that offers no end-user value. Distributed clients still use an immutable released public API for server lifecycle, bot processes, compatibility enforcement, full-round execution, results, and replay recording. Runner upgrades become explicit client dependency updates and ranked compatibility remains governed by the synchronized behavior version rather than inferred from the dependency version.

docs/plans/P-003-rumble.md

@@ -23,4 +23,4 @@ The milestones mirror the design's Change Proposal Roadmap in order. Each milest
 | M-010 | GUI supports TwinDuel | The GUI game-type dialog can select and start the `TwinDuel` preset using the common game-type contract; it is shipped in Tank Royale 1.1.0 | done | CH-013; CAP-017/GTD-001 and GUI acceptance evidence |
 | M-009 | Rumble documentation published | User guides live under `/web/docs/rumble/` with one quickstart per audience: bot author, battle contributor, moderator | todo | |
 
-M-006 and M-007 both depend only on M-005 and may proceed in parallel; M-008 depends on the `rumble-bots` catalog, the `rumble-data` engine/matchmaking files, the official Tank Royale 1.1.0 release, and a published Battle Runner artifact containing BR-049; M-010 depends only on M-005's common game-type contract and is shipped in Tank Royale 1.1.0; M-009 follows the settled client and GUI interfaces.
+M-006 and M-007 both depend only on M-005 and may proceed in parallel; M-008 depends on the `rumble-bots` catalog, the `rumble-data` engine/matchmaking files, the official Tank Royale 1.1.0 release, and merged BR-049 Runner support available through a local build during development; distributing the ranked client depends on a published Battle Runner artifact containing BR-049. M-010 depends only on M-005's common game-type contract and is shipped in Tank Royale 1.1.0; M-009 follows the settled client and GUI interfaces.