feat(workspace): reply to a message from inside the chat (abilityai/trinity-enterprise#738)

[webmixgamer]

Summary

• You can now reply to a specific agent message inside the 1:1 Workspace chat, not only from the Inbox.
  • Every saved agent message gets a Reply button in its action row: Copy · Reply · 👍 👎.
  • Clicking it shows the same "replying to" chip above the composer that the Inbox uses, and puts the cursor in the composer.
  • The send carries reply_to_message_id, and the sent bubble shows the quote. Both behave exactly as when the reply starts in the Inbox.
• Nothing changes on the backend: no new endpoint, no migration. The send, the server check on the reply id, and the error path when a reply is refused are all reused unchanged.
• Esc closes the innermost thing first:
  • with the @/ picker open, the first Esc closes the picker;
  • otherwise Esc clears the chip;
  • only then does Esc stop a running turn.
• A chip never follows you into another chat.

Changes

• PortalAgentBubble.vue owns Reply (replyLabel, replyDisabled, reply event).
  • Copy and Reply share one button style at the thumbs' shade: gray-500 light, gray-400 dark. Copy's old light gray-400 was 2.54:1 on white, below the 3:1 an icon needs.
  • The colour baseline is re-frozen +1 in its own commit, with a note.
• PortalInboxPane.vue: the per-message arrow is now the bubble's own Reply. The event it sends is unchanged.
• PortalConversation.vue:
  • Reply appears only on saved rows, and is disabled during a voice call without moving the row.
  • The reply uses the chat id the conversation resolved itself, not the one from the URL: a link that doesn't name the chat has no id in the URL.
  • Focus moves to the composer within the tap.
  • The textarea is aria-describedby the chip's "Replying to: …" text. PortalReplyChip gains a textId prop so the description leaves out the remove button's name.
• portalUtils.js: resolveComposerKey gains hasReply and returns 'drop-reply'. The composer then calls preventDefault, which makes the turn-cancel listener ignore that Escape.
• Portal.vue:
  • setReplyTarget handles the new event.
  • A new watcher on convKey, the conversation's identity, drops the reply target when the conversation changes. Before this, New chat or switching agent on a link that didn't name the chat left the target hidden, and it came back when you reopened that chat.
• Docs:
  • the requirement in core-agent.md;
  • architecture/workspace.md (the second way in);
  • three feature flows;
  • a learnings fragment;
  • the cso --diff report (no findings).

Decisions taken with the product owner

• Touch target: Reply is 22px like its neighbours. The issue's "≥44px on touch" line is moved to the whole action row as one change on trinity#3056; scope added in a comment there.
  • Three 44px hit areas can't fit around 22px buttons 4px apart without overlapping.
  • Meanwhile the row passes WCAG 2.5.8 through spacing: button centres are 26px apart.
• Follow-up: abilityai/trinity-enterprise#746 (incubating). It would save the reply link on the stored message so the quote survives a reload.

Test Plan

• portalInChatReply.mount.spec.js (new, mounts the real conversation, bubble, chip and Inbox pane):
  • Reply appears only on saved agent messages.
  • The reply names the chat the conversation resolved, not the URL's.
  • The cursor lands in the composer.
  • The chip appears, and the textarea's aria-describedby points at its text.
  • The send carries the id, and the sent bubble shows the quote.
  • The chip's × returns focus to the composer.
  • Reply is disabled during a voice call.
  • Esc closes the innermost thing first: picker, then chip, then turn. The turn case includes a positive control that the second Esc does stop it.
  • A reply aimed at another chat never swallows the turn's Esc.
  • An Esc an overlay already claimed leaves the chip alone.
  • The bubble's row order and the shared style.
  • The Inbox pane's Reply still opens the chat at that message.
• portalInboxShell.mount.spec.js (the real Portal.vue):
  • reply sets the target, and a target with no message id is ignored.
  • Leaving a chat drops the target, and coming back doesn't restore it.
  • New chat on a link that doesn't name the chat drops it.
  • The Inbox path keeps its target through its own navigation.
• resolveComposerKey truth table: drop-reply only with the picker closed, never during IME composition.
• 18 call-site mutations, each wiring line broken from a scratch copy: all red.
• Full vitest run, the raw-colour, loading-gate and source-text ratchets, and check:tokens pass. Three failures are local-environment only and touch no file in this diff:
  • the two room specs fail at load on the host (known);
  • markdownCodeBlocks.spec.js reads the installed DOMPurify, which resolved to a newer version than the lockfile in a local pnpm install. CI's npm ci decides that one.
• tests/unit/test_ent610_reply_to_message.py: 18 passed. This is the server-side check on the client-chosen id.
• Manual: checked on localhost by the product owner (Reply, the chip, Esc order, chat switch, the Inbox pane, 375px, both themes).

Fixes abilityai/trinity-enterprise#738

🤖 Generated with Claude Code

[vybe]

merge-train: validated READY: no criticals, and the mount specs fail for each wiring line I reverted. It's held only because it conflicts with #3156 (on this train) in src/frontend/src/components/portal/PortalConversation.vue, so it rides the next train once #3156 is on dev and this branch is merged up. After merge, trinity-enterprise#738 needs status-in-dev set by hand (cross-repo keyword).

[AndriiPasternak31]

Approve with nits. Reviewed at 96ab54389.

I found no correctness, auth or prompt-safety defect. The change is frontend-only. reply_context still re-proves the agent, email and session server-side, returns one uniform 422, and builds the quote from the DB, bounded at 2000 chars. Esc order, the clear-on-chat-switch watcher and focus behaviour are all covered.

Verified locally

• vitest: the PR's 4 specs plus the raw-colour, loading-gate and source-text ratchets pass. vite build exits 0.
• Mutation battery: I broke 8 wiring lines one at a time (hasReply, the defaultPrevented guard, the session the reply names, focusComposer, the convKey watcher ×2, the chip's Esc preventDefault, and reply-disabled). 8 of 8 turned a test red.
• Not verified: a live browser in both themes or at 375px.

Before merge

1. It conflicts with dev. The only clash is in PortalConversation.vue, in defineEmits: #3156 added 'thread-missing' and this PR adds 'reply'. Keep both, then re-run CI. The current green runs predate the conflict.
2. Collision with #3181 (medium; whichever PR lands second fixes it):
   • #3181 renders its "Send as answer" row between PortalReplyChip and the composer box, so the chip, which is styled as a tab fused to the composer, ends up floating.
   • answerDiscussedAsk neither reads nor clears replyTo. In a discussion chat, Reply then Send as answer sends the answer without the quote, and the chip survives, so the next ordinary message silently becomes a reply.
   • Suggested fix: render that row above the chip, have a successful Send as answer clear the reply (or make the two mutually exclusive), and add a mount test with both present.
   • Note: #3181's diff doesn't actually use this PR's reply entry point. Apart from this, the two PRs are independent.

Low / nits

• Reply is never an ask decision: no operator_queue write, so the single-row CAS is untouched. Replying "yes" to the message that raised an ask leaves the ask pending. Worth one line in workspace.md.
• This is pre-existing, but the PR widens it: channel_completion_report stores a delegated child's result as an assistant row, and reply_context quotes it as "your earlier message". Reply now puts that one click away on every report bubble. A follow-up could frame completion:* rows differently.
• PortalAgentBubble.vue:46 hard-codes data-testid="portal-message-reply", so the Inbox's per-message inbox-pane-reply-to-<id> is gone. There's no live collision, because the panes are mutually exclusive, but tests lose a per-message address.
• ACTION_BUTTON uses focus:ring-2 where the old Inbox arrow used focus-visible:, so a mouse click now shows a ring.
• drop-reply also fires on Shift/Ctrl/Meta+Esc (portalUtils.js:1281).

ent#738 acceptance criteria: all met, except the 44px touch target, which is partial. That deviation is documented: the product-owner ruling moved it row-wide to #3056.