feat(server): createMediaBuyStore — opt-in targeting_overlay echo for property-lists / collection-lists sellers

[bokelley]

Parent: #452

JS source

6.7 commit dda2a77e feat(server): createMediaBuyStore.

Use case

Narrow but mechanical. Sellers claiming property-lists / collection-lists specialisms have to echo targeting_overlay on get_media_buys. Currently hand-rolled in every adopter.

Proposed API

from adcp.decisioning import create_media_buy_store

platform.media_buy_store = create_media_buy_store(store)

Opt-in framework wiring that handles the echo automatically when the seller declares property-lists or collection-lists.

Acceptance criteria

• create_media_buy_store exported from adcp.decisioning.
• targeting_overlay echoed correctly on get_media_buys responses for declared specialisms.
• No-op for sellers not claiming those specialisms.
• Tests cover both paths.

[bokelley]

Triage

Classification: Feature request
Bucket(s): handlers (no matching label in repo — gap noted in run summary)
Status: clarify

What the experts said:

• code-reviewer: three correctness blockers — targeting_overlay lives at package level in the schema (needs (media_buy_id, package_id) keying, not per-media-buy); injection must be additive not replace; update_media_buy must also write to the store (spec: "echoed from the most recent create_media_buy or update_media_buy").
• dx-expert: proposed platform.media_buy_store = create_media_buy_store(store) breaks the framework's kwarg-on-factory wiring grammar (every other opt-in — buyer_agent_registry, webhook_sender, resource_resolver — is a kwarg on create_adcp_server_from_platform); needs a typed MediaBuyStore Protocol matching the existing AccountStore/TaskRegistry pattern.

My take: The use-case is spec-mandated and the change is clearly non-breaking, but the acceptance criteria leaves three questions unanswered that would produce subtly wrong behavior if resolved incorrectly at implementation time.

1. Per-package keying + update_media_buy: The get-media-buys-response schema puts targeting_overlay at the package level and says "echoed from the most recent create_media_buy or update_media_buy." Should the store key by (media_buy_id, package_id) and write on both shims? (Current AC only mentions create_media_buy.)

2. Merge semantics: When an adopter's get_media_buys response already carries a partial targeting_overlay (e.g. a frequency cap or geo), should the shim inject PropertyListReference/CollectionListReference additively into the existing overlay, or replace it entirely with what was stored?

3. API shape: Should media_buy_store be a kwarg on create_adcp_server_from_platform (matching the framework's opt-in grammar) rather than a post-construction attribute assignment on the platform?

---

Triaged by Claude Code. Session: https://claude.ai/code/session_014j4ZPx2Y4MvG67gQXPykQW

---

Generated by Claude Code