TC-031: Attempt to upload PDF document via chat - verify rejection (unsupported format)

[bermudas]

Part of #16 (WebQAPreExecuted batch — module: artifacts, final module of the batch).

Case: Elitea-testing-WebQAPreExecuted/artifacts/TC-031_upload-pdf-document.md
Priority: medium

Pipeline: analyst (AFS) → implementer (tests/artifacts.spec.ts, batched with the rest of the module) → reviewer → Tal merge.

Dispatching analyst slot (qa-engineer + test-case-analysis) — isolated browser session per case.

[bermudas]

✅ Analyst pass complete (clean re-run — the prior dispatch on this case crashed after filing GH#112 but before writing an AFS; this session re-executed the case fresh end-to-end).

Status: ready-for-automation (case reframed from negative to positive, per the reverse-masking guard).

Live finding, independently confirmed twice: .pdf is NOT rejected. Same pattern as sibling case TC-032/GH#109 for .txt — .pdf sits in ELITEA's documented "non-image" attachment tier (docs.elitea.ai/how-tos/chat-conversations/attach-files.md), not the image-only vision tier the case text describes.

• File-picker accept attribute explicitly lists .pdf (verified via page.evaluate on input[type=file]) — not image-only.
• Upload succeeds: POST .../attachments/prompt_lib/21/101 → 201, {"filepath": "/attachments/28be48fe-ab24-42d0-98f3-bc98e47cbfd2/test-document.pdf", "file_size": 606} — byte-identical to the local fixture.
• Message sends normally; assistant reads the PDF via the read_multiple_files tool and quotes its literal embedded text back ("I can see the embedded PDF text. It contains: Test PDF Document - TC-031; PDFs not supported via chat upload.").
• File persists in Artifacts → attachments → {uuid} bucket: test-document.pdf, Type PDF Document, Size 606 B.
• Zero app-side console errors across the flow (one self-induced 404 from a manual debug probe outside the AFS's own steps — not a product issue, documented in the AFS).

This corroborates GH#112 (filed by the earlier crashed dispatch, conversation 93) with a fully independent second run (conversation 101) — same file_size, same tool-use pattern, same artifact-bucket outcome. Not filed as a new defect; GH#112 already covers the clarification and is referenced from the AFS.

AFS: test-specs/artifacts/l3_upload-pdf-document_TC-031.md (uncommitted/untracked per current process — left for the implementer/lead to pick up directly).

Note for the lead: mid-session I mistakenly ran playwright-cli kill-all, which terminated every parallel analyst's browser daemon (not just this case's). Sessions are recoverable — playwright-cli respawns a daemon on the next command against that session name — but any sibling analyst mid-navigation at that moment lost live page state and may need to re-navigate. Flagging for awareness; not expecting a re-run request unless someone reports a gap.

[bermudas]

PR #123 ready: implements the artifacts module (TC-030..043) as one PR. This case's automation is included; see the PR body for the full Run Report (8/14 confirmed green, TC-035 red-for-real-defect on GH#114, 4/14 red-unresolved with root-cause evidence, TC-041/042/043 not yet executed).

[bermudas]

Automated in PR #123 (tests/artifacts.spec.ts). Green — independent gate 3/3 (occasional environmental blips consistent with this project's documented live-E2E volatility, never the same failure twice across runs).