BUG: PDF files accepted by library upload but cannot be read by Amico — no upfront warning

[boyarnaito]

Summary

The Amicode library upload UI accepts PDF files without error, but after upload
Amico reports it cannot read the file. There is no upfront indication that PDFs
are unsupported or only partially supported — the user discovers the limitation
only after completing the upload. The expected behaviour is either that PDFs are
readable after upload, or that the UI communicates the limitation before or
during the upload flow (e.g. via a picker filter, a format warning, or inline
messaging).

Context

• Extension: harmoniqs.amicode 0.2.2
• OS: Linux 6.18.33.2-microsoft-standard-WSL2 x86_64
• Engine pin: v1.18.10-amicode.11 (harmoniqs/opencode, base v1.18.10)
• Activity: uploading a PDF via the library upload UI, then asking Amico to read it

Expected vs actual

Expected: PDFs uploaded to the library are readable by Amico; or, if PDF
reading is unsupported, the upload UI communicates this before the file is
submitted (picker filter, format warning, or inline note).
Actual: PDF upload succeeds silently; Amico then reports it cannot read the
file. No warning is shown at any point before or during upload.

Diagnostics

• No active run at time of report
• No absolute paths, no binary uploads
• Related open issue: BUG: .docx files rejected by file picker and at upload — format not supported #474 (.docx rejection — different failure
  mode: rejected at upload vs silently accepted then unreadable)

---

intake: not-ready — mature per the maturity contract before picking up
suggested_path: B
diagnostics: inline
upstream: n/a