Correction on point 6 after follow-up: the root cause should be treated as workflow/harness design in the repo, not act-runner availability.
What I now think is more accurate:
act-runneris…
Approving based on the current head and the passing branch-local verification I ran for the photo-only scope in Issue #101.
Requesting changes because the latest head still fails the documented end-to-end photo validation in both Chromium projects, and the original issue explicitly requires these upload flows to be proven working by proper testing.
These alias-normalization cases are still failing in both documented browser projects on the latest head. In the local rerun, Quick Add never reaches the accepted-photo state for image/jpg or image/pjpeg, and the main Add Person flow still fails for image/x-png. So the branch still does not prove that these claimed format fixes actually work end-to-end.
This decode-fallback scenario is also still failing in both documented browser projects on the latest head. The expected backend-verification failure path is not what the test observes under the advertised validation command, so the PR still does not meet the original issue’s testing bar for this behavior.
These alias-normalization cases are still failing in both documented browser projects on the latest head. In the local rerun, Quick Add never reaches the accepted-photo state for image/jpg or image/pjpeg, and the main Add Person flow still fails for image/x-png. So the branch still does not prove that these claimed format fixes actually work end-to-end.
I re-reviewed this against the original issue scope for photo upload problems only: Quick Add, the main Add Person flow, and Person Profile uploads.
This decode-fallback scenario is also still failing in both documented browser projects on the latest head. The expected backend-verification failure path is not what the test observes under the advertised validation command, so the PR still does not meet the original issue’s testing bar for this behavior.
I re-reviewed this from the original issue scope again, not just the previous comments. I re-read Issue #101, reviewed the full PR delta against develop, checked the photo prep/upload changes in Quick Add, main Add Person, Person Profile, the S3 presign change, and the new tests.
This decode-fallback scenario is also still failing in both documented browser projects on the latest head. The expected backend-verification failure path is not what the test observes under the advertised validation command, so the PR still does not meet the original issue’s testing bar for this behavior.
These alias-normalization cases are still failing in both documented browser projects on the latest head. In the local rerun, Quick Add never reaches the accepted-photo state for image/jpg or image/pjpeg, and the main Add Person flow still fails for image/x-png. So the branch still does not prove that these claimed format fixes actually work end-to-end.
Still failing on the latest head in both Chromium projects. The decode-fallback scenario does not surface the expected backend-verification failure path under the documented Playwright run, so this branch still does not prove the user-facing recovery behavior end-to-end.
Requesting changes again because the latest head still fails the documented photo-format Playwright validation in both Chromium projects.
Still failing on the latest head in both Chromium projects. The image/jpg, image/pjpeg, and image/x-png cases never reach the accepted-photo state (Remove photo never appears), so the PR still does not prove that legacy JPEG/PNG MIME aliases work end-to-end under the documented test invocation.
Re-reviewed on the latest head commit. The targeted Vitest suite, npm run typecheck, npm run lint -- --quiet, and docker compose -f docker-compose.dev.yml exec -T archive-api pytest tests/unit/test_s3_storage.py still pass.
Still failing on the latest head in both Chromium projects. The decode-fallback scenario does not surface the expected backend-verification failure path under the documented Playwright run, so this branch still does not prove the user-facing recovery behavior end-to-end.