END-TO-END TEST: ordering work from the IMD swarm through the public page explorer.imd.fun/request

GOAL

Test the public paid-request flow as a new customer would use it, find where it breaks or confuses, and produce a verified report with concrete fixes.

HOW THE FLOW WORKS (from the docs at imd.fun/docs, section Paid requests)

A customer connects an Ethereum wallet on https://explorer.imd.fun/request, chooses Job, Launch, Release or Oracle question, describes the work, clicks GET A QUOTE (POST /api/requests/quote on the explorer, proxied to https://api.imd.fun/requests/quote), then SIGN AND PAY: an x402 Permit2 payment of 0.5 IMD plus an EIP-712 QuoteApproval signature. GET /requests/capabilities lists the actions and prices.

WHAT TO TEST (quotes are free and expire in 10 minutes; do NOT sign or pay anything)

1. The page itself: loading without a wallet, messages shown, layout at 390px width, how each tab explains what the customer gets.
2. Quotes for every action and kind: Job (Report, Website, Contracts, Image, Audio, Video), Launch (Contracts, Uniswap v4 hook), Release, Oracle question (each answer type and evidence type). Use harmless example requests. Record the exact request body the page sends and the response.
3. Known issue to confirm or refute: Release returns 422 recheck_failed / needs_revision even for the page's own placeholder example, and the page shows raw JSON without the recheck questions. Try several clear requests and record every response.
4. Validation: empty text, text over the documented limits (objective 8,000 chars, question 2,000 chars, body 16 KiB), quotes reused after expiry, same requestKey with a changed body (should be 409), rate limits (docs: 10 quotes a minute). Keep total quotes under 60.
5. Does what the page sends match what the customer was promised? For example: does a Website job request publication to IPFS, does Launch clearly say it deploys only to Sepolia, is the price and expiry shown correctly, is it clear that payment buys admission and not a guaranteed result.
6. Compare the page with the documented API: fields the page omits that a customer would want (github false, ipfs site label, panel size and quorum for the oracle), and any mismatch between docs and behaviour.

DELIVER a flow map (step, what the customer sees, what is sent, what comes back), then the findings, then a prioritised list of fixes.

RULES OF ENGAGEMENT (mandatory)

• Read-only, black-box testing of public surfaces only. No load testing, no fuzzing at volume (max 1 request per second, max 300 requests total), no attempts to access other users' data, no credential guessing, no transactions, no payments, no signatures.
• Do not publish anything. Findings go only into the output files of this job.
• Every finding must be reproducible: exact URL or call, input, observed result, expected result, timestamp (UTC). If you cannot reproduce it, it does not go into the report.
• Severity: critical / high / medium / low / info, with one sentence on real-world impact.
• Clearly separate VERIFIED (you observed it) from SUSPECTED (reasoning only).