fix: publish screen library images reliably - #3141
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Code-analysis diffPainscore total: 8347.79 → 8347.79 (0) |
🧪 UI test report — ✅ all greenSuites
📊 Coverage (unit)
⏱ 10 slowest test cases
|
![chip-peanut-bot[bot]](https://avatars.githubusercontent.com/in/2915219?s=60&v=4){kind=small}
There was a problem hiding this comment.
Chip review — no blocking findings — this is not an approval
The Cloudflare metadata-based reuse path is coherent, but the capture command now exits successfully for real per-screen runtime failures as well as intentional gaps.
Findings
- MAJOR · scripts/screens/capture.ts:483 · Keep real per-screen runtime failures red
The new success path removes the only aggregate failure signal, but the per-screen catch above also handles real failures such as an HTTP mismatch, missing synthetic response, local transport failure, stabilization timeout, or screenshot error and records them asfailed(orunavailablefor historical runs). For example, if one current screen hits an unmapped API request, the catch writes that failure tocapture.json, this function returns with exit code 0, and the capture job is green even though the PR description and documentation say runtime failures remain red. Distinguish expected publishable gaps from caught capture/runtime failures and retain a nonzero exit for the latter; add a regression case that injects one such failure and asserts the command status.
Checked clean
- Confirmed the detached worktree HEAD and merge base exactly match the supplied SHAs.
- Reviewed the capture, report, publication, and workflow status propagation paths.
- Checked Cloudflare Images lookup, upload, metadata repair, custom-ID, and public-delivery behavior against the current official API contract.
- Ran the changed Cloudflare storage tests plus worker and public-origin tests; all 11 passed, and git diff --check passed.
- Exact-head unit, typecheck, screen-tests, format, eslint, native-export, and policy checks were green when reviewed; capture/report checks were still running.
Security review: did not run — this change has no security, privacy or money surface, so it was not asked. This review is one reviewer short.
Third opinion: did not run — claude-api_error. This review is one reviewer short.
Exact head: a4f0deebaba5 · Context: repo, provider · Took 6m
There was a problem hiding this comment.
Chip review — no blocking findings — this is not an approval
Current-revision capture failures are red again, but caught runtime failures in a historical baseline still exit successfully and can be published as ordinary gaps.
Findings
- MAJOR · scripts/screens/capture-status.mjs:2 · Keep historical runtime failures red
When the baseline predates the fixture registry,historicalis true. Any exception from an otherwise supported screen—such as an unexpected HTTP response, missing synthetic response, transport failure, or screenshot timeout—is caught and recorded asunavailable; this helper then returns 0 solely because the run is historical. Thecapture (before)job therefore succeeds and the publisher can expose a baseline produced by a real harness/runtime failure. Expected historical gaps are already classified before the capture try block, so preserve a separate failure signal for caught exceptions (or retainfailedfor exit calculation) and return nonzero for those failures on both revisions.
Checked clean
- Confirmed the detached worktree HEAD, trusted author, dev base, merge base, and exact supplied SHAs.
- Reviewed the complete six-file diff and traced current and historical capture status through run-capture, capture, report, and the always-running publisher workflow.
- Confirmed Cloudflare image lookup, upload, metadata repair, full source-identity validation, and public variant checks against the official API contract.
- Focused capture-status and Cloudflare storage tests pass locally; exact-head screen-tests, unit, typecheck, eslint, format, native-export, analyze, and policy checks are green. Capture/report checks were queued or running when reviewed.
- The broader local screen-test command could not load dependencies absent from the detached worktree; exact-head CI covers that suite.
Security review by moonshotai/kimi-k3: 0 finding(s), marked with the model name. It reads the diff only and answers only security, privacy and money, so treat its findings as advice.
Third opinion: did not run — claude-api_error. This review is one reviewer short.
Exact head: 97e7685589f0 · Context: repo, cloudflare-docs · Took 7m
There was a problem hiding this comment.
Chip review — no blocking findings — this is not an approval
Clean at this head. Runtime failures remain red on both current and historical captures, while expected catalogue gaps stay publishable; the Cloudflare upload and reuse changes fail closed on identity or metadata mismatches.
Checked clean
- Confirmed the detached worktree head and merge base exactly match the supplied SHAs.
- Verified caught per-screen exceptions are recorded as failed for both current and historical revisions and captureExitCode returns non-zero whenever any failed result exists.
- Verified expected excluded, unavailable, and absent states remain publishable without masking harness, build, or uncaught runtime failures.
- Checked Cloudflare image ID length, full source digest and filename metadata matching, legacy metadata repair, mismatch rejection, and public-delivery validation against the current Cloudflare Images API contract.
- Focused capture-status and Cloudflare storage tests pass; exact-head typecheck, lint, format, unit, screen-tests, native-export, and aggregate CI gates are green. The detached worktree lacks dependencies for the unrelated full local screen-test sweep, and the exact-head visual capture jobs were still running when reviewed.
Security review: did not run — this change has no security, privacy or money surface, so it was not asked. This review is one reviewer short.
Third opinion: did not run — claude-api_error. This review is one reviewer short.
Exact head: e4e246c3f189 · Context: repo, ci, provider-docs · Took 6m
There was a problem hiding this comment.
Chip review — no blocking findings — this is not an approval
No findings at the reviewed head.
Checked clean
- Current and historical per-screen exceptions remain failed and force a nonzero capture exit code; focused regression tests and the exact-head screen-tests check pass.
- Cloudflare image lookup, metadata reuse, legacy repair, and public delivery validation fail closed; focused storage tests pass.
- Updated GitHub Actions references resolve to the stated signed upstream releases, Node 22 is allowed by package engines, and the exact-head aggregate CI check is green; standalone visual capture jobs were still running when checked.
Security review by moonshotai/kimi-k3: 0 finding(s), marked with the model name. It reads the diff only and answers only security, privacy and money, so treat its findings as advice.
Third opinion: did not run — claude-api_error. This review is one reviewer short.
Exact head: 1b750c19ede7 · Context: repo · Took 6m
🖼 Visual diff — 17 screens moved23 of 84 shots changed · 61 identical · baseline
job summary · before/after/diff images — artifact Fixture screenshots, no backend. Advisory — this check never blocks a merge. Posted from the default branch by ds-shots-comment.yml; the report it renders is untrusted data. |
There was a problem hiding this comment.
Chip review — no blocking findings — this is not an approval
The reusable baseline path has two major defects: harness-changing PRs cannot be compared, and scheduled baselines can never satisfy the resolver's branch identity check.
Findings
-
MAJOR · .github/workflows/screen-library.yml:100 · Capture the base with the PR harness when identities change
PRs always skip this job, so their before manifest comes from a dev run whose harness and fixture hashes were computed from the base checkout. The after capture hashes the PR checkout, and compare() rejects any mismatch. This head itself changes scripts/screens, so its comparison will throwCapture environments differ; the same happens for any PR changing capture scripts, catalogue/surfaces, fixtures, or the lockfile. Reuse an external baseline only when its environment identity matches, and otherwise capture the base target with the PR harness (or conditionally restore the before capture). -
MAJOR · scripts/screens/resolve-baseline.mjs:48 · Accept the actual identity of scheduled baseline runs
GitHub records scheduled workflows against the latest commit and branch of the default branch, which ismainhere, even when their steps check outdev. Requiringrun.head_branch === 'dev'andrun.head_sha === expectedBasetherefore rejects every scheduled baseline artifact. Once no successful dev integration artifact is younger than 30 hours, every PR publisher ends withNo trusted baseline capture. Validate a scheduled run as a trusted default-branch workflow and use the downloaded capture manifest to bind the captured dev commit, or dispatch a separately verified dev-scoped run whose metadata can satisfy this check.
Checked clean
- Exact detached head, requested base, trusted author, PR metadata, and merge base match the supplied values.
- Current and historical per-screen runtime exceptions are recorded as failed and produce a nonzero capture exit code; expected pre-harness gaps remain unavailable.
- Cloudflare Images reuse and legacy repair validate full source metadata and public delivery before publishing.
- Exact-head ci-success, screen-tests, typecheck, lint, format, and unit checks passed; capture_after was still running when reviewed.
- Targeted local status, artifact, storage, and provenance tests passed; the local core test could not load pngjs in the detached worktree, while the exact-head screen-tests CI gate covering it passed.
Security review by moonshotai/kimi-k3: 0 finding(s), marked with the model name. It reads the diff only and answers only security, privacy and money, so treat its findings as advice.
Third opinion: did not run — claude-api_error. This review is one reviewer short.
Exact head: 5626936a5df9 · Context: repo, web · Took 12m
There was a problem hiding this comment.
Chip review — no blocking findings — this is not an approval
Four findings remain: required PR-harness captures can fall back to incompatible baselines, the daily schedule is not registered on the default branch, scheduled checkouts can split revisions, and the format gate is red.
Findings
-
MAJOR · .github/workflows/screen-library-publish.yml:53 · Fail closed when the required PR-harness baseline is missing
The refs job marks identity-changing PRs as requiring capture_before, but that requirement is not passed into the publisher. If that base capture aborts before writing capture.json (for example, the new harness cannot build the old base), this branch silently downloads an external baseline produced by the old dev harness and compares it with an after capture produced by the PR harness. That can publish false visual changes instead of failing closed. Pass the required-baseline mode to the reusable workflow and reject a missing same-run base whenever capture_before was required. -
MAJOR · .github/workflows/screen-library-baseline.yml:7 · Register the daily baseline scheduler on the default branch
This workflow is newly added only by a PR targeting dev, while the repository default branch is main and main does not contain this file. GitHub only schedules workflows present on the default branch, so after 30 hours without a successful dev integration artifact the resolver has no fresh baseline and ordinary PR publication fails. Install a default-branch scheduler (or an equivalent default-branch stub that runs the trusted dev capture) before relying on daily refreshes. -
MAJOR · .github/workflows/screen-library-baseline.yml:28 · Pin both baseline checkouts to one dev revision
The harness and target checkouts independently resolve the moving dev ref. If dev advances between these sequential steps, the artifact is named for the target SHA but was captured with a different harness revision; the resolver then accepts that mislabeled baseline for a later PR. Resolve one immutable dev SHA first and use it for both checkouts and the artifact identity. -
MINOR · scripts/screens/resolve-baseline.mjs:51 · Apply Prettier to the baseline resolver
The exact-head format check fails on scripts/screens/resolve-baseline.mjs; Prettier collapses this two-line conditional. Run the repository formatter on the resolver so the required format and ci-success checks return green.
Checked clean
- The detached worktree head, supplied base SHA, merge base, PR author, base ref, and PR metadata all matched the request.
- P1/P2: current and historical per-screen runtime exceptions remain failed and force a nonzero capture exit; focused capture-status tests passed.
- P4: scheduled/manual artifacts bind the checked-out dev SHA while the resolver verifies the default-branch scheduler and the publisher rechecks the capture manifest commit.
- P5/P6: harness-change detection now uses native git pathspecs and conservatively recaptures on any nonzero diff result, without depending on rg.
- Focused artifact-selection, capture-status, Cloudflare storage, public-origin, and worker tests passed (18/18); syntax and git diff checks passed.
- Exact-head unit, screen-tests, typecheck, ESLint, DS lint, native export, and backend baseline checks were green; format and ci-success were red, while visual capture jobs were still running.
- The repository default branch is main, and main does not contain .github/workflows/screen-library-baseline.yml.
Security review by moonshotai/kimi-k3: 0 finding(s), marked with the model name. It reads the diff only and answers only security, privacy and money, so treat its findings as advice.
Third opinion: did not run — claude-api_error. This review is one reviewer short.
Exact head: c24d28e24998 · Context: repo · Took 13m
There was a problem hiding this comment.
Chip review — no blocking findings — this is not an approval
Two distinct major baseline defects remain: the daily scheduler is not installed on the default branch, and its two dev checkouts can resolve different revisions.
Findings
-
MAJOR · .github/workflows/screen-library-baseline.yml:7 · Register the daily baseline scheduler on the default branch
The repository default branch is main, and the remote main branch still has no screen-library-baseline.yml. GitHub only triggers scheduled workflows whose file exists on the default branch, so merging this dev-targeted PR cannot start the advertised daily refresh. After 30 hours without a successful dev integration artifact, ordinary PR publication fails with no trusted baseline. Install a default-branch scheduler before relying on daily reuse, or keep a same-run base-capture fallback until it is active. -
MAJOR · .github/workflows/screen-library-baseline.yml:7 · Install the daily scheduler on the default branch before relying on it
This workflow is still added only by a PR targeting dev, while the repository default branch is main and does not contain the file. GitHub therefore never registers its schedule; once no successful dev integration artifact is younger than 30 hours, an ordinary PR cannot resolve a baseline. Land the scheduler on main first, or retain same-run base capture until a scheduled baseline has been verified. -
MAJOR · .github/workflows/screen-library-baseline.yml:28 · Pin both daily checkouts to one dev revision
The harness and target checkouts still resolve the moving dev ref independently. If dev advances between these sequential steps, the artifact is named for the newer target SHA but was produced by the older harness, so the resolver accepts a mislabeled baseline and the next PR comparison rejects it as a different capture environment. Resolve one immutable dev SHA and use it for both checkouts and the artifact name. -
MAJOR · .github/workflows/screen-library-baseline.yml:28 · Pin both daily checkouts to the same dev commit
Both checkout steps still dereference dev separately. A dev push between them can pair an older harness with a newer target, while the artifact name records only the target SHA; that trusted artifact then fails environment compatibility when reused. Resolve dev once and check out both directories at that exact commit.
Checked clean
- Confirmed the detached worktree head, supplied base SHA, merge base, trusted author, base ref, and PR metadata exactly match the requested review identity.
- P1/P2: current and historical per-screen runtime exceptions remain failed and force a nonzero capture exit, while expected unavailable gaps remain publishable.
- P3/P5/P10: harness-change detection now uses native git pathspecs, treats every nonzero result conservatively, and the exact-head PR scheduled capture_before rather than skipping it.
- P4: scheduled-run provenance uses the repository default branch, while artifact naming and publisher manifest validation bind the captured dev merge base.
- P6: a missing same-run base can select an external artifact, but any actual harness or fixture mismatch is rejected by compare() before publication, so this path already fails closed.
- P9: the resolver is formatted; the exact-head format and aggregate CI checks pass.
- Focused artifact-selection, capture-status, Cloudflare storage, public-origin, and worker tests passed (18/18); changed JavaScript syntax and diff whitespace checks passed.
- Exact-head aggregate CI, unit, screen-tests, typecheck, ESLint, DS lint, native export, workflow analysis, authorship, and backend-baseline checks are green; the visual capture jobs were queued when reviewed.
- Reviewed Cloudflare source-metadata reuse, legacy repair, public-delivery validation, artifact provenance, PR binding, baseline age, and commit checks without finding another reachable defect.
Security review by moonshotai/kimi-k3: 0 finding(s), marked with the model name. It reads the diff only and answers only security, privacy and money, so treat its findings as advice.
Third opinion: did not run — claude-api_error. This review is one reviewer short.
Exact head: e400d96d8cf5 · Context: repo, ci, web · Took 9m
There was a problem hiding this comment.
Chip review — no blocking findings — this is not an approval
Three distinct major defects remain: the daily scheduler is not installed on the default branch, its checkouts can split revisions, and capture normalization can conceal later video changes.
Findings
-
MAJOR · .github/workflows/screen-library-baseline.yml:7 · Register the daily baseline scheduler on the default branch — also flagged by moonshotai/kimi-k3
The repository default branch is main, and main still has no screen-library-baseline.yml, so GitHub has not registered this schedule. After 30 hours without a successful dev integration artifact, ordinary PR publication has no trusted baseline. Install the scheduler on main before relying on daily reuse, or retain same-run base capture until it is active. -
MAJOR · .github/workflows/screen-library-baseline.yml:7 · Register the daily baseline scheduler on the default branch
This workflow is still added only by a PR targeting dev, while the repository default branch is main and does not contain the file. GitHub therefore cannot trigger the advertised daily refresh; once no exact dev integration artifact is younger than 30 hours, baseline resolution fails. Land the scheduler on main first or keep a same-run fallback until a scheduled run is verified. -
MAJOR · .github/workflows/screen-library-baseline.yml:7 · Install the daily scheduler on the default branch before relying on it
The remote default branch is main, but main still returns no workflow at this path. Merging this dev-targeted PR alone cannot register the schedule, leaving product-only PR previews dependent on a recent integration artifact. Install a default-branch scheduler before removing the guaranteed same-run baseline. -
MAJOR · .github/workflows/screen-library-baseline.yml:28 · Pin both baseline checkouts to one dev revision — also flagged by moonshotai/kimi-k3
The harness and target checkouts still resolve the moving dev ref independently. If dev advances between these sequential steps, the artifact is named for the newer target SHA but carries the older harness identity, so a later exact-base comparison rejects the supposedly trusted baseline. Resolve one immutable dev SHA and use it for both checkouts and the artifact name. -
MAJOR · .github/workflows/screen-library-baseline.yml:28 · Pin both daily checkouts to one dev revision
Both checkout steps still dereference dev separately. A dev push between them can pair one revision's harness with another revision's target while the artifact name records only the target SHA, producing a successful but unusable daily baseline. Resolve dev once, then check out both directories at that exact commit. -
MAJOR · .github/workflows/screen-library-baseline.yml:28 · Pin both daily checkouts to the same dev commit
The scheduled job still checks out dev twice rather than binding both trees to one SHA. If dev moves between checkout operations, the capture manifest identifies a harness/target combination that no repository revision represents and reuse fails environment validation. Resolve and pin one dev commit for both checkouts. -
MAJOR · scripts/screens/run-capture.mjs:47 · Do not replace base media with the head assets
This copies the harness checkout's videos into every distinct target without checking that the target contains one of the known legacy HEVC encodings. A future PR that changes either video together with any capture-harness or fixture path will run capture_before, but both before and after builds will use the head video, so the captured 0.5-second PWA frame can appear unchanged while the manifest claims the base commit. Restrict substitution to the known legacy hashes and record it in adapter provenance so later media changes remain observable.
Checked clean
- Confirmed the detached worktree head, supplied base SHA, merge base, trusted author, base ref, and PR metadata exactly match the requested review identity.
- P1/P2: current and historical per-screen runtime exceptions remain failed and force a nonzero capture exit, while expected unavailable gaps remain publishable.
- P3/P5: identity-changing PRs select capture_before using native git pathspecs; this exact head queued that job.
- P4: scheduled and manual artifacts bind the captured dev SHA while source-run provenance is validated against the repository default branch.
- P6: an external fallback with a real harness, fixture, renderer, adapter, profile, or origin mismatch is rejected by compare() before publication.
- P9: the resolver is formatted and the exact-head format check is green.
- Focused dependency-free artifact-selection, capture-status, and Cloudflare storage tests passed (14/14). The full local screen suite could not load uninstalled workspace dependencies in the detached worktree; the exact-head screen-tests CI check is green.
- Exact-head aggregate CI, unit, screen-tests, typecheck, ESLint, formatting, native export, workflow analysis, authorship, and backend-baseline checks are green; visual capture jobs were still queued when reviewed.
- The new H.264 assets retain the original dimensions and durations and decode with high frame similarity; the reported issue is the unconditional future target substitution, not this conversion's fidelity.
- Reviewed Cloudflare metadata reuse and repair, public delivery checks, artifact age and provenance, PR binding, commit matching, and failure-status propagation without finding another reachable defect.
Security review by moonshotai/kimi-k3: 2 finding(s), marked with the model name. It reads the diff only and answers only security, privacy and money, so treat its findings as advice.
Third opinion: did not run — claude-api_error. This review is one reviewer short.
Exact head: f8c0fee71850 · Context: repo, ci, web · Took 13m
There was a problem hiding this comment.
Chip review — changes requested
One blocking workflow-secret exposure and three distinct major correctness defects remain.
Findings
-
BLOCKING · .github/workflows/screen-library.yml:172 · Keep pull request code out of the credentialed publisher
This local reusable-workflow reference resolves from the same pull request commit as the caller. The callee then checks out that pull request head, receives the repository Cloudflare publishing token plus a write-capable GitHub token, and runsscripts/screens/publish-run.mjsfrom that checkout. After this merges, any same-repository pull request can change the callee or publisher script and exfiltrate the token or mutate the public Images/R2 gallery before review. Keep the secret-bearing workflow and every executable publisher file pinned to a trusted revision (or trigger a trustedworkflow_run) and consume pull request captures only as validated data. -
MAJOR · .github/workflows/screen-library-baseline.yml:7 · Register the daily baseline scheduler on the default branch
The repository default branch ismain, where this workflow file is still absent, while this pull request targetsdev. GitHub therefore cannot register the advertised schedule; after 30 hours without a matching integration artifact, ordinary pull request publication has no trusted baseline. Install the scheduler onmainbefore relying on daily reuse, or retain a same-run base capture until it is active. -
MAJOR · .github/workflows/screen-library-baseline.yml:7 · Register the daily baseline scheduler on the default branch
The repository default branch ismain, where this workflow file is still absent, while this pull request targetsdev. GitHub therefore cannot register the advertised schedule; after 30 hours without a matching integration artifact, ordinary pull request publication has no trusted baseline. Install the scheduler onmainbefore relying on daily reuse, or retain a same-run base capture until it is active. -
MAJOR · .github/workflows/screen-library-baseline.yml:7 · Install the daily scheduler on the default branch before relying on it
This workflow is still added only by a pull request targetingdev; the repository default branch ismainand has no file at this path. Merging this pull request alone cannot start scheduled baseline refreshes, so product-only pull requests eventually fail baseline resolution. Land the scheduler onmainfirst or keep a guaranteed same-run fallback. -
MAJOR · .github/workflows/screen-library-baseline.yml:7 · Register the daily baseline scheduler on the default branch
The repository default branch ismain, where this workflow file is still absent, while this pull request targetsdev. GitHub therefore cannot register the advertised schedule; after 30 hours without a matching integration artifact, ordinary pull request publication has no trusted baseline. Install the scheduler onmainbefore relying on daily reuse, or retain a same-run base capture until it is active. -
MAJOR · .github/workflows/screen-library-baseline.yml:7 · Register the daily baseline scheduler on the default branch
The repository default branch ismain, where this workflow file is still absent, while this pull request targetsdev. GitHub therefore cannot register the advertised schedule; after 30 hours without a matching integration artifact, ordinary pull request publication has no trusted baseline. Install the scheduler onmainbefore relying on daily reuse, or retain a same-run base capture until it is active. -
MAJOR · .github/workflows/screen-library-baseline.yml:7 · Install the daily scheduler on the default branch before relying on it
This workflow is still added only by a pull request targetingdev; the repository default branch ismainand has no file at this path. Merging this pull request alone cannot start scheduled baseline refreshes, so product-only pull requests eventually fail baseline resolution. Land the scheduler onmainfirst or keep a guaranteed same-run fallback. -
MAJOR · .github/workflows/screen-library-baseline.yml:28 · Pin both baseline checkouts to one dev revision
The harness and target checkouts still resolve the movingdevref independently. Ifdevadvances between these sequential steps, the artifact is named for the newer target SHA but carries the older harness identity, so the next exact-base comparison rejects the supposedly trusted baseline. Resolve one immutabledevSHA first and use it for both checkouts and the artifact name. -
MAJOR · .github/workflows/screen-library-baseline.yml:28 · Pin both daily checkouts to one dev revision
Both checkout steps still dereference the movingdevbranch separately. A push between them can combine one revision's harness with another revision's target while the artifact name records only the target SHA, producing a successful but unusable baseline. Resolvedevonce and check out both directories at that exact commit. -
MAJOR · .github/workflows/screen-library-baseline.yml:28 · Pin both daily checkouts to the same dev commit
The scheduled job still checks outdevtwice instead of binding both trees to one SHA. Ifdevmoves between checkout operations, the capture manifest describes a harness/target combination that no repository revision represents and reuse fails environment validation. Resolve and pin one commit for both checkouts. -
MAJOR · .github/workflows/screen-library-baseline.yml:28 · Pin both baseline checkouts to one dev revision
The harness and target checkouts still resolve the movingdevref independently. Ifdevadvances between these sequential steps, the artifact is named for the newer target SHA but carries the older harness identity, so the next exact-base comparison rejects the supposedly trusted baseline. Resolve one immutabledevSHA first and use it for both checkouts and the artifact name. -
MAJOR · .github/workflows/screen-library-baseline.yml:28 · Pin both daily checkouts to one dev revision
Both checkout steps still dereference the movingdevbranch separately. A push between them can combine one revision's harness with another revision's target while the artifact name records only the target SHA, producing a successful but unusable baseline. Resolvedevonce and check out both directories at that exact commit. -
MAJOR · .github/workflows/screen-library-baseline.yml:28 · Pin both daily checkouts to the same dev commit
The scheduled job still checks outdevtwice instead of binding both trees to one SHA. Ifdevmoves between checkout operations, the capture manifest describes a harness/target combination that no repository revision represents and reuse fails environment validation. Resolve and pin one commit for both checkouts. -
MAJOR · scripts/screens/run-capture.mjs:47 · Do not replace base media with the head assets
This still copies the harness checkout's videos into every distinct target without verifying that the target contains one of the known legacy HEVC files. A future pull request that changes either video together with any harness or fixture path will runcapture_before, but both before and after builds will use the head video, hiding the media change while the baseline manifest claims the base commit. Restrict substitution to the known legacy hashes and record it in adapter provenance so later media changes remain observable. -
BLOCKING · .github/workflows/screen-library-publish.yml:24 · [moonshotai/kimi-k3] Publisher runs PR-controlled code with the Cloudflare publish token
The previous design ran the publisher strictly from dev: screen-library.yml calledpeanutprotocol/peanut-ui/.github/workflows/screen-library-publish.yml@devand the callee checked outref: dev, so no PR code ever ran in the job holding secrets. This PR changes both sides: the caller now usesuses: ./.github/workflows/screen-library-publish.yml(screen-library.yml, publish job), which resolves the reusable workflow — including its job definitions — from the PR head revision, and the callee checks outref: ${{ github.event.pull_request.head.sha || github.sha }}(screen-library-publish.yml, checkout step). The PR author therefore controls the checked-outscripts/screens/publish-run.mjs,scripts/screens/resolve-baseline.mjs, and even the callee workflow YAML itself, all executed in a job that receivesCLOUDFLARE_PUBLISH_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}and Cloudflare account/bucket variables. Any same-repo PR can exfiltrate that token (e.g. a one-line addition to resolve-baseline.mjs curling it out, since the job has network access) or use it to push arbitrary content to the public R2 bucket / Cloudflare Images account. Thegithub.event.pull_request.head.repo.full_name == github.repositoryguard only excludes forks, not branch authors. Fix: restore resolution of the publisher from dev —uses: peanutprotocol/peanut-ui/.github/workflows/screen-library-publish.yml@devandref: devin the callee checkout — and if the new baseline-resolution logic must ship with this PR, land the publisher changes on dev first as the docs themselves prescribe ('Merge publisher PR #3107 into dev first').
Checked clean
- Confirmed the detached worktree head, supplied base SHA, merge base, trusted author, base ref, and pull request metadata exactly match the requested review identity.
- P1/P2: current and historical per-screen runtime exceptions remain failed and force a nonzero capture exit, while expected unavailable gaps remain publishable.
- P3/P5: identity-changing pull requests select capture_before using native git pathspecs; this exact head queued capture_before.
- P4: scheduled/manual run provenance now uses the repository default branch, while artifact naming and downloaded manifest validation bind the actual dev revision.
- P6: external fallback cannot publish a genuinely incompatible harness or fixture baseline because report comparison requires matching capture identities; conservative path-only changes with unchanged identities do not require recapture.
- P9: the resolver is formatted and the exact-head format check passes.
- Reviewed Cloudflare source-metadata reuse, legacy repair, public delivery validation, baseline age and provenance, pull request binding, commit matching, and failure propagation without finding another defect.
- Focused artifact-selection, capture-status, Cloudflare storage, public-origin, and worker tests passed (18/18); all screen JavaScript syntax checks and diff whitespace checks passed.
- Exact-head ci-success, unit, screen-tests, typecheck, ESLint, formatting, native export, workflow analysis, authorship, backend-baseline, and preview checks are green; visual capture and design-shot jobs were still queued or running at the final read.
- GitHub's reusable-workflow contract confirms that a local
./.github/workflows/...call loads the callee from the same commit as the caller and passes explicitly mapped secrets into it.
Security review by moonshotai/kimi-k3: 1 finding(s), marked with the model name. It reads the diff only and answers only security, privacy and money, so treat its findings as advice.
Third opinion: did not run — claude-api_error. This review is one reviewer short.
Exact head: ba85d5b407eb · Context: repo, ci, github-docs · Took 11m
There was a problem hiding this comment.
Chip review — changes requested
One blocking workflow trust-boundary defect and three major capture-integrity or availability defects remain.
Findings
-
BLOCKING · .github/workflows/screen-library.yml:172 · Keep pull request code out of the credentialed publisher
This local reusable-workflow reference still loads the callee from the pull request commit. That callee checks out the pull request head, passes the Cloudflare publishing token and a pull-request-write GitHub token, and executes publisher scripts from that checkout. Any same-repository pull request can therefore alter the callee or publisher script and exfiltrate the token or mutate the public gallery before review. Pin the secret-bearing workflow and all executable publisher code to a trusted revision, or move publication behind a trusted workflow_run that treats pull request artifacts only as validated data. -
MAJOR · .github/workflows/screen-library-baseline.yml:7 · Register the daily baseline scheduler on the default branch
The repository default branch is main, where this workflow file is still absent, while this pull request targets dev. GitHub only triggers scheduled workflows whose file exists on the default branch, so merging this pull request cannot start the advertised daily refresh. After 30 hours without a matching successful dev integration artifact, ordinary pull request publication has no trusted baseline. Install the scheduler on main before relying on daily reuse, or retain a guaranteed same-run base capture until it is active. -
MAJOR · .github/workflows/screen-library-baseline.yml:28 · Pin both daily checkouts to one dev revision
The harness and target checkouts still dereference the moving dev branch independently. If dev advances between these sequential steps, the artifact is named for the newer target SHA but was produced with the older harness, so the trusted baseline describes a mixed revision and later reuse can reject it. Resolve one immutable dev SHA first and use it for both checkouts and the artifact name. -
MAJOR · scripts/screens/run-capture.mjs:47 · Do not replace base media with the head assets
This still copies the harness checkout's videos into every distinct target without verifying that the target contains one of the known legacy HEVC files. A pull request that changes either video together with a harness or fixture path runs capture_before, but both before and after builds then use the head video, hiding the media change while the baseline manifest claims the base commit. Restrict substitution to known legacy hashes and record it in adapter provenance so later media changes remain observable. -
BLOCKING · .github/workflows/screen-library-publish.yml:24 · [moonshotai/kimi-k3] Publisher checks out PR-controlled code with the Cloudflare publish token
The reusable publish workflow changedref: devtoref: ${{ github.event.pull_request.head.sha || github.sha }}, so the 'Verify provenance and publish' step (which holds CLOUDFLARE_API_TOKEN and runsnode scripts/screens/publish-run.mjsfrom the checkout) now executes scripts taken from the pull request head. The caller also switched fromuses: peanutprotocol/peanut-ui/.github/workflows/screen-library-publish.yml@devtouses: ./.github/workflows/screen-library-publish.yml, so the workflow itself is resolved from the PR ref as well. Any author who can open a same-repo PR (the job'sifonly requires head.repo == base repo, which any collaborator branch satisfies) can modify publish-run.mjs or the workflow to exfiltrate the token or push arbitrary content to the public R2 bucket / Cloudflare Images. The docs in this same diff still claim 'the publisher checks out dev; PR checkout code never runs in that job', confirming the intent. Fix: pin the caller back to@devand the checkout back toref: dev, keeping all credentialed publishing code on the trusted branch. -
BLOCKING · .github/workflows/screen-library.yml:172 · [moonshotai/kimi-k3] Caller invokes the reusable publisher from the PR revision
uses: ./.github/workflows/screen-library-publish.ymlresolves the reusable workflow from the triggering ref, so a same-repo PR can rewrite the publisher job (steps, env, token handling) and have it run with secrets.CLOUDFLARE_API_TOKEN. Combined with the checkout change above this fully breaks the trusted-publisher model. Fix: restoreuses: peanutprotocol/peanut-ui/.github/workflows/screen-library-publish.yml@dev. -
MAJOR · scripts/screens/run-capture.mjs:47 · [moonshotai/kimi-k3] run-capture overwrites target-revision media with harness (head) assets
The new loop copiespublic/iosPwaChrome.movandpublic/iosPwaSafari.movfrom the harness checkout into the target checkout before building, so the 'before' capture is built with media from the 'after' revision. This silently contaminates the baseline artifact that the trusted publisher later verifies and publishes as belonging to the base commit. Fix: transcode or substitute within the capture pipeline, not by mutating the target tree whose commit identity is asserted.
Checked and not raised again
- MAJOR · scripts/screens/resolve-baseline.mjs:48 · [moonshotai/kimi-k3] Accept the actual identity of scheduled baseline runs — this review checked it and does not believe it. No task filed.
Checked clean
- Confirmed the detached worktree head, supplied base SHA, merge base, trusted author, base ref, and pull request metadata exactly match the requested review identity.
- P1/P2: current and historical per-screen runtime exceptions remain failed and force a nonzero capture exit, while expected unavailable gaps remain publishable.
- P3/P5: identity-changing pull requests select capture_before using native git pathspecs; this exact head selected that job.
- P4: scheduled and manual run provenance uses the repository default branch, while artifact naming and downloaded-manifest validation bind the actual dev revision.
- P6: a missing same-run baseline cannot publish a capture with different harness, fixture, renderer, adapter, profile, or origin identities; incompatible external reuse fails closed.
- P9: the baseline resolver is formatted and the exact-head format check passes.
- P7/P10/P11/P14/P15/P16/P22/P23/P24/P25/P26/P27 are duplicate instances of the surviving default-branch scheduler defect reported against P22.
- P8/P12/P13/P17/P18/P19/P28/P29/P30/P31/P32/P33 are duplicate instances of the surviving split-revision checkout defect reported against P28.
- P20/P34 are the surviving head-media overlay defect reported against P34; P21/P35 are the surviving credentialed PR-publisher defect reported against P21.
- The new browser-start retry preserves a red failure after three unsuccessful launches and does not weaken per-screen or process-level failure propagation.
- Focused artifact-selection, capture-status, Cloudflare storage, public-origin, and worker tests passed (18/18); changed JavaScript syntax checks and diff whitespace checks passed.
- Exact-head aggregate CI, unit, screen-tests, typecheck, ESLint, formatting, native export, workflow analysis, authorship, backend-baseline, and preview checks are green; visual capture and design-shot jobs were still queued or running at the final read.
- Reviewed Cloudflare source-metadata reuse, legacy repair, public delivery validation, baseline age and provenance, pull request binding, commit matching, artifact selection, and failure propagation without finding another defect.
- GitHub's reusable-workflow contract confirms that a local same-repository workflow call loads the callee from the same commit as the caller, and GitHub's schedule contract requires the workflow file on the default branch.
Security review by moonshotai/kimi-k3: 4 finding(s), marked with the model name. It reads the diff only and answers only security, privacy and money, so treat its findings as advice.
Third opinion: did not run — claude-api_error. This review is one reviewer short.
Exact head: da283faea4eb · Context: repo, ci, github-docs · Took 8m
There was a problem hiding this comment.
Chip review — no blocking findings — this is not an approval
Two major screen-library defects remain: the daily baseline scheduler is not registered, and legacy video overlays target URLs the app never requests.
Findings
-
MAJOR · .github/workflows/screen-library-baseline.yml:7 · Register the daily baseline scheduler on the default branch
The repository default branch ismain, where this workflow file is absent, and the live Actions workflow inventory has no scheduler at this path. Because this pull request targetsdev, merging it cannot register the advertised daily run; after 30 hours without a matching integration artifact, ordinary pull request publication has no trusted baseline. Install the scheduler onmainbefore relying on daily reuse, or retain a guaranteed same-run base capture until it is active. -
MAJOR · scripts/screens/run-capture.mjs:63 · Route video overlays at their public URLs
The detected filesystem key ispublic/iosPwaChrome.mov(and likewise Safari), so this constructs/public/iosPwaChrome.mov. The app actually requests/iosPwaChrome.mov, andcapture.tsonly applies an overlay on an exact pathname match. Historical/base captures therefore keep serving the legacy HEVC files that Chromium cannot decode, leaving the video hidden and producing misleading comparisons. Keep the filesystem path for hashing, but remove thepublic/prefix from the routed URL.
Checked clean
- Confirmed the detached worktree head, supplied base SHA, merge base, trusted author, base ref, and pull request metadata exactly match the requested review identity.
- P1/P2: current and historical per-screen runtime exceptions remain failed and force a nonzero capture exit, while expected unavailable gaps remain publishable.
- P3/P5/P6: identity-changing pull requests use native git pathspec detection, recapture the merge base with the pull request harness, and carry a fail-closed same-run requirement into the trusted publisher.
- P4: scheduled/manual run provenance uses the repository default branch, while the artifact name and downloaded manifest bind the actual captured dev revision.
- P7/P10/P11/P14/P15/P16/P22/P23/P24/P25/P26/P27/P36 are duplicate instances of the surviving default-branch scheduler defect reported against P22.
- P8/P12/P13/P17/P18/P19/P28/P29/P30/P31/P32/P33/P37: the baseline workflow resolves one immutable dev SHA before checkout and uses it for both trees, capture identity, and artifact naming.
- P9: the baseline resolver is formatted and the exact-head format check is green.
- P20/P34/P38/P41: the original target-mutation and future-media-substitution defect is fixed by hash-bound in-memory overlays recorded in adapter provenance; the separate public-URL mismatch is reported above.
- P21/P35/P39/P40/P42: the caller resolves the reusable publisher at trusted
dev, and the publisher checks outdevbefore receiving Cloudflare and write-capable GitHub credentials. - Reviewed Cloudflare source-metadata reuse, collision fail-closed behavior, legacy metadata repair, public delivery validation, R2 immutability, baseline age/provenance, pull request binding, artifact selection, and failure propagation without another finding.
- Focused artifact-selection, capture-status, Cloudflare storage, public-origin, and worker tests passed (18/18); changed JavaScript syntax checks and diff whitespace checks passed.
- Exact-head ci-success, unit, screen-tests, typecheck, ESLint, format, native export, workflow analysis, authorship, backend-baseline, and preview checks are green. The advisory ds-shots job hit an internal Webpack hash exception while other exact-head builds succeeded; capture_before and capture_after were still running at the final read.
Security review by moonshotai/kimi-k3: 0 finding(s), marked with the model name. It reads the diff only and answers only security, privacy and money, so treat its findings as advice.
Third opinion: did not run — claude-api_error. This review is one reviewer short.
Exact head: ea89e506827b · Context: repo, ci · Took 15m
There was a problem hiding this comment.
Chip review — no blocking findings — this is not an approval
Two major screen-library defects remain: the daily baseline scheduler is not registered on the default branch, and the video-overlay URL fix now resolves the base asset from the wrong filesystem path.
Findings
-
MAJOR · .github/workflows/screen-library-baseline.yml:7 · Register the daily baseline scheduler on the default branch
The repository default branch ismain, where this workflow file still returns 404 and the live Actions workflow inventory has no entry at this path. Because this pull request targetsdev, merging it cannot register the advertised schedule; after 30 hours without an exact successful dev integration artifact, ordinary product-only pull request publication throws because no trusted baseline is available. Install this scheduler onmainbefore relying on daily reuse, or retain a guaranteed same-run base capture until it is active. -
MAJOR · scripts/screens/run-capture.mjs:63 · Keep a filesystem path for overlay verification
For this exact merge base, bothpublic/iosPwa*.movfiles match the hard-coded legacy hashes, so this line enqueues overlays using/iosPwa*.mov.capture.tsthen strips the leading slash and callsreadFileSync(join(source, relative)), which resolves<target>/iosPwa*.mov; those files do not exist because the assets live under<target>/public/. The required base capture therefore throws before the browser can route either overlay. Carry separate public-URL and target-relative paths (or map the URL back throughpublic/) so hashing reads the real base asset while routing still matches/iosPwa*.mov.
Checked and not raised again
- BLOCKING · .github/workflows/screen-library.yml:172 · [moonshotai/kimi-k3] Keep pull request code out of the credentialed publisher — this review checked it and does not believe it. No task filed.
Checked clean
- Confirmed the detached worktree head, supplied base SHA, merge base, trusted author, base ref, and pull request metadata exactly match the requested review identity.
- P1/P2: current and historical per-screen runtime exceptions remain failed and force a nonzero capture exit, while expected unavailable gaps remain publishable.
- P3/P5/P6: identity-changing pull requests use native git pathspec detection, recapture the merge base with the pull request harness, and fail closed on an incompatible or missing required baseline.
- P4: scheduled/manual source runs are validated against the repository default branch, while artifact names and downloaded manifests bind the captured immutable dev SHA.
- P7/P10/P11/P14/P15/P16/P22/P23/P24/P25/P26/P27/P36/P39 are duplicate instances of the surviving default-branch scheduler defect reported against P22.
- P8/P12/P13/P17/P18/P19/P28/P29/P30/P31/P32/P33/P37: both baseline checkouts now use one immutable dev SHA resolved before either checkout.
- P20/P34/P38/P43: target media is no longer overwritten; substitution is restricted to exact known legacy/current hashes and remains in-memory.
- P21/P35/P41/P42: the caller resolves the secret-bearing reusable publisher at trusted
dev, and that publisher checks outdevbefore receiving Cloudflare and pull-request-write credentials. - P40: the overlay route key now matches the app's
/iosPwa*.movrequest; the separate filesystem-path regression in that fix is reported above. - Verified the exact base files match the configured legacy SHA-256 values, the exact head files match the configured replacement values, and only the
public/filesystem paths exist. - Focused artifact-selection, capture-status, Cloudflare storage, public-origin, and worker tests passed (18/18); changed JavaScript syntax and diff whitespace checks passed.
- Exact-head ci-success, unit, screen-tests, typecheck, ESLint, format, native export, workflow analysis, authorship, and backend-baseline checks are green; capture_before and capture_after were still running at the final review snapshot.
- Reviewed Cloudflare source-metadata reuse, collision handling, legacy repair, public-delivery validation, R2 immutability, artifact age/provenance, pull request binding, capture identity, and failure propagation without finding another reachable defect.
Security review by moonshotai/kimi-k3: 1 finding(s), marked with the model name. It reads the diff only and answers only security, privacy and money, so treat its findings as advice.
Third opinion: did not run — claude-api_error. This review is one reviewer short.
Exact head: 996fd5b8be93 · Context: repo · Took 11m
There was a problem hiding this comment.
Chip review — no blocking findings — this is not an approval
One major screen-library defect remains: the daily baseline scheduler is not registered on the repository default branch.
Findings
- MAJOR · .github/workflows/screen-library-baseline.yml:7 · Register the daily baseline scheduler on the default branch
The repository default branch ismain, where this workflow file still returns 404, while this pull request targetsdev. GitHub therefore cannot register the advertised schedule; after 30 hours without an exact successful dev integration artifact, an ordinary product-only pull request has no trusted baseline and publication fails. Install this scheduler onmainbefore relying on daily reuse, or retain a guaranteed same-run base capture until it is active.
Checked clean
- Confirmed the detached worktree head, supplied base SHA, merge base, trusted author, base ref, and pull request metadata exactly match the requested review identity.
- P1/P2: current and historical per-screen runtime exceptions remain failed and force a nonzero capture exit, while expected unavailable gaps remain publishable.
- P3/P5/P6: identity-changing pull requests use native git pathspec detection, recapture the merge base with the pull request harness, and fail closed on a missing or incompatible required baseline.
- P4: scheduled/manual source runs are validated against the repository default branch, while artifact names and downloaded manifests bind the actual captured dev revision.
- P7/P10/P11/P14/P15/P16/P22/P23/P24/P25/P26/P27/P36/P39/P41 are duplicate instances of the surviving default-branch scheduler defect reported against P41.
- P8/P12/P13/P17/P18/P19/P28/P29/P30/P31/P32/P33/P37: both baseline checkouts use one immutable dev SHA resolved before either checkout.
- P9: the baseline resolver matches repository formatting and exact-head format CI is green.
- P20/P34/P38: target media is no longer overwritten; substitution is restricted to exact known legacy/current hashes and remains in memory.
- P21/P35: the caller resolves the secret-bearing reusable publisher at trusted
dev, and that publisher checks outdevbefore receiving Cloudflare and pull-request-write credentials. - P40/P42: overlay browser routes now use
/iosPwa*.mov, while hashing and adapter provenance retain the distinctpublic/iosPwa*.movfilesystem paths; exact base and head hashes match the configured identities. - Reviewed Cloudflare source-metadata reuse, collision fail-closed behavior, legacy repair, public delivery validation, R2 immutability, baseline age/provenance, pull request binding, artifact selection, and failure propagation without another reachable defect.
- Focused artifact-selection, capture-status, Cloudflare storage, public-origin, and worker tests passed 18/18; diff whitespace checks passed.
- The full local screen-test sweep could not load tsx/pngjs because dependencies are absent from the detached worktree; exact-head screen-tests CI is green.
- Exact-head ci-success, unit, screen-tests, typecheck, ESLint, format, native export, workflow analysis, authorship, backend-baseline, report, and preview checks are green; advisory capture_before, capture_after, and design-shot jobs were still running at the final read.
Security review by moonshotai/kimi-k3: 0 finding(s), marked with the model name. It reads the diff only and answers only security, privacy and money, so treat its findings as advice.
Third opinion: did not run — claude-api_error. This review is one reviewer short.
Exact head: 216f478fdd26 · Context: repo, ci · Took 13m
There was a problem hiding this comment.
Chip review — no blocking findings — this is not an approval
The default-branch scheduler defect remains and is explicitly deferred to PR #3147; the new full-catalogue guard introduces no additional defect.
Answered by a human, not raised again
These are still present as far as this review can tell. You resolved the thread or deferred the fix, so Chip files them instead of repeating them.
- MAJOR · .github/workflows/screen-library-baseline.yml:7 · Register the daily baseline scheduler on the default branch — task
Checked clean
- Confirmed the detached worktree head, supplied base SHA, merge base, trusted author, base ref, and pull request metadata exactly match the requested review identity.
- P1/P2: current and historical per-screen runtime exceptions remain failed and force a nonzero capture exit, while expected unavailable gaps remain publishable.
- P3/P5/P6: identity-changing pull requests use native git pathspec detection, recapture the merge base with the pull request harness, and fail closed on a missing or incompatible required baseline.
- P4: scheduled/manual source runs are validated against the repository default branch, while artifact names and downloaded manifests bind the actual captured dev revision.
- P7/P10/P11/P14/P15/P16/P22/P23/P24/P25/P26/P27/P36/P39/P41/P43 are duplicate instances of the scheduler defect consolidated under P43 and explicitly deferred by the supplied reply to PR #3147.
- P8/P12/P13/P17/P18/P19/P28/P29/P30/P31/P32/P33/P37: both baseline checkouts use one immutable dev SHA resolved before either checkout.
- P9: the baseline resolver matches repository formatting and the exact-head workflow analysis check is green.
- P20/P34/P38: target media is no longer overwritten; substitution is restricted to exact known legacy/current hashes and remains in memory.
- P21/P35: the caller resolves the secret-bearing reusable publisher at trusted
dev, and that publisher checks outdevbefore receiving Cloudflare and pull-request-write credentials. - P40/P42: overlay browser routes use
/iosPwa*.mov, while hashing and adapter provenance retain the distinctpublic/iosPwa*.movfilesystem paths. - The scheduled baseline now passes
--full-catalogue; unavailable or missing catalogue coverage makes that job fail, while the always-uploaded artifact cannot be reused because baseline resolution requires a successful source run. - Successful dev integration artifacts may remain incomplete, but reuse preserves their explicit unavailable rows, environment compatibility is still enforced, and incomplete comparisons cannot advance the latest full-library pointer; this is documented degraded coverage rather than a wrong result.
- The viewer accepts both legacy full-digest preview IDs and the publisher's 32-character
ps-IDs while rejecting non-Cloudflare preview URLs and preserving the local asset fallback. - Reviewed Cloudflare source-metadata reuse, collision fail-closed behavior, legacy repair, public delivery validation, R2 immutability, baseline age/provenance, pull request binding, artifact selection, capture completeness, and failure propagation without another reachable defect.
- Focused artifact-selection, capture-status, Cloudflare storage, public-origin, and worker tests passed 18/18; changed-script syntax and diff-whitespace checks passed.
- Dependency-backed local tests were unavailable because the detached worktree has no installed dependencies. Exact-head workflow analysis, supply-chain freshness, bot-approval, preview, and ref-resolution checks are green; the main test workflow and advisory capture jobs were still pending at the final read.
Security review by moonshotai/kimi-k3: 1 finding(s), marked with the model name. It reads the diff only and answers only security, privacy and money, so treat its findings as advice.
Third opinion: did not run — claude-api_error. This review is one reviewer short.
Exact head: 52c30ea4de4c · Context: repo, ci · Took 12m
1 participant
What changed
/blobresponse byte-for-byte. Cloudflare may optimize the stored/original response, which was stopping publication before the R2 manifest was committed.Verification
node --test scripts/screens/cloudflare-storage.test.mjs scripts/screens/worker.test.mjs scripts/screens/public-origin.test.mjs