Skip to content

feat(decisioning): UserWarning when sales-* required methods missing (#423)#445

Merged
bokelley merged 2 commits intomainfrom
bokelley/dx-423-validate-platform
May 3, 2026
Merged

feat(decisioning): UserWarning when sales-* required methods missing (#423)#445
bokelley merged 2 commits intomainfrom
bokelley/dx-423-validate-platform

Conversation

@bokelley
Copy link
Copy Markdown
Contributor

@bokelley bokelley commented May 3, 2026

Summary

  • Wires validate_platform to soft-warn when a sales-* platform claims a specialism but is missing one of the four v6.0 rc.1 required methods (get_media_buys, provide_performance_feedback, list_creative_formats, list_creatives) that the strict-required core (REQUIRED_METHODS_PER_SPECIALISM) doesn't yet enforce. Without this, adopters mid-upgrade could ship a sales-* platform missing four spec-required methods silently — exactly what the v3 ref seller hit until the deep review caught it manually.
  • Adds RECOMMENDED_METHODS_PER_SPECIALISM covering all six sales-* slugs, deduped warnings across overlapping specialisms, and an ADCP_DECISIONING_STRICT_VALIDATE_PLATFORM=1 env flag that flips the soft warning into a hard AdcpError("INVALID_REQUEST") for adopters who have completed the migration and want to lock the gain in via CI.
  • Each warning identifies the specialism + missing method and points adopters at the Protocol docstring source (src/adcp/decisioning/specialisms/sales.py:184-227).

Test plan

  • New test file tests/test_validate_platform_warnings.py (7 tests):
    • Soft-warn happy path: missing methods on sales-non-guaranteed produce one UserWarning per method, all pointing at the Protocol docstring.
    • No warning when all 9 methods are present.
    • Strict-mode env var flips warning to AdcpError("INVALID_REQUEST") with structured details.missing_recommended.
    • Strict-mode is exact-match "1" (not "true" etc.).
    • Dedup across overlapping specialisms (sales-non-guaranteed + sales-guaranteed warns once per method, not twice).
    • Static drift guard: every sales-* spec slug appears in the recommended map.
    • Regression guard: v3 reference seller (post-PR feat(v3-ref-seller): broaden sales surface + sync_accounts + invoice_recipient #408) emits zero warnings.
  • ruff check src/ tests/ clean.
  • mypy src/adcp clean.
  • pytest tests/ -k validate_platform — 35 passed (7 new + 28 pre-existing).
  • pytest examples/v3_reference_seller/tests/ — 13 passed (no regression).

🤖 Generated with Claude Code

bokelley and others added 2 commits May 3, 2026 00:30
…423)

The SalesPlatform Protocol docstring (src/adcp/decisioning/specialisms/
sales.py:184-227) marks four methods — get_media_buys,
provide_performance_feedback, list_creative_formats, list_creatives —
as required for any sales-* specialism in v6.0 rc.1+, but
validate_platform only enforced the five-method core. Adopters
mid-upgrade could ship a sales-* platform missing the broader surface
silently (the v3 ref seller hit exactly this until the deep review
caught it).

Adds RECOMMENDED_METHODS_PER_SPECIALISM with the four-method recommended
set wired to all six sales-* slugs. validate_platform now walks each
claimed specialism's recommended set and emits one UserWarning per
missing method (deduped across overlapping specialisms) pointing the
adopter at the Protocol docstring. Setting
ADCP_DECISIONING_STRICT_VALIDATE_PLATFORM=1 flips soft-warn into a
hard AdcpError("INVALID_REQUEST") so adopters who have completed the
v6.0 rc.1 surface migration can lock the gain in via CI.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…icks (#423 fix-pack)

The docstring-vs-code consistency test (#424, just merged) caught two
issues in this PR:

1. The strict-mode env-var read used os.environ.get(_STRICT_VALIDATE_ENV)
   indirection, which the consistency test's regex doesn't follow.
   Inline the literal 'ADCP_DECISIONING_STRICT_VALIDATE_PLATFORM' string
   so the test sees the read.

2. The docstring wrapped 'INVALID_REQUEST' in backticks on lines near
   env-var context keywords, tripping the test's SCREAMING_CASE heuristic
   (it treats backtick-wrapped uppercase tokens as candidate env vars).
   INVALID_REQUEST is a spec error code, not an env var — drop the
   backticks so it's plain prose.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@bokelley bokelley force-pushed the bokelley/dx-423-validate-platform branch from 9fa4827 to 16f435f Compare May 3, 2026 04:32
@bokelley bokelley merged commit 5349ddc into main May 3, 2026
11 of 13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant