feat(issues): a report on an older version is reproduced on the current code, not told to update

[soydiloreto]

📝 What changes

• issue-triage.yml: a defect report with steps is bug_unconfirmed whatever version it names; an older release or an older development build (see the brief's "Current versions") is no longer a reason for needs_info. The reply names the current version and says the reproduction runs on it. needs_info is again only for a report missing what a maintainer needs (naming the current version when the reported one is not current). Header comment updated.
• issue-repro.yml: new input dev-tag (default dev). The write job also returns reported_version (validated to X.Y.Z or X.Y.Z-dev.N, passed as a job output). Both verdicts say what they ran on: confirmed adds "you saw it on X; this ran on the current code (development build, linked), so the bug is there now"; not reproduced adds "if it was there in X it may have been fixed since: install the current development build and say whether it is still there". Header comment updated.
• README: the triage and reproduction rows.

💡 Why

Yesterday's version (v2.2.0) answered a report made on an older version with "please update and see": cheap, but it can be a loop (the reporter updates, the bug is still there, we ask again) and it tells the maintainer nothing. The maintainer asked for an answer about the current code without spending another model call. The reproduction already runs its test on main, which is the current development build, so it is the answer: the triage sends the report there instead of asking to update, and the verdict says explicitly what it ran on and what the reporter should do next.

🧪 How I tested it

• actionlint 1.7.12 on every workflow.
• The reported_version filter: 1.0.0, 2.0.0-dev.7 pass; free text yields an empty string, so the extra sentences are not added.
• Live test: the next bug report on Offload that names 1.0.0 must be labelled bug:unconfirmed, reproduced on main, and its verdict must carry the "you saw it on 1.0.0" sentence.

🤖 AI-generated · Claude Fable 5.1 (Anthropic)

[dilux-bot]

Claude review · risk high · complexity medium · type feat

The new commit fixes my earlier minor finding. A report on the release the current dev build grows from (X.Y.Z when the dev build is X.Y.Z-dev.N) is no longer counted as older, so right after a release it doesn't get the "may have been fixed since" line by mistake. I checked the comparison: ${dev%%-dev.*} removes the pre-release suffix, and the new check runs before sort -V. Before this change, sort -V put 1.0.0 ahead of 1.0.0-dev.N, which is how the release ended up counted as older. A report naming a version newer than a stale dev build still counts as not older. The new comment on the check says the same thing the code does. The header comment, the dev-tag input description, the README rows and the triage prompt all still say the extra sentence is only for an older version, so the docs match the code. Nothing is left open. The pull request as a whole adds behaviour (triage sends reports on older versions to reproduction instead of asking the reporter to update, and the verdicts say what they ran on), so it is a feat. It stays high risk because it changes shared issue workflows used across all repositories. The description still matches the diff.

No findings.

_{Policy floor: high (touches high-risk paths: .github/workflows/issue-repro.yml, .github/workflows/issue-triage.yml, README.md). Reviewed 979a81b (since df2ce3b; review 3 of 5 automatic). Author trusted for auto-merge: true.}

_{🤖 AI review · claude-opus-5-5 (Anthropic) · $0.17, 4 turns}