Reviewer's five "highest priority" items, each checked against the source before acting:
* 38% speedup -> 38.1% less render time (352s -> 218s, 1.61x throughput); says it was
a single run each, same clip, same machine, same encoder settings.
* "microsecond-accurate" -> frame-accurate: at 30 fps one frame is 33.3 ms, and the text
now states that word-level timestamps are not microsecond-accurate.
* "Three minutes later" -> "a few minutes later", plus the one measured number (218 s
render for the 4-minute track) so the claim is checkable.
* Zero Jitter / Zero Light Flashing -> "no visible jitter" / "no dark flash at the cut",
scoped to the clip that was measured.
* ti.mode 0o666 -> 0o644. Hygiene, not the syntax error he reported: source and live HTML
both read 0o666 (the live page splits it across two highlight spans and his text
extraction inserted a space), and 0o666 is legal Python.
* "0 MB RAM spike in Chrome" now scopes itself to the Chrome container and says the
Python client still buffers the whole tar. New "What this pattern does not solve"
block: client buffering, target directory must already exist, tar member names become
container paths, Portainer key / CDP 9222 are root-equivalent.
All three posts get a TL;DR and inline cross-links (the trio had zero internal links
before); the ZH links use the real /posts/zh/<slug>/ path.
Not done, because it needs the owner's data rather than invention: end-to-end timing
table, benchmark conditions, whether 1.89 s was a single run, before/after jitter clips,
the "what still needs a human" list. Task list:
docs/consultant-review-2026-10-22-3-video-posts.md.
Artwork for the three slugs regenerated (1600x900 banner, 1200x630 share cards EN+ZH,
400/800 list thumbs); the ZH pipeline card already carries the corrected description.
hoelee