Use the reviewed media contract

Driver App media is not one capability. Chat images, chat signatures, document selection, status photos, returned images, and delivery proof have different entry points and ownership. A visible control or preview proves only local UI state; it does not prove authorization, upload, storage, delivery, or proof.

This contract is source-api-only. Public procedures stop before picker, camera, signature, upload, message, status, or provider effects.

Availability

Media surface	Current public boundary
Chat image	Photo-library handler and local preview exist; send remains blocked
Chat signature	Canvas output becomes the same local image candidate; it is not identity, consent, or delivery proof
Chat document	Picker and file-state definitions exist, but the action is not rendered and the file is not sent
Chat camera	No productive camera import or call exists
Status image	Configured statuses can request rear-camera capture before a status request
Returned media	A returned source can render as an image; storage, safety, and availability remain unproved
PIN or status proof	Media presence does not validate PIN, location, status, pickup, or delivery

Prerequisites

• Use only an authenticated Driver context and an order the Driver is authorized to handle.
• Resolve server authorization before any upload or message/status mutation.
• Treat images, signatures, filenames, metadata, coordinates, order references, and returned sources as private.
• Separate permission, picker/camera opening, selection/capture, preview, request, persistence, association, and downstream delivery.
• Keep every documentation runtime media provider replaced or denied; a simulator is not a hermetic media fixture.

Responsibility boundaries

Owner	Responsibility
Driver App UI	Render controls, local preview/canvas, validation copy, and cancellation/error states
Photo/document provider	Permission, selection, metadata, file access, and cancellation
Camera provider	Permission, capture, device photo-library side effects, and returned asset
Signature canvas	Local drawing and image-shaped output only
Client request layer	Construct media/message or status intent and preserve an honest result boundary
API	Authorize before effects, validate media, persist atomically, associate with the intended record, and return a receipt
Storage/media provider	Content lifecycle, access control, retention, deletion, and serving
Product/security owner	Define what can count as status or delivery proof and accept negative tests

Inputs and result

Chat image and signature

The current chat can create a local image candidate from the photo library or signature canvas. Both converge on an image-shaped message path. The client can clear preview and signature state immediately after invoking send, before settlement. A disappearing preview is therefore not a receipt.

Media send is excluded: the reviewed write path does not yet establish that authorization always precedes upload and persistence.

Documents and camera

Document-picker code and local file state exist, but the productive composer does not render that action and the outgoing message ignores the document. Chat camera capture is not implemented. Native declarations, tutorial text, or camera use elsewhere do not change those boundaries.

Status images

Configuration can require a rear-camera image for a status. The client accepts specific image types and can prepare a multipart candidate before a status request. Capture may also ask the OS to save a copy to photos. None of these states proves effective permission, correct location, status authorization, association, persistence, or delivery completion.

Security and privacy

• Authorize the Driver, order, action, and recipient before upload or write.
• Validate type, size, content, metadata, and association server-side.
• Do not treat a filename, MIME label, signature bitmap, photo, PIN field, or coordinate as trusted proof.
• Do not publish provider locations, private request shapes, storage paths, source URLs, media bytes, tokens, order identifiers, or security test detail.
• Define retention, deletion, access, and partial-failure cleanup across API and storage owners.
• Reject remote media and real picker/camera/canvas providers in evidence capture unless a separately reviewed zero-egress fixture is accepted.

Limits and failure states

State	Required interpretation
Control visible	UI availability only
Permission declared	Not requested, granted, effective, or sufficient
Picker/camera opened	Provider handoff only
Local candidate	Sensitive local state; not upload
Preview removed	Client state cleared; provider copy/temporary data may remain
Document selected	Definition/local state only; transmission is unwired
Signature completed	Image candidate, not consent or identity proof
Status image captured	Candidate for a separate status request, not status success
Returned image rendered	Presentation only; not authorization, safety, retention, or currentness
Error after request intent	Earlier upload or persistence may have occurred; do not retry blindly

Troubleshooting

A camera or document control is expected in chat

Do not infer it from permissions or adjacent flows. Current chat uses the photo library, has no camera call, and does not productively render/send documents.

A preview disappears after Send

Treat that as immediate local cleanup. Verify an authoritative, authorized server receipt and partial-effect reconciliation before claiming success or offering retry.

A status requires a photo

Keep permission, capture, optional photo-library copy, multipart construction, status authorization, record association, and completion separate. Do not use a photo as PIN, location, or delivery proof by itself.

An existing image does not load

Do not open or fetch it in documentation evidence. The source, access policy, network, cache, storage lifecycle, and authorization can fail independently.

Related guides: Use the reviewed communication contract · Run governed evidence safely · Add and view chat media · Complete a delivery · Use force-status actions