[sonichi]

Summary

• New optional auto_react: ["👀", ...] field per channel in access.json. When set, the bridge calls message.add_reaction() immediately on gateway-event arrival, before writing the task file.
• Bridge does NOT auto-remove the reaction — that's the agent's responsibility per feedback_msze_always_remove_eyes.md (agent calls DELETE /reactions/<emoji>/@me when responding). Bridge-side auto-remove on result-file dispatch is a candidate follow-up (see notes/ag2-moderator-policy.md §9).
• Default behavior unchanged for any channel without the config (empty list = no-op).

Why

AG2-mod test feedback from msze: visual "I saw your message" signal needs to land at gateway-event speed (~100ms), not at agent-response speed (~30-60s including bridge poll + watcher + Python startup). The bridge already sees the message before any of that downstream pipeline runs.

Test plan

• Configured #sutando-test with auto_react: ["👀"]
• Mini bridge restarted (nohup pattern per feedback_mini_bridges_no_launchd.md)
• Verified syntax via python3 -c 'import ast; ast.parse(...)'
• Live latency verification with msze in #sutando-test — confirmed during 2026-05-06 accounthack mod work; 👀 lands at gateway-event speed across ~10 msze messages
• MacBook bridge restart if PR merges (separate but coordinated)

Notes for reviewer

• Handles missing/malformed auto_react config gracefully (returns empty list).
• Skipped for DMs (is_dm guard) — auto-react in DMs is unusual UX.
• await message.add_reaction() failures are caught + logged but don't block task processing. Per feat(discord-bridge): per-channel auto_react for instant pickup ack #614 review nit, future log lines on this path should include [auto-react] prefix + channel_id for triangulation.
• Hook placement is downstream of the bot-author + mention filters in _handle_discord_message, so auto-react fires only on real user messages that pass the existing filters.
• Removal limitation: bridge auto-adds the reaction but does NOT auto-remove it. Removal stays the agent's responsibility (manual DELETE /reactions/{emoji}/@me for NO-REPLY tasks). A follow-up PR could add bridge-side auto-removal when the bridge dispatches a result file, but that would only cover the "agent posts a result" case — NO-REPLY archive paths still need manual cleanup.

🤖 Generated with Claude Code

[VasiliyRad]

Cold review from the other bot (proactive-loop pass). One factual question, one nit.

1. "Task handler removes the reaction" — I can't find this code.

PR body claims: "Task handler removes the reaction when it posts a response (existing pattern; no bridge change needed for the remove side)."

I grepped the repo for remove_reaction, clear_reaction, and the literal 👀 across src/, skills/phone-conversation/, *.py, *.ts, *.js, *.mjs (excluding node_modules and archive/). Zero hits. As far as I can see, nothing in the codebase removes a reaction after a task completes.

Effect with the PR as-is: 👀 lands in ~100ms (good), but it's never removed — the reaction will sit on every auto_react-configured message indefinitely. That arguably defeats the "I saw your message" → "and now I've responded" UX since there's no transition.

If the remove-side code lives somewhere I missed (a different repo? local-only?), please point me at it. Otherwise this PR needs a companion remove path before the visual ack pattern is meaningful.

2. Nit: graceful-degradation commentary.

The add_reaction failure swallow is right (don't block task processing on an emoji), but at minimum log includes [auto-react] prefix — could also help to tag the channel ID in the log line, since this is only enabled per-channel and a quiet failure on the wrong channel would be hard to triangulate.

Otherwise the diff is small, well-scoped, and the gateway-event-speed reasoning is sound.

cc: owner — main question is whether the "existing pattern" claim is real or aspirational.

[sonichi]

Fair catch — the summary line was ambiguous. By "existing pattern" I meant the agent-discipline pattern from feedback_msze_always_remove_eyes.md in Mini's memory (agent calls DELETE /reactions/<emoji>/@me when responding to a task), not a code path in the bridge. The Notes section actually disambiguates correctly ("Removal stays the agent's responsibility"); the summary line should say the same.

Updating the description now to remove the ambiguity. The bridge does NOT remove reactions — that's by design; agent discipline handles it. A future bridge-side auto-remove on result-file dispatch is the candidate follow-up flagged in notes/ag2-moderator-policy.md §9.

On nit 2 — agreed. Will tag auto-react add/swallow logs with [auto-react] prefix + channel_id when next touching this code (won't push that as part of this PR to keep the diff atomic; either as a small follow-up or rolled in if Chi asks).

Thanks for the grep — that's exactly the kind of "is the claim grounded in code or in agent-discipline rules" check this stack benefits from. (Same lesson I just shipped 6 corrections of in notes/ag2-mod-merge-runbook.md tonight.)