Voting now runs on the three-day average, but I couldn't do the deploy, connect-check and bake-in steps from your request: no deployed service URL was given, and this job can't host a long-running service.

The three-day change

• What changed: voting opens once 3 complete days exist. The target is the average of all complete days in the last week, so today it's the 3-day average and it becomes the 7-day average by itself as more days are recorded. The threshold is MIN_DAYS in src/lib/data.mjs. Partial or missing days are still left out.
• Live data: Squeekhub now has 3 complete days (Oct 27–29), which gives a target of 10.18 km/day. I ran the real service against live data and it reported voting open with a valid 3-day signing message. I didn't sign a live vote.
• Locked targets: each prediction stores how many days its average used, and that number appears in the message the wallet signs. Results are scored against that prediction's own target, even after the window grows. If a new day completes while someone is signing, the vote is refused and they're asked to review the new target.
• Existing database: on startup the service updates a database from the 7-day version, and predictions already in it keep their 7-day targets.
• On the site: it says how many days the target uses, explains why it's fewer than seven, and shows "· 3-day average" next to a locked pick.

Deploy, connect and bake-in: not done public/spm-config.json still has an empty apiBase. Until you deploy the service and fill it in, the published site shows the 3-day target with voting marked "Predictions opening soon". A guessed URL would break voting for every visitor. The README's After launch section has the steps:

1. Run npm run service -- --host 0.0.0.0 --origin https://<your-service-host> --allow-origin https://spm-squeek-prediction-market.imd.site.
2. Paste https://<your-service-host>/api into Score service in the site footer. It only saves if the service answers.
3. Put the same URL in apiBase, run npm run build, and republish dist/.

Checks run on the final source

• npm run typecheck: passed.
• npm run build: passed.
• npm test: 9 passed, 0 failed. Two of those tests are new: the 3-day flow, and updating a database from the 7-day version.
• SPM_BROWSERS=chromium npm run test:browser: 15 passed, 0 failed, run with three complete days to match the live situation.
• WebKit was not tested: it's missing system libraries on this machine. I added the SPM_BROWSERS option so the browser tests can run on one engine.
• Design probe (taste.mjs): 16/16 passed. The 390-wide screenshot shows the target, both choices and the main button on the first screen.

Docs and delivery

• I updated the README and DESIGN.md, and wrote the design review and check results to artifacts/validation.md. This workspace's Git settings exclude artifacts/, so that file is collected separately and the README repeats the key results.
• I left the changes uncommitted. The rebuilt dist/ is about 1.5 MB.
• I installed dependencies outside the repository, and no build config or lockfile changed.

Not delivered: artifacts/validation.md. Under artifacts/, only this step's named outputs leave the machine.

The three-day voting change is done and correct, and nothing blocks shipping. The other three items in the brief (deploying the service, testing its URL in the dialog, putting the URL into spm-config.json and republishing) can only happen once you deploy it. I found two medium bugs that make that connection step misleading, and no high-severity issues.

Area	Count
Brief requirements	4: 2 met, 0 missing, 0 faked, 1 after review, 1 needs the requester
Broken features	2 (both medium)
Product on the first screen at 390	yes
taste@1 checks passed	16/16
Copy findings	0
Share card	present (title, favicon, og:title, og:image, description)

Requirements

• "allow the voting to work off the current 3 day average": met. The vote opens once 3 complete days exist (MIN_DAYS = 3, src/lib/data.mjs:7, and ready: complete.length >= MIN_DAYS). The 390 screen shows "10.18 km/day" and "Average of the last three complete days". Each prediction keeps its own day count, so a 3-day vote is scored against 3 days (outcome(..., days)).
• "Deploy the service with --allow-origin https://spm-squeek-prediction-market.imd.site": after review. The README's After launch command includes this exact flag, and server/start.mjs accepts it. Running the deploy is not part of this build.
• "Paste its /api URL into this dialog to check that it connects": met, with a bug. The footer's "Score service" button opens the "Connect the score service" dialog, which calls /market before saving. When the site's origin isn't allowed, though, the error it shows is wrong (finding 1).
• "Bake the URL into spm-config.json and republish": needs the requester: the deployed service's /api URL. public/spm-config.json still has "apiBase": "". Republishing comes after review.

The idea: a warm-paper prediction tool where you choose Over or Under on a hamster's daily run, carried by one image, the illustrated wheel.

Findings (saved in .imd-findings.json)

1. Medium, bug: the dialog misreports a blocked site. If the service wasn't started with the site's origin in --allow-origin, it refuses with a 403 but leaves out the browser header that lets the page read the reply (server/http.mjs:57). The browser therefore hides the service's own "not allowed" message, and the dialog says "Couldn’t reach the service. Check your connection and try again." I reproduced this in Chromium at 390 wide with a stub server that answers the way http.mjs does.
   • Fix: set the header on the 403 reply too, and change the message in src/lib/api.ts:24 to name the --allow-origin value the site needs.
2. Medium, bug: an unusable vote looks open. With no service configured (the state that currently ships), the first screen shows "Baseline ready" and an enabled "Connect to predict" button. The reason voting is closed is hidden by an apiBase && check at src/App.tsx:402, so a visitor only finds out after connecting a wallet.
   • Fix: remove that check so the reason shows to every visitor.
3. Low, taste: the header name wraps. At 390 wide, "Squeek Prediction Market" breaks onto two lines and the header grows to about 88px.
   • Fix: add white-space: nowrap to .brand-caption.

What I checked: taste@1 ran in Chromium at 320, 390 and 1440 wide, and I looked at its screenshots. I ran the dialog flow in Chromium with a stub service. I did not run the real service, because its packages aren't installed in the workspace. WebKit was not tested on this machine, and Safari behaviour is unconfirmed. I changed no repository files apart from the findings file.