test(post): retract the "these specs are red" notes — the merge fixed them

The warnings added in 6398542 were wrong. UG1, UG2 and LD1 were failing
because this branch predated e17a5dc, not because the behaviour they assert
was missing: merging user/main brought the FilePond upload gate and the
oriented-derivative slide dims, and all three pass with no product change.

Headers now point at e17a5dc for both mechanisms. Also corrects the plan's
.env note — the env layering is intentional (.env global, .env.<ENV> per
environment via the generated remote-*-<env> targets); the actual fault is
just that `-include .env` additionally requires makefile-valid syntax and
line 6 is not, which breaks make in both non-worktree clones.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
2026-07-24 23:40:48 +02:00
co-authored by Claude Opus 5
parent b02f27f559
commit d57041d316
3 changed files with 16 additions and 30 deletions
+7 -11
View File
@@ -3,19 +3,15 @@
// 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 feeds `img.width`/`img.height` (raw
// Root cause: entry-journal.html.twig fed `img.width`/`img.height` (raw
// getimagesize() of the ORIGINAL file — EXIF orientation ignored) into
// 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.
// 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.
//
// ⚠️ 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.
// Fixed in e17a5dc: slides now link a 2000px fit-within derivative and measure
// THAT file, and derivatives are re-encoded upright, so the attrs and the
// rendered pixels agree.
//
// The invariant tested here is environment-proof: whatever file the slide
// links to, its browser-rendered natural size must equal the data-pswp-*
+5 -13
View File
@@ -13,19 +13,11 @@
// 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.
// The gate lives in e17a5dc: submit is blocked unless EVERY FilePond item is
// processing-complete, with distinct messages for the failed and still-uploading
// cases. Both assert on .photo-convert-status, which post-form.js's setStatus()
// creates via photoStatusEl() — so a passing expectation here proves the THEME
// gate fired, not the form plugin's, whose own guard only raises alert().
const { test, expect } = require('@playwright/test');
const { fillEditor, findEntry, cleanupEntry, TEST_PHOTO } = require('../helpers');