Summary
The published @adcp/sdk@6.17.0 bundles compliance/cache/3.0.6/... storyboard YAMLs, but the AdCP spec is at 3.0.8. So even when fixes land in adcontextprotocol/adcp (e.g. #4218, #4230, the remaining static-key sweep filed today), they don't reach SDK adopters until the bundle is regenerated and a new SDK version published.
Repro
$ npx -y @adcp/sdk@6.17.0 --version
@adcp/sdk@6.17.0
$ ls node_modules/@adcp/sdk/compliance/cache/
3.0.6/ # <-- two minor versions behind spec
Inspecting the cached YAMLs shows behavior the spec source has presumably moved past — e.g. the surviving 24 static idempotency_key strings we're filing as a follow-up to adcp#4230. Even after that follow-up lands in spec source, SDK users will still hit the static keys until the cache is regenerated.
Why this matters
Storyboard validation is the buyer-side proof of seller compliance. If the cached scenarios in the SDK lag the spec, the validation grades sellers against an old contract — false positives (failing on behavior the seller actually fixed) and false negatives (passing on behavior the spec has tightened) both happen.
We're hitting this concretely: shape changes in our seller surface as storyboard failures because the SDK bundle's static-key scenarios collide with cached idempotency responses.
Proposed fix
Either:
-
Regenerate the bundled cache on every SDK release — CI step that pulls compliance/source/... from adcontextprotocol/adcp@<spec_version> matching the SDK's pinned spec version, runs whatever build step produces the cache. Bumps cache version with each spec bump.
-
Fetch latest cache at install/invocation time — npx -y @adcp/sdk could fetch the current spec's cache from a CDN or from adcontextprotocol/adcp directly. Avoids the rebuild-cycle entirely but introduces a network dependency at storyboard-runtime.
(1) is more robust and is what most SDK-spec relationships look like. (2) is more responsive to spec changes but riskier for offline users.
Either way, the SDK should advertise which spec version its bundled cache corresponds to (already does via the path), and its release notes / --version should mention any spec-version drift the user might care about. Currently SDK 6.17.0 says "AdCP 3.0.8" in its compliance report header but ships 3.0.6 cache — silent inconsistency.
Related
Environment
- @adcp/sdk: 6.17.0
- Spec advertised in CLI output: 3.0.8
- Bundled cache path:
compliance/cache/3.0.6/
Summary
The published
@adcp/sdk@6.17.0bundlescompliance/cache/3.0.6/...storyboard YAMLs, but the AdCP spec is at 3.0.8. So even when fixes land inadcontextprotocol/adcp(e.g. #4218, #4230, the remaining static-key sweep filed today), they don't reach SDK adopters until the bundle is regenerated and a new SDK version published.Repro
$ npx -y @adcp/sdk@6.17.0 --version @adcp/sdk@6.17.0 $ ls node_modules/@adcp/sdk/compliance/cache/ 3.0.6/ # <-- two minor versions behind specInspecting the cached YAMLs shows behavior the spec source has presumably moved past — e.g. the surviving 24 static
idempotency_keystrings we're filing as a follow-up to adcp#4230. Even after that follow-up lands in spec source, SDK users will still hit the static keys until the cache is regenerated.Why this matters
Storyboard validation is the buyer-side proof of seller compliance. If the cached scenarios in the SDK lag the spec, the validation grades sellers against an old contract — false positives (failing on behavior the seller actually fixed) and false negatives (passing on behavior the spec has tightened) both happen.
We're hitting this concretely: shape changes in our seller surface as storyboard failures because the SDK bundle's static-key scenarios collide with cached idempotency responses.
Proposed fix
Either:
Regenerate the bundled cache on every SDK release — CI step that pulls
compliance/source/...fromadcontextprotocol/adcp@<spec_version>matching the SDK's pinned spec version, runs whatever build step produces the cache. Bumps cache version with each spec bump.Fetch latest cache at install/invocation time —
npx -y @adcp/sdkcould fetch the current spec's cache from a CDN or fromadcontextprotocol/adcpdirectly. Avoids the rebuild-cycle entirely but introduces a network dependency at storyboard-runtime.(1) is more robust and is what most SDK-spec relationships look like. (2) is more responsive to spec changes but riskier for offline users.
Either way, the SDK should advertise which spec version its bundled cache corresponds to (already does via the path), and its release notes /
--versionshould mention any spec-version drift the user might care about. Currently SDK 6.17.0 says "AdCP 3.0.8" in its compliance report header but ships 3.0.6 cache — silent inconsistency.Related
Environment
compliance/cache/3.0.6/