[ApGa]

This pull request releases platoon 0.5.0, following CONTRIBUTING.md's "Cut a release", and readies the TextCraft
extension's release for it, platoon-textcraft 0.4.0. It holds the release commit alone, on main after every pull
request of 0.5.0 has merged. Once it merges, the tag v0.5.0 on its merge commit publishes platoon 0.5.0 to PyPI.

What 0.5.0 contains

What merged since 0.4.0, as CHANGELOG.md's 0.5.0 section lists it:

• Harbor's multi-container tasks run. The compose subset, with main-only compose files running as the task's one
  sandbox (feat: Add the compose subset for Harbor tasks, and run main-only compose files #57); the stack layer and the process provider's stacks (feat: Run multi-container Harbor tasks: the stack layer and the process provider #58); stacks as docker compose projects
  (feat: Run Harbor stacks with docker compose #66), as rootless pods on Singularity, Apptainer and enroot (feat: Run Harbor stacks as pods on Singularity, Apptainer and enroot #67, experimental), and on the host network where
  pods cannot run (feat: Add the host-network fallback for Harbor stacks #75); hpc-sandbox 0.5.1 for the hpc extra, and fetches that lock stacks as runnable (feat: Require hpc-sandbox 0.5.1, and lock fetched stacks as runnable #71); a
  task's MCP servers served through the tool plane, a stack's among them (feat: Serve task MCP servers through the tool plane #74).
• Harbor datasets from the Harbor Hub, git repositories and adapters (feat: Fetch Harbor datasets from the Hub, git and adapters #60), tasks that run as the users they
  name through fakeroot (feat: Honor [agent].user and [verifier].user through fakeroot #68), and node services with the FrontierSmith recipe (feat: Add node services and the FrontierSmith recipe #95).
• The trainer API (experimental), after RFC 0021 (docs: Add RFC 0021 on trainers, credit and policies #64): the training code in packages named after the stages of a
  run (refactor: Move the training code into packages named after the stages of a run #62, refactor: Decompose the training loop into the stages of one step #69, refactor: Decompose the long functions of the trainer, the group workflow and the workers #70, refactor: Clean up the training code #82, refactor: Finish cleaning up the training code #90; the old platoon.train.tinker paths warn until 0.6.0), the workflow contract (refactor: Write down the workflow contract #76),
  policy objects (refactor: Hold each model's state in a policy object #77), learners and objectives (refactor: Update a policy through a learner and an objective #78), one lifecycle for every trainer (refactor: Run every trainer through one lifecycle #79), the rollout source
  (refactor: Draw rollouts through a rollout source #80), the SFT trainer (feat: Add the SFT trainer #81), step hooks (feat: Let a trainer add work at the end of each step #86), per-datum stale masks (feat: Mask stale tokens per datum #83), credit estimators (feat: Add credit estimators #84), several
  policies and frozen scorers (feat: Sample several policies, and score with frozen ones #88), a tool allowlist per agent role (feat: Add a tool allowlist per agent role #89), policies trained in lockstep (feat: Train several policies in lockstep #91) and on
  their own clocks (feat: Let each policy step on its own clock #94).
• Fixes: a process sandbox reap waits for the processes it kills (fix: Make a process sandbox reap wait for the processes it kills #73), and a checkpoint key that a row already
  holds is refused (fix: Refuse checkpoint keys that a row already holds #92).
• Tests that hold on slow runners (test: Make the resume test that drops waiting slots hold on slow runners #59, test: Make the ORS loop-end teardown test hold on slow runners #61, test: Make the admission interrupt and binding poll tests hold on slow runners #72, test: Wait for the pid files the grading tests read #87) and the reorganized training tests (test: Reorganize the training tests to mirror the packages #85), which change nothing
  in the package.

What changes

• pyproject.toml and uv.lock: version 0.5.0. The lock records platoon-textcraft 0.4.0 too; nothing else in it
  moves.
• CHANGELOG.md: ## 0.5.0 (unreleased) becomes ## 0.5.0 (2026-10-29), the day (UTC) the tag is to land (should
  the merge slip past that day, date it again first: the Release workflow checks only that the heading has a date).
  The section gains install and upgrade notes: the upgrade commands, moving a pinned range to 0.5 (and how to load an
  extension that does not admit 0.5 yet), the hpc extra's move to hpc-sandbox 0.5.1, the fetch that now locks
  multi-container tasks as runnable (and how to keep them refused), the training code's move out of
  platoon.train.tinker, a restart of a run that is training, and the TextCraft extension's release for 0.5. The
  intro's example range names 0.5.
• CHANGELOG.md, entries brought up to what 0.5.0 ships, where later pull requests overtook them: a compose file
  with services besides main runs as a stack, where the entry said such stacks stay refused; the defaults of
  TrainerNeeds are told once, in the new feature, instead of as a change to 0.4.0's trainer API, which did not
  exist; the Changes no longer name methods that 0.4.0 never had (TrainStep.advance, _new_stats_logger); entries
  that said a 0.5.0 API "gains" or "now" does something say what it does; the FrontierSmith entry is reworded and
  rewrapped; and blank lines no longer split the list of new features.
• Ranges: a minor release moves every range that names the previous one, so these now name 0.5 (>=0.5,<0.6):
  README.md's install line, CHANGELOG.md's intro, CONTRIBUTING.md's sections on extensions, versions and the TextCraft
  extension, the install guide, the extension guides (docs/extending/index.md and publish-a-package.md), the two
  example packages, the TextCraft extension and its README, and the fake extensions of the tests
  (tests/extension_site.py and three tests), which platoon 0.5 would otherwise refuse. The changelog's earlier
  sections keep their ranges.
• Docs: the listings of platoon harness list and platoon extensions list show 0.5.0; the FrontierSmith recipe
  names platoon 0.5.0 without "(unreleased)"; the RAO recipe's requirements name platoon 0.5 and platoon-textcraft
  0.4; and CONTRIBUTING.md's example of the extension's release names 0.4.0. No docs say "the next release".
• Deprecations: no form is due for removal in 0.5.0, since 0.4.0 deprecated nothing (grep -rn 'removed_in="0.5.0"' platoon finds none). The module paths that 0.5.0 moved out of platoon.train.tinker go in 0.6.0, and so does the
  warning of a GroupRolloutWorkflow subclass that defines a method of its startup gate under its name before 0.5.0;
  CONTRIBUTING.md's check now lists the forms due in 0.6.0 and names that warning.
• The TextCraft extension, platoon-textcraft 0.4.0: its platoon extra requires platoon[ors]>=0.5,<0.6, so that
  platoon-textcraft[platoon] installs beside platoon 0.5. Its code and data are those of 0.3.0, which stays the
  release for platoon 0.4; its README says how to install the release for platoon 0.4, 0.3 or 0.2. It is 0.4.0, not
  0.3.1, because a patch release only fixes bugs and this one moves the platoon it installs to a new minor release.

After the merge

1. The tag v0.5.0 on the merge commit, on the day the changelog dates (2026-10-29, UTC). The Release workflow checks
   that the commit is on main and that CHANGELOG.md dates 0.5.0, builds and checks both distributions, and uploads
   platoon.
2. Once platoon 0.5.0 is on PyPI, and promptly then, the tag platoon-textcraft-v0.4.0 on the same commit publishes
   platoon-textcraft 0.4.0. Not earlier: its platoon extra cannot be installed until platoon 0.5.0 is there. Not
   much later either: until it is on PyPI, the changelog's second upgrade command, which names
   platoon-textcraft[platoon], does not resolve.
3. The GitHub releases for both tags: v0.5.0's from the changelog's 0.5.0 section, with its links pinned to the tag,
   as v0.4.0's.

Checks

• CI's jobs, run on this commit as CI runs them (fresh checkouts, no secrets, an empty Hugging Face cache), on main
  with every pull request of 0.5.0: lint; the tests on Python 3.12, 3.13 and 3.14 (8765 passed and 253 skipped on
  each, and the 2 serial tests), with uv lock --check, the generated reference, the public API snapshot and a clean
  tree after the tests on 3.12; the TextCraft extension's tests (38 passed, 6 skipped); the recipes (33 passed); and
  the release workflow's build and checks: the sdist and the wheel of platoon 0.5.0 and of platoon-textcraft 0.4.0
  pass twine check --strict, the wheel's platoon --version prints 0.5.0, its platoon harness list matches the
  docs' listing, and the TextCraft wheel serves its environments alone, without platoon. All pass.
• The built wheel, installed with [tinker,ors,hpc] into a fresh virtual environment outside the checkout (which
  resolves hpc-sandbox 0.5.1): platoon --version prints 0.5.0, import platoon, platoon.experimental imports from
  the installed package, and platoon config validate passes on the number-search example's train.yaml and
  eval.yaml.
• The training loop's golden trace (tests/train/parity): 27 passed.
• uv lock moved only platoon (0.4.0 to 0.5.0) and platoon-textcraft (0.3.0 to 0.4.0).
• main before this commit passed CI with all of 0.5.0's pull requests merged.