Prevent stale UI assets after BUS Core updates

[truegoodcraft]

Objective

Prevent BUS Core users from running stale frontend/UI code after an update.

A recent beta bug appeared to still be broken after the fix was deployed because the browser cached old UI JavaScript. A hard refresh cleared the issue, but users should not need to know or do that after normal BUS Core updates.

Background

BUS Core serves a local SPA UI through the browser. When BUS Core updates, the backend/runtime may be current while the browser can still serve cached versions of frontend assets such as app.js or UI card modules.

This can create false bug reports, confusing update behavior, and support friction.

Scope

Implement a cache-busting strategy for BUS Core UI assets so new releases reliably load the current frontend code.

Possible approaches:

• Version query strings on JS/CSS assets using the app release version.
• Hashed/static asset filenames during build.
• No-cache headers for local UI assets where appropriate.
• A lightweight UI asset version constant tied to core/version.py.
• Automatic update of referenced UI asset URLs during build/release.

Requirements

• Normal browser refresh after a BUS Core update should load current UI assets.
• Users should not need to hard refresh, clear cache, or use DevTools.
• Cache-busting must apply to main UI entry assets such as:
  • app.js
  • major UI modules/cards
  • CSS if needed
• The solution should be automatic during version/build/release flow.
• Do not break local-first runtime behavior.
• Do not introduce external CDN dependencies.
• Do not add telemetry or remote asset loading.
• Keep behavior compatible with native Windows and Docker deployments.

Acceptance Criteria

• After a version bump/update, browser requests current UI JS/CSS assets.
• Old cached frontend code is not used after normal update/restart.
• Manual smoke confirms a previously loaded browser session receives updated UI code after release update.
• Dev mode remains convenient and does not require excessive rebuild steps.
• Release/build process documents or automates the asset versioning step.
• Regression or static test verifies the main UI asset reference includes a version/cache-busting mechanism.

Risk Notes

Main risks:

• Over-aggressive no-cache behavior could hurt normal UI loading.
• Partial cache-busting could fix app.js but leave imported modules stale.
• Version source drift could occur if UI asset versioning is not tied to the canonical release version.
• Docker and native Windows may serve assets slightly differently, so both paths should be checked.

Definition of Done

This issue is complete when BUS Core can be updated and restarted without users needing to hard refresh the browser to get the current UI code.