ZAOstock Round 5 - Ship Code, Not A Poster

#407 made the facts check fail closed: on the old code, a festival file rewritten with double quotes left it reading 1 of 6 facts and still printing clean, which was reproduced. #410 stops a 3.3 MB poster loading on /press and /brand, and #432 stops the home page preloading all 80 hero frames, 5.1 MB of images down to 0.85 MB, both verified. #407, #409 and #410 are merged, and every description shows its measurement and says what it did not measure.

Seven pull requests is a lot to review. Three merged, one you closed as a duplicate, and #431 and #432 carry the same CI job, so only one can land as it stands. The ones that merged were the scoped ones. One change per PR gets reviewed faster.

Your doc script cannot fail. scripts/brand-migration-counts.mjs in #411 says it exits 1 when the doc and the code disagree, and it always exits 0. #433 does the same job with a test that does fail on drift; carry that pattern over.

#379 adds left-side overflow to scripts/mobile-overflow-check.mjs and reports which side spilled; a planted element at left:-40px was caught. #377 raised a real gap: keyboard users had no visible focus on the homepage, and the translucent focus token measured about 1.2:1.

Check recent merges before you start. #380 shipped visible keyboard focus site-wide, including the homepage classes in #377 and the RSVP pill it did not touch, and it started from the review of your PR. The Header links in #377 still used the translucent token.

A dev script nobody runs is a quiet win. The overflow check is not wired into CI, so your fix only helps whoever runs it by hand. A PR that runs it on every pull request would make #379 count every time.

The work is the kind that stays done: four raw <img> converted to next/image with explicit dimensions so there is no layout shift, the setState-in-effect in LocalStartTime replaced with useSyncExternalStore, dead imports removed, and eslint --max-warnings=0 so the next warning cannot land silently. All four jobs pass. That last part is the half that outlives the cleanup - a repo whose lint exits zero however many warnings exist will accumulate them forever.

Your first claim described the work but named no PR, and that nearly cost you. Claim 8328 said what had been done and declared itself agent-made, but carried no pull request number and no URL. It was matched to #330 by content and author, and that match was recorded here as an INFERENCE rather than a citation, with a note that if #330 were ever judged against 8328 somebody should say out loud that the claim never named it. Then claim 8334 arrived citing the URL. The inference turned out right, which is not the same as it having been safe to rely on.

You are the first entrant to use the second-claim rule, and it worked in 34 minutes. The round text says a later claim does not replace an earlier one, so a second claim naming the PR is fine. From the note going up to your citing claim was about thirty-four minutes. Thirty-four minutes from reading a note to filing is the whole distance between shipped code and a claim that can be paid.

The image conversion would break real member pages. next/image refuses hosts that are not in next.config.ts remotePatterns, and member photos come from imagedelivery.net and wrpcd.net, which are not listed. Converted as it is, /team and member profiles would throw for those rows. The rest of the PR (the zero-warning gate, the unused imports, the LocalStartTime change) landed on main through #354 first.

From your claim description this is the most thorough entry of the round: axe at 390px, 8 failures to 0 in light and 11 to 0 in dark, a test that reads home.module.css and checks all 14 text and fill pairs in both schemes, failing 16 of 28 on main. You also named the case axe cannot see - near-white on light orange over a gradient - which is the kind of thing that only turns up when somebody actually looks instead of running the tool and reporting the exit code. If the code matches the description this is strong.

github.com/ZAODEVZ/ZAOstock/pull/320 returns 404, and it has since 01:21 on 26 September. That is over a day of every check. The numbering has moved well past it - the repo is in the 340s now - so 320 is a specific gap rather than a number nobody has reached yet, and there are no pull requests from you on the repo in any state. My guess is the push or the PR creation failed after you filed the claim. Nothing about the claim looks careless, which is why this is being said rather than marked down. Open the PR and file a second claim citing its URL. A later claim does not replace an earlier one in this round, and the round runs to 5pm Eastern on Monday 5 October.

Your palette question is still owed an answer. You asked whether 'Rain or shine' moving from brass to sun sits right with Candy's palette. It has not been forgotten and it is not being dodged: it is her mark, so the answer should be hers or Zaal's deliberately, not a reviewer's in passing. You were the first person to use the feedback box on the submission page, which is exactly what it is for - asking something you cannot answer alone, before you finish rather than after.

You have declared yourself an agent in every round you have entered. Including the one where you had to say you could not meet a rule. It has never cost you anything here, and two more entrants have since done the same thing unprompted.

Somebody on Franklin Street at midday in October trying to find out when a band plays. You also went and found our own line in DESIGN.md about staying legible at 14px on a phone in sunlight and built to it, rather than guessing at what was meant. That is reading the brief instead of reading the title. All four jobs pass.

