[htcom-code]

What & why

The committed development version was 0.0.1-SNAPSHOT and stayed there
permanently — release coordinates are injected with -Pversion, so the
placeholder never needed to move. That held while the version was only a
publishing coordinate. It stopped holding in #80, when the SSE ready frame
started reporting it to clients as platformVersion.

0.0.1-SNAPSHOT sorts before 0.0.1. So a build of main — carrying a
frame that 0.0.1 does not have — announced itself as older than the release
that lacks it. Not vague: inverted. A console asking "does this server send
ready?" got a number meaning "pre-0.0.1" from a server that was sending it.

The default now names the version being worked towards and is bumped right after
each release.

Decision "b" is unchanged in substance. Release coordinates are still never
committed and still arrive via -Pversion. What changed is which version the
development placeholder holds — the next one instead of the last.

Six places carried the literal

One left behind would disagree with the rest, so they move together:

file	what
build.gradle	the version itself, plus why the default is the next release
build.gradle	a POM comment that pinned the literal
.github/workflows/release.yml	the two comments explaining decision "b"
verification/consumer/build.gradle	the consume-test harness's default coordinate
docs/guide/11-operations.md + .ko.md	the release section, plus the bump-after-release rule that keeps the new default true

CI gained the gate this needs

platformVersion is read from the jar manifest, and nothing in the test suite
can observe it: tests run from exploded classes, where there is no manifest and
the field is null by design. Dropping the manifest attribute would therefore
ship platformVersion=null to every consumer with a fully green build.

The build job now asserts, on the artifact, that the manifest version equals the
version the build declared — not merely that it is non-empty, which an earlier
draft of this check would have satisfied with a stale jar.

Consumers of development snapshots are affected

The GitHub Packages coordinate moves to 0.1.0-SNAPSHOT, so a build pinned to
0.0.1-SNAPSHOT stops receiving updates. Released coordinates are untouched. The
changelog says so in both languages.

Also narrowed the platformVersion docs. They said null happens on "tests, IDE
runs", which reads as common; every path a console actually connects to resolves
protean as a jar, including the quickstart demo, so null is rare in practice.

Type of change

• fix — bug fix (no new API)
• feat — new capability (dynamic loading, gates, isolation, MCP, debug, data access)
• perf — performance, no observable behaviour change
• docs — documentation only
• refactor / chore / test / ci — no behaviour change

Correctness & safety

No production code path is touched: this changes a build property, comments, docs,
and adds a CI assertion. The only runtime-visible effect is the string a jar
reports as its version, which is the point.

• N/A — Unload path, promotion gates, config binding: not touched.

Verification

• gradle clean bootJar assembles — the jar is protean-0.1.0-SNAPSHOT.jar
  and its manifest carries Implementation-Version: 0.1.0-SNAPSHOT, checked
  on the built artifact
• gradle test passes (full regression, run after the jar exists) — 599
  tests, 0 failures, 0 skipped
• Docs updated — docs/guide/11-operations.md + .ko.md, CHANGELOG (en + ko)
• Container/isolation tests actually ran (not self-skipped)
• PoC gate passes — 6 combinations x 6 criteria, no SKIPPED, no unreported cell
• The new CI check was dry-run locally against the built artifact and matches
  (0.1.0-SNAPSHOT == 0.1.0-SNAPSHOT)

Related

Follow-up to #80, which made this version runtime-visible.