d8bd07d1-3f79-40da-a371-a9f8611aad36IMD JOB

I wrote `artifacts/plan.json`. It passes the planning schema check. The feedback asked for a final independent review after the launch manifest. The revised plan keeps the same three worker steps and makes that review step the final one. The control plane adds the launch manifest, so the plan has four steps in total. 1. **`contracts`** (`build-contract-project`): sets up the empty repository as a Foundry project, with its dependencies committed as ordinary files and no submodules. It builds the fixed-supply membership token and the soulbound badge. The badge has one mint per address, a threshold set at deployment, the `isEligible`, `hasBadge` and `isLapsed` checks, and a `BadgeMinted` event. This step also writes the tests, the ABI files in `docs/abi/` and `docs/contracts.md`. It does not deploy anything. 2. **`review`** (`adversarial-review`, depends on `contracts`): now explicitly the final independent launch review. It runs after the launch manifest is generated and before deployment. It looks for ways to get around the mint and threshold rules, to transfer a badge, or to create extra tokens. It checks that the source, the ABIs, the docs and the manifest match each other and target Sepolia (including the token pool seeding), and gives a blocking or non-blocking verdict. It writes nothing. 3. **`frontend`** (`frontend-for-contract`, depends on `review`): the last worker step, which starts after deployment. It builds a static site under `web/` and exports it to `dist/`, and it works from an IPFS gateway with no backend. It reads addresses and ABIs from the deployment handoff rather than hardcoding them. It includes all the requested features: wallet connection on Sepolia, balance against the threshold, a link to buy on the pool, the mint button, the badge display, and the member list with lapsed members marked. The plan keeps the full request, the Sepolia-only and IPFS/GitHub permissions, and the rule that the control plane handles deployment, pool seeding and publication. The contracts and frontend write to separate paths, and they share one agreed interface (`sharedInterfaces`). There are no open questions. The feedback's wording ("after the manifest") could also mean the validator wants the review somewhere else. But the planning rules say the frontend must be the final worker step with no review after it, so I kept the order. If the validator rejects this again, that ordering is the likely cause. I left the file untracked, as the output instructions require.