Escalations for pass 01

Round 1

Q1. An attach-then-cancel cycle permanently consumes one of the six open draft batches for 24 hours. Should a cancelled composer discard its batch, should attachment-free or cancelled batches stop counting toward the cap, or is the 24-hour lockout acceptable as designed?

Source: grok-ce-code-review-adversarial-01.md Finding: Each first upload POSTs a new batch and disconnect never discards it (batches_controller.rb:25). After six attach-and-cancel cycles the user gets too_many_open_batches — "Finish or discard one first" — but there is no destroy endpoint, so the only remedy is posting a message or waiting out the 24-hour expiry. Context checked: plan Unit 2 step 5 ("a per-user cap of 6 open batches") and Unit 1 step 1 (the cap is "abuse headroom for three mounted composers and retries, not the per-message limit"); plan Unit 3 step 5 ("Treat Annotorious cancelForm and Turbo disconnect/navigation as client disconnect only; leave committed drafts for 24-hour expiry"); plan Scope Boundaries (no draft-discard surface listed); brainstorm A4/A6 (abandoned drafts are reclaimed by bounded background cleanup); app/controllers/image_attachment_drafts/ (create/show/upload/alt/remove only — no batch destroy); image_attachment_composer_controller.js:236 (batch is created lazily on the first upload, cached per mount, and reset only after a successful post). Why not auto-fixable: The plan prescribes both halves of the behavior — the cap of 6 and cancel-as-client-disconnect — so the finding is a product tradeoff, and each remedy (new discard route plus an unreliable unload-time call, exempting cancelled/empty batches from the cap, or raising the cap) changes a different contract. Suggested default: Add an idempotent DELETE /image_attachment_drafts/batches/:public_id that discards an unclaimed batch and purges its blobs, and have the composer call it on Annotorious cancelForm (best-effort via navigator.sendBeacon, with the 24-hour expiry still the guaranteed backstop). This keeps the cap at 6, makes the existing error copy truthful, and reclaims bytes sooner than the scheduler would.

A1.

Add an idempotent discard endpoint for an unclaimed draft batch and call it only for an explicit Annotorious cancel. Purge that batch's draft attachments promptly. Ordinary Turbo disconnect, navigation, and reconnect must continue to preserve the batch for the existing 24-hour recovery window. The server must lock and recheck the batch so cancel racing a successful claim cannot delete submitted attachments.