C14.14 r1: HTML from the syntax tree; pictures claimed by create_new; one scratch per PDF; diagram glyphs checked; rich copy reports

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

tasks/reviews/C14.14-r1.md

@@ -0,0 +1,21 @@
+FAIL
+
+- apps/ely-mark/src/output/pictures.rs:87 — The resource-folder name is inserted into a quoted HTML attribute without URL encoding or HTML escaping. Exporting to `note#1.html` copies the image successfully but emits `src="note#1_files/pic.png"`, so the browser treats the resource path as a fragment. On Linux, the valid filename `note" onerror="alert(1);x=.html` produces an actual `onerror` attribute; parsing the exported file and executing that handler with a mock `alert` confirms execution. Encode the folder as a URL path segment and escape the completed attribute. Evidence: `.work/C14.14-r1/windows-probe.log`, `linux-security-probe.log`.
+
+- apps/ely-mark/src/output/files.rs:90 — Every PDF operation for a tab shares `work/pdf`, deleting and overwriting another operation's HTML, PDF and cleanup directory. The action handlers launch background jobs without serializing them. Two concurrent exports with different text reproduced a destination containing the other job's text, a cleanup error after a destination was written, and a PDF that failed to open with `no objects found`. Give each operation its own scratch files, or serialize the tab's export/print operations through completion and cleanup. Evidence: `.work/C14.14-r1/linux-pdf-probe.log`.
+
+- apps/ely-mark/src/output/pictures.rs:103 — Resource-name collision detection compares strings case-sensitively, but copying overwrites existing files on case-insensitive filesystems. On native Windows, exporting `source-one/image.png` and `source-two/IMAGE.PNG` succeeds with two copy records and no warning, yet the output directory contains one file holding the second image's bytes; both references display that image. Allocate names without overwriting, accounting for the destination filesystem's filename equivalence. Evidence: `case_collision` in `.work/C14.14-r1/windows-probe.log`.
+
+- apps/ely-mark/src/output/pictures.rs:64 — Missing or unsupported pictures become `<img src="">`. For HTML this discards the original address, contrary to the documented preservation rule. For PDF, even a known missing image causes MuPDF to warn `html: cannot load image src=''`, failing the entire export before `left_out` can show its missing-picture notice. A document containing ordinary text and `![lost](gone.png)` cannot export or print; the explicitly excluded WebP and network pictures take the same path. Preserve missing addresses in HTML and represent known PDF omissions without asking Story to load an empty image, while retaining their diagnostics. Evidence: `.work/C14.14-r1/linux-probe.log`, `linux-pdf-probe.log`.
+
+- apps/ely-mark/src/output/pictures.rs:38 — Percent decoding is applied to network URLs before they are returned as supposedly unchanged addresses. `https://example.com/a%2Fb.png?q=a%26b` exports as `https://example.com/a/b.png?q=a&amp;b`, changing both the requested path and query parameters without a warning. Preserve network URL escaping; decode only the filesystem path used to read a local resource. Native Windows and WSL reproduce this in `.work/C14.14-r1/windows-probe.log` and `linux-probe.log`.
+
+- apps/ely-mark/src/output/mod.rs:52 — The default compiler blanks `data:` image destinations before picture handling can inspect them. A valid embedded PNG supported by the document renderer becomes `src=""` and is reported missing by its alt text; HTML/rich copying loses the image, and PDF export fails. The `data:` branch in `Placed::place` is consequently unreachable for these images. Process supported image destinations from the syntax tree before compilation discards them, retaining the protection against executable links and raw HTML. Evidence: `data_picture` in `.work/C14.14-r1/windows-probe.log`, and `data` in `linux-pdf-probe.log`.
+
+- reference/Ely-GPUI-Components/src/documents/diagram.rs:114 (c7a8607) — Counting retained text nodes does not establish that their characters found fonts. The WSL probe checked every loaded font face and found zero covering `𓀀`, yet `diagram_svg` returned success for both `A[𓀀]` and `A[ABC 𓀀]`. The exported SVG therefore substitutes missing glyphs without a diagram diagnostic, contradicting the stated missing-font error behavior. Validate glyph coverage/shaping failures and return an error so ElyMark preserves the diagram's source and reports its line. Evidence: `.work/C14.14-r1/linux-diagram-probe.log`.
+
+- apps/ely-mark/src/output/plain.rs:58 — Plain-text extraction handles `Node::Image` but drops `Node::ImageReference`, which has alt text and no children. `A ![a cat][cat].` followed by `[cat]: pic.png` exports as `A .\n`, whereas the equivalent inline image retains `a cat`. Preserve alt text for reference-style images as well. Native Windows and WSL reproduce `plain_reference="A .\n"` in `.work/C14.14-r1/windows-probe.log` and `linux-probe.log`.
+
+- apps/ely-mark/src/export/mod.rs:294 — Rich copying discards `Page.missing`, `Page.formulas` and `Page.diagrams` and only reports a fatal conversion/clipboard error. Copying a missing local image or an invalid formula therefore succeeds silently with missing content or fallback code; the user receives none of the available omission/error diagnostics. Retain the page metadata through clipboard writing and surface these warnings on successful copy, as the other output actions do. The missing-image and invalid-formula metadata returned by the same converter is demonstrated in `.work/C14.14-r1/windows-probe.log`.
+
+- apps/ely-mark/src/output/mod.rs:145 — Error positions are recovered by repeatedly searching the entire tree for the first matching source string. Two identical invalid formulas on lines 1 and 3 produce diagnostics for lines `[1, 1]`; repeated invalid diagrams have the same problem. Track each rendered occurrence's syntax-tree position rather than looking up its text from the beginning, so each warning identifies its actual line. Evidence: `same_bad_formula` in `.work/C14.14-r1/windows-probe.log` and `linux-probe.log`.