[mremond]

Why

New pull requests had to be put in the upcoming release's milestone by hand. Draftline already does this automatically; Nera now works the same way.

What changed

• A target file names the next release (0.1.1), and a new workflow puts each newly opened pull request in that open milestone.
• The check never creates a milestone and never overrides one set by hand; a missing, closed or duplicated target fails the run.
• The release steps now move the target in the commit that bumps the version.
• Editing the target file or the workflow starts no CI job.

Before and after

Before: Each pull request was put in a milestone by hand.

After: Each newly opened pull request lands in the milestone named by the target file.

Build and release tooling only; nothing visible in the product changes.

Checked

• Script tests against a local stand-in GitHub server, replaying Draftline's cases, run ten times in a row: 25 tests in the CI script folder passed on every run
• Change map case for the target file and workflow: selects no job

How it was checked

python3 -m unittest discover -s scripts/ci -p 'test_*.py' ten times: all passed

Risk

Risk above low: Evidence, medium — Tested against a stand-in server; the workflow only runs from main.; Sensitivity, medium — pull_request_target with a write token, never checking out pull request code.; Novelty, medium — New script beside existing CI tooling.

Full risk assessment

Dimension	Level	Why
Blast radius	low	New workflow and script; one change-map rule.
Behavior	low	Only sets a milestone on newly opened pull requests.
Undo	low	Revert the commit.
Evidence	medium	Tested against a stand-in server; the workflow only runs from main.
Sensitivity	medium	pull_request_target with a write token, never checking out pull request code.
Novelty	medium	New script beside existing CI tooling.
Dependencies	low	None added.

Not done

The first pull request opened after merge should carry the 0.1.1 milestone; the workflow cannot show this on its own pull request.