chore(release): Bump version to 0.19.2

[arcaputo3]

Release prep for the 0.19.2 "Fixpoint" cut (2026-08-08): version fallback to 0.19.2, dep strings in README/QUICK-START, CHANGELOG gains the Performance section for the perf stack (#521/#523/#524) alongside the existing Wave-24 and lint entries (#527/#530), STATUS/roadmap refreshed.

After merge: annotated tag v0.19.2 triggers the release workflow (native binaries × 5 platforms, Maven Central, CLI JAR, packaged skills, GitHub Release).

🤖 Generated with Claude Code

[claude]

Review: chore(release): Bump version to 0.19.2

Docs/version-only PR, and the prose is good — I spot-checked the CHANGELOG's factual claims against the code and they hold up (shutdownHookTimeout = 2.seconds at xl-cli/src/com/tjclp/xl/cli/Main.scala:107, --parallel at Main.scala:1264, recalculateParallel in WorkbookEvaluator.scala). The "Honest assessment: ~1.0x on measured shapes today" line on wave-parallel recalc is exactly the right register for a release note.

The problem is what the bump left behind. This PR touches 6 files; the 0.19.1 release-prep PR (#489) touched 15. The 9 files it skipped are precisely the ones that still say 0.19.1 today — and one of them will break the release.

🔴 1. The release workflow will fail — after Maven Central publish

plugin/skills/xl-scripting/SKILL.md (6 pins) and plugin/skills/xl-scripting/reference/RECIPES.md (9 pins) still say //> using dep com.tjclp::xl:0.19.1. .github/workflows/release.yml:352-360 gates on exactly this:

if ! grep -rq "com.tjclp::xl:$VERSION" plugin/skills/xl-scripting/SKILL.md plugin/skills/xl-scripting/reference/; then
  echo "::error::xl-scripting skill does not pin com.tjclp::xl:$VERSION — run release-prep version bump"

Both the presence check and the STALE check fail. The damaging part is the ordering: that step (line 346) runs after Publish to Maven Central (line 265) in the same release job. So tagging v0.19.2 as-is would push 0.19.2 to Maven Central — immutable, cannot be re-published — and then abort, leaving no GitHub Release, no native binaries, no packaged skills. Recovery is a 0.19.3 cut, not a re-tag.

Fix this before tagging.

🟠 2. WorkbookMetadata.appVersion still defaults to "0.19.1"

xl-core/src/com/tjclp/xl/workbooks/WorkbookMetadata.scala:38. This flows through DocProps.scala:129 into docProps/app.xml, so every workbook written by 0.19.2 with default metadata stamps <AppVersion>0.19.1</AppVersion>. A wrong provenance value rather than a missing one — in the release whose stated principle is "a missing value is always acceptable, a wrong one never is."

#489 bumped this field, so it is the established contract. No test pins the literal (DocPropsSpec uses "1.0" and round-trip equality), so the bump is safe.

Worth a follow-up issue: this is a hand-maintained duplicate of BuildConfig.version. Deriving it from a generated BuildInfo would delete this failure mode permanently.

🟡 3. Remaining stale pins

File	Pins	Impact
plugin/.claude-plugin/plugin.json:4	1	Marketplace manifest advertises 0.19.1
docs/reference/scripting.md	6	Docs teach a stale dep
xl/src/com/tjclp/xl/scripting.scala:7	1	Scaladoc — ships inside the 0.19.2 javadoc jar telling readers to depend on 0.19.1
examples/project.scala:5, examples/README.md:173	2	scala-cli examples resolve the old release

Correctly left alone: plugin/skills/xl-cli/SKILL.md:118 (the (0.19.1) there is a historical "rule introduced in" annotation), the CHANGELOG/roadmap/LIMITATIONS backreferences, and the New in 0.19.1 STATUS section.

One-liner for the follow-up:

grep -rl "com.tjclp::xl:0.19.1" docs/reference/scripting.md examples plugin/skills/xl-scripting \
  | xargs sed -i 's/com\.tjclp::xl:0\.19\.1/com.tjclp::xl:0.19.2/g'
sed -i 's/"0\.19\.1"/"0.19.2"/' xl-core/src/com/tjclp/xl/workbooks/WorkbookMetadata.scala plugin/.claude-plugin/plugin.json
sed -i 's/xl:0\.19\.1/xl:0.19.2/' xl/src/com/tjclp/xl/scripting.scala examples/README.md

Why CI did not catch any of this

Two structural gaps, both worth closing:

1. skill-verify.yml only triggers on plugin/skills/xl-scripting/** or xl*/src/** — this PR touches neither, so it never ran.
2. Even when it does run, it uses --local, and scripts/verify-skill-snippets.sh:53 rewrites the pin to the local build version before compiling. It structurally cannot see a stale pin. (That is the right design for snippet verification — it just means nothing else is watching.)

So the sole detector is the release-time gate, which fires post-publish. Two cheap improvements:

• Add a version-consistency check to ci.yml: parse BuildConfig.version from build.mill and fail if any tracked file still carries a different com.tjclp::xl:<v> pin or a stale appVersion / plugin.json version. Catches this at PR time instead of at tag time.
• Move the skill version gate to the top of the release job (or into build-native), before Publish to Maven Central. A gate that only fires after an irreversible step is a post-mortem, not a gate.

Nits

• docs/STATUS.md: evaluator: parallel evaluation of independent condensation layers (recalc is single-threaded; container CPUs sit idle) #520 is now described twice — the new bullet 1 ends with "recalc --parallel N ships equivalence-gated (evaluator: parallel evaluation of independent condensation layers (recalc is single-threaded; container CPUs sit idle) #520)" and bullet 4 is the dedicated "Opt-in wave-parallel recalculation (evaluator: parallel evaluation of independent condensation layers (recalc is single-threaded; container CPUs sit idle) #520)" entry. Fold one in.
• CHANGELOG/roadmap now assert "released 2026-08-08" before the tag exists. That date already slipped once (08-06 → 08-08); if the tag does not land today it drifts again.

Summary

Content is accurate and the release notes are unusually honest about the parallel-recalc result. But do not tag v0.19.2 until the xl-scripting pins are bumped — the failure mode is an immutable Maven Central publish followed by an aborted release. Items 2-3 are same-PR cleanups; the CI gate reordering is the durable fix.