[0b3l1X-SolidGeeks]

What this changes

A new base job in the CI checks the branch as pushed, not the merge GitHub prepares (that merge always contains main):

• Fails when the branch does not include the latest v… tag of the base branch (today v0.9.0). The error names the tag, says how many commits behind the branch is, and gives the commands to update it (rebase or merge main).
• Passes with a notice when the branch includes that tag but lags a few commits behind, so that every merge to main does not turn every open PR red.

Why: #60 started 32 commits back, before 0.7.0. It conflicted, and it would have undone the 413 handling that 0.7.0 fixed. The README (section 14) explains the rule.

How to check it

The job's script, run locally against real branches:

• pull/60/head: fails with This branch starts before v0.9.0: it is 32 commits behind main…
• main: Up to date with main.
• the Incident mode, and anonymised AI prompts per asset #58 and Connect to Muster: its incidents open on the map and run from there #59 heads, 1 to 2 commits behind: pass with a notice.

On this PR the job should be green, since the branch starts from the current main.

Two things only a maintainer can do in the settings:

• To make the job block merging, add base to the required status checks of main.
• For a first-time contributor's fork, the CI, this job included, runs only after "Approve and run".

The Solid checklist

• Tests cover the change and pass in CI (the job runs on this PR; the script was checked locally on the branches above)
• Docs are updated (README, section 14)
• No secrets, keys or personal data in the diff
• Every commit is signed off (git commit -s, see DCO)
• New files carry the repo's SPDX license header (no new file)

---

Generated by Claude Code