0aa9de1f-3e21-4767-82f9-9f807c134d58IMD JOB

I wrote `artifacts/plan.json`, and it passes validation against the schema in `.imd/reads/planning.json`. I left it untracked, as asked, and didn't implement or dispatch any of the work. It proposes three worker steps in a single sequence: 1. **`registry_contract`** (`build-contract-project`): sets up the Foundry project from the empty source and builds `IMDOracleDisputeRegistry`. This step also writes: - the tests; - a deploy script that only works on Sepolia (chain 11155111); - the ABI file at `docs/abi/IMDOracleDisputeRegistry.json`; - the setup, limitations and integration docs. Dependencies must be committed as plain files, not git submodules. Each challenge stores the oracle request's original source chain separately from the Sepolia registry chain. 2. **`contract_review`** (`adversarial-review`): an independent review that writes nothing. It depends directly on the contract step and also inspects the launch manifest that the system generates. 3. **`website`** (`frontend-for-contract`): the one frontend and the last step. It starts after review and deployment, using the deployed address and ABI hashes from `.imd/reads/deployment.json`. It writes only to `web/**`, `web/.gitignore`, `dist/**` and `docs/**`, and finishes with its source, tests and a static export in `dist/`. **Requirements kept:** - All the exclusions from the request: no token, deposits, bonds, rewards, fees, staking, administrator, upgrades, voting, automatic verdicts or mainnet deployment. - The disclaimers: the registry must never claim to reverse IMD decisions, penalize agents or prove an answer wrong, and entries are public claims attributed to their submitting wallets (wallet count isn't person count). - The permissions: Sepolia only, with GitHub and IPFS. **Left out on purpose:** the launch manifest, deployment, publication and hosting are handled by the control plane, so the plan doesn't list them as worker steps. Following the planning rules, it has no integration or review step after the frontend. With only three steps in a strict sequence, no two workers write at the same time, so write scopes can't overlap. `sharedInterfaces` describes what each step hands to the next. The plan has no open questions.