hermes - 💡(How to fix) Fix Telegram replies to cron deliveries can revive stale tasks via quoted cron context

Summary

Telegram replies to bot-sent cron deliveries can inject stale cron output into the next live user turn as [Replying to: "..."]. Because cron deliveries are labeled in plain text and cron sessions are discoverable by default recall paths, actionable text from old scheduled jobs can be interpreted as current task context and then preserved by compaction as ## Active Task material.

This is a bug/risk in task selection precedence: the latest authenticated user message should outrank cron delivery text, compaction summaries, todo state, memory notes, proof files, and old assistant summaries. Quoted cron text should be treated as non-authoritative reference, not as live work.

Evidence from current source

• gateway/platforms/telegram.py extracts reply context. It prefers Telegram native quote text, but falls back to full replied-to message text/caption when no partial quote is present.
• gateway/run.py prepends that quote directly to the user message as [Replying to: "..."] with no freshness, author/source, or cron-delivery check.
• cron/scheduler.py wraps scheduled output as Cronjob Response: <name> (job_id: <id>) plus management text. This is human-readable but not machine-distinct from task context.
• cron/scheduler.py also initializes SessionDB for cron jobs so cron messages are persisted and discoverable via recall.
• tools/session_search_tool.py excludes only tool sessions by default, not cron sessions.
• agent/context_compressor.py keeps an ## Active Task section and tells the summarizer to copy the most recent unfinished user request verbatim. If that request includes injected reply text from a cron delivery, the quote can become durable continuity context.
• tools/task_state.py has a conservative classify_latest_user_message() receipt helper, but it does not mutate active tasks and does not appear wired into the Telegram gateway path that builds the live prompt.

Expected behavior

• Cron delivery content should never become the current active task unless the user explicitly asks to resume or act on that scheduled job.
• When a user replies to a cron delivery, the reply quote should be represented as typed metadata, e.g. quoted_message_type=cron_delivery, and marked non-authoritative.
• User-facing recall/session search should exclude cron sessions by default, with an explicit include-cron option for operational debugging.
• Compaction summaries should preserve quoted cron text only as reference evidence and must not copy it into ## Active Task unless the live user text explicitly selects it.

Suggested patch direction

1. In Telegram event handling, classify replied-to bot messages whose text starts with Cronjob Response: or whose metadata indicates scheduled delivery.
2. Inject cron reply context with a non-instructional wrapper such as [Non-authoritative cron delivery quoted for reference only: ...], or suppress it unless the live user text explicitly says to act on that cron job.
3. In session_search_tool.py, add cron to hidden sources by default and expose an explicit include_sources or include_cron option.
4. Strengthen compaction tests so a user turn containing a cron quote plus a correction does not copy the cron quote into ## Active Task.
5. Wire the active-task conflict classifier, or an equivalent invariant, into the gateway path before constructing the LLM prompt.

Regression tests to add

• Latest live user message outranks quoted cron output.
• Replying to a cron delivery cannot make that cron delivery the active task unless explicitly requested.
• Cron sessions are hidden from default recall/search and recent-session listing.
• Compaction marked reference-only cannot promote quoted cron text into ## Active Task.
• Completed todo/tombstone narrative cannot revive as active work.

No secrets, raw configs, or private credentials are included here. This report is based on source inspection and sanitized local runtime evidence.