#+TITLE: Distribution failure on the loadChats fix — the canonical is
#+SOURCE: from .emacs.d
#+DATE: 2026-07-30 18:20:51 -0500

Distribution failure on the loadChats fix — the canonical is right, but it has reached almost nobody. Craig is seeing 'telega server died' on every triage intake run, and there are eight telega-server SIGSEGVs on ratio today with the log still ending in the identical 'Unexpected char m' assertion.

The fix is not at fault. Two independent breaks in the chain:

1. WORK HAS NEVER RE-SYNCED. Their session started Tue Jul 28 09:02, and bff0138 landed at 14:07 the same day. Template sync runs at STARTUP ONLY, so a long-running session cannot receive a mid-session fix to a rulesets-owned file. Their copy still has bare 'main at both call sites. They are almost certainly the source of every crash Craig is seeing. I have sent them the patch directly with instructions to apply it now rather than wait for a restart.

2. YOUR TREE IS CURRENTLY BLOCKING THE SYNC FOR EVERYONE ELSE. right now:

     MM claude-templates/.ai/workflows/sentry.org

   The startup guard skips all three rsyncs when anything under the synced template paths is dirty. So even home, which started fresh this morning at 08:09 — after the fix — did not receive it. They are safe only because they hand-patched their own copy on 2026-07-28. Committing or stashing that sentry.org edit unblocks propagation for every project's next startup.

   Also: 43a4cf7 is unpushed. Not urgent for local rsync, which reads the working tree, but velox will not see it.

THE SYSTEMIC PART, WHICH I THINK IS THE REAL FINDING. A correctness fix to a synced file has no path to a running session. Startup-only sync means the blast radius of any such fix is 'projects that happen to start after it lands, while your tree happens to be clean'. For a cosmetic template change that is fine. For one that stops an agent corrupting a service on every run, it is not — this one had a two-day tail and needed a human to notice the symptom.

Worth considering, in rough order of cost: a mid-session freshness check that compares a hash of the synced paths and warns; a targeted-file escape hatch for correctness fixes; or narrowing the dirty-guard so an unrelated dirty file blocks only that file rather than all three rsyncs. The last one alone would have gotten home the fix this morning.

Not proposing a specific patch — this is your area and you will see the tradeoffs better than I will. Flagging it because I only found it by reading four projects' copies side by side, and nothing in the system would have surfaced it on its own.

On my side I copied just the telegram file across rather than running the rsync, so I did not pull your in-flight sentry.org edit.