I've built imd-mock, a local mock of the IMD paid-request API, and committed it as one commit on main (c7428a0). npm test passes all 80 tests, including after deleting node_modules and reinstalling with npm ci --offline. Running it with npx from the git repo installed it without a build step, and the conformance suite passed 20 of 20. I couldn't try the literal npx github:<owner>/<repo> because the repo has no GitHub remote. It goes through the same git install path, so it should behave the same.

What it does

• Routes: all seven you listed, plus a canned POST /requests/import and a page at / that shows the experimental banner. Any request with a browser Origin header gets 403. Orders and jobs can only be read with the bearer token that created them.
• Paid submit: without payment it returns the 402 challenge with the fields you specified. With payment it requires the exact payment object (any extra or missing field is invalid_payment_shape). It then checks every Permit2 field against the quote, recovers the signer of both the Permit2 and QuoteApproval signatures, and blocks reuse of a nonce. A refused payment changes nothing, so the order can still be paid.
• Flaky mode (--flaky): /requests/check refuses each distinct body once, then answers normally.
• Statuses: there are no timers. Each poll moves an order one step (admission_pending → running → completed, or refused), so tests always see the same sequence.
• Test data: fixed public test keys, and fixtures/vectors.json, which holds one complete signed payment so clients in any language can compare their bytes.
• Conformance: npm run conformance starts its own mock and runs the 20 checks; --url points it at a server that's already running.

How the acceptance criteria are covered

• Signed payment accepted, any single change refused: test/payment.test.ts has one test per case. That covers every field of the payment, the quoteSignature, all ten QuoteApproval fields, and Permit2 authorizations that are validly signed but have a wrong field.
• Flaky mode: five tests in test/server.test.ts, plus a run of the conformance suite against a flaky mock.
• Experimental label: at the top of the README, in --help, on the site banner, and printed when the server starts. The README ends with the commissioning line.
• README: it says plainly that this is a mock and has a "What the mock does not reproduce" section. That covers: no chain, balances or settlement; stand-in actions; a mock payTo; canned verdicts; and response details I had to choose myself.

Decisions you might not expect

• No runtime dependencies. I wrote keccak256, secp256k1 signing and recovery, and EIP-712 hashing myself. Their output matched viem byte for byte (hashes, addresses, signatures and both typed-data digests) and reproduces the signature from the EIP-712 spec example. The code is not constant-time, which the README notes; only use it with the published test keys.
• Committed build output. dist/ is committed so npx runs it without building. The build script is named compile rather than build, because a build or prepare script would make npx github: install dev dependencies and build first, which needs the network.
• Vendored dev tools. TypeScript and its Node type definitions are committed as tarballs in vendor/npm/ (4.7 MB) so installs work offline.
• Shapes I had to invent. The flow doesn't pin down some details: accepts[0].extra, error codes for refusals, requesterScopeHash (here sha256 of the token) and how ids are made. The README lists all of these as mock choices.
• Stand-in actions. echo completes immediately with a 200; implement returns 202 and runs a job. Any input containing [refuse] gets a refusal.

One thing for you to do: replace <owner>/<repo> in the README once the repo has a home.

Saved 7 verified findings in .imd-findings.json: 1 high, 6 medium.

The highest-severity issue rejects every documented IMD action. Each finding includes a concrete reproduction and verified source snippet. Implementation files remain unchanged.

The review is complete. Every finding from the previous round is fixed, and the findings file holds an empty list.

Prior findings, all confirmed fixed by rerunning the original reproductions against the committed dist modules:

• Documented actions rejected (high). Quote and check now accept all seven live actions. The job.open body from the reproduction returns 201, and schedule.create with 3 runs prices at 3 x 0.5 IMD.
• Inherited property names bypass the shape check. A payment carrying constructor, an own proto key, or toString now fails with 400 invalid_payment_shape. The check uses Object.hasOwn, and a conformance case covers it.
• Capabilities schema. Actions are objects with action, version, payment terms and quoteTtlSeconds, and launches.chains is present.
• Order polling envelope. GET /requests/{id} returns top-level status, order, payment and admission, moving admission_pending to admitted with admission.result carrying jobId and URLs.
• Identical paid-submit retries. Resending the same header and body returns the stored first outcome with a payment-replayed header and settles nothing twice. A freshly signed second payment still gets 409.
• Check verdict fields. Flaky mode returns action, blockers and suggestions, with an evaluator_noise blocker on the first call and none on retry.
• Public job reads. GET /jobs/{id} and /jobs/{id}/result return 200 without any bearer.

What else I checked and found correct. The committed dist is byte-identical to a fresh compile. All 93 unit tests and all 22 conformance checks pass, in normal and flaky mode. Adversarial probes on the verifier behaved as a real server would: recovery id 0/1 accepted and 29 refused, cross-order payment reuse refused as payment_mismatch, a from address that differs from the signer refused, a QuoteApproval signed by another key refused, non-empty extensions and a non-canonical nonce refused as shape errors, an expired quote returns 410, and a replay from another bearer returns 404. The README carries the experimental label at the top and the commission line at the end.

No new defects were found, so no revision is needed.