Patterns
Read a thread and inspect its context
Understand the latest message while retaining earlier history, recipient identity and delivery context.
On this page
User goal
Understand the latest message while retaining earlier history, recipient identity and delivery context.
Workflow
| Step | Expected behavior |
|---|---|
| 1 | Open the conversation from a queue or person history. |
| 2 | Read the subject and participant identities. |
| 3 | Read the latest full message; expand earlier message previews when relevant. |
| 4 | Expand quoted text or inspect attachment metadata as needed. |
| 5 | Open Message details for per-message identity/status; use Conversation details for thread routing and ownership. |
Decision and composition rules
- Latest message is last in the supplied array.
- Earlier cards intentionally overlap; expand rather than stretching the stack.
- Message delivery and conversation queue state answer different questions.
Edge cases and recovery
- Missing contact joins currently return no detail content.
- Reconstructed original email is not raw MIME.
- Attachment metadata does not prove downloadable bytes exist.
- Do not infer delivery from an omitted status that defaults to delivered.
Persistence boundary
The demonstrated frontend uses local React state or static fixtures. Read the readiness topic before connecting these actions to authenticated persistence. A visible toast, badge or timer is not a server acknowledgement.
Source references
| File | Responsibility |
|---|---|
| components/inbox/conversation-detail.tsx | Layered history |
| components/inbox/message-details-dialog.tsx | Message source/status |
| components/inbox/conversation-details-dialog.tsx | Thread metadata |
Examples from the app
Actual Sonarist components with fictional conversations, people, example.com addresses and simulated operational states. Captured at 2× resolution or higher. Select an image to inspect it full size.
Related topics
Source audit: 2026-10-08 · Revision 10f45d1377b5 · Documentation v1.0.0