| 1 | # Message Components DOX |
| 2 | |
| 3 | ## Purpose |
| 4 | |
| 5 | - Own message rendering helpers, action buttons, process groups, and resize behavior. |
| 6 | |
| 7 | ## Ownership |
| 8 | |
| 9 | - `action-buttons/` owns simple message action controls. |
| 10 | - `process-group/` owns grouped process-step DOM and styling helpers. |
| 11 | - `resize/` owns message resize state. |
| 12 | |
| 13 | ## Local Contracts |
| 14 | |
| 15 | - Keep message DOM helpers compatible with extension points that modify rendered messages. |
| 16 | - Sanitize or safely render model/user-provided content through shared rendering paths. |
| 17 | - Avoid layout shifts that break long-running message streaming. |
| 18 | - Keep message action chrome out of text selection so copy/paste captures message content without button labels or icons. |
| 19 | - Reconcile standard action buttons in place during streamed updates so hover, focus, tooltips, and click feedback survive while handlers receive the latest message data; preserve extension-owned buttons in the same action bar. |
| 20 | - Order standard message actions as Detail, Copy, then Speak; omit unavailable actions without changing the relative order of the remaining controls. Plugin-rendered message actions must follow the same order. |
| 21 | - Keep collapsed process-step detail text out of the DOM; opening a step may materialize its current cached log data and collapsing it must discard that heavy detail again without removing extension action hooks. |
| 22 | - Preference-driven process detail modes must await the same materialization path as manual expansion and accept an explicit chat-history target for off-screen window staging. `STEP` opens only the current non-utility step at the live tail; historical windows must not invent a current step at their boundary. |
| 23 | - Keep oversized standalone replay bodies and key/value tables in a bounded preview state until the user expands them; collapsing must remove the full body again. |
| 24 | - Message-window boundaries must not split process groups. Groups with more than 50 steps initially render their newest 50 steps and prepend earlier steps in 50-step increments through the group-local `Show more` control while retaining stable full-group header metrics. |
| 25 | - The process-group `Show more` paging control uses the same understated, non-underlined typography and hover-opacity treatment as message-body expansion controls. |
| 26 | - A root response may attach only to a substantive process render unit. Utility-prefixed units remain visible even while utility steps are hidden; standalone utility-only groups remain separate and hidden while utility messages are disabled, and completed groups must not absorb later utility records. Determine this from full-log render metadata, not partially mounted DOM children. |
| 27 | |
| 28 | ## Work Guidance |
| 29 | |
| 30 | - Coordinate changes with `webui/js/messages.js` and frontend extension hooks. |
| 31 | |
| 32 | ## Verification |
| 33 | |
| 34 | - Smoke-test message rendering, action buttons, process groups, and resizing after changes. |
| 35 | |
| 36 | ## Child DOX Index |
| 37 | |
| 38 | No child DOX files. |