Implemented v7 and rebuilt the static export in dist/. STATUS, CHANGELOG, DESIGN and agent docs are updated.

• Build, typecheck, manifest checks, 110 browser scenarios and 10 unit suites pass.
• Submission is 7.05 MiB, below 8 MiB.
• Live funding now makes week 2963 the newest qualifying default.

Validation details record the design-probe copy exception and unavailable WebKit checks. No transactions were sent.

Saved .imd-findings.json. Revision required.

• High — bug: History refresh temporarily removes loaded Annex receipts, unmounting their pages and erasing transaction confirmations. Reproduced in Chromium and WebKit; two retained tests fail. Source: web/src/App.tsx:88.
• Low — taste: Pool amounts touch judging-state labels with a measured 0px column gap. Source: web/src/styles.css:130.

Requirement coverage:

Saved findings: one medium defect where malformed RPC responses bypass healthy fallback nodes, leaving history incomplete. No critical/high findings.

Reviewed the hosted export and source. All 110 browser scenarios, ten unit suites, and 249 non-fork Foundry tests passed. Application files remain unchanged.

Review complete. Findings are written to .imd-findings.json in the repository root. No files in the tree were changed.

What I found

• High. Pot page default week is wrong on today's chain. readOpenWeeks in web/src/week.ts takes the newest week with a positive, unpaid thesis pool, starting from the current chain week. Fees accrue to the current week's pool on every noted sell, so that week is almost always positive. Live reads on 2026-10-17 confirm it: week 2963 has about 19 IMD and zero eligible theses, week 2962 has about 559 IMD and 5 eligible theses. The site therefore defaults to 2963 and shows the "0 eligible theses" screen the brief asked to remove. The unit test at web/tests/v7-unit.ts line 31 asserts this incorrect behaviour, and the browser fixture passes only because it zeroes the current week's pool. The fix is to skip the current chain week when choosing the default. The Me tab's Your week block is unaffected and correctly keeps the current week.

• Medium. A malformed primary log response blocks healthy fallback nodes. Confirmed the specialist's finding against the built source with the locked viem. When only the first node returns HTTP 200 with a matching id and no result for a chunk, the result check in web/src/notes.ts runs after the fallback transport has accepted the response, so the chunk is recorded as failed without asking the other nodes. Manual retry repeats the same node. The existing test cannot see this because it makes every node malformed.

What checked out

• Manifest node order in both rpcUrls lists matches the brief, and none of the forbidden hosts appear.
• The existing v7 unit suite passes in a temporary mirror. Real HTTP 429 and JSON-RPC archive errors hand the chunk to the next node, and per-node concurrency peaked at 4 and 3.
• The automatic history scan completes from the deploy block, failed chunks leave holes rather than empty coverage, and the retry button appears only after the scan ends.
• Feedback link is gone from the top bar and bundle; the #/feedback route renders the single paused paragraph with the X link; loop.md carries the one-line pause.
• Your week lines render the three states and the no-thesis, other-wallet, Annex and unfunded cases produce nothing. Week assignment uses the same timestamp-based week as the hook.
• Child-call button is gated on zero children from both cached and fresh reads, and the feed badge text is unchanged.
• No new addresses, approvals or external scripts were introduced. Nothing critical refuses hosting.

Fixed all four findings, rebuilt dist/, and recorded responses in .imd-responses.json.

Build, typecheck, integrity checks, 112 Chromium scenarios and ten unit suites pass. Submission size is 7.48 MB, below 8 MiB.

WebKit could not run due to missing system libraries; validation documentation records the limitation.

Confirmed the prior fallback finding is fixed. No reproducible defects remain; .imd-findings.json contains {"findings":[]}.

Passed: ten unit suites, eleven browser scenarios, build/typecheck, manifest checks, and byte-for-byte export comparison. Project files remain unchanged.

Both reported findings are fixed:

• bug: Annex receipts disappeared during refresh. Chromium and WebKit, 390×844, with Annex logs delayed 200 ms: no receipt unmount, one retained confirmation and transaction link, exactly one Observe request. The retained Annex lifecycle and approval cases also pass. Evidence: [App.tsx][app].
• taste: pot amounts touched the judging-state column. The header and value gutters now measure 12 px at 320, 390 and 1440 px in both browsers, without horizontal overflow. Evidence: [styles.css][styles].

[.imd-findings.json][findings] contains {"findings":[]}. No application or documentation files were changed during review.

Both findings from the previous round are settled as fixed. .imd-findings.json holds an empty findings list and no repository file was changed.

High: pot page defaulted to the current chain week. Fixed. readOpenWeeks in web/src/week.ts now returns the newest funded, unpaid week strictly below the current chain week, falling back to the previous week when none qualifies. The current week stays in the returned list, so the Me-tab "Your week" block still covers it. The pot page in judging.tsx consumes that default and keeps the selector editable. The unit test that formerly asserted the wrong behaviour now funds the current week and asserts the completed week is chosen, and a further assertion checks that a paid completed week is skipped in favour of the next older one.

Medium: malformed HTTP 200 log response never reached the fallback nodes. Fixed. makePublicClient in web/src/chain.ts wraps each HTTP transport in a custom transport that rejects any eth_getLogs response whose result is not an array, so the viem fallback moves the same chunk to the next node before decoding happens. The test "Primary missing JSON-RPC result falls back to a healthy node and completes coverage" reproduces my earlier scenario against the locked viem transport with two local HTTP servers and asserts the chunk was asked of node 0 then node 1, with coverage complete and no failed ranges. The all-nodes-malformed test still asserts the chunk is recorded as a hole, never as covered empty history, and that a manual retry closes it.

How I verified. I installed the locked dependencies with install scripts disabled, bundled the v7 unit suite with the project's own esbuild, and ran it. All nine scenarios passed, including the HTTP 429 fallback, the four-request concurrency ceiling per node, and localStorage coverage persistence. Temporary bundle output was removed and the working tree is clean.

Nothing new to report. I found no further reproducible defect in the revised code, and the specialist pass reported none either.