docs(producer): note Chromium/zlib byte-drift as known failure mode for png-sequence fixture

Address @vanceingalls review on #847: the maxFrameFailures=0 byte-identity
threshold will fail when Chromium's CDP screenshot bytes or libpng's
deflate output shifts on a Docker image bump. Pin the recovery procedure
in the fixture's description so a future on-call sees 'regenerate
baselines' rather than spending time investigating a non-regression.

🤖 Generated with [Claude Code](https://claude.com/claude-code)
This commit is contained in:
James
2026-05-14 23:51:44 +00:00
parent ff503cd5c0
commit 3c29060e87
@@ -1,6 +1,6 @@
{
"name": "Distributed: png-sequence",
"description": "60-frame composition (2s @ 30fps) with transparent background, text, and a rotating SVG icon. Output is a directory of zero-padded RGBA PNGs; the assemble path merges chunk frame directories rather than concat-copying mp4 files. renderConfig.chunkSize=15 produces N=4 chunks, exercising the per-frame state continuity across chunk seams that distinguishes the assemble path's directory-merge from mp4's concat-copy.",
"description": "60-frame composition (2s @ 30fps) with transparent background, text, and a rotating SVG icon. Output is a directory of zero-padded RGBA PNGs; the assemble path merges chunk frame directories rather than concat-copying mp4 files. renderConfig.chunkSize=15 produces N=4 chunks, exercising the per-frame state continuity across chunk seams that distinguishes the assemble path's directory-merge from mp4's concat-copy. maxFrameFailures=0 makes this a strict byte-identity gate; the upstream byte sources are Chrome's CDP screenshot output and libpng's deflate, so a Chromium or zlib bump in Dockerfile.test will produce identical pixels but different bytes — the failure mode on a Chrome version bump is 'regenerate baselines via docker:test:update', not 'investigate regression'.",
"tags": ["distributed", "png-sequence", "alpha"],
"minPsnr": 30,