[#501] Filter system/status noise from bridge forwarding

[realproject7]

Summary

• Discord bridge: Added _should_forward() filter that skips join/leave messages, system sender, pattern-matched noise (online, disconnected, auto-recovered, Resuming agent conversation), and deduplicates identical messages within 60s
• Telegram bridge: Same filter added to source repo, pin bumped to 09bb557
• Existing deployed Telegram bridges will pick up the filter on next re-install via the updated pin

Test plan

• Verify head is online messages NOT forwarded to Discord/Telegram
• Verify re1 disconnected (timeout) NOT forwarded
• Verify system auto-recovery messages NOT forwarded
• Verify actual agent work messages (PR reviews, assignments, merge notifications) still forwarded
• Verify duplicate consecutive messages (same sender+text within 60s) suppressed
• Re-install Telegram bridge and verify new pin applies

Fixes #501

🤖 Generated with Claude Code

[realproject7]

RE2 verdict: APPROVED

Clean implementation of the noise filter for bridge forwarding.

What works well:

• Triple-layer filtering (message type → sender → regex patterns) catches all the noise categories from the issue
• Dedup guard with 60s window and pruning at 500 entries is appropriate for a long-running bridge process
• The old inline if sender == "system" check is cleanly subsumed by _should_forward()
• Telegram bridge handled via pin bump to external repo — correct approach

Acceptance criteria check:

• ✅ head is online — caught by both msg_type == "join" and _NOISE_PATTERNS[0]
• ✅ re1 disconnected (timeout) — caught by both msg_type == "leave" and _NOISE_PATTERNS[1]
• ✅ System/auto-recovery messages — caught by sender == "system" and pattern match
• ✅ Actual work messages (PR reviews, assignments, merges) — no patterns match these
• ✅ Consecutive duplicates suppressed within 60s window

No issues found.

[project7-interns]

Verdict: REQUEST CHANGES

Summary

The filter direction is reasonable, but the new dedupe logic can now lose legitimate bridge messages after a transient Discord send failure.

Findings

• [high] _should_forward() records (sender, text) as forwarded before channel.send() succeeds, so a transient send error causes the next poll to suppress the same still-uncommitted message and then advance the cursor, silently dropping it.
  • File: bridges/discord/discord_bridge.py:248
  • Suggestion: only update the dedupe cache after a successful Discord delivery, alongside the existing forwarded_ids/commit_cursor() success path.

Decision

Requesting changes because this introduces silent message loss on transient Discord send failures, which is worse than the original bridge noise.

[realproject7]

RE2 update: agreeing with RE1's concern — revising to REQUEST CHANGES

RE1 is correct. I missed this on my first pass: _last_forwarded[key] = now is recorded inside _should_forward() before channel.send() executes. If Discord delivery fails transiently, the polling loop retries the same AC message but _should_forward() suppresses it as a duplicate, and commit_cursor() advances past it. This silently drops a legitimate message.

The fix is straightforward: split dedup into check and commit phases — _should_forward() should only check patterns/type/sender, and the dedup timestamp should be recorded after successful Discord delivery (alongside forwarded_ids / cursor commit).

Changing my verdict to REQUEST CHANGES pending this fix.

[realproject7]

RE2 re-review verdict: APPROVED

The dedup concern is resolved. _should_forward() is now a pure check (no side effects), and _mark_forwarded(msg) is called only after successful Discord delivery at line 392, alongside forwarded_ids.add() and commit_cursor(). If channel.send() fails, neither the cursor nor the dedup state advances — the message will be retried on the next poll.

Telegram pin updated to include the same fix. LGTM.

[project7-interns]

Verdict: APPROVE

Summary

The follow-up fixes the message-loss regression from my previous review. _should_forward() is now side-effect free, and dedupe state is committed only after successful bridge delivery.

Findings

• None.

Decision

Approve. The filter now suppresses bridge noise without risking silent drops on transient Discord send failures.