chore(inbox): park lint-org and telegram fixes from home and .emacs.d

1 files changed, 35 insertions, 0 deletions

diff --git a/todo.org b/todo.org
index 023f991..8c1a4f1 100644
--- a/todo.org
+++ b/todo.org
@@ -93,6 +93,41 @@ Since Craig already made this call, the remaining decision is only adoption scop
 
 Prepared: [[file:working/hook-fail-open/validate-el.diff]], plus =test-validate-el-hook.bats= (6 tests, two of which stage a deliberately failing test so a quiet pass proves the run happened).
 
+** TODO [#C] lint-org invalid-block false-positives inside example/src blocks :bug:solo:
+:PROPERTIES:
+:LAST_REVIEWED: 2026-07-24
+:END:
+home reported it, and I verified it: an =#+begin_example= block whose body contains a line beginning =** = (or any heading-shaped line) makes =invalid-block= flag *both* delimiters as "Possible incomplete block", even though the block is correctly paired. The checker reads the heading line inside the verbatim body as a structural break and loses the open block.
+
+Reproduced 2026-07-24 on a three-line example block: 2 judgment findings, both false. This is a docs-file-common shape — any org file documenting org syntax inside an example block hits it (home's notes.org PENDING DECISIONS section does).
+
+*This is the root cause behind a workaround I already shipped.* During fire 1 last night I comma-escaped exactly this =** Feature Name= line in =claude-templates/.ai/notes.org= to silence the two findings. That fixed the symptom in one file; the checker bug it worked around is still live and recurs everywhere. Fixing the checker lets that escape be reverted.
+
+Grading: Minor severity (judgment output, nothing mutates; pure noise that trains the reader to skim) x most users, frequently (every org file documenting org syntax in a verbatim block) = P3 = [#C].
+
+Fix direction (per home): while inside a =begin_example= / =begin_src= block, skip structural parsing of the body until the matching =#+end_= line — verbatim blocks contain no headings, timestamps, or delimiters by definition. The same class hits a src block containing =#+end_example= as literal text. Open question to settle at fix time: is =invalid-block= lint-org.el's own checker (fix in place) or org-lint's own (filter its output)? =link-to-local-file= turned out to be org-lint's; this one needs the same determination before the approach is chosen. Tagged :solo: because once that's known the fix and its test are mechanical.
+
+** VERIFY [#B] Parked: telegram source treats "down" as launch, not SCAN FAILED (from .emacs.d)
+:PROPERTIES:
+:LAST_REVIEWED: 2026-07-24
+:END:
+What arrived: a superseding handoff (the 17:23 setq-only version is retained as context but not the one to take). Both work and home independently hit the same failure — the telegram source, finding telega down or unloaded (its *normal* entry state), reported "SCAN FAILED: telegram — not loaded" or ran a blind sweep, instead of running Step 1 to launch it. Neither hit a segfault. The recovery IS Step 1: =(telega t)= both loads the package and starts the docker server.
+
+Root cause is wording, not code: the Quick Reference said "never skips because the server is down" but the closing paragraph said "if any lifecycle step fails ... reports SCAN FAILED", and two agents conflated "server is down" with "a lifecycle step failed" → blind sweep without ever attempting the launch.
+
+The fix (33-line diff, verified present): a directive after the Quick Reference that down/not-loaded is the *trigger* to launch, never a skip; the =:ENABLED:= guard tests whether telega is *installed* (=fboundp=), not whether the server is up; SCAN FAILED reserved for a launch that was attempted and didn't reach Ready; a note that a blind sweep is worse than a clean failure because it hides real unread behind a false all-clear. Also keeps the earlier =(setq telega-use-docker t)= segfault guard in Step 1 — both projects confirmed it's a real latent guard though not the cause here.
+
+Recommendation: accept the superseding version. The wording defect is real and reproduced by two projects, and a triage source silently reporting all-clear on a mailbox it never scanned is exactly the false-negative class that matters.
+
+Prepared: [[file:working/triage-telegram-down-launch/proposed.diff]] and the full proposed file beside it.
+Say "approve the parked telegram fix" and it gets applied.
+
+*** VERIFY a SCAN FAILED source must not advance its sentinel (engine, not the plugin)
+:PROPERTIES:
+:LAST_REVIEWED: 2026-07-24
+:END:
+Secondary finding from the same handoff, flagged for your judgment because it's *engine* behavior in =triage-intake.org=, not the telegram plugin. work reported that after a SCAN FAILED, "the marker still advanced" — and telegram is =:ANCHOR: none=, so something advanced a cursor it shouldn't have. The compounding harm: a source that reports SCAN FAILED but advances its window means the next sweep believes it already covered that window, so the blind-sweep hole persists across sweeps rather than self-healing. Not touched .emacs.d-side; needs a look at the engine's per-source last-run/anchor advance.
+
 ** TODO [#B] cj-remove-block still can delete the WRONG cj block :bug:
 :PROPERTIES:
 :LAST_REVIEWED: 2026-07-24