feat: trust whatsapp_from_owner flag for /takeback recognition

[keiravoss94]

Motivation

In profiles where the owner notification destination is Telegram but the human owner actually types replies from the same WhatsApp Business account as the bot (e.g. basketball-jersey-demo), /takeback from the owner's phone is not recognized as owner-issued — _is_owner_message only matched on (handover.owner.platform, handover.owner.chat_id). Result: the bot only resumes when the sliding TTL expires.

Design

Extend rules/handover.py::_is_owner_message with a metadata short-circuit before the legacy platform/sender check:

metadata = getattr(event, "metadata", None) or {}
if metadata.get("whatsapp_from_owner"):
    return True

The bridge LRU classifier in hermes-agent (WhatsAppAdapter._build_message_event, gated by WHATSAPP_FORWARD_OWNER_MESSAGES) only sets that flag for inbounds that came from the bot's own WhatsApp account — by definition the owner. Same trust model as the implicit-owner-activate branch shipped in #3.

The legacy (platform, sender_id) path is unchanged for profiles that don't enable owner forwarding.

No config change

No new keys, no schema bump. Profiles opt in via the existing WHATSAPP_FORWARD_OWNER_MESSAGES env in hermes-agent.

Dependencies

• hermes-agent: PR refactor: agent-driven handover, drop gateway-side classifier #1 propagating metadata['whatsapp_from_owner'] (merged into pebble/main as b1e7628d7).
• This repo: feat: implicit handover on owner reply + sliding TTL #3 (sliding TTL + implicit owner-reply handover), which introduced the whatsapp_from_owner consumer pattern.

Tests

Two new tests in tests/test_rules.py::TestHandover:

1. test_takeback_via_whatsapp_from_owner_flag_alone_deactivates — owner configured for Telegram, /takeback arrives via WhatsApp with metadata['whatsapp_from_owner']=True → handover ends.
2. test_takeback_without_owner_flag_from_stranger_does_not_deactivate — no flag, non-owner sender, /takeback text → falls through to the active-handover silent-ingest path; handover stays active.

Existing 42 tests remain green; suite is now 44.

[coderabbitai]

Warning

Rate limit exceeded

@keiravoss94 has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 1 minutes and 44 seconds before requesting another review.

To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: b68896b1-ba9a-4a2e-8ad3-fd9aaf64f44a

📥 Commits

Reviewing files that changed from the base of the PR and between ad41982 and 7e49730.

📒 Files selected for processing (2)

• rules/handover.py
• tests/test_rules.py

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/whatsapp-from-owner-takeback

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}