Roadmap item 7 — File attachments

[BabuBahir]

Roadmap item 7 — File attachments

Status update (Aug 2026): OUT OF SCOPE by product decision. ROADMAP.md
item 7 and AGENTS.md both mark this "LAST PRIORITY / DO NOT PROPOSE" — real
file upload is explicitly out of scope for this demo and must not be brought
up in planning or proposed as work. This issue stays open (per the roadmap),
but treat it as closed for planning purposes. Do not assign, do not
implement, do not surface in plans.

---

Reference: ROADMAP.md item 7; AGENTS.md §1.2 (Add from List / Add New / Edit / Delete pattern for reusable items).

Gap

Attachments on a protocol are just filename strings in the related list — there is no real upload, storage, or retrieval.

Existing state

protocols.related_items / detail page render attachment entries as text only. No attachments table, no file endpoints.

Recommended design

• attachments 1:N table (protocol_id, original filename, stored path/name, kind, uploaded_by, uploaded_at).
• Real upload storage (local disk or object storage), GET (download / inline preview), DELETE endpoints.
• Size + type validation; tie uploaded_by to the authenticated user (see item 4).
• UI on the detail page: upload list with add/delete, reusing the Add-from-List pattern.

Tests

Server: upload/download/delete incl. validation + 404s. Client: attachment list + upload form. e2e: upload a file and see it listed.