[vvillait88]

Summary

createBazaarDiscovery typed bodyType as 'json' | 'form', but the x402 discovery schema accepts only json, form-data and text. A declaration using 'form' is rejected by the upstream validator (/input/bodyType: must be equal to one of the allowed values), and the types offered no way to declare a multipart or text body. This narrows the type to upstream's set.

Type of change

• Bug fix (no breaking change)
• New feature (no breaking change)
• Breaking change (existing callers must update)
• Docs, tests, or internal maintenance only

Public API

BazaarDiscoveryConfig.bodyType is now 'json' | 'form-data' | 'text'. A caller passing 'form' now gets a type error. Such a declaration already failed upstream validation, so this changes no working behavior.

Test plan

• New tests in tests/discovery/bazaar.test.ts declare each accepted value, enrich it with enrichBazaarDiscoveryExtensions, and run upstream's validateDiscoveryExtension, which returns { valid: true }. A separate test confirms 'form' comes back invalid with a bodyType error, so the suite fails if upstream drops one of our three values or starts accepting 'form'. A value upstream adds later would not fail it.
• bun run lint, typecheck, test (1641 passed, 4 skipped) and knip all exit 0.
• The repo's typecheck covers src and examples, not tests, so the runtime tests are what hold this in place.
• The Python package types body_type as a plain str, so it has no equivalent wrong value.

Checklist

• Tests cover the new behavior, and the suite passes locally
• Lint, format, and type checks pass
• Docs and README examples updated if the public surface changed (no README or example uses bodyType: 'form')
• No secrets, credentials, or personal data in the diff or the tests

[vvillait88]

Review: Bazaar bodyType union (head 7b6ddab)

Nothing blocks this PR. This comment is the approval, subject to the merge order in item 3.

Probes (run in a detached worktree at this head, installed with bun install --frozen-lockfile):

1. vitest run tests/discovery/bazaar.test.ts passed 6 of 6 against the @x402/extensions 2.28.0 that main locks. I then swapped in the 2.29.0 core and extensions dists from their npm tarballs and reran: 6 of 6 again, so the tests hold across the bump in Bump @x402 dev set to 2.29.0 and exempt it from the release-age soak #164.
2. Mutation control: I changed the rejected value from 'form' to 'json', and the rejection test failed (1 failed, 5 passed). The negative test does fire.
3. CI: Dependency Scan fails on this head because of the qs 6.16.0 advisory GHSA-6pq8-jhm2-2vcw, which comes from main, not from this change; Bump @x402 dev set to 2.29.0 and exempt it from the release-age soak #164 fixes it. Every other row passes (ci, node-compat 22/24/26, CodeQL, Analyze). Merge Bump @x402 dev set to 2.29.0 and exempt it from the release-age soak #164 first, update this branch from main, and confirm the scan is green before merging.

Correctness:

• The new union matches upstream VALID_BODY_TYPES (json, form-data, text) in both 2.28.0 and 2.29.0. With bodyType set, both versions enrich a POST to method POST, so the valid-case assertions describe real output.
• git grep finds no other bodyType or body_type use outside tests, so no docs or examples need updating.
• The Python twin (build_bazaar_discovery_payload) takes body_type: str and passes it through, so there is no wrong literal to fix there.
• Describing this as a bug fix is fair. The type narrowing is a compile-time break only for a caller passing 'form', and that caller already produced a declaration upstream rejects. The PR body says exactly this.

Non-blocking: the test plan says the suite "fails if the accepted sets drift apart". That holds in one direction: it fails if upstream drops one of the three values or starts accepting 'form'. If upstream adds a fourth type, the suite stays green and the union is merely narrower than upstream, which is the safe side. A wording tweak to the body is enough.

[vvillait88]

Body wording corrected: the tests fail if upstream drops one of the three accepted values or starts accepting 'form', and would not catch a value upstream adds later. Merging after #164, then updating from main so the dependency scan picks up the qs fix.