fix(slack): prevent thread parent edit replays

[nahyeongjin1]

What does this PR do?

Slack can emit message_changed for an existing thread parent. In the incident that motivated this follow-up, the Slack thread contained a root text edit but no new user reply; the adapter normalized that edit as fresh inbound input when the root timestamp was absent from the process-local _processed_message_ts set.

A missing in-memory timestamp does not prove that the root was never delivered. Replaying an already-addressed parent can therefore create a phantom user turn from instructions the agent already acted on.

This PR now handles both replay classes before message normalization:

• filters metadata-only parent updates without suppressing proven visible text, block, attachment, or file additions/removals
• detects replied parents whose pre-edit snapshot already addressed this workspace's bot by mention, Block Kit, or configured wake pattern
• suppresses later edits of those addressed parents even if the mention is removed or the current payload is malformed
• routes a newly added mention exactly once only when the previous snapshot reliably proves that the bot was not addressed
• fails closed when the current edit addresses the bot but previous_message is missing, partial, or malformed
• preserves existing visible-edit routing when there is no bot-address evidence, and preserves edits with no reply evidence
• validates reply evidence and traversed Block Kit shapes before using them as proof
• resolves one workspace-local bot identity, with the edited message's team used only as a fallback when the outer event has none

Users who want revised parent text acted on can send a new thread reply. The adapter does not synthesize one and does not add durable session infrastructure.

Related Issue

N/A — reproduced from a live Slack Socket Mode event sequence and covered by regression tests.

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• plugins/platforms/slack/adapter.py
  • classifies visible parent edits before normalization
  • validates thread-reply evidence
  • derives a tri-state pre-edit bot-address result from trusted text and Block Kit data
  • blocks answered-parent replays while preserving proven absent-to-present mention transitions
  • keeps workspace bot identity scoped to the event team
• tests/gateway/test_slack.py
  • covers cold process state, repeated edits, mention and wake-word removal, malformed current and previous payloads, nested Block Kit corruption, valid Block Kit transitions, malformed/valid reply evidence, multi-workspace identity, and preserved visible-edit paths

How to Test

scripts/run_tests.sh tests/gateway/test_slack.py -q
ruff check plugins/platforms/slack/adapter.py tests/gateway/test_slack.py
python -m py_compile plugins/platforms/slack/adapter.py tests/gateway/test_slack.py
git diff --check

The broader Slack run dynamically resolves every tests/**/*slack*.py file and passes all 33 files.

Verification

• focused parent-edit/proof regressions: 26 passed
• tests/gateway/test_slack.py: 260 passed
• all dynamically resolved Slack test files: 33 files, 476 passed
• Ruff check: passed
• py_compile: passed
• git diff --check: passed
• fresh read-only exact-diff review: no blocking findings
• current upstream main conflict probe: clean; no relevant overlap since the reviewed target snapshot

A local canonical full-run attempt did not pass: it reported 73 non-Slack test failures and 10 collection/import failures. No Slack test failed in that run, and the full-suite checklist remains unchecked. Upstream Actions remain the authority for the repository-wide and cross-platform result.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes
• I've tested on my platform: macOS 26.3.1

Documentation & Housekeeping

• I've updated relevant documentation — N/A; internal Slack event filtering only
• I've updated cli-config.yaml.example if I added/changed config keys — N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — N/A
• I've considered cross-platform impact — platform-independent Python event handling
• I've updated tool descriptions/schemas if I changed tool behavior — N/A

Screenshots / Logs

The regression tests model sanitized Slack envelopes directly; no workspace-specific logs or identifiers are included.

[teknium1]

Thanks for isolating a real Slack ingress replay path. Current main still normalizes every message_changed event at plugins/platforms/slack/adapter.py:5251-5283, so filtering metadata-only parent updates is worthwhile.

Problems

• The new classifier can drop a real visible removal. In the PR at plugins/platforms/slack/adapter.py:5284, a prior non-empty attachments/files/blocks value and an omitted current value is marked unknown, not changed. If reply metadata also changes, the return at the new reply-metadata guard suppresses the event. Treat a formerly non-empty visible field becoming missing/empty as a visible change, and add coverage for that case.
• The test hunk is stale: its anchor was removed by 6b81590c55 from tests/gateway/test_slack.py; GitHub currently marks the branch DIRTY.

Suggested changes

• Preserve visible field removals, then relocate the focused regressions into current test structure.

Automated hermes-sweeper review.

[0xble]

I opened #83501 as a deliberately narrower, current-main alternative for the metadata-only replay path. It filters hidden thread-parent updates that change only Slack reply bookkeeping while preserving visible text, block, attachment, file, and newly-added mention changes. The broader answered-parent and bot-address-history policy in this PR remains a distinct follow-up rather than being silently replaced.