The pinned repair patch is applied exactly as reviewed, including its config/release.json changes, and every baseline check passes. It's committed as 536451f on top of the starting commit 9b0294e.

Inputs verified before any edits

• The starting HEAD matched 9b0294e7ab19060bd00c489fbe032cf248528e0d.
• The patch was 194,891 bytes with SHA-256 3028547365…2989, as pinned. The pinned SOURCE-INPUTS.json records the same size and hash.
• git apply --check was clean, and the patch went in unmodified: 34 files changed.
• All 70 files listed in the patch's docs/validation/review-fixes/source-sha256.json matched (0 mismatched, 0 missing).
• The protected build files and dependencies (foundry.toml, remappings.txt, package.json, the lockfile, lib/, vendor/) are identical to HEAD.

Checks on the patched code (raw logs are in docs/validation/integration/)

• Contracts: forge build succeeded with lint warnings only; forge test -vv gave 125 passed, 0 failed; forge fmt --check passed.
• SDK and CLI: the Node tests gave 27 passed, 0 failed; the PNG fixture check and cli help passed.
• Release metadata: the five ABIs match the build, and the contract hashes and sizes in config/release.json match all four compiled contracts. The checker is new, at tools/check-release.mjs, and only reads.
• Local run: the real SDK drove contracts deployed on a local Anvil chain for 7 rounds and 33 transactions. The Intake and IMD token were mocks, so this says nothing about live IMD behaviour.

Gaps

• Missing patch evidence: the patch's own evidence pages link to 16 raw logs it doesn't include, such as the pre-repair failure baselines and the gas traces. I didn't recreate them, since that would rewrite the reviewed patch. My new logs cover the current pass results but not those baselines or traces.
• Measurement tool not run: tools/measure-release.mjs rewrites a file in the patch's evidence directory and needs those missing traces. tools/check-release.mjs makes the same ABI and metadata checks instead.
• Known risk kept: a genuine result too large for the manifest limits can still leave a Branch unable to bind it. As the brief requires, there's no admin or timeout unlock, refund or automatic retry.
• Not done in this stage: importing W1, the browser SDK and the browser signing tests belong to the later build-website step. productionDeployment stays null, liveCompatibility stays NOT_RUN and productionReady stays false.

This machine has no git identity, so I made the commit with the earlier commits' author ("IdentityMD Worker") passed for that one commit; git's config was not changed.

The full report is docs/validation/integration/README.md.

I built the browser-compatible A1 SDK. The Node entrypoint and CLI still behave as before, and every check below passed. I didn't commit anything, and I didn't modify configuration, lockfiles, abi/, src/ or Foundry files.

What changed

• Shared core: encoding and validation now live in one module, sdk/core.mjs, used by both runtimes. It keeps the patched rules: the output name/path/prefix collision guards, dist/ reserved for the single HTML file, full bounded JSON validation (including ignored metadata) and the fixed v2 policy. sdk/strict-json.mjs no longer uses Buffer.
• ABIs: sdk/abi.mjs is generated from abi/*.json by tools/generate-sdk-abi.mjs; its --check mode confirms the copy matches byte for byte.
• Node entrypoint: sdk/index.mjs keeps the same exports, using Node's own SHA-256. sdk/files.mjs and cli/relay.mjs are untouched.
• Browser entrypoint: sdk/browser.mjs plus sdk/files-browser.mjs. It uses no node:*, fs, DNS, HTTPS sockets, process or Buffer. Downloads only come from configured HTTPS locations, read as a stream that stops at the size cap, with redirects refused by default and every file's bytes checked against the expected size, hash and format.
  • DNS limit: a browser can't see DNS answers or the connected IP address, so it can't repeat the Node adapter's private-address and IP-pinning protection. Trusting the configured artifact hosts is a configuration decision; this is written up in docs/SDK-BROWSER.md.
  • Loopback fixtures: the loopback fixture policy is test-only. It is refused unless the page itself is on a loopback address, and its results are labelled as fixtures.
• New helpers: an exact (never unlimited) token approval, price/allowance/factory reads, and toWalletRequest, which shapes a prepared transaction for the user's chosen wallet. The SDK holds no key and never submits, retries or buys anything itself.
• Config generator: sdk/config.mjs and tools/generate-local-config.mjs build the local config from the deployed contracts and refuse non-local chains. The public config stays closed while productionDeployment is null. Where the file is finally written is left to the build-website stage.

Checks run (raw logs, chain traces and SHA-256 hashes are in docs/validation/integration/sdk-browser/; its README.md has the PASS/FAIL/NOT_RUN table)

tools/sdk-local-check.mjs deploys the actual contracts to a throwaway local chain (anvil), with mock token and intake contracts at the release's addresses. It then sends 15 real transactions through the browser entrypoint in each runtime:

• create, propose, exact approval followed by sponsor, a refusal followed by an explicitly funded identical retry by a second account, bind, reading files and history, and a fork of revision 1.
• In Chromium, 25 calldata/hash results and 37 rejection cases were identical to Node, and WebCrypto's SHA-256 matched.
• Real browser downloads were checked: a tampered file, a 70 KiB oversized body, a redirect and an off-list URL were all refused.

Not done here

• Chromium isn't committed: the Chromium used for this check was installed only in test/scratch/, which gets deleted. The offline verifier can't rerun that part; without Chromium the tool reports it as NOT_RUN.
• No real-IMD or live testing: nothing ran against the live Intake or real IMD. liveCompatibility stays NOT_RUN, productionReady stays false, and the known risk remains: an authenticated result that exceeds the manifest limits may be impossible to bind.
• No wallet signing UI: the local runs signed with the test chain

Implemented W1 integration, actual local contract flows, safe previews, setup tools and root dist/.

Passed: build/typecheck, 125 Foundry, 39 SDK, 30 unit, 72 UI and 12 browser-chain cases. Rebuild matches the export. Source snapshot: 7.34 MB.

Setup · Validation

WebKit and independent contributor review remain NOT_RUN. Production readiness stays false; oversized-manifest risk remains.

Updated the static export and acceptance report.

• Passed: build, typecheck, 125 Foundry, 39 SDK, 30 unit and 120 fixture tests.
• All 13 actual-contract scenarios passed in Chromium and WebKit.
• Source snapshot bundle: 7,859,229 bytes, under 8 MiB. Protected files unchanged.

Acceptance remains incomplete: independent review is NOT_RUN and intermittent WebKit RPC diagnostics remain open. No public deployment; productionReady:false. The manifest-envelope risk remains.

The review is complete. The findings file .imd-findings.json is valid JSON with three entries, and the working tree has no stray files.

Outcome: no Critical or High defects found in the integrated contracts, browser and Node SDK, or the frontend transaction and file boundaries. Readiness is not blocked by this review. The existing posture stays as delivered: productionDeployment null, liveCompatibility NOT_RUN, productionReady false.

What I checked and found sound

• Payer and spender: the sponsor approves the Branch exactly, the Branch is the only payer at the Intake, and the contract verifies balances before and after the pull and leaves zero allowance. The frontend re-reads price, anchor, body hash, parent job, spender and exact allowance immediately before each signature.
• Stale state: proposals bind the anchor, bodyOf re-encodes and compares the stored body hash, and a stale proposal is refused on chain and in the UI. Sponsors cannot edit proposals.
• Unknown transaction and rebuy: the journal records hash, nonce, account, chain and operation before the receipt wait. Reconciliation classifies mined, reverted, pending, replaced and dropped outcomes, and a pending account nonce with lost storage blocks a new purchase. Status 1 allows only an identical-body retry; status 2 or unknown freezes.
• Witness and manifest: the verifier requires exact raw bytes matching the callback hash, one output file matching the proposal's name, path and media type, and rejects reused job ids and parent-project reuse on forks. Create and update profiles enforce target existence, kind match, name and path-ancestor collision guards.
• Preview isolation: HTML renders in an opaque-origin sandbox with no scripts, a restrictive CSP, stripped hrefs, forms and navigable elements, and bounded data-image checks. Markdown goes through DOMPurify with https-only links.
• Fork provenance: forks require a registered parent, a nonzero accepted checkpoint and the exact witness table, and copy only that revision's assets.

Findings reported

• Low: the fixture adapter advertises JPEG and WebP image types that the contracts and SDK never accept, so fixture mode can show a verified badge no real Branch can produce.
• Low: a callback whose URI exceeds 1024 bytes reverts and leaves the attempt pending forever, an undisclosed second liveness case beside the disclosed oversized-manifest one.
• Info: the finite-manifest limit is preserved as designed and remains an honest residual liveness risk.

Not done: no Foundry proof files were written, since no finding reached High severity. Independent review of the browser matrix logs beyond the author's own acceptance reports was limited by time, so the author's WebKit runtime-diagnostic FAIL stands as they reported it.

I rewrote README.md and added three docs plus a folder of fresh test evidence. I changed nothing outside README.md and docs/, and nothing is committed yet.

What I ran first (on 2026-10-21, against the unchanged tree):

• Contracts: forge build and forge fmt --check pass. The seeded forge test passes all 125 tests.
• SDK and tools: 39 SDK tests pass, including the 27 baseline ones. The release, ABI and inline-fixture checks pass, and the CLI help prints.
• Frontend: npm ci, typecheck, the 30 unit tests and the build all pass. The rebuilt dist/ is byte-identical to the committed one.
• Browser on the local chain (Chromium): all 13 cases pass. That's 80 wallet submissions, 78 receipts and 2 deliberately dropped transactions. The audit that re-encodes every transaction passes, with 0 browser errors.
• Local config: a fresh local deployment generates exactly the committed local-config.json.
• Demo-mode UI tests: 24/24 pass on chromium-desktop.
• Source hashes: all 217 entries in the earlier hash record matched before I edited anything.

Delivered:

• README.md:
  • Up front: the "read this first" section says plainly that the project is not deployed and not production-ready (productionDeployment: null, liveCompatibility: NOT_RUN, productionReady: false). It says everything ran on mocks, that real IMD has never run anything (including a contract-paid continuation), and that oversized results or missing callbacks can leave a project stuck for good. It also lists the open findings.
  • Commands: build and test commands from a fresh clone, plus local setup and the browser tests.
  • Usage: the six functions with who may call them, cost and failures, the Agent CLI and SDK handoff, source pins with hash evidence, and an acceptance summary.
• docs/FRONTEND.md: every route (#/, #/local, #/local/b/…, #/demo) and every button, with permissions, cost and the actual error messages from the code. It also covers the transaction journal and recovery after reload, and the file and preview isolation.
• docs/ACCEPTANCE.md: the 13-case matrix with separate Fixture UI, Actual local (Chromium this pass, Chromium earlier, WebKit earlier) and Real IMD columns. Every Real IMD cell is NOT_RUN. It also has the check table, review outcomes and seven unresolved issues, including the retained oversized-result risk.
• docs/PROTOCOL-OVERVIEW.md: the previous README kept word for word, with its links fixed, so none of its protocol detail is lost.
• docs/validation/integration/documentation/: this pass's raw logs, the full Chromium browser-chain.json, three screenshots, tool versions and a new final-sha256.json. Machine paths in the logs are replaced with placeholders.

Where the brief and the repo differ (stated in the README):

• config/release.json comes from the pinned patch that an earlier contributor applied. It was not edited in this pass.
• The integration started from commit 8c0d6da, not directly from the A1 commit 9b0294e.
• sdk/index.mjs and sdk/strict-json.mjs were deliberately changed after the patch to add the browser entry point.

Not rerun or still open:

• I did not rerun WebKit, the browser SDK parity check or the other four demo-mode test setups, so those results are cited from earlier evidence.
• WebKit's 3 intermittent page errors from earlier runs are still open.
• No fresh independent review has been done.
• On this machine Chromium needed system libraries it was missing. I loaded them from a temporary directory without installing anything; the README explains how.
• A browser test run without --out overwrites the earlier evidence folder, so the README warns to pass it. My one demo-mode run's default report wrote 9 new screenshots into that folder; I moved them out, and nothing tracked changed.

Recorded three verified bugs in .imd-findings.json:

• bug: workspace synchronization stalls. Mixed revision reads leave only the syncing message, with no refresh control. Restoring current RPC responses did not recover it.
• bug: PNG previews distort aspect ratios. An accepted 320×160 PNG rendered at 128×128.
• bug: actual-contract downloads lose extensions. Verified dist/index.html downloaded as site.

Build, typecheck, 125 Foundry tests, 39 SDK tests, 30 frontend unit tests, both browser SDK parity checks and Chromium’s 13 actual-contract cases passed. WebKit’s file group failed its runtime gate twice on reload-time fetch errors. Its clean acceptance remains incomplete; the cause is unresolved.

The site is a Chinese project workspace carried by stone surfaces, green actions and clear branch/checkpoint records.

acceptance/ below means docs/validation/integration/acceptance/. “Met” describes the commissioned local scope and available evidence, without implying live IMD compatibility.