test: add receive display msglib smoke

This commit is contained in:
zhaoyilun
2026-07-10 08:24:08 +08:00
parent 298482c25d
commit 07d127c44a
5 changed files with 225 additions and 17 deletions

View File

@@ -56,7 +56,7 @@ N13/N14/N15 are pre-business validation results. They can help identify UI eleme
## Current loop
Current loop: `Stage C / Loop C33 - optional real receive-message display smoke`.
Current loop: `Stage C / Loop C34 - MsgLib enrichment operator runbook and setup smoke`.
Plan file: `docs/superpowers/plans/2026-07-09-stage-c-log-backed-receive-messages-loop.md`.
@@ -101,10 +101,11 @@ Current loop output so far:
30. C30: wired `DisplayEntities` into `isphere_search_contacts` and `isphere_search_groups` as an optional env-configured enrichment source with fake-source tests; default MCP verification now clears MsgLib env to keep the standard smoke deterministic.
31. C31: added optional `scripts/verify-msglib-mcp-enrichment.ps1`; real copied-DB MCP smoke returned sanitized contact/group counts and MsgLib source refs without printing names, JIDs, message bodies, file paths, or raw rows.
32. C32: `isphere_receive_messages` can now use the optional MsgLib display-entity source to fill safe `sender_name` and `conversation.display_name` fields while preserving message text/content/attachment behavior.
33. C33: optional real copied-DB MCP smoke now also constructs a synthetic encrypted PacketReader fixture from internally selected MsgLib contact/group metadata and verifies receive-message display enrichment through MCP; output stays sanitized to counts, booleans, and `msglib:<source_table>` refs only.
## Next business mainline
1. Run Stage C Loop C33: add an optional real copied-DB smoke for receive-message display-name enrichment, keeping output sanitized by default.
1. Run Stage C Loop C34: document and verify the operator setup path for enabling optional MsgLib enrichment in MCP without exposing local names, JIDs, file paths, message bodies, or raw rows.
2. Leave `isphere_send_message` blocked until bridge/API, UIA action-chain, or protocol connector evidence is validated.
3. Leave actual file download/cache mapping as a later connector node until a message-to-cache hash or client download source is validated.
4. Keep UIA selector/report work as fallback support, not as the primary roadmap.