[Feature] Composer: inline image/file nodes with drag reorder / 输入框支持图片与文件内联并拖拽调位

[yqx2006-maker]

Summary

The composer is already a Lexical rich-text editor and already supports atomic inline chips for references, commands and quotes. Images and files are not part of the draft document, though: they live in input.attachmentIds plus the separate attachment rail, so a user cannot place an image between two sentences, cannot drag an attachment to a position, and the submitted prompt always puts every attachment before the text block.

Requesting first-class inline attachment nodes with drag reorder — the composer behaviour of WorkBuddy / Claude / ChatGPT.

Environment

• DSH Desktop 0.2.2-rc.1 (@deepseek-ai/dsh-desktop-runtime 0.2.2-rc.1) on Windows 11; the same composer renders in dsh web.
• Verified against the shipped @deepseek-ai/dsh-client-ui-conversation/lib/client.js (940 KB bundle; the asar ships no src/).

Current behaviour (verified in the shipped bundle)

1. Draft editor is Lexical 0.49; ReferenceChipNode, CommandChipNode, QuoteNode are decorator nodes inside the document, so "text and file chips interleaved" already works.
2. Attachments live outside the document: SessionInputShell.attachmentIds is an ordered array rendered by the attachment rail, and addAttachments / removeAttachment / pruneAttachments are its only mutations.
3. Submission serialises attachments first and then one text block — client.js:4822-4832 builds content = [...await serializeAttachments(), {type:'text', text}] and calls session.prompt(content, mode, signal, requestId).
4. The public inputActions surface is insertQuote, captureInsertion, insertText (plain text only, revision-guarded), setDraft, persistDraft, addAttachments, removeAttachment, pruneAttachments, submit. There is no node-level operation, so a plugin can neither place an attachment into the document nor reorder nodes in it.

Why this matters (beyond aesthetics)

• Placement encodes intent. "This screenshot belongs to sentence 2, that log to sentence 5" is information. Flattening to attachments-first drops the anchor the user expressed, and the model has to guess.
• The wire format already supports it. session.prompt accepts an ordered block list; only the assembly step is fixed. This is a localised change with no protocol impact.
• Users already work around it with Markdown image text in the draft (see [Bug] Composer input box disappears when deleting a markdown image reference in the draft #2206), which has no thumbnail, no drag, and known rendering bugs.
• Parity. WorkBuddy, Claude and ChatGPT composers all allow inline images with drag reorder; this is the one interaction where the DSH composer currently feels behind a textarea-plus-shelf design.

Proposal (smallest unblocking surface, in preference order)

A. Make attachments first-class draft nodes (preferred).

• inputActions.insertAttachmentNode(attachmentId, span?) and inputActions.moveAttachmentNode(nodeId, at) with node ids stable across ordinary edits.
• The rail remains as the "not placed yet" view so nothing regresses for users who never drag.
• sendSession derives content from document order (interleaved image/file blocks and text blocks) instead of attachments-first.

B. Export-only alternative (no editor change).

Keep the rail, but let a takeover composer send explicit structure: inputActions.submit({ blocks }) (or an equivalent submitInterleaved), so plugin composers built on conversation.composer can preserve their own ordering. This alone does not give the default composer inline images.

C. Minimum read/reorder surface for plugins.

Expose a read-only draft projection plus reorderAttachments(ids); a plugin-side dnd implementation then covers drag-reorder of the rail even without host editor changes.

Acceptance criteria

• An image pasted, dropped or picked can be placed at the caret and renders as a thumbnail node inside the draft text.
• Any node can be dragged with a caret hit-test and a 2 px insertion indicator; dropping mid-sentence inserts exactly there.
• Backspace/Delete selects the node first and a second press removes it; removal is one undoable step (a real document mutation, not a CSS transform).
• Node order survives draft persistence and reload, and reaches the model in the same order.
• Esc/Esc-Esc, IME composition, paste routing and attachment-limit errors keep their current behaviour.

Reference recipe (from an Electron composer we reversed for comparison)

The mechanism is small and well understood; it does not need a new editor:

• PointerSensor with activationConstraint: { distance: 8 }, closestCenter collision detection, and a single SortableContext over the draggable nodes.
• On drag move (rAF-throttled): hide the drag overlay for hit-testing, document.caretPositionFromPoint (fallback caretRangeFromPoint), map to an editor point with exactMatch: false.
• Adjust the point against the enclosing node's rect: if clientX is left of its horizontal midpoint, use the node start, otherwise the node end; render the indicator from the same rect.
• Mount the 2 px indicator by portal into the composer wrapper (position: relative), not into the document, and keep the same portal trick for the drag overlay.
• On drop, a single normalised transaction (remove + insert at the pending point) so undo is one step.

Notes

• This is a feature request, not a bug report.
• Happy to prototype behind a Config flag if a direction is acceptable; we already maintain a third-party composer plugin, so even a narrow API is enough to build on.
• Related: Host-owned atomic, lossless pre-submit hold/resume for human text and ordered attachments #10064 (ordered attachments, pre-submit hold), [Bug] Composer input box disappears when deleting a markdown image reference in the draft #2206 (Markdown image reference inside a draft).