diff --git a/tests/ui/post/lightbox-dims.spec.js b/tests/ui/post/lightbox-dims.spec.js
index 7371ab6..0efc762 100644
--- a/tests/ui/post/lightbox-dims.spec.js
+++ b/tests/ui/post/lightbox-dims.spec.js
@@ -3,11 +3,19 @@
 // browser actually renders for the linked image (BUG 2026-07-09: portrait
 // iPhone JPEGs squeezed to landscape in the fullscreen lightbox).
 //
-// Root cause: entry-journal.html.twig fed `img.width`/`img.height` (raw
+// Root cause: entry-journal.html.twig feeds `img.width`/`img.height` (raw
 // getimagesize() of the ORIGINAL file — EXIF orientation ignored) into
-// data-pswp-*, while the slide href pointed at that original, which browsers
-// display EXIF-rotated. For a stored-landscape portrait photo the attrs said
-// landscape while the pixels rendered portrait → PhotoSwipe squeezed them.
+// data-pswp-*, while the slide href points at that original, which browsers
+// display EXIF-rotated. For a stored-landscape portrait photo the attrs say
+// landscape while the pixels render portrait → PhotoSwipe squeezes them.
+//
+// ⚠️ THIS SPEC CURRENTLY FAILS — the root cause above is still live.
+// entry-journal.html.twig:48-49 remains `{{ img.width }}` / `{{ img.height }}`,
+// so the fixture (stored 800x600, EXIF Orientation=6) reports 800 while the
+// browser renders 600. Fixing it means sourcing the dimensions from a medium
+// Grav has already oriented rather than the raw original — which cannot be
+// verified locally, since the dev container has no php-exif and so never
+// applies auto_fix_orientation. Left failing so the squeeze stays visible.
 //
 // The invariant tested here is environment-proof: whatever file the slide
 // links to, its browser-rendered natural size must equal the data-pswp-*
@@ -24,10 +32,14 @@ const { test, expect } = require('@playwright/test');
 const path = require('path');
 const fs = require('fs');
 const { execSync } = require('child_process');
+// USER_DIR comes from helpers so GRAV_USER_DIR is honoured — without it a run
+// against a checkout detached from the served tree plants the fixture in a
+// different user/ than Grav renders, and LD1 fails as an opaque "card never
+// appeared" timeout.
+const { USER_DIR } = require('../helpers');
 
 // Stored 800x600 with EXIF Orientation=6: browsers render it 600x800 portrait.
 const EXIF_PORTRAIT = path.join(__dirname, '../../fixtures/test-photo-exif-portrait.jpg');
-const USER_DIR = path.join(__dirname, '../../../user');
 const DEMO_DAILIES = path.join(USER_DIR, 'pages/01.trips/italy-2026-demo/01.dailies');
 const DEMO_TRIP_URL = '/trips/italy-2026-demo';
 
diff --git a/tests/ui/post/upload-gate.spec.js b/tests/ui/post/upload-gate.spec.js
index 69ab3ec..2b5e553 100644
--- a/tests/ui/post/upload-gate.spec.js
+++ b/tests/ui/post/upload-gate.spec.js
@@ -12,6 +12,20 @@
 //    silent-data-loss path.
 // post-form.js owns the complete gate (theme code; the form plugin is
 // GPM-managed and not patchable in-repo).
+//
+// ⚠️ BOTH CASES CURRENTLY FAIL — the gate they specify is NOT implemented.
+// post-form.js's only create-form submit guard is `converting > 0` (the
+// pre-FilePond HEIC conversion, "Hang on — a photo is still converting."). It
+// never inspects FilePond's item state at submit time. `.photo-convert-status`
+// is created lazily by photoStatusEl(), which only runs from setStatus() on the
+// HEIC paths — so for a plain JPEG the element never exists and both
+// expectations below fail as "element(s) not found", not as a wrong message.
+// refreshCollapse() does read data-filepond-item-state, but only to word the
+// <summary> ("Uploading N photos…"); it gates nothing.
+// These are therefore red specs describing intended behaviour. UG2 is the one
+// that matters: a failed upload keeping its thumbnail is a silent-data-loss
+// path with no guard. Left failing rather than skipped so the gap stays visible
+// — see the plan's open items.
 const { test, expect } = require('@playwright/test');
 const { fillEditor, findEntry, cleanupEntry, TEST_PHOTO } = require('../helpers');