feat(task-detail): replace inline comment input with ChatInput that triggers a new run#14873
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ba495a098b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## canary #14873 +/- ##
==========================================
- Coverage 70.85% 70.85% -0.01%
==========================================
Files 3256 3256
Lines 321442 321441 -1
Branches 29378 34092 +4714
==========================================
- Hits 227754 227750 -4
- Misses 93506 93509 +3
Partials 182 182
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
ba495a0 to
57cdd3e
Compare
57cdd3e to
a450153
Compare
a450153 to
1726088
Compare
CommentInput in TaskActivities stays as-is on canary — avatar + EditorCanvas + attachment + send button, posting a plain task-level comment. TopicChatDrawer footer becomes a FeedbackInput that calls the in-scope ConversationProvider's sendMessage, continuing the existing topic conversation instead of attaching a comment + restarting the run. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
1726088 to
d48e234
Compare
Drop the canLeaveFeedback gate so the in-thread reply box renders even when the topic is pending/running. ConversationStore.sendMessage already queues messages during an in-flight stream, so this just exposes the queue affordance to the user — letting them steer the next step without waiting for the current run to terminate. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…n + add attach action FeedbackInput now starts collapsed as a full-width "Send follow up message" button. Click expands a ChatInput shell with EditorCanvas inside and a footer that carries an AttachmentUploadButton on the left (+ icon) and the send button on the right. Files are inserted inline into the editor (same pattern as CommentInput) so they ride along on sendMessage's editorData. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…tton to filled - CommentInput card: padding-block 8px → 4px, editor placeholder fontSize 14px - FeedbackInput collapsed button: default size + variant="filled" for a less obtrusive look that sits flush in the chat footer Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…rawer Use paddingBlock="0 12px" so the follow-up button hugs the last message instead of floating with a 12px gap above. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…ssage Previously the editor cleanup ran after the awaited sendMessage call, so the box kept the just-sent text on screen until the entire send + stream lifecycle resolved. Move clearContent / collapse before the await so the input feels responsive (sendMessage already snapshots markdown and editorData for its optimistic update). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Drop the setExpanded(false) call in handleSubmit so the ChatInput remains open once the user has opened it. Collapsing it back to the "Send follow up message" button right after every reply was disruptive mid-conversation; the button only makes sense as the initial resting state of the drawer. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Plumb a new optional forceRuntime field through SendMessageParams → ConversationLifecycle.sendMessage → selectRuntimeType(parentRuntime). parentRuntime already wins over every other signal in the dispatcher, so callers can pin a send to 'gateway' / 'client' / 'hetero' regardless of the agent's local/cloud config. Also propagate forceRuntime through the message queue (QueuedMessage + MergedQueuedMessage + mergeQueuedMessages + both drain sites in the client and hetero executors) so a follow-up queued during an in-flight run keeps its runtime pin when it eventually fires. FeedbackInput in TopicChatDrawer passes forceRuntime: 'gateway' so task-topic follow-ups stay on the server-side path that runTask originally used, even if the user's global runtime preference is local. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Summary
TaskActivities(top of activities) andTopicChatDrawer(drawer footer) with a richerChatInputshell (@lobehub/editor/react), implemented as a newTaskChatInputcomponent.comment(addComment) — it now dispatches a new task run with the typed message as the prompt (runTask(taskId, { prompt })), so the message immediately drives the next run instead of just being recorded as feedback.CommentInput.tsx/FeedbackInput.tsxplus their sharedcommentInputCardstyle, and refresh the affected i18n keys (taskDetail.commentPlaceholderrephrased,taskDetail.commentSubmitAndRunreplaced withtaskDetail.sendMessage).pnpm i18nwas not run — onlyen-US/zh-CNare updated; the other locales will resync on the next i18n pass.Test plan
bunx vitest run src/features/AgentTasks/AgentTaskDetail/TopicChatDrawer/index.test.tsxbunx vitest run src/features/AgentTasks/(all green)🤖 Generated with Claude Code