docs: sync roadmap claim statuses with accepted proposals

[hiter-joe]

The roadmap, README and website still advertise three claimed directions as unclaimed, which can lead contributors to duplicate active work.

Mark routing-network closure as accepted (#108), and snowpack cold content and wave celerity as in progress (#147/#148, PRs #150/#149). Link the proposals and implementations, explain the snowpack proposal's refinement to meltwater outflow, and update all three website language blocks and the README overview. Keep channel-routing mass closure unclaimed with its existing inflow-contract limitations.

Validation: verified the nine translated status rows against GitHub; git diff --check passes. Only README.md, ROADMAP.md and site/index.html change. Focused docs tests could not run locally because the available environments lack the package or pytest.

[chrimerss]

/review

[github-actions]

Automated review by Claude (changes-suggested), not a maintainer approval.

Docs-only sync of roadmap claim status. mass/routing-network-closure becomes accepted (#108), energy/snowpack-cold-content and momentum/wave-celerity-bounds become in progress (#147/#150 and #148/#149), each with a claim line in ROADMAP.md and a linked tag in all three site/index.html language blocks; the README's probe-count sentence is reworded; momentum/channel-routing-mass stays unclaimed.

The mechanics hold up. .tag.accepted and .tag.progress already exist in the stylesheet (site/index.html:151) and the pre-existing probes.legend in all three languages already defines both states, so the new tags are documented and styled. The four non-merged roadmap entries match the README's "four further directions: three are claimed". renderToggles counts only .tag.merged, and test_docs_in_sync.py constrains merged probes only, so nothing in the tests or the site JS is disturbed. No energy/snowpack-ripening or momentum/wave-celerity-bounds directory exists in probes/, so "in progress" is at least consistent with the checkout — but the names, issue numbers and whether #149/#150 are still open can't be checked offline and are worth confirming before merge.

The main thing to know: the README's own Status section (line 416) still says "The roadmap lists the remaining unclaimed directions", which this change makes false in the same file. AGENTS.md step 4 asks for exactly that paragraph to be rewritten when the unclaimed entries change.

---

README.md:416 medium: README Status section still calls the roadmap a list of unclaimed directions

The change rewrites line 86 to say three of the four roadmap directions are claimed, but the Status section 330 lines later still reads "The roadmap lists the remaining unclaimed directions." A contributor who reaches the README through the Status section — or who reads both — is told the opposite of what the PR is trying to establish, which is the duplicate-work risk the description names. AGENTS.md step 4 ("Rewrite the paragraph above it if it counted the unclaimed entries") covers this case; no test enforces it, so it has to be caught here.

Fix: reword to something like "The roadmap lists the remaining directions and who has claimed them."

_{Posted by the pr-review workflow. Run}

[github-actions]

low: Site tags snowpack-cold-content in progress but links to a differently scoped probe

The row keeps the id energy/snowpack-cold-content and the description "The full snowpack energy budget, cold content and phase change included", while the status now links to PR #150 — which, per the new ROADMAP text at ROADMAP.md:243-247, implements energy/snowpack-ripening and tests meltwater leaving a cold pack instead of forbidding internal melt in a layered pack. ROADMAP.md carries that refinement note; the site carries none. A visitor reading the site concludes the probe as described is taken, follows the link, and finds a different probe; someone who would build the layered-pack version is discouraged for no reason.

Same row in the other two language blocks: lines 1159 and 1403.

Fix: either link this tag to the proposal issue #147 rather than the PR, or carry the id the probe actually took into the row (the description would then need to match), consistent with AGENTS.md step 4's "under the id the probe actually took".

[github-actions]

low: Reworded sentence leaves no claimable probe and no alternative

The new text states that three of the four directions are claimed and the fourth "awaits a suitable inflow contract" — i.e. nothing on the list is available. The recruiting banner at README.md:35 still says "Start with a probe", so a prospective contributor following that link now hits a dead end, even though ROADMAP.md:376 ("Adding something not on this list") invites proposing a new one.

Fix: add a clause pointing at ROADMAP.md#adding-something-not-on-this-list, e.g. "...awaits a suitable inflow contract; new probes outside the list are welcome too."

[chrimerss]

Thanks @hiter-joe — this is ready to merge after one fix.

mass/routing-network-closure should be in progress, not accepted: its implementation #118 (a draft) has been open since 2026-09-19, and the site's status legend says a probe is in progress "once a pull request is open". Could you push this change?

ROADMAP.md

-### `mass/routing-network-closure` · standard · **accepted**
-Claimed by Jiao Wang in [#108](https://github.com/Flood-Lab/HydroTuring/issues/108).
+### `mass/routing-network-closure` · standard · **in progress**
+Claimed by Jiao Wang in [#108](https://github.com/Flood-Lab/HydroTuring/issues/108),
+with a draft implementation in [#118](https://github.com/Flood-Lab/HydroTuring/pull/118).

site/index.html: in all three language blocks, the routing-network-closure row's status cell becomes

<a href="https://github.com/Flood-Lab/HydroTuring/pull/118"><span class="tag progress">in progress</span></a>

with en curso and 进行中 in the Spanish and Chinese blocks.

README.md needs no change ("three are claimed" stays true).

A heads-up on ordering: #149 and #150 rewrite the same README sentence, ROADMAP headings and site rows, so we plan to merge this one first and have them keep their own side when they resolve the conflict.

---

Generated by Claude Code