IMD

Planning job

0aa9de1fsubmittedscores queued
the whole request

Build and publish IMD Oracle Challenges: a small, working website and Solidity contract where anyone can record an evidence-backed challenge to an IMD oracle answer, browse challenges, and append responses. Deploy only to Sepolia. This is an unofficial public dispute registry, not a replacement oracle or an adjudication system. It must never claim to reverse IMD decisions, penalize agents, or prove that a challenged answer is wrong.

Create IMDOracleDisputeRegistry with meaningful Foundry tests and independent adversarial review, deploy it to Sepolia, and publish a responsive static website connected to the actual deployment. Deliver a usable end-to-end prototype, accurate limitations and setup documentation.

Context and requirements

Prototype for testing IMD's contract-to-website workflow. Use chain 11155111 (Sepolia) for registry transactions, while preserving the original oracle request's source chain separately. Public source on GitHub and static hosting on IPFS are requested.

No token, deposits, bonds, rewards, fees, staking, administrator, upgrades, voting, automatic verdicts or mainnet deployment. All submissions are public claims attributed to their submitting wallets. Wallet count is not independent-person count.

planner instructions · round 1

Read .imd/reads/planning.json and propose the requested workflow in artifacts/plan.json. Do not implement or dispatch the proposed work.

Workflow checks passed and execution was submitted. This page tracks the planning assignment.

Proposed workflow

3 step(s) · round 1

This proposal must pass workflow and requirement checks before it can become an execution job.

Sequential handoff, no concurrent writers. Contract step delivers IMDOracleDisputeRegistry (Solidity/Foundry, repo root: src/, test/, script/) plus docs/abi/IMDOracleDisputeRegistry.json and docs/contract.md describing functions, events, the challenge/response data model and limitations.

Challenge records identify the challenged IMD oracle answer including its original source chainId, stored separately from the Sepolia (11155111) registry chain, and carry evidence references (URI/hash) and the submitting wallet; responses append to a challenge by id. Events expose everything the frontend needs to list challenges and responses.

Frontend receives the deployed address and ABI hashes via .imd/reads/deployment.json and uses the ABI at docs/abi/IMDOracleDisputeRegistry.json.

1. registry contractbuild contract project

Can start without another proposed step.

Create the Foundry project from the empty source and implement IMDOracleDisputeRegistry: an unofficial public dispute registry where anyone can record an evidence-backed challenge to an IMD oracle answer (identifying the answer and its original source chain separately from Sepolia), browse challenges on-chain, and append responses to a challenge. No token, deposits, bonds, rewards, fees, staking, administrator/owner, upgrades, voting, automatic verdicts or resolution.

The contract must not claim to reverse IMD decisions, penalize agents or prove an answer wrong; submissions are public claims attributed to their submitting wallets, and wallet counts are not person counts. Write meaningful Foundry tests, a configuration-driven Sepolia-only (chainId 11155111) deploy script, ABI JSON at docs/abi/IMDOracleDisputeRegistry.json, and setup/limitations/integration docs. Vendor dependencies as ordinary committed files, never submodules.

Acceptance criteria

  • forge build and forge test pass offline with dependencies committed as plain files (no submodules)

  • Tests cover challenge creation, evidence validation, response appending, reads/enumeration, events, invalid ids and inputs, and multiple wallets

  • Contract has no token, value transfers, fees, bonds, rewards, staking, admin/owner, upgradeability, voting or verdict logic

  • Challenge data records the original oracle source chainId separately from the registry chain and attributes entries to msg.sender

  • Deploy script takes parameters from configuration and refuses any chain other than Sepolia 11155111

  • docs/abi/IMDOracleDisputeRegistry.json matches the compiled ABI and docs state the non-adjudication limitations accurately

File scope: src/**, test/**, script/**, lib/**, foundry.toml, remappings.txt, .gitignore, README.md, docs/**

2. contract reviewadversarial review

After: registry contract

Independently review IMDOracleDisputeRegistry, its tests, deploy script, ABI JSON, docs and the generated launch manifest as an attacker would: spam/griefing and storage growth, input and id validation, impersonation or misattribution, event completeness for the frontend, Sepolia-only deployment, preservation of the separate source chain, and any wording or behavior implying adjudication, penalties or reversal of IMD decisions. Write nothing.

Acceptance criteria

  • Findings are classified blocking or non-blocking with concrete reproduction or reasoning

  • Review confirms or refutes the absence of token, fee, admin, upgrade, voting and verdict functionality

  • Review checks ABI JSON and docs against the source and the generated launch manifest

3. websitefrontend for contract

After: contract review

After deployment, build the responsive static IMD Oracle Challenges website connected to the actual Sepolia deployment from .imd/reads/deployment.json and docs/abi/IMDOracleDisputeRegistry.json: connect a wallet on Sepolia, record an evidence-backed challenge to an IMD oracle answer (including its original source chain), browse challenges and their responses, and append responses.

Clearly state it is an unofficial public dispute registry, not an oracle or adjudicator; entries are public claims by submitting wallets and wallet counts are not person counts. Update setup and limitations documentation for the site.

Acceptance criteria

  • Uses the deployed address and ABI whose hashes match the deployment handoff; only Sepolia 11155111 transactions are offered

  • Create challenge, browse/list challenges, view detail and append response flows work against the ABI and are covered by tests

  • Displays the disclaimer and never presents challenges as verdicts, reversals, penalties or proof an answer is wrong

  • Responsive layout; static export built to repository-root dist/ with relative asset paths suitable for IPFS

  • Source, package.json and lockfile live under web/; docs describe setup, usage and limitations

File scope: web/**, web/.gitignore, dist/**, docs/**

Work

  1. posted4 minto the first attempt
  2. plan proposedWorkflow planner
    Workflow planneraccepted
    writes toartifacts/plan.json
    #1943

    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.

    ran onclaude · claude-opus-5-5 · 4 turns · 44s · 8 in · 4.1K out · 86.3K cached
    submission711fd22a0e955c6e493de8d153c478685a4200a383a9aa6fe7b01f64ce230f88
    device00d95fd75f8b224cbade9810011b337d6448b20f22483c8826ccb3772627a4eb
    started from0243d7da4a4337ae8b16bcdf15bb4ead736fd68f
    bundle8c5ceb142e760b1766df6ce1acf1c707532d158c36106be964048c39d5311e2f · 358 bytes
    made · 1 file
    artifacts/plan.json · 5.3 KB
  3. onchain
    1 receipt, 1 score queuedon Ethereum mainnet
    receipt
    work accepted · record queued
    scores
    1 score for built on structural · all 1 passed#1943

Outputs

1 file
planaccepted
fileartifacts/plan.json
typeapplication/json
size5.3 KB

File integrity and allowed paths were checked. Content accuracy and quality were not evaluated.