Approved workflow

Implemented LaunchToken and Sepolia-only ImdCardPayment, with ABI exports, vendored dependencies, and deployment documentation.

Verified forge build, forge test, and forge fmt --check: 37 tests pass, including clean offline verification with an empty environment.

Payments forward to an immutable operator. Card delivery and 15-minute refunds remain backend obligations, documented in README.md.

Added failure-path, arithmetic-boundary, and stateful invariant tests under test/.

Validation: forge build and offline forge test pass—50 tests, zero failures or skips. No confirmed contract defects found.

Coverage limits are documented in test/TESTING.md; card delivery and timely refunds still require service-level verification.

Created launch.json matching the accepted contracts, with $owner as settlement recipient.

Schema and ABI checks passed. forge build passed; forge test passed all 58 tests, including protected checks.

Notes preserve beneficiary authorization and off-chain refund/float concerns. No files outside launch.json and permitted scratch space were changed.

Saved .imd-findings.json.

No substantiated math or boundary defects. All four entry points covered; 50 Foundry tests passed offline. ABI exports match compiled contracts. Source unchanged.

Off-chain refund and float enforcement remain unverified.

Saved .imd-findings.json.

• No substantiated defects; all four entry points reviewed.
• Offline Foundry: 50 passed, 0 failed.
• Exported ABIs and manifest arguments match the implementation.

Off-chain refunds, actual float reserves, and settlement-operator authorization remain unverified and are recorded in coverage.

Review complete. The findings and coverage record are in .imd-findings.json; no repository file was changed and the scratch tests and build artifacts are removed.

Outcome: the permission model holds. There is no owner, setter, pause, withdraw, receive or fallback on either contract, all configuration is immutable, and the single state-changing entry point pulls tokens only from its own caller, so no approval held by one user can be spent by another. The ABI exports are byte-identical to the compiler output, and the manifest is schema-valid with the token taking no arguments.

Findings recorded:

• Low, constructor recipient check. The constructor rejects zero, itself and the token as settlement recipient but not its own deployer. Under factory deployment that is the immutable ProjectFactory, so a manifest that passed the factory address would strand every customer payment while still emitting successful receipts. I reproduced this with a factory stand-in: deployment succeeds, a payment goes through, and the funds land in the factory. The accepted launch.json uses $owner, so the shipped configuration does not trigger it. The fix is one extra clause in the existing condition.
• Info, beneficiary trust assumption. All proceeds are forwarded irrevocably to the policy owner, and the 15-minute refund can only be paid by whoever controls that address. This is by design under the approved workflow, so it is documented as a trust assumption with the evidence the admission stage needs: confirmation that the policy owner is the operator's refund-capable wallet.

Static-analysis leads were checked and rejected: the reentrancy lines are covered by the guard and a hook-free token, the constructor's external call is a view read on the reviewed token, and no ETH is ever sent.

Coverage rows answer all four listed entry points plus the constructor, the manifest constructor arguments, and three invariants. Nothing in my area was left unreached.

Recorded no substantiated findings and coverage for all four entry points in .imd-findings.json.

All 50 tests passed offline. ABIs match compiled contracts. Source and configuration remain unchanged.

Off-chain refunds and actual operator authorization remain unverified service-level obligations.

Wrote .imd-findings.json with no substantiated defects and all four entry points marked holds.

All 50 Foundry tests passed offline. ABI exports match compilation; manifest schema and constructor checks passed.

The factory-recipient claim requires changing the accepted manifest. Refund fulfillment remains an operator trust assumption, not a demonstrated code defect.

Committed as be95781 on top of the pinned source commit. Only web/, dist/ and docs/ changed, no node_modules or generated inputs are tracked, and the submission bundle is about 1.4 MB, well under the 8 MiB limit. The focus-ring screenshot now shows the 2px blue ring on the email field.

What was delivered

Frontend source under web/ (Vite 8, React 19, TypeScript 7, wagmi 3, viem 2). The app loads ./imd-deployment.json at runtime for chain, addresses, RPC URLs and ABI paths, verifies each ABI's canonical keccak against its abiHash before enabling anything, and keeps no separate address map. Pages use hash routing:

• Get a spend card: pack picker (1 to 3, live quote() and USD context from the contract's own quote inputs), email field, four-state action (connect, switch to Sepolia, approve exact IMD, pay), live balance and allowance once connected, simulation before signing with translated revert reasons, and per-action pending states.
• Order status: local orders with receipts read live from the contract, refund-deadline countdown, explorer links, and manual lookup by wallet plus order reference.
• Claim card: paid orders with their delivery email; an optional operator claim form appears only when a public operator URL is configured.
• Wrong network: wallet_switchEthereumChain, then wallet_addEthereumChain with the manifest's walletAddChain on error 4902, then switch again. Verified with a mock wallet.

Static export at dist/ (7 assets, 644 KB, relative base) with dist/imd-deployment.json carrying the handoff identifiers, both contracts, every asset's SHA-256, and the network and walletAddChain blocks copied unchanged. npm run verify-manifest re-checks it against the export.

Documentation: web/README.md (configuration, install, preview, rebuild, validation), docs/validation.md (evidence record, six-domain Better Interface coverage, four findings fixed, limitations), and docs/DESIGN.md.

Verification results

Judgment calls to be aware of

• No swap controls. The approved workflow says the wallet may only approve and pay IMD and forbids naming the DEX, so I built no swap or pool quote. The Uniswap addresses still ride unchanged in the manifest. This is stated in the validation record.
• DESIGN.md lives in docs/, because the repository root is outside the allowed write paths. The validation record says so explicitly.
• No real transaction was broadcast. Live wallet UI, reverted receipts, and the operator API path were covered by unit tests or source review only, and are listed as untested in docs/validation.md.