Incident (2026-09-19)
#1245 (SessionStreamVeil accessor — blanking on tab switch / send / new session) was merged to main on Sep 16. But in fleet-client posture the webview loads the app served by the hub's binary (no local service boots; frameUrl() resolves the tunnel engine origin), and the deployed hub binary predates the fix — so every fleet client got the blank-panel bug from the hub's embedded SPA, with no code path for main's app fixes to reach them. No fork release since Sep 16 carries the fix either, so even a release-based hub refresh wouldn't have helped today.
App fixes reach local/standalone users via main builds; fleet clients only via hub binary rebuilds. The two paths have drifted by a full week of app fixes already.
Ask
Pick one (or both):
- Serve the app dist separately on the hub (the way the local shelf does — the amicode app dist exists and is built independently) so app fixes deploy without binary rebuilds; the hub serves its embedded SPA only as a fallback.
- A hub binary refresh pipeline that tracks main's app fixes (or at least: a check that flags when the deployed hub's embedded app is older than the app fixes users depend on).
Mitigation shipped locally (today, erlich)
The frontdoor now rewrites the served JS in flight: content-hashed asset URLs are immutable, so it fetches each .js asset once from the backend, applies the same-length substitution (degraded:{streamGap()} → the accessor), and caches the patched response for the process lifetime (~/.amico/server/hub-frontdoor.py, backup .bak-pre-veilfix). That fixed the whole fleet in one restart — but it is a band-aid over the structural gap, and it must be REMOVED when the hub binary carries the fix (the rewrite logs its substitution count; zero hits = remove).
Related
Incident (2026-09-19)
#1245 (SessionStreamVeil accessor — blanking on tab switch / send / new session) was merged to main on Sep 16. But in fleet-client posture the webview loads the app served by the hub's binary (no local service boots;
frameUrl()resolves the tunnel engine origin), and the deployed hub binary predates the fix — so every fleet client got the blank-panel bug from the hub's embedded SPA, with no code path for main's app fixes to reach them. No fork release since Sep 16 carries the fix either, so even a release-based hub refresh wouldn't have helped today.App fixes reach local/standalone users via main builds; fleet clients only via hub binary rebuilds. The two paths have drifted by a full week of app fixes already.
Ask
Pick one (or both):
Mitigation shipped locally (today, erlich)
The frontdoor now rewrites the served JS in flight: content-hashed asset URLs are immutable, so it fetches each
.jsasset once from the backend, applies the same-length substitution (degraded:{streamGap()}→ the accessor), and caches the patched response for the process lifetime (~/.amico/server/hub-frontdoor.py, backup.bak-pre-veilfix). That fixed the whole fleet in one restart — but it is a band-aid over the structural gap, and it must be REMOVED when the hub binary carries the fix (the rewrite logs its substitution count; zero hits = remove).Related