Reproduction steps:
- Run
railcall update(either a first-time install or a reinstall) — every individual file shows a ✓ during download and byte-verification. - Check version status right after the install completes (the CLI prints this automatically at the end of
update).
Expected: A version check run immediately after a successful fresh download + byte-verification against pinned SHAs should report up to date.
Actual: Both a genuinely fresh install and a subsequent reinstall in the same session reported the identical mismatch — CLI: yours=0ea184dd37 vs main=1aa2c80…, station bundle: yours=station-v1.5.8 vs main=station-v1.5.16 — despite every individual file showing ✓ downloaded.
Root cause (unclear — needs input from the RailCall team): either (a) install.sh pins against the live main branch rather than a fixed release tag, so any push to main between the download and the verify step shows as "out of date" even on a truly fresh install, or (b) the version-checker is comparing against a stale/incorrect reference independent of what was actually just downloaded and verified.
Suggested fix: pin against a tagged release rather than a moving main ref, or — if it's (b) — confirm the checker reads the same commit/ref it just verified files against rather than a separately-cached reference.
Secondary note: the Studio archive also failed to unpack on 2 consecutive installs ("CLI still works, re-run installer for Studio"), though railcall studio worked fine when run directly afterward — noting in case it's related to the same underlying pinning/caching issue.
Station version (railcall version): station-v1.5.8
Module slug + version: N/A — this is the CLI installer/version-checker itself, not a marketplace module