Open enhancement proposals that could use TC input

[hemanth]

I have a handful of open issues on the repo that go beyond simple bug fixes -- they touch schema design, new operations, and cross-capability boundaries. Some I have already turned into PRs (#402, #403), but the rest need design decisions that I do not think should be made unilaterally.

Posting this here so the TC can look at them together and decide which ones are worth pursuing, which need more discussion, and which should wait.

Already shipped as PRs

Issue	PR	What it does
#349 - Line items need buyer notes	#402	Adds buyer_notes string to line items for per-item instructions (food customization, gift messages)
#345 - Catalog availability needs stock signals	#403	Extends variant.availability with quantity, restock date, low-stock threshold, and per-location stock

Both are optional-field additions, backward-compatible, no breaking changes. Reviews welcome.

Needs TC design input

These are the ones I did not PR because they have open design questions.

#343 - Guest checkout (identity-optional checkout path)

The checkout flow assumes OAuth-based identity linking, which blocks scenarios where account creation is unnecessary -- voice agent ordering a coffee, one-time farmers market purchases, agent-mediated impulse buys. The issue proposes an auth_mode field on the buyer object and a guest_checkout config flag on the checkout capability.

Why it needs TC input: Three design questions are unresolved:

1. Should auth_mode live on the buyer object or on the checkout request metadata?
2. Should guest checkout require buyer.email as mandatory, or leave that to business policy?
3. Should this be a config field on the existing checkout capability, or a separate extension?

These are not implementation questions -- they are architecture choices that affect how the ecosystem evolves.

#346 - No way to discover available discounts before applying codes

The discount extension is reactive: you submit a code, you find out if it works. There is no way to ask "what promotions are running?" before guessing. For agents, this means they can not proactively tell a buyer "there is a 20% off sale right now" unless they already know the code.

Why it needs TC input: Adding a list_discounts or available_promotions operation touches all three transport bindings (REST, MCP, embedded). It also raises a business sensitivity question -- some merchants do not want all their active promotions exposed programmatically.

#348 - Orders lack modification support after placement

Once checkout completes, the order is read-only. No cancel_order, no modify_order, no line-item-level changes. Platforms fall back to continue_url for anything beyond reading status, which breaks the agent flow.

Why it needs TC input: Order modification is a large surface area. It needs new operations in three transport bindings, new webhook events, modification window semantics, and re-authorization flows for quantity increases. This is probably a multi-PR effort that should start with an agreed-upon scope.

#347 - Fulfillment extension and order events are disconnected

At checkout, the buyer picks "Express Shipping." After purchase, a fulfillment event says "shipped." Nothing connects the two -- the event does not reference which fulfillment method or option was selected. The agent can not say "your express order shipped" because it does not know which shipment is which.

Why it needs TC input: Linking fulfillment events back to checkout selections crosses the fulfillment-order capability boundary. The fulfillment extension currently lives on checkout only; extending its references into order events is a structural decision.

#344 - Cart session persistence guidance

The cart schema defines expires_at but says nothing about reasonable TTLs, session binding, reconnection semantics, or cross-transport persistence. There is even a TODO in the spec: cart.md line 103 says TODO: discuss continue_url destination - cart vs checkout. This one is docs-only, no schema changes needed.

What I am looking for

Not expecting all of these to move forward at once. Even a "yes, #343 is worth designing" or "hold off on #348 until v2" would help prioritize. Happy to write the PRs for anything the TC greenlights.

[hemanth]

cc @igrigorik @amithanda @richmolj @lemonmade -- would love TC eyes on which of these are worth designing next