[task] Screenshot Card and attach an image

[lukemaj]

State: shaping decision needed. Await human approval or rejection of the complete minimal v1 image-attachment contract in issue comment 5466895269. Even if approved, implementation stays unowned until #116 is dispositioned, #137 then #139 are rebuilt on the current train, and corrected-train #80 acceptance establishes the exact Messenger baseline, because the claim overlaps Messenger/Home surfaces.

Parent

[spec] Messenger UI: human chat, not a log.

Blocked by

• Human approval or rejection of the complete contract in comment 5466895269.
• Exact-head [task] Converge familiar Messenger and isolated-runtime trains #116 live and human disposition.
• Ordered corrected [bug] Keep selected-Bot Instructions inside its panel #137 then [bug] Give the phone Chat composer full touch targets #139 re-anchoring plus fresh exact-candidate [task] V1 messenger acceptance through Computer Use #80 acceptance, which releases and verifies the overlapping Messenger claim.

The former several-bubbles prerequisite is delivered; it is historical, not the current blocker.

Outcome

A Card is a transcript item that is not a text bubble. v1 Card here: a screenshot in the thread (Computer frame when it helps), and an image the user attaches from the composer +. Images are first-class, not markdown image syntax. Attach Computer frames and files the Bot made when they help, not as a default dump.

Demo

1. Attach an image from the composer. See it in the thread as a Card or as images on a bubble.
2. When a screenshot helps, see it in the thread. Not a dump of every Computer frame.
3. Refresh: the Card is still there.

Existing constraints

Talk HTTP persists Card kind. The vanishing permission panel is not this ticket. File chips (csv/pdf), mermaid, and widgets stay parked. Do not copy Grok Bot artwork. Do not publish Grok screenshots to the repo.

Acceptance criteria

These criteria apply only if the human approves the complete contract in comment 5466895269.

• One staged, removable composer image can send alone or with text and reaches only a Harness that advertises ACP image prompt capability.
• Unsupported Harnesses fail before Transcript mutation and preserve the staged image.
• A deliberate provider-neutral openbot-transcript attach_image action can import one allowed Bot-directory/shared-drop image as a Bot-owned Transcript image Card.
• Every persisted image is decoded and normalized to metadata-free PNG, at most 8 MiB and 4096 by 4096 pixels, behind an authenticated same-origin media route.
• Attachment publication and message relation are atomic; startup reconciles temporary, orphaned, and missing files; deletion removes message-owned media.
• The thumbnail opens an accessible focus-trapped contain-scaled dialog with Close, Escape, and exact focus restoration.
• Images are first-class Transcript objects, never markdown, Workspace paths, base64 JSON, arbitrary ACP output, or automatic frame dumps.

Non-goals

• Multiple images, generic file chips, video, SVG, animation, galleries, annotation, pan, or a carousel in v1.
• Inferring attachments from arbitrary ACP/tool output or attaching every Computer frame.
• Transcript-only decoration that was not delivered to the selected Harness.
• Publishing private paths, original filenames, EXIF, raw provider payloads, or user secrets.
• Starting a worker before the human decision and corrected train order settle.

Required proof

• Public Home/API regressions for validation, normalization, atomic publication, authenticated retrieval, cleanup, and crash reconciliation.
• ACP capability and explicit MCP-action coverage with unsupported-provider failure preserving staged UI state.
• Focused rendered PWA coverage for staging, removal, send, Card rendering, full-size dialog, accessibility, and refresh persistence.
• Full deterministic suite, typechecks, production build, version gates, and exact-build real attachment/screenshot persistence acceptance.
• Separate implementation, deterministic, live, commit, push, PR, train, main merge, release, deployment, and installation states.

Human decision

Approve or reject the complete seven-part contract in #41 (comment). A change to Harness delivery, the explicit MCP event, PNG limits, or message-owned lifetime changes the implementation and proof shape. The safe default is to keep the issue unowned.

[lukemaj]

Dispatcher note: the former parent #37 is closed as superseded by #71. This image and Screenshot Card task remains active as the separate attachment capability explicitly left out of the #71 core redesign. Its prerequisite #38 is closed, so the ready-for-agent label is current.

[lukemaj]

Current dispatcher disposition:

#38 is closed and the corrected combined train exists at 47923fd005590ffa57bf161fdb32bf6cc50221dd, so the product dependency is substantially unblocked. However, #41 overlaps the Messenger/PWA files currently being reconstructed for accepted #137/#139 behavior on the corrected train. Starting a second writer now would create avoidable conflict and stale ancestry.

Queue #41 as the next attachment/Card feature candidate after the corrected successor freezes. Start it from that exact successor, preserve the accepted complete-bubble/Card contracts, use one declared file claim, and require real exact-build attachment/screenshot persistence acceptance before human review. No worker is claimed yet and no code/live/publication action occurred under this note.

[lukemaj]

Architecture audit checkpoint for [task] Screenshot Card and attach an image:

The current combined product has typed Transcript Cards, but it does not yet have image or screenshot Card kinds. Home schema already contains a private path-backed attachments table, but there are no attachment insert/read/reconciliation/cleanup paths, no upload or media-serving route, no PWA file-selection pipeline, no Harness image-delivery contract, and no provider-neutral event that can create a screenshot Card. Existing ACP output extraction is text-only, and the current PWA regression explicitly rules out rendered images.

The narrow canonical seam is therefore Home-owned private Transcript attachments, not Workspace files. Images remain first-class Transcript objects, never markdown, raw ACP payloads, or automatic frame dumps.

Before implementation, five product decisions must be made:

1. Does a composer image also reach the Harness, or is it transcript-only in v1?
2. What explicit provider-neutral event creates a useful screenshot Card?
3. Is send immediate on file selection or staged as a removable chip, and are attachment-only sends allowed?
4. What are the storage/security/retention rules: accepted types, byte/pixel limits, magic-byte validation, SVG/animation policy, filename/EXIF handling, re-encoding, cleanup, and crash reconciliation?
5. What is the full-size viewing interaction?

Likely implementation ownership spans Home and Transcript persistence, Bot/Box delivery, ACP only if Harness image input or output is selected, PWA session types, a new image-attachment helper, Messenger composer, TranscriptCard rendering, focused daemon/PWA tests, and version files.

No implementation worker is claimed. This remains an enhancement shaping checkpoint and should not be dispatched until the five decisions above are explicit and the active core-file writers release their claims. No code, test, live, branch, or publication action was taken.

[lukemaj]

Human decision packet: minimal v1 image-attachment contract

No implementation worker is starting from this comment. This reduces the five open product questions to one bounded contract.

Verified seams

• Home already has an unused private path-backed attachments table, but no insert/read/reconcile/delete API.
• Public Transcript Cards currently support permission, dormant Host-grant, Bot-failure, and Computer kinds only.
• The PWA has no file selector or image renderer, and one focused regression explicitly preserves an attachment-free seam.
• OpenBot's ACP client currently sends text blocks only and discards initialization prompt capabilities.
• ACP v1 supports image content blocks only when the agent advertises agentCapabilities.promptCapabilities.image. A client must adapt to that capability: https://github.com/agentclientprotocol/agent-client-protocol/blob/main/schema/v1/schema.json
• Current codex-acp maps ACP image blocks into Codex image input: https://github.com/agentclientprotocol/codex-acp/blob/main/src/CodexAcpClient.ts
• Automatic image inference from arbitrary ACP/tool output would recreate the raw-log problem and cannot distinguish useful evidence from frame dumps.

Recommendation

Approve this complete v1 contract:

1. One staged composer image. The Plus action opens a file chooser. Selection creates one removable thumbnail chip. Nothing sends immediately. The user may send the image alone or with text.
2. The image reaches the Harness. On send, Talk includes one ACP image block plus any text only if the initialized adapter advertises image prompt capability. If it does not, fail before Transcript mutation with calm unsupported feedback and keep the staged chip. Never silently store a transcript-only image that the Bot did not receive.
3. One explicit Bot-output event. Add a product-owned openbot-transcript MCP tool with one attach_image action. It accepts a PNG path in the current Bot directory or shared drop plus concise alt text. Talk imports a private copy and appends one Bot-owned image Card to the current Channel. A Bot that wants to show a useful browser or Computer frame takes one deliberate screenshot, saves it, then invokes this tool. Do not infer attachments from arbitrary ACP output or attach every frame.
4. One normalized storage format. Persist sanitized PNG only, at most 8 MiB and 4096 by 4096 pixels. Browser uploads and MCP-path imports are decoded and re-encoded before persistence. Reject SVG, animation, malformed data, unsupported formats, excess bytes, and excess dimensions. Strip EXIF, original filename, and other metadata. Use opaque IDs and an authenticated same-origin media route; never expose the private path.
5. Message-owned lifetime. Stage to a private temporary file, atomically publish the attachment plus its message relation, reconcile temp/orphan/missing files at startup, and delete the private file when its message or Home is deleted. A failed import or database write leaves neither a visible message nor a durable orphan.
6. Accessible full-size view. Activating the Transcript thumbnail opens one focus-trapped image dialog with contain scaling, Close, Escape, and exact focus restoration. No pan, annotation, gallery, generic file chips, or multi-image carousel in v1.
7. Exact Transcript shape. The image is a first-class attachment/Card tied to one message, never markdown image syntax, a Workspace path, base64 in JSON, or raw ACP/tool data.

Why this shape

• It makes a composer attachment behave like a real Chat input instead of decoration.
• Capability gating follows the ACP contract and prevents provider-specific guessing.
• The explicit MCP action is provider-neutral and gives useful screenshots a deliberate event without automatic frame dumping.
• PNG normalization removes filename and camera metadata and avoids active SVG or animation behavior.
• One image per message keeps the first implementation and failure recovery bounded.

Decision needed

Approve or reject this contract as one decision. Approval unblocks a scoped #41 implementation only after the corrected combined successor is frozen. Any change to Harness delivery, the explicit MCP event, or normalization limits changes the implementation and proof shape.

Until confirmed, keep #41 unowned. Do not add ready-for-agent or agent-running, and do not start a second writer in the active Messenger/Home files.