training-agent /signals: implement sync_governance + activate_signal governance check (signal_marketplace/governance_denied)

[bokelley]

Summary

Storyboard signal_marketplace/governance_denied shows 1P / 4S on /signals — only the discovery phase passes; the four real coverage phases skip because /signals doesn't currently implement governance integration.

The spec-correct flow:

1. Buyer calls sync_plans on a governance agent (e.g. /governance) to register a strict $100 plan
2. Buyer calls sync_governance on /signals to register that governance agent as the authority for the buyer's account
3. Buyer calls get_signals on /signals to find a signal
4. Buyer calls activate_signal on /signals
5. /signals must consult the registered governance agent (HTTP check_governance call) and emit GOVERNANCE_DENIED when the plan denies

Scope

• Implement sync_governance tool on /signals (currently not registered)
• Wire activate_signal to look up the registered governance agent for the caller's account and call check_governance over HTTP
• Surface GOVERNANCE_DENIED with findings propagated from the governance agent's response
• Storyboard fixture: governance plan named comply-signal-gov-denied with $100 budget — anything above ~$0.01/segment denies

Out of scope

• Cross-agent test-controller orchestration (governance plan must be seeded on /governance separately; the storyboard runner does this)
• New governance specialism on /signals (we just need governance-aware-seller behavior — calling out to an external governance, not hosting plans locally)

References

• Storyboard: static/compliance/source/specialisms/signal-marketplace/scenarios/governance_denied.yaml
• Required tools per spec: sync_governance, get_signals, activate_signal
• Default governance_agent_url in storyboard context: https://test-agent.adcontextprotocol.org (same training agent, /governance tenant)
• Similar governance integration already exists on /sales (search governanceContext in task-handlers.ts:handleCreateMediaBuy)

Coverage lift

Tenant	Today	After fix	Δ
/signals	67 / 58	67 / 62	+0 / +4

[bokelley]

Triage

Classification: compliance-coverage gap (tool missing from tenant)
Bucket(s): compliance-suite, signals, governance
Status: drafting-pr

What the experts said:

• ad-tech-protocol-expert: approved — activate_signal has no structured rejection arm; errors[] placement is correct per spec's GOVERNANCE_DENIED wire-placement rule (case 2 in error-code.json); .min(1).max(1) on governance_agents consistent with one-agent-per-account invariant.
• code-reviewer: blocker found and fixed — ERROR_IN_BODY_TOOLS is dead code on the v6 per-tenant path; fix applied in v6-platform.ts:activateSignal to bypass translateV5Result and return errors in body with context echoed from the request.

My take: Session-sharing by brand.domain (all tenants share session.governancePlans) already propagates the governance plan from /governance to /signals without HTTP calls — the same pattern brand_rights/governance_denied uses for acquire_rights. The HTTP outbound check_governance call described in the issue body is the correct production pattern but out of scope for the training agent's session-based simulation; storyboard coverage is equivalent.

Shipped in #4100: sync_governance on /signals, v6-platform.ts:activateSignal errors-in-body bypass, tool-catalog.ts drift guard.
Remaining: full HTTP outbound check_governance call via the registered governance agent URL (session sharing is sufficient for training-agent storyboard coverage; a real seller would need the HTTP call). Issue stays open as a long-term architecture note.

---

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

---

Generated by Claude Code