fix(bridges): the bot was blind to its own commitments, and killed real replies

[dshakes]

Four defects found by auditing a week of production logs, chat.db, and the reply path. All four were silent — nothing errored, the bot just sounded like a bot.

1. It denied work it was actively doing

Owner: "Track above flight" → "I don't see a flight in our conversation." The watch was on disk with 4 completed checks.

Two things had to line up: WatchStore was never injected into the owner prompt, and the bot's own 📡 watching: announcement is stripped from history by isBotSelfMessage (correct — it's the echo-loop guard). So the only record of the commitment was erased and the store was never read. Not a reasoning failure; the context genuinely wasn't there.

watchContextBlock() renders active watches into the owner prompt. Verified by replaying the real stored watch at the exact failure timestamp.

2. The same blindness on the contact path — the general case

Every module documented "owner self-chat only" writes state the contact reply path never reads. working-memory has 9 write sites and zero reads there. The bot books Raju's event, then replies to Raju with no idea it happened.

contactWatchBlock() + a selfContextBlock field close it for watches — the case with per-contact attribution, and therefore the case that is safe to surface. Thread isolation is the load-bearing property and is tested: a watch started off one contact's message can never appear in another's thread. working-memory stays out until its actions carry a contact; dumping it would leak.

3. It suppressed real human drafts

AI_TELL_WORDS matched as a raw substring:

• "as personal as it gets" → tripped "as per"
• "kindlyn said she'd come" → tripped "kindly"

Both reproduced. A suppressed draft falls through to five hardcoded greeting strings, hash-indexed — so a contact texting "hey" gets the byte-identical reply forever — or to silence.

Fixed to word-boundary matching with inflections. Every genuine tell still suppresses; the test pins both directions.

4. Reply quality was structurally unmeasurable

Successful sends were never logged with their text. A full week of traffic left ~33 verbatim replies, all from sidecar files. Logged at the existing send choke point after delivery confirms, bot-self tagged rather than dropped so "real reply vs machinery" is answerable — 210 of 627 sent messages were machinery, and that ratio was invisible. Preview-capped at 160 chars.

Verification

• 1496/1496 bridge-core tests pass
• Both bridges typecheck clean
• bridge-core has 972 pre-existing tsc errors (missing @types/node); this diff adds no new error class — verified against a stashed baseline

Deliberately not fixed

iMessage hardcodes disclosed: false while WhatsApp passes real state. The obvious one-word fix wouldn't compile (disclosedJids doesn't exist there) and the feature is inert anyway — env unset, set empty.

Known ceiling, not addressed

Memory has no embeddings. It's token-set intersection, so "any update on that thing we discussed?" scores zero against everything and returns the 6 newest irrelevant episodes.

[github-actions]

🔎 Codex cross-audit (agent:audit)

Blocking

• services/imessage-bridge/src/session.ts:5617 and services/whatsapp-bridge/src/session.ts:3433: this logs textPreview for every successful outbound send. That can include owner-only self-chat replies, document/ID answers, OTPs, private-vault-derived text, or sensitive contact replies. The repo invariant says secrets must never appear in logs; “preview-capped” does not make the first 160 chars safe. Redact, classify, or make this opt-in local debug only.

• packages/bridge-core/src/live-watch.ts:295 and packages/bridge-core/src/live-watch.ts:324: topic, doneCondition, and lastSummary are untrusted LLM/web/contact-derived strings, but they are injected raw into high-priority prompt context. A contact or search result can persist text like “ignore previous instructions…” in the watch store, then have it replayed on later turns as “already tracking” context. Treat these fields as untrusted data: quote/escape/delimit them, strip instruction-like content, and add regression coverage for prompt-injection text in watch metadata.

Tests

I attempted the focused packages/bridge-core tests, but they could not run because tsx is missing in this checkout; all failures were module-loader errors before test code executed.

[github-actions]

🔷 Gemini cross-audit (agent:audit-gemini)

Audit Report: Unified Diff Assessment (pr-diff.patch)

---

⚠️ Blocking / Correctness Regression

Dropped-E Verb Inflections Bypass AI-Tell Filter

The word-boundary regex generator aiTellRe(word) incorrectly assumes all suffixes append directly to the literal base word:

re = new RegExp(`\\b${escaped}(?:'?s|d|ed|ing)?\\b`, "i");

In standard English, verbs ending in a silent e drop the e before taking the -ing suffix (e.g., delve $\rightarrow$ delving, navigate $\rightarrow$ navigating, facilitate $\rightarrow$ facilitating, utilize $\rightarrow$ utilizing, elaborate $\rightarrow$ elaborating).

• The Bug: For delve, the regex generated is \bdelve(?:'?s|d|ed|ing)?\b. This matches the non-existent "delveing" but fails to match the correct English word "delving".
• Impact: Common AI-generated tell phrases (e.g., "delving deeper into...", "navigating this situation", "facilitating the process") will completely bypass the coherence filter, leaking obvious bot indicators to contacts.
• Recommended Remedy: Adjust aiTellRe to handle silent-e dropping gracefully:

  function aiTellRe(word: string): RegExp {
    let re = aiTellReCache.get(word);
    if (!re) {
      let pattern = word.replace(/[.*+?^${}()|[\]\\]/g, "\\$&");
      if (word.endsWith("e")) {
        const base = pattern.slice(0, -1);
        pattern = `${base}(?:e|e'?s|ed|ing)`;
      } else {
        pattern = `${pattern}(?:'?s|d|ed|ing)?`;
      }
      re = new RegExp(`\\b${pattern}\\b`, "i");
      aiTellReCache.set(word, re);
    }
    return re;
  }

---

🔍 Non-Blocking Findings & Observations

1. Outbound Audit Logger PII Safety (Compliance with Invariant #10)

The addition of outbound message logging (textPreview: text.slice(0, 160)) in both IMessageSession and WhatsAppSession is highly effective for auditing quality while complying with Invariant 10. Slicing at 160 characters is consistent with other previews in the codebase, ensuring full message bodies (and potential bulk PII) are never logged verbatim.

2. Performance & Thread-Safety of aiTellReCache

The module-level caching const aiTellReCache = new Map<string, RegExp>(); is highly performant. Since AI_TELL_WORDS is a fixed, small list (14 entries), it has a bounded memory footprint. Because JavaScript/Node.js executes on a single-threaded event loop, there are zero concurrency/race hazards with this shared cache.

3. Isolation of contactWatchBlock and watchContextBlock

• Contact-facing isolation is perfectly preserved by filtering against the specific JID (w.jid === jid), preventing cross-contact leaks.
• Owner-facing visibility correctly gathers active watches globally, enabling the owner's briefing loop to accurately represent what the bot is actively tracking without hallucinations.

[github-actions]

🛡️ Vuln scan — ❌ vulnerable dependency found

cd services/control-plane && govulncheck ./...
=== Symbol Results ===

No vulnerabilities found.

Your code is affected by 0 vulnerabilities.
This scan also found 1 vulnerability in packages you import and 15
vulnerabilities in modules you require, but your code doesn't appear to call
these vulnerabilities.
Use '-show verbose' for more details.
cd services/gateway && cargo audit
    Fetching advisory database from `https://github.com/RustSec/advisory-db.git`
      Loaded 1225 security advisories (from /home/runner/.cargo/advisory-db)
    Updating crates.io index
    Scanning Cargo.lock for vulnerabilities (272 crate dependencies)
Crate:     h2
Version:   0.4.13
Title:     h2 unbounded empty DATA frames
Date:      2026-08-17
ID:        RUSTSEC-2026-0258
URL:       https://rustsec.org/advisories/RUSTSEC-2026-0258
Solution:  Upgrade to >=0.4.16

error: 1 vulnerability found!
make: *** [Makefile:268: audit] Error 1

[github-actions]

🛡️ Vuln scan — ❌ vulnerable dependency found

cd services/control-plane && govulncheck ./...
=== Symbol Results ===

No vulnerabilities found.

Your code is affected by 0 vulnerabilities.
This scan also found 1 vulnerability in packages you import and 15
vulnerabilities in modules you require, but your code doesn't appear to call
these vulnerabilities.
Use '-show verbose' for more details.
cd services/gateway && cargo audit
    Fetching advisory database from `https://github.com/RustSec/advisory-db.git`
      Loaded 1225 security advisories (from /home/runner/.cargo/advisory-db)
    Updating crates.io index
    Scanning Cargo.lock for vulnerabilities (272 crate dependencies)
cd services/model-router && cargo audit
    Fetching advisory database from `https://github.com/RustSec/advisory-db.git`
      Loaded 1225 security advisories (from /home/runner/.cargo/advisory-db)
    Updating crates.io index
    Scanning Cargo.lock for vulnerabilities (251 crate dependencies)
Crate:     h2
Version:   0.4.13
Title:     h2 unbounded empty DATA frames
Date:      2026-08-17
ID:        RUSTSEC-2026-0258
URL:       https://rustsec.org/advisories/RUSTSEC-2026-0258
Solution:  Upgrade to >=0.4.16

error: 1 vulnerability found!
make: *** [Makefile:269: audit] Error 1