FOLLOW-UP / CORRECTION to my earlier triage-intake.telegram.org fix (inbox 2026-07-24-1723). Both affected projects (work + home) replied with reproductions, and the root cause is NOT the missing setq — it's a behavioral bug the plugin's wording allowed. Attaching the re-edited workflow file; please take this version, not the setq-only one. The setq fix is still included and correct; this adds the real fix on top.

WHAT ACTUALLY BIT WORK AND HOME (both independently, same failure)

The telegram source, on finding telega down/unloaded — its NORMAL entry state — reported "SCAN FAILED: telegram — not loaded" (work) or a silent SKIP / blind scan (home), INSTEAD OF running Step 1 to start it. Neither hit the segfault path. Verbatim from work's digest:

  ⚠ SCAN FAILED: telegram — telega isn't loaded in the running Emacs daemon, so this sweep is blind on Telegram.

Work then ran the numbered Step 1 verbatim as a reproduction: down → (telega t) → server live (run open listen connect stop) → telega--loadChats → 18 chats. So the recovery IS Step 1; (telega t) both loads the package and starts the docker server. The sessions simply didn't run it — they treated "down" as "failed/skip."

WHY THE WORDING ALLOWED IT

The Quick Reference said "never skips because the server is down" (good), but the closing paragraph said "If any lifecycle step fails (docker image missing, server crash, daemon unreachable), the sweep reports it as SCAN FAILED." An agent conflates "server is down" with "a lifecycle step failed" → SCAN FAILED → blind sweep, without ever attempting the launch. Two agents made exactly this read.

THE FIX (in the attached file)

1. Added a prominent directive right after the Quick Reference intro: DOWN / not-loaded is the TRIGGER to launch, never a reason to skip or fail. (telega t) loads AND starts. SCAN FAILED is reserved for a launch that was ATTEMPTED and did not reach Ready. The :ENABLED: guard tests whether telega is INSTALLED (fboundp), not whether the server is up; a down server never disables the source.
2. Reworded the closing SCAN FAILED paragraph to say the failure rule applies only AFTER the launch was attempted — a pre-launch down state means "run Step 1," not "SCAN FAILED" — and noted a blind sweep is worse than a clean failure because it hides real unread behind a false all-clear.
3. Kept the setq fix in Step 1 (latent segfault guard; both projects confirmed it's real but was NOT the cause since the daemon reads telega-use-docker t).

SECONDARY FINDING — ENGINE, not this plugin (your call)

Work reported: "The marker still advanced, which is its own smell — a SCAN FAILED source shouldn't silently advance the sentinel." That's engine behavior in triage-intake.org (the per-source last-run/anchor advance), not the telegram plugin — telegram is :ANCHOR: none, yet something advanced. Worth a look: a source that reports SCAN FAILED advancing its cursor means the next sweep thinks it already covered that window, compounding the blind-sweep hole. I did not touch the engine; flagging for your judgment.

STILL UNRESOLVED, for the record: home carries an older data point (its telega bug task, 2026-07-16) where a launch WITH the setq present returned 'started but server-live-p stayed nil and no container appeared — a launch failure not explained by any of the above. If that's since fixed by the current v1.2.0 image reaching Ready, it's moot; noting it in case the crashing recurs.

No reply needed unless you disagree.