The release train's version contract contradicts how the charts are actually versioned

[Mtze]

Raised by CodeRabbit on #43 and worth settling separately, because it is a decision rather than a fix.

Two models, both in the repo

release-train.yml's publish-charts job asserts that both charts carry one platform version:

cv=$(yq -r '.version' "charts/$c/Chart.yaml")
av=$(yq -r '.appVersion' "charts/$c/Chart.yaml")
if [[ "$cv" != "$V" ]]; then ... fi
if [[ "$av" != "$V" ]]; then ... fi

That held at 2.0.0, when the charts split (#24) and the train last ran (2026-08-26).

Since then appVersion has tracked the EduIDE release (1.2.0, now 1.3.0 via #43) while the chart version moved on its own cadence (2.1.x, 2.2.x, 2.3.0). The values file documents that model - versions.ide empty falls through to appVersion, so a chart release pins the IDE images - and the deployment repo depends on it.

So main has failed the train's check since appVersion was set to 1.2.0. Nobody noticed because the train has not been dispatched since.

The decision

Either:

(a) appVersion keeps tracking EduIDE. Then the train should check version == $V only, and derive or accept appVersion separately. This matches what every consumer already assumes.

(b) One platform version for everything. Then a release moves chart version and appVersion together and the IDE images take the platform version as their tag, which means EduIDE stops publishing its own version-numbered releases - a much larger change touching four repositories.

(a) looks right, but it is not a call to make inside a version-bump PR.

Also

The charts had drifted apart (eduide 2.2.1, eduide-cluster 2.2.2) despite AGENTS.md saying they are released together at the same version. #43 puts both at 2.3.0. Nothing enforces it - worth a CI check in whichever direction this lands.

[Mtze]

Decided: per-repo versions. Each repository releases on its own cadence, the chart tracks EduIDE through appVersion, and the chart version stays semver about the chart.

EduIDE-Helm#45 implements it:

• release.yml verifies every image the chart pins exists and is multi-arch, then publishes, tags, and creates a GitHub release naming what the version pins
• ci.yml enforces the lockstep between the two charts that AGENTS.md asserted and nothing checked (the 2.2.1 / 2.2.2 drift this issue mentions)
• release-train.yml keeps its unified contract, with its header and failure message rewritten to say it is a deliberate lockstep release and not the ordinary path - so failing its pre-check against a normal main reads as correct rather than broken
• .claude/skills/cut-a-release.md rewritten around the real process

Closing once #45 merges.