Investigate standup cron chatty-trailer leak to D0ATM82H3T8 (3 consecutive days of post-standup self-narration)
completedAgent: stefan-engineer
Priority: 3
Per LEARNINGS.md 2026-06-05. Standup cron has been posting a SECOND message to D0ATM82H3T8 ~4-6s after the standup body, three days in a row. The trailer is the model's post-tool-call self-narration leaking through the channel binding. The standup body itself is correct on all three days.
Leaked trailing messages (exact Slack ts values from D0ATM82H3T8 read 2026-06-05 04:50 UTC):
- 2026-06-02 14:30:57 UTC (ts=1780410657.860419): "Perfect! The standup has been successfully sent to Stefan's DM channel (D0ATM82H3T8) at timestamp 1780410651.643179 and written to the standups file. The delivery worked correctly..."
- 2026-06-03 14:30:49 UTC (ts=1780497049.961289): near-identical "Perfect! The standup has been sent successfully..."
- 2026-06-04 14:30:52 UTC (ts=1780583452.812449): "I'll gather all the standup data silently, then compose the complete report."
DO THIS:
1. Pull the standup cron session jsonl files for 2026-06-02/03/04 from ~/.openclaw/agents/stefan-engineer/sessions/. Find each session by matching label='Cron: Daily Standup (Molly)' in sessions.json and the 14:30 UTC timestamp. Session ids known to date: d967e878 (6/3), 1780583400016->lookup (6/4).
2. Inspect each session's final assistant turn. Determine whether the trailing text is (a) emitted by the model AFTER the message:send tool call returns, then auto-delivered by the channel binding as a second Slack message; or (b) some other path.
3. Cross-reference: heartbeat sessions for stefan-engineer also call message:send (status reactions) and do NOT produce trailing Slack messages. What's different about the standup cron prompt or its delivery configuration?
4. Once root cause is known, choose fix at the right layer:
- If cron prompt allows trailing text -> propose to Victor: append explicit NO_REPLY-style end-turn directive to standup cron template. Don't edit local AGENTS.md, the cron doesn't read it.
- If channel auto-delivery binding is flushing trailing assistant text -> Victor's fleet-runtime territory, propose via DM (bundle with June 6 batch).
- If model is emitting narration despite directives -> propose stronger directive in shared/local files where the cron actually reads them.
5. Either land the fix proposal or write a measured "accept the noise" entry in LEARNINGS.md with reasoning. Per May 18 indecisive-defer rule, no third week of journaling.
P3, 14-day cap. Not a fire; cost is ~3 extra benign Slack messages per day. But it's the second standup-delivery quality regression in 5 weeks (May 29 misroute was first), and the May 30 lesson 'read the receiving channel, not just the tool result' applies. The investigation belongs in a coding-shaped session, not heartbeat time.
SEE: LEARNINGS.md 2026-06-05 (this entry), LEARNINGS.md 2026-05-30 (May 29 misroute), LEARNINGS.md 2026-05-07 (blast-radius rule), LEARNINGS.md 2026-05-18 (indecisive-defer rule).
Event Timeline
created
status_change
queued → in_progress
status_change
in_progress → completed