fix(slack-agent): give the bot the whole thread, alert cards included

[JeremyFunk]

Replying to a Maple alert in Slack meant hand-writing a recap first — the agent reached the model with no context at all. Two eve behaviours stacked:

1. Content comes from text alone. Our alert notifications have none: the blocks ride inside a colored attachment (AlertDeliveryDispatch.ts — top-level text would render as a duplicate line above the color bar). eve rendered the alert as an empty <content></content>.
2. since: "last-agent-reply" counted that alert as the agent's own reply (eve's isMe is bot_id !== undefined, i.e. any bot) and cut context off after it, dropping the alert and everything before. Any third-party app in the channel truncated context the same way.

Changes

• agent/lib/thread-context.ts — renders turn context ourselves in eve's same <slack_thread_context> / <slack_message> envelope, with content falling back to top-level blocks → attachment blocks → attachment fallback. Covers header/section/fields/actions (buttons emit label: url, so the incident link survives)/context/rich_text/markdown/image, plus a generic text sweep for block types it has no case for. Boundary is the full thread, which also survives a session lost to a redeploy — where an incremental boundary silently assumes history that is gone.
• agent/lib/bot-identity.ts — learns the workspace's bot user id from each verified webhook's authorizations (free, no auth.test), so the agent's own replies are agent and alert cards / other apps are bot. The model no longer reads an alert as something it already reported. thread-follow-up.ts now shares its envelope parser.
• agent/channels/slack.ts — threadContext replaced by onAppMention / onDirectMessage that do exactly what eve's defaults did (typing indicator + defaultSlackAuth) plus return the transcript as context. Runs after eve's 200 to Slack, so it is off the webhook budget, and it cannot throw: eve drops the whole mention when that handler does, so a Slack failure degrades to no context instead of no reply.
• agent/instructions.md — read the thread context, never ask the user to restate it, and treat an opening alert card as the subject (load the incident-investigation skill).
• README — layout table, the parity bullet that already claimed alert context comes from the thread, and a Notes entry on why we do not use slackChannel({ threadContext }).

Verification

bun test 188 pass (15 new: alert-card rendering, rich-text paragraphs, attribution, load path), bun typecheck clean, oxfmt/oxlint applied. Verified against eve's compiled channel code, not a live workspace — the end-to-end check is the README's acceptance item (c): @mention in a real alert-notification thread.

Two bounds documented rather than silently widened: eve's thread.refresh() fetches one oldest-first page of 50 replies, and an un-mentioned reply still needs the 30-minute engagement window in thread-follow-up.ts.

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[github-actions]

🍁 Maple PR preview

Note

Preview resources were removed when this pull request closed.

Final commit 7fcc695 · View workflow run