Greptile Summary

This PR adds live WhatsApp commentary delivery via a commentaryDelivery: "off" | "live" config flag. While an agent run is in progress, intermediate commentary-phase assistant messages are now sent to the WhatsApp thread in real time, and already-delivered commentary is filtered out of the final reply to avoid duplication. The implementation is gated entirely behind a new config flag, is backward-compatible (default stays "off"), and does not affect any other channel.

Key design decisions that are working correctly:

• A serial per-run commentary delivery queue with generation-based staleness tracking, per-segment AbortController wiring, and upstream-abort forwarding prevents double-delivery or leaked listeners.
• seenLiveCommentarySegmentIds prevents re-queuing a streaming segment already picked up from message_update; deliveredCommentarySegmentIds survives compaction retry to suppress replay of the same segment ID.
• waitForCommentaryDeliveryBounded in the attempt runner uses a pendingCount-scaled timeout and catches runner-abort errors cleanly before proceeding to final payload assembly.
• The !queuedFinal → return didSendReply change in process-message.ts correctly surfaces true when live commentary was the only output from a turn.

Three P2 observations:

• normalizeDirectiveAliases is injected into normalizeReplyPayloadDirectives globally, affecting all channels — confirm this is intentional.
• The 15_000 ms timeout is hardcoded in two places and must be kept in sync manually.
• When all assistantOutputs are delivered commentary, the final reply is intentionally empty — operators should be aware a turn can produce a zero-text final reply with commentaryDelivery: "live".

Confidence Score: 5/5

Safe to merge — no P0/P1 issues found; all three observations are P2 design/style notes that do not affect correctness.

The implementation is well-scoped behind a new config flag with a safe default, backed by comprehensive seam tests covering abort, timeout, compaction retry, async drain, and cross-turn deduplication. Abort/cleanup semantics are correct, the delivered-commentary filter is explicitly tested, and the channel boundary is guarded by a Telegram boundary test. All findings are P2.

src/auto-reply/reply/reply-delivery.ts — confirm global normalizeDirectiveAliases application is intentional. src/agents/pi-embedded-runner/run/attempt.ts and extensions/whatsapp/src/auto-reply/monitor/process-message.ts — duplicate 15_000 constant needs to stay in sync.

This is a comment left during a code review.
Path: src/auto-reply/reply/reply-delivery.ts
Line: 26-28

Comment:
**`normalizeDirectiveAliases` applies globally to all channels**

`normalizeDirectiveAliases` is now called unconditionally inside `normalizeReplyPayloadDirectives`, meaning camelCase directive aliases (`[[replyToCurrent]]`, `[[audioAsVoice]]`, `[[replyTo:...]]`) are normalized for *all* channels and callers — not just the new WhatsApp commentary path.

This may be intentional as a general cleanup (the test `"normalizes commentary directives before delivery"` explicitly verifies it), but it is an undocumented side-effect on Telegram, Slack, and other channels that is outside the stated PR scope. If the model was previously emitting `[[replyToCurrent]]` on any channel and that literal token was expected to pass through unchanged, it will now be silently rewritten to `[[reply_to_current]]`.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/agents/pi-embedded-runner/run/attempt.ts
Line: 1290-1292

Comment:
**Hardcoded `15_000` timeout duplicated across two files**

`COMMENTARY_REPLY_TIMEOUT_MS = 15_000` in `process-message.ts` is wired as `blockReplyTimeoutMs`, and `attempt.ts` has `params.blockReplyTimeoutMs ?? 15_000` as the fallback inside `waitForCommentaryDeliveryBounded`. Both constants must be kept in sync manually. If the timeout in `process-message.ts` is updated but the fallback here is not, the scaling logic (`commentaryDeliveryTimeoutMs * pendingCount`) would silently use a different cap for callers that omit `blockReplyTimeoutMs`.

Consider exporting the constant from a shared location or adding a comment cross-referencing both sites.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/agents/pi-embedded-runner/run/payloads.ts
Line: 248-270

Comment:
**`assistantTexts` no longer consulted as fallback when `assistantOutputs` is non-empty but entirely filtered**

The old fallback chain was: `assistantTexts || extractAssistantText(lastAssistant) || []`. The new logic uses `assistantOutputs` when non-empty, but if all entries are commentary segments that were already delivered live, `filteredAssistantOutputs` becomes `[]` — and `assistantTexts` is *not* consulted.

The test `"does not fall back to assistantTexts when delivered commentary strips all assistant outputs"` confirms this is intentional. The design decision is sound, but operators should be aware: when the model emits only `phase: "commentary"` blocks (no `phase: "final_answer"`) and all are delivered live, the final WhatsApp reply will be empty.

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "WhatsApp: send commentary live" | Re-trigger Greptile}

Addressed the open review items and pushed 2931754962.

What changed:

• scoped camelCase directive alias normalization to the WhatsApp commentary delivery path instead of applying it globally
• shared the commentary reply timeout constant between the WhatsApp caller and the runner fallback
• merged repeated same-signature assistant text blocks before storing/delivering them, with coverage for the OpenAI Responses-style split-block case
• regenerated the plugin SDK API baseline after exporting the shared timeout constant

Validation:

• pnpm test -- src/auto-reply/reply/reply-delivery.test.ts src/agents/pi-embedded-subscribe.commentary.test.ts src/agents/pi-embedded-runner/run/payloads.test.ts
• pnpm check
• pnpm build

I left the assistantTexts fallback thread open for now because that behavior still looks intentional: if we reintroduce the fallback when commentary-only segments were already delivered live, we risk duplicating text instead of producing a true final-only payload.

Addressed the remaining unresolved bot threads in 6997165d4f.

What changed:

• restore assistantTexts fallback when live-delivered commentary strips all finalized assistant outputs
• track delivered commentary text per segment so later updates send only the appended suffix and message_end flushes any remaining tail
• propagate AbortError from later WhatsApp media sends so truncated commentary is not marked as delivered

Verification:

• pnpm test -- src/agents/pi-embedded-runner/run/payloads.test.ts src/agents/pi-embedded-subscribe.commentary.test.ts extensions/whatsapp/src/auto-reply/deliver-reply.test.ts
• pnpm check

Addressed the two remaining bot threads in 5508a7e796.

What changed:

• preserve undelivered commentary suffixes in the final payload by carrying delivered commentary text through the runner result
• queue a follow-up live commentary delta after an in-flight send completes if the same segment grew while pending, including the message_end case with no later events

Validation:

• pnpm test -- src/agents/pi-embedded-subscribe.commentary.test.ts src/agents/pi-embedded-runner/run/payloads.test.ts
• pnpm build

Superseded by #57484.

This replacement PR carries the same feature on a fresh current-main branch with clean history, plus the latest follow-up fix for the lastAssistant timeout/abort fallback.

🔒 Aisle Security Analysis

We found 3 potential security issue(s) in this PR:

state.deliveredCommentarySegmentIds.add(segment.segmentId);
state.deliveredCommentarySegmentTexts.set(
  segment.segmentId,
  options?.deliveredText ?? segment.text,
);

const parsed = JSON.parse(trimmed) as { id?: unknown; phase?: unknown };
...
return { id: parsed.id, ... };

const MAX_SEGMENTS = 500;
const MAX_SEGMENT_ID_LEN = 128;
const MAX_DELIVERED_TEXT_LEN = 10_000;

function normalizeSegmentId(id: string): string | null {
  const trimmed = id.trim();
  if (trimmed.length === 0 || trimmed.length > MAX_SEGMENT_ID_LEN) return null;
  return trimmed;
}

function rememberDelivered(segmentId: string, text: string) {
  if (state.deliveredCommentarySegmentIds.size >= MAX_SEGMENTS) {
    ​// evict oldest / use LRU structure
    const oldest = state.deliveredCommentarySegmentIds.values().next().value;
    state.deliveredCommentarySegmentIds.delete(oldest);
    state.deliveredCommentarySegmentTexts.delete(oldest);
  }
  state.deliveredCommentarySegmentIds.add(segmentId);
  state.deliveredCommentarySegmentTexts.set(segmentId, text.slice(0, MAX_DELIVERED_TEXT_LEN));
}

const pendingCount = Math.max(1, getPendingCommentaryDeliveryCount());
const roundTimeoutMs = commentaryDeliveryTimeoutMs * pendingCount;
...
timer = setTimeout(() => reject(timeoutError), roundTimeoutMs);

const MAX_PENDING_MULTIPLIER = 10; // or another small constant
const MAX_TIMEOUT_MS = 60_000;     // e.g., 60s, product decision
const rawPending = getPendingCommentaryDeliveryCount();
const pendingCount = Math.max(1, Math.min(MAX_PENDING_MULTIPLIER, rawPending));

const roundTimeoutMs = Math.min(
  MAX_TIMEOUT_MS,
  commentaryDeliveryTimeoutMs * pendingCount,
);

onCommentaryReply:
  commentaryDelivery === "live"
    ? async (_payload, _context) => {
        ​// Intentionally do not forward model commentary to WhatsApp.
        ​// Optionally send a fixed typing/progress indicator instead.
      }
    : undefined,

if (payload.isReasoning) return;
if (!isAllowedCommentary(payload.text ?? "")) return;

Analyzed PR: #57289 at commit 0bea12b

_{Last updated on: 2026-03-30T09:55:14Z}

Addressed the latest bot feedback and pushed 4ad996ebb1 to the PR branch.

What changed:

• restored the lastAssistant fallback when finalized assistant outputs are empty (12ab6b9a05), resolving the remaining Codex thread
• bounds live-commentary segment IDs from model-provided textSignature values and falls back to generated segment IDs for invalid/oversized IDs
• caps delivered-commentary tracking to 500 segment IDs and stores only a bounded text prefix plus exact delivered length, so suffix preservation still works without retaining unbounded text
• clamps the commentary delivery wait multiplier to prevent unbounded timeout growth

Validation:

• pnpm test -- src/agents/pi-embedded-subscribe.commentary.test.ts src/agents/pi-embedded-runner/run/payloads.test.ts
• pnpm check
• npm_config_cache=/tmp/openclaw-npm-cache pnpm build

Note: the first plain pnpm build hit a local npm cache ownership problem (EPERM under /Users/tristan/.npm/_cacache), so I reran it with a temporary npm cache. The temporary-cache build passed; it still printed the existing local config warning for channels.telegram.streaming.

On the Aisle item about live commentary exposure: this PR keeps free-form WhatsApp commentary as an explicit opt-in (commentaryDelivery: "live", default off) and continues to restrict delivery to sanitized phase: "commentary" assistant output rather than reasoning/block streams. I treated that as a product/security tradeoff rather than replacing the feature with fixed status text in this follow-up.