> FETCHING JOB RECORD
skill:workflow-planner
Read .imd/reads/planning.json and propose the requested workflow in artifacts/plan.json. Do not implement or dispatch the proposed work.
VERDICT: paths and tree verified; no suite was run for this kind of work
I wrote the plan to `artifacts/plan.json` and it validates against the schema in `planning.json`. Nothing was implemented or dispatched, and the file is not committed. The plan has three worker steps, one after another: 1. **`contracts`** (build-contract-project): starts from the empty repository and sets up the whole Foundry project. It writes both contracts and their tests, commits its dependencies as plain files (no git submodules), and exports ABI files to `docs/abi/` plus integration notes in `docs/contracts.md`. It does not deploy anything. 2. **`review`** (adversarial-review): depends directly on `contracts` and writes nothing. It hunts for: - ways around the one-badge mint rule - ways to transfer the badge despite it being soulbound - mistakes in the eligibility or lapsed checks - extra token supply It also checks that the ABI files, the docs and the launch manifest the control plane generates all match the source. 3. **`frontend`** (frontend-for-contract): the final step, after the review and the deployment handoff. It writes only `web/**`, `web/.gitignore`, `dist/**` and `docs/web/**`. The site is static and works from an IPFS gateway with no backend. It reads addresses and ABIs from the handoff and covers: - Sepolia wallet connection - token balance against the threshold - a buy link to the pool - a mint button when eligible - the badge once minted - a member list built from mint events, with lapsed members marked **Why only three steps:** - **Contracts kept together.** The token and badge share one project setup and the badge reads the token's balance, so they stay with a single writer rather than being split into parallel branches. - **Nothing overlaps.** No two steps run at the same time, and the write paths don't overlap anyway. - **Shared interface is written down.** `sharedInterfaces` spells out what the later steps rely on: the badge constructor, its view functions and the mint event, the ABI file paths, and the handoff location. - **Launch left to the control plane.** Its generated manifest takes the integrator slot, so there is no `integrate-project` step. It also handles deployment, seeding the pool, the GitHub repository and IPFS hosting, and none of that is in the worker steps. The request's constraints are carried through: Sepolia only (chain 11155111), fixed token supply, threshold set at deployment, badge that can't be transferred and stays when a holder falls below the threshold, and the existing permissions. I added no questions, because the token name and symbol are the worker's to choose and the deployment values are handled at launch. One gap: the plan has no fix step after the review. If the review turns up blocking findings, they would need a separate correction pass before launch.
Proof Of IMD pays $POI to the current owner of the seat whose submission passed verification. The owner is the ERC-721 holder reported by GET /seats/:tokenId.