feat: composable scenario library for seller storyboards#528
Merged
Conversation
…tion Decompose the base media_buy_seller storyboard into reusable scenarios that specialization storyboards compose via requires_scenarios. Scenarios are small, focused behavior tests organized by agent type under storyboards/scenarios/media_buy_seller/. Initial scenarios: - governance_approved/denied/conditions (using force_governance_outcome) - refine_products (product-level refinement) - proposal_finalize (draft -> refine -> finalize -> committed -> IO) All 7 media buy seller storyboards now declare requires_scenarios. The compliance engine resolves and runs them alongside the main storyboard. Closes #527 partially (governance + refine scenarios shipped; creative, async, and error scenarios tracked in the issue for follow-up). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…-agent harness Governance is an external call the seller makes to a governance agent — the right way to test it is to control what's on the other end of that call, not to tell the seller to pretend it got a specific answer. Updated governance scenarios to document that the test harness must act as the governance agent. Added $harness.governance_url placeholders. Removed force_governance_outcome from the test controller. See #529 for the multi-agent harness capability needed to run these. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Governance is a multi-agent interaction — the test harness sets up real governance plans (spending limits, custom policies) on a governance agent, then registers that agent with the seller. The seller calls check_governance during create_media_buy and gets a real response. The training agent acts as the default governance agent. Override with --governance-agent-url for custom/local governance agents. Scenarios: - governance_approved: permissive plan ($100K limit), $25K buy passes - governance_denied: strict plan ($10K limit), $50K buy denied - governance_conditions: conditional plan (CTV reporting), CTV buy approved with conditions See #529 for remaining harness integration work. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This was referenced Apr 15, 2026
Creates media_buy_seller/delivery_reporting scenario that chains: simulate_delivery (via comply_test_controller) → get_media_buy_delivery → schema validation. Catches sellers returning non-compliant delivery response formats. All 7 media buy seller storyboards now require this scenario. Closes #543. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…dcoded ones Steps after search_by_spec now use context from the discovery step (signal_id, signal_agent_segment_id, pricing_option_id) instead of hardcoded IDs that may not exist on the agent being tested. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
These files were rewritten with the real-plan approach but the final versions weren't included in the earlier commit. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…tions Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
storyboards/scenarios/media_buy_seller/requires_scenarios— the compliance engine resolves and runs them alongside the main storyboardsignal_marketplacestoryboard to chain discovered IDs instead of hardcoded onesMotivation
Specialization storyboards (broadcast, non-guaranteed, etc.) skipped shared behaviors like governance integration, product refinement, and delivery reporting. Sellers could pass certification without proving they handle governance denial, product refinement, or schema-compliant delivery responses.
Scenarios shipped
governance_approvedgovernance_deniedgovernance_conditionsrefine_productsproposal_finalizedelivery_reportingStoryboard requirements
TypeScript changes
types.ts—requires_scenariosfield onStoryboardinterfaceloader.ts— recursive scenario loading fromstoryboards/scenarios/,getScenarioById(),resolveRequiredScenarios()comply.ts—expandScenarios()with dedup, nested scenario rejection, throw on missing IDsschema.yaml— documentedrequires_scenariosAdditional fix
signal_marketplace.yaml— steps aftersearch_by_specnow usecontext_outputsfrom discovery instead of hardcoded signal IDs that may not exist on the agent being tested.Follow-up issues
GOVERNANCE_DENIEDerror code in protocolTest plan
npm run buildpassesnpm testpasses (2832/2832)npx adcp storyboard list— scenarios don't appear in listingexpandScenariosthrows on missing scenario IDs (not silent skip)expandScenariosrejects nestedrequires_scenarios🤖 Generated with Claude Code