I built imd-schedule-pack and committed it to main as e98977c. All 12 bodies passed the live check: on 2026-10-02 the API accepted every one with no blockers, and each quoted price equalled runs × 0.5 IMD.

What's in the repository

• bodies/: 12 schedule bodies, one per JSON file, written against the Schedule body section of the IMD docs:
  • 01–03: hourly on-chain canaries (IMD burned, ETH wrapped into WETH, IMD transfer count).
  • 04–06: daily questions (two volume rankings over the last 24 hours, and one GitHub question about go-ethereum releases).
  • 07–09: weekly research digests with continue: true.
  • 10–12: monthly reviews.
  • Every body has 7 runs or fewer, and none of the job bodies contains onchain, parentJobId or projectId.
• README.md:
  • Opens with the experimental label.
  • The table shows what each body does, its cadence, runs, and total cost. Together the 12 come to 70 runs, or 35 IMD. The table is generated from the files (npm run table), so the costs can't drift from the bodies.
  • Has the warning that unused runs are not refunded, with the advice to start at 7 runs or fewer and top up.
  • Explains how to run the check and what each field in results.json means.
  • Ends with "Commissioned through paid IMD swarm requests."
• bin/check.mjs (Node 20, built-ins and fetch only):
  • --help shows the experimental label.
  • --validate checks the documented limits locally, including working out the shortest gap a cron or interval can produce (10 minutes for questions, 30 for jobs).
  • The default run sends each body to /requests/check and writes results.json, recording the verdict and date per body.
  • A failed request is retried up to 3 times, 3 seconds apart. If the network can't be reached, that is recorded instead of a verdict. I tested this against a dead port: it made 4 attempts over about 9 seconds and recorded "unreachable".
• package.json (npm scripts) and an MIT LICENSE.

Decisions you should know about

• The first live check blocked all three hourly canaries. The API's wording screen judged them ambiguous. I rewrote 01 and 03 with exact event and unit definitions.
• I replaced the ERC-8004 canary with a WETH one. The docs give no ERC-8004 registry address to pin it to. I confirmed on mainnet that the WETH and IMD addresses hold the expected contracts (symbol() returned WETH and IMD).
• "Retry up to 3 times" is implemented as 3 retries after the first attempt, so up to 4 requests per body.
• There is no site banner, because this assignment covered bodies/, the README and the script, and there is no site. The label appears in the README and in --help; a site would need to add it.

The script only checks bodies; it never quotes, signs or pays for anything.

The review is complete. The findings file is on disk (excluded from git by the repository's own .git/info/exclude, so the tree is clean) and no repository file was changed.

Result: all 12 bodies and every cost line match the documented limits. I checked each body against the Schedule body, Oracle body and Job body sections of the IMD docs and against the live quote endpoint:

• Cadence floors hold. The three hourly oracle bodies fire 60 minutes apart against a 10-minute floor, and every job body fires weekly or monthly against a 30-minute floor.
• No job input carries onchain, parentJobId, projectId, deploymentLaunchId, submissionKey or expiresAt. The only job fields used are objective, skill, outputs, minCitations and github, all within their limits.
• Runs are 7, 7, 5, 7, 7, 7, 7, 7, 7, 3, 3, 3. All are inside 1 to 1,000,000 and at or under the README's "7 or fewer" advice.
• Every cost line equals runs times 0.5 IMD, the total row is 70 runs and 35 IMD, and the README table is byte-identical to the output of the table generator.
• Oracle inputs: labels, questions and definitions are within length limits, panel sizes are 5 to 10 with quorums inside 2 to panelSize, windows are 1 or 24 hours, validForSeconds is 3600 or 86400, and answer types are documented ones.
• The live API accepted all 12 with no blockers and quoted exactly the table amounts, today, reproducing the committed results.json.

The defects are all in the checker, not the bodies. I probed the local validator and the live check endpoint with about 45 variant bodies and found four divergences, written to the findings file ranked by severity:

1. Medium. The bin entry in package.json is a silent no-op. Through an npm bin symlink the script's "am I the main module" guard compares the symlink path with the real path, so imd-schedule-check --help prints nothing and exits 0. The experimental label never reaches someone who installed the package, and a CI step using it passes while checking nothing. Verified with a symlink on Node 24.
2. Low. The validator accepts {every: "P1M"} and "P1Y", computing 28 and 365 days, but the API refuses both as not an accepted duration. Weeks, days, hours, minutes and seconds are fine on both sides.
3. Low. The validator throws on cron day names such as MON and on L, which the API accepts. That false positive makes the table command refuse to print and the check command exit 1 even when the API accepts the body.
4. Low. A startAt in the past passes local validation but is refused by the API with "startAt is in the past".

Observations that are not findings. The retry path waits 3 seconds on a 429 and, after four attempts, records the body as "unreachable" although the network was reached. I could not trigger this: three consecutive full runs stayed under the 30 quotes per minute limit. The check endpoint accepted a panelSize of 4 with no blocker, while the docs say 5 or more, which is an API-side quirk. The task mentions a site banner, but this repository ships no site, so there is nothing to label there.