Expose seller request constructibility

[epistemedeus]

Problem

Agent402 already crawls seller OpenAPI and CDP Bazaar metadata, but its marketplace rows currently drop the required request inputs and authored examples. A buyer can discover a payable route yet still be unable to construct the request. We observed this directly as missing_required_input on an external x402 call.

What this changes

• adds a reporting-only requestContract to seller detail, route, find, and index-tool projections
• reports provenance, state, required path/query/header/body fields, an optional seller-authored example, and runtimeVerified: false
• reads the same evidence from seller OpenAPI, Bazaar, and Agent402's local catalog
• stores a compact tuple with a 1 KiB per-operation ceiling and revalidates legacy cache values at every public projection
• withholds credential, identity, header, cookie, write-only, sensitive, prototype-special, and secret-shaped values, including encoded URL components
• preserves existing ranking, price, payability, payment-network, pay-to, and execution-hint behavior

This does not probe or pay sellers, rank request completeness, or claim that a documented request worked at runtime.

Verification

• request-contract parser and privacy suite: 48 passed
• end-to-end projection and invariance suite: 12 passed
• live local projection parity: 18 passed
• MCP full catalog: 222 free tools executed and 308 wallet-only tools refused, 0 failures
• MCP HTTP connector suite: passed
• existing OpenAPI fallback, producer-shape, kit2, conversion, and memory suites: passed
• npm audit: 0 vulnerabilities
• 510-endpoint free-mode sweep: every documented output shape clean; two unrelated B20 probes returned public Base RPC 502s while direct public RPC health was available

On the current 533-operation public Agent402 OpenAPI snapshot, stored request tuples totaled about 43.4 KiB, averaging 81 bytes with a 554-byte maximum.

Conservative boundaries

Root-array and composition-heavy request bodies may report missing_example instead of guessing. Header and cookie values are intentionally never projected. Secret detection is bounded and signature-based, so ambiguous evidence fails closed.

Checklist

• DCO sign-off included
• no ranking or payment behavior changed
• no wallet, payment, or external spend used in tests
• offline regression tests added to the deploy workflow

[epistemedeus]

CI update for exact head 4bf464c:

The full test job failed only in the unrelated strict live-dependency sweep. It executed 411 of 419 in-scope tools successfully, soft-skipped the eight documented rate/media cases, and failed GET /api/barcode-lookup because Open Food Facts returned its own Unscheduled downtime HTTP 502 page.

A direct probe of the official Open Food Facts product endpoint reproduces the same 502. This PR does not change the data-kit, barcode route, fetch guard, or strict sweep. The request-contract suites and the rest of the exact-head local acceptance remain green.

I have kept the PR in draft and have not weakened the strict availability gate. Once the provider recovers, the same unchanged head can be rerun.

[MikeyPetrillo]

This is worth having and the privacy handling is careful. Four things before it can merge: (1) cap required breadth and thread one shared seen set through $ref resolution so a hostile schema cannot stall the crawler; (2) wrap the per-operation parse in its own try/catch so a throw never drops the seller's whole listing (today it lands in the manifest-only catch); (3) run projected example strings and field names through looksLikeListingInjection before they reach /api/route; (4) add an unknown state for rows without a tuple instead of reporting absent. Also please scope the field to external rows (on /api/find it duplicates and, for params named key/token/email, contradicts the existing example), and drop the unrelated parity-test rewrite. The Open Food Facts 502 is not on you.