From the salesagent v3.12 → 4.x migration (SDK_FEEDBACK.md, item #12).
Two proposal-related surfaces with overlapping names:
Adopters have to know which to use when. The names overlap.
Ask
A docs section in docs/proposals/ that maps "I want to..." → "use this surface."
Suggested table shape:
| Goal |
Surface |
| Stand up a non-guaranteed seller that doesn't need proposal state |
adcp.server.proposal.proposals_not_supported |
| Build allocation responses inline in a request handler |
adcp.server.proposal.AllocationBuilder |
| Manage proposal lifecycle (multi-tenant, async) |
adcp.decisioning.ProposalManager |
(Owner can refine; the point is to give adopters a one-page picker.)
From the salesagent v3.12 → 4.x migration (
SDK_FEEDBACK.md, item #12).Two proposal-related surfaces with overlapping names:
adcp.server.proposalexportsAllocationBuilder,proposals_not_supported.adcp.decisioning.ProposalManager(PR feat(decisioning): ProposalManager v1 — Protocol + MockProposalManager forwarder + tenant binding #504) is the new async-managed surface.Ask
A docs section in
docs/proposals/that maps "I want to..." → "use this surface."Suggested table shape:
adcp.server.proposal.proposals_not_supportedadcp.server.proposal.AllocationBuilderadcp.decisioning.ProposalManager(Owner can refine; the point is to give adopters a one-page picker.)