openclaw - 💡(How to fix) Fix Regression: 2026.4.27 artifacts lack public/internal assistant audience boundary for visible delivery [2 comments, 2 participants]

Summary

The 2026.4.27 npm artifacts checked on 2026-04-29 appear to preserve some commentary / final_answer phase separation, but do not expose or enforce an explicit public/internal assistant audience boundary at the shared visible-text / delivery extraction layer.

This report is intentionally limited to synthetic package-level smoke evidence. It does not include private transcripts, screenshots, local paths, account identifiers, channel IDs, session IDs, or environment-specific runtime logs.

Versions checked

Checked via isolated npm temp-prefix installs with lifecycle scripts disabled:

• openclaw@latest at the time checked: 2026.4.27
• openclaw@beta at the time checked: 2026.4.27-beta.1

This issue does not make claims about packages published after 2026.4.27.

Synthetic smoke result

Both checked artifacts had the same relevant behavior:

• no exported public/internal audience helpers were present
• the packaged visible-text helper did not recognize audience: "public"
• text marked with audience: "internal" and phase: "final_answer" was still selected as visible text
• exact NO_REPLY text was still returned as visible text by the shared helper

The synthetic messages used textSignature JSON containing only version, id, phase, and audience fields.

Expected behavior

At the channel-visible delivery boundary:

• explicitly internal assistant text should not be selected for user-visible delivery
• explicitly public assistant text should be eligible according to delivery policy
• invalid or unknown audience values should fail closed
• exact silent sentinels such as NO_REPLY should not be returned as visible assistant text
• legacy phase-only behavior can remain as a compatibility fallback where needed

Why this matters

Visible delivery currently appears to depend on phase filtering and exact sentinel handling. A separate explicit audience contract would provide a stronger boundary between internal assistant/runtime text and user-facing channel delivery.

Related issues

This appears related to, but not fully covered by:

• #44905
• #65132
• #74510
• #73269
• #74674

This issue is specifically about the missing public/internal assistant audience contract in the checked npm artifacts.

Suggested fix direction

Consider adding an explicit assistant audience contract through provider stream parsing, replay, transcript/message content helpers, and final delivery selection:

• encode/parse audience: "public" | "internal" in assistant text signatures
• expose shared audience helpers
• suppress explicitly internal assistant text at visible extraction and delivery boundaries
• fail closed on invalid audience values
• keep legacy phase-only fallback only where required for older transcript compatibility
• add regression tests for internal/public audience handling and exact silent-sentinel suppression