WhatsApp data is stored locally but unavailable to agent tasks

Summary

WhatsApp Web data is fetched and persisted into the local whatsapp_data SQLite store, but the agent still cannot reliably use that data when asked to summarize chats, find action items, or do tasks based on WhatsApp messages.

Problem

Expected: after WhatsApp scanner data is stored locally, user requests such as “summarize my WhatsApp messages”, “what did my client say on WhatsApp?”, or “find action items from WhatsApp” should route to the stored WhatsApp data and return grounded answers.

Actual: the data reaches the local DB, but it is not fed into the agent’s normal task/context path in a way the orchestrator can use reliably.

Current repo shape:

app/src-tauri/src/whatsapp_scanner/mod.rs posts scanner snapshots to openhuman.whatsapp_data_ingest.
src/openhuman/whatsapp_data/ stores chats/messages in whatsapp_data/whatsapp_data.db and exposes read-only controllers: openhuman.whatsapp_data_list_chats, openhuman.whatsapp_data_list_messages, and openhuman.whatsapp_data_search_messages.
src/core/all.rs registers whatsapp_data controllers and marks ingest as internal-only.
The orchestrator direct tool list in src/openhuman/agent/agents/orchestrator/agent.toml includes memory and memory-tree tools, but no WhatsApp data tools.
WhatsApp data appears separate from the memory tree/context path used by memory_tree_* tools, so local WhatsApp rows may exist without becoming task-usable agent context.

Impact: WhatsApp looks connected and ingested, but users cannot actually ask the agent to reason over WhatsApp conversations. This breaks the multi-channel assistant promise and makes stored local data feel invisible.

Steps to reproduce:

Open OpenHuman desktop in a dev or packaged environment with WhatsApp Web connected.
Let the WhatsApp scanner run until logs show whatsapp_data_ingest ok or verify rows exist in whatsapp_data/whatsapp_data.db.
Ask the agent to summarize recent WhatsApp messages or find action items from a specific WhatsApp chat.
Observe that the agent does not query/use the stored WhatsApp data, or responds as if WhatsApp messages are unavailable.

Version / platform:

App/core version: current main unless reproduced on a specific build.
Platform: desktop app; WhatsApp Web scanner path.

Solution (optional)

Wire WhatsApp local data into the agent task surface without exposing the scanner write path.

Possible implementation paths:

Add read-only agent tools/controllers for WhatsApp list/search/read and include them in the appropriate agent tool scope, or
Ingest/canonicalize WhatsApp rows into the memory tree so existing memory_tree_* tools can retrieve them with source/provenance, or
Do both: direct structured WhatsApp tools for exact chat lookup plus memory-tree ingestion for semantic recall/action-item workflows.

Keep all data local. Do not expose whatsapp_data_ingest to agents.

Acceptance criteria

Repro gone — With WhatsApp rows present in whatsapp_data.db, the agent can answer grounded questions about recent WhatsApp chats/messages.
Agent task support — The agent can summarize WhatsApp conversations, search for a person/chat/topic, and extract action items from stored WhatsApp messages.
Read-only boundary preserved — Agents can only read/query WhatsApp data; they cannot call or discover the scanner ingest/write path.
Grounding/provenance — Responses identify WhatsApp as the source and include enough chat/message context to verify where the answer came from, without dumping excessive private content.
No duplicate storage confusion — The implementation documents whether WhatsApp data is queried directly, fed into memory tree, or both, and keeps the two paths consistent.
Regression safety — Rust and/or E2E coverage proves scanner-ingested WhatsApp data becomes available to agent/task flows while ingest remains internal-only.
Diff coverage ≥ 80% — the fix PR meets the changed-lines coverage gate (Vitest + cargo-llvm-cov, enforced by .github/workflows/coverage.yml).