Frontend has no version: the cited 1.1.5 exists only in CLAUDE.md #469

Problem

The web frontend has no version at all — not an automated one, not a manually bumped one. The number we cite as "the frontend version" exists only in an agent-instructions file and corresponds to nothing that ships.

What is actually true today

1.1.5 appears nowhere in this repository — not in a package.json, a source file, the docs, or a workflow. It lives in the suite-level CLAUDE.md, which is outside the repo and hand-maintained. The only in-repo matches for that string are an unrelated @napi-rs/wasm-runtime entry in pnpm-lock.yaml.

Nothing surfaces a version in the UI either: there is no APP_VERSION, __APP_VERSION__, import.meta.env.*VERSION, or pkg.version reference anywhere in apps/web/src or packages/core/src.

Why this is not the same as the PyPI pipeline

The Python package is fine and should not be touched. .github/workflows/protspace-release.yml is path-gated to apps/protspace/** and is working exactly as designed — v4.11.2 matches pyproject.toml precisely.

The frontend is continuously deployed instead: deploy.yml fires on any push to main outside apps/protspace/** and apps/prep/**, rebuilding GitHub Pages. So the site always reflects main, and there is no artifact carrying an identifier.

This came up while merging #460 — asking "will this cut a release?" surfaced that the answer for the frontend is "there is no such thing", which is a reasonable choice but currently an undocumented and slightly misdescribed one.

Why it matters

• Bug reports are unanchorable. A user reporting a rendering problem cannot tell us which build they saw, and we cannot ask. With a rolling deploy and no identifier, "it broke sometime last week" is the best anyone can do.
• The published paper points at a moving target. The web-server preprint describes a site whose behaviour changes with every merge, with nothing citable.
• CLAUDE.md currently misinforms. Any agent or contributor reading it believes there is a 1.1.5 to reason about. It is stale in a way that cannot be detected, because it is not derived from anything.

Options

1. Do nothing, but stop claiming a version. Remove the Version: 1.1.5 line from the suite CLAUDE.md and state that the frontend is continuously deployed. Zero cost, removes the misinformation, keeps the gap.
2. Surface the build without versioning it. Inject the short commit SHA and build date at build time and show it in the About/footer. Makes any deployed build identifiable and bug reports anchorable, without adopting a release cadence. Cheapest option that solves the real problem.
3. Version the frontend properly. Extend semantic-release with a second, path-scoped configuration for apps/web/** + packages/**, tagged distinctly from the Python package (e.g. web-v1.2.0) so the two version lines cannot collide. Most work, and worth it only if we actually want a frontend changelog.

Recommendation

Option 2, plus the CLAUDE.md correction from option 1. The concrete pain is "which build is the user on", which a SHA solves completely; a semver line for a continuously deployed site mostly invents bookkeeping. Option 3 stays open if a frontend changelog is later wanted.

Deliberately not doing option 3 by default: adding a second semantic-release configuration to a repo whose per-commit path scoping is already load-bearing (squash-merging is disabled repo-wide precisely to protect it — see #387 → v4.9.1) is a change that deserves its own design, not a drive-by.

Notes

• Whatever we pick, the suite CLAUDE.md line must change — it is wrong today under every option.
• No urgency; nothing is broken. This is a traceability and documentation-accuracy gap.