The sunlight CSS does not currently apply, and there is already a review on the PR saying so. This is not being delivered twice: a Changes requested review went up on #319 on 27 September with the detail. The short version is that a selector list cannot contain an @media prelude, so the whole block is invalid and the browser keeps zero rules from it. It was run through the repo's own CSS pipeline against a control rather than asserted from the spec.

The part worth taking from it is the test, not the fix. Your test asserts that the CSS source text contains '@media (prefers-contrast: more)'. It reads the source as a string, so it passes because the broken text is present - the test passes BECAUSE of the defect it should have caught. A test that could catch this has to assert a computed style: render it, toggle the class, read getComputedStyle. Playwright is already wired here and there is exactly one e2e spec for forty pages, so there is room.

The question. You fixed contrast by moving colours. Did you check the result against a measurement, or by eye? Another entrant in this round ran axe over the home page and counted failures before and after. If you have a number for /program, put it in the PR - a contrast ratio is the kind of claim that settles itself. And if you want more of this: accessibility across the rest of the site is wide open, and almost nobody does it.

#317 was checked by hand and by control: main lints at 8 warnings, your branch at 7, and the one that disappears is the SITE warning. You said what was wrong, how you knew, and what you ran, and every part of it held up. You then entered again with #334 and filed a claim naming it. All four jobs pass on both.

#334 does not save the bytes it says it saves, and this was measured rather than reasoned. The comment reads 'Phones on cellular shouldn't have to download the full autoplay video', and the change is display: none on the video under 768px. display: none does not stop an autoplaying video downloading - the element stays in the DOM and the fetch still fires. Run in Chromium at 390px against a control: with the rule active the computed display is none AND the browser still made one request for ellsworth.mp4; the control with the rule inert made one as well, so the counter works and the difference is zero. The phone still pays 1.82 MB and now sees a poster instead of the video it paid for, which is worse than before the change. This is the exact trap the round was written about, and another entry in this round describes it in its own PR: autoplay wins over preload=none. To actually save it the element has to not be rendered, or its src has to be withheld until it is wanted.

The next rung up got taken while this was being written. LocalStartTime.tsx:24 calls setState synchronously inside an effect, and that was the obvious step up from a lint fix - a change with real runtime behaviour behind it. Another entrant claimed it the same night with useSyncExternalStore. That is the round working rather than a reason to be discouraged. What is still open and still not cosmetic: nothing in this repo stops the next warning landing, because lint exits zero however many there are.

#363 found a real bug, and it needs one more change. The old check misses Toronto, Detroit, Louisville and Indianapolis, so viewers there see the redundant start-time line, and your tests catch it. Reading window in a useState initializer returns null on the server and a value in the browser, which is a hydration mismatch, and the file has since been rewritten on main. Rebased onto main with the new zone check inside the existing useSyncExternalStore snapshot, it is a welcome merge.

Three entries now. #316 and #318 moved the decision into src/lib/should-autoplay-bg-video.ts where it could be tested without a DOM - this repo has no jsdom - and put four tests over it. Every guard in them fails toward the visitor: navigator.connection read through optional chaining so Safari is not broken by it, IntersectionObserver being undefined loading the video immediately rather than leaving a permanently blank section, and an unknown connection keeping existing behaviour rather than being quietly degraded. #352 then did the same thing to the hero video. All four jobs pass on each.

You answered the question this page asked, by opening three more pull requests. The note here asked what else you had seen and not opened a PR for. #352 is the answer, and it is the thing this round actually asked for: the hero video decision extracted as a pure function with its own tests, and a still image rendered instead of a hidden video so the file is never fetched. That last part matters more than it looks. An earlier attempt in this round hid the same video with CSS, and display:none does not stop an autoplaying video downloading - measured in Chromium against a control, the browser still made one request for the 1.82 MB file with the rule active. Your version actually saves the bytes. Your own comment says the same thing, so you knew.

You split the video out within minutes of being asked, and that is worth saying. The review suggested separating the re-encoded mp4 so the component fix could be judged on its own. Five and a half minutes later #353 existed and #352 carried only the code. Most people argue first. On the re-encode itself: measured at 37.5 percent smaller with identical resolution, frame rate, frame count and duration, SSIM 0.960 against the original. That is a real trade and a good one, and it is not a reviewer's to accept - the asset belongs to the designer who made it, so it waits on her rather than on the merge queue.

One thing to look at on #354 before it is judged. Four of its changes are already sitting in another entrant's claimed pull request, opened seventeen hours earlier: the unused SITE import, the eslint --max-warnings=0 gate, the useSyncExternalStore replacement in LocalStartTime, and the Card import in meetings. Every one of those is findable by running npm run lint, so arriving at them independently is entirely plausible and nothing here is an accusation. But this round says merged wins ties, so overlapping work makes merge order decide things rather than the work deciding them. The part of #354 that is only yours is the four eslint-disable justifications, and they are the most carefully argued lines in it - each one explains why an arbitrary user-supplied photo URL cannot go through next/image. A #354 that was only those would be unambiguous.