[yia-mw-agent]

Summary

Prepares FAVA Trails 0.9.3rc1 as a same-base, metadata-only release candidate of main commit ed59cd4. Stable baseline is 0.9.3, bumped in #156 and never published; PyPI latest is 0.9.2 and no v0.9.3* tag exists. This PR does not repeat that bump, does not go to 0.9.4, and does not touch release.yml.

Why a tooling change was needed: the updater's only RC entry (Release-Channel: rc) increments the base (0.9.3 becomes 0.9.4rc1), and a version-only edit to 0.9.3rc1 fails check (expected 0.9.3). release.yml requires tag == package version and tag == current main tip, so v0.9.3rc1 cannot be cut on source 0.9.3.

What changes:

• scripts/mw-version.py: new exact-line marker Release-Channel: rc-same-base (also in the embedded guidance). 0.9.3 becomes 0.9.3-rc.1 (0.9.3rc1) with no increment. After stripping configured version values, any remaining release-path difference from the base is rejected. Needs a stable baseline, is mutually exclusive with Release-Channel: rc, and is ignored by the promotion title. The updater never tags or publishes.
• pyproject.toml, uv.lock, src/fava_trails/__init__.py: the three synchronized mirrors, written by mw-version.py update (not by hand), 3 lines changed in total.
• scripts/check-rc-artifact-identity.py (new, non-product path): builds the base and the candidate with uv build from git archive trees and fails unless the wheel and sdist have the same members and identical bytes after rewriting 0.9.3rc1 to 0.9.3 (wheel RECORD ignored).
• docs/version-policy.md: documents both RC markers and the artifact check.
• tests/test_release_channels.py: 21 new tests.
• CHANGELOG.md/README.md are deliberately untouched, because the sdist ships them and the candidate must keep the base's bytes.

Evidence (head = this PR's head, base = ed59cd4)

• python3 scripts/mw-version.py check --base origin/main --title '<this title>' --body-file <this body>: repo: 0.9.3 -> 0.9.3-rc.1, Version policy passed.
• uv run pytest excluding tests/test_packaged_mcp.py: 1251 passed. tests/test_release_channels.py: 56 passed (35 existing, 21 new).
• New tests cover: base kept and mirrors in sync; only version lines change; rejection of product source, new shipped file, unlisted root file, a mirror edited beyond its version, and a product change committed on the branch; allowance for docs/tests/check scripts; unprepared and wrong versions (0.9.4rc1, 0.9.3rc2, 0.9.4) fail check; no-marker RC relabel rejected; prerelease baseline rejected; marker exclusivity and exact-line matching; promotion title ignores the marker; later promotion (0.9.3rc1 to 0.9.3) and a later product change (0.9.4rc1) keep their semantics; artifact comparison accepts a version-only candidate and rejects changed bytes, an adjacent changed line, added/removed files, sdist changes, no version change, and a wrong artifact name.
• Artifact identity vs ed59cd4 (check-rc-artifact-identity.py --base-ref ed59cd47...): no problems.
  • base wheel fava_trails-0.9.3-py3-none-any.whl sha256 5b022ca188d029c51332f2a243577f7ae570a8497410d414ff2db2150dedf01d
  • base sdist fava_trails-0.9.3.tar.gz sha256 aed3d5a8989e4b4930b53eee0ab651ca05289ae436e7404be8f6d0997b5bb2a8
  • candidate wheel fava_trails-0.9.3rc1-py3-none-any.whl sha256 e5cdc675c3e55b2c0c069ba7360ad166b623666029814674c35bcf6cc8c7509b
  • candidate sdist fava_trails-0.9.3rc1.tar.gz sha256 63a2b2717772ad6252bc7e18d321615324d59214a0354e30ab778778e01d9c25
• Packaged smoke/MCP proof on those exact candidate files (FAVA_CANDIDATE_WHEEL/FAVA_CANDIDATE_SDIST, FAVA_EXPECT_WHEEL=1, as in release.yml): tests/test_packaged_mcp.py 3 passed (wheel serves MCP, governed recall isolation, fresh install and upgrade from 0.6.0). Hashes were identical before and after.

Not done here (separate publication step)

No tag, GitHub Release, PyPI upload, install, runtime restart, or provider/model/data/config change. These local sha256 values are build-environment evidence; the Release workflow rebuilds once from the tag and records its own candidate-SHA256SUMS.

Handoff for the First Officer

1. Review this PR and merge only while main is still ed59cd4 (or re-run the updater check after any main change).
2. Tag the merged main tip v0.9.3rc1 (release.yml requires tag == main tip and tag == pyproject.toml version) and dispatch the Release workflow; release-tag.py classifies it as rc (prerelease, not latest).
3. Promotion later uses the exact title chore(release): promote version (0.9.3rc1 to 0.9.3, no base increment). The CHANGELOG has no 0.9.3 section yet; add notes in a separate change (editing it changes the sdist).

Rollback: revert the merge commit. Nothing is published by this PR, so reverting restores 0.9.3 in all mirrors; if a v0.9.3rc1 tag was already cut, it is immutable and 0.9.4rc1/promotion would follow normal policy.

Known gaps: open Dependabot #162 (pyasn1) will need 0.9.4rc1 if it merges after this PR (the baseline is then a prerelease) and does not change this candidate; merge order is the First Officer's call. scripts/mw-version.py is a toolkit-distributed file, so the marker should be upstreamed to wise-agents-toolkit; this repo's copy now differs from the toolkit's.

Release-Channel: rc-same-base

Refs #163