Ward: PayCostsReq routing + multi-trigger + Countered affectorId

[delebedev]

Confidence: HIGH — full wire sequence from proxy recording (2026-03-21_23-56-57, Sheltered by Ghosts ward 2 vs Bushwhack).

Finding

Ward triggers use PayCostsReq (promptId=11) routed to the spell controller (not ward owner). Multiple ward triggers from one creature fire independently — paying one doesn't satisfy others.

Wire sequence

1. Targeting submitted → two AbilityInstanceCreated (one per ward trigger) spawn simultaneously
2. Both go to Pending zone, then Stack (LIFO: [trigger2, trigger1, spell])
3. First trigger resolves: PayCostsReq → opponent auto-taps → ResolutionComplete
4. Second trigger resolves: no PayCostsReq (opponent already tapped out) → auto-counters spell
5. Spell → GY with ZoneTransfer(category="Countered"), affectorId=wardTriggerIid

Code gaps

1. PayCostsReq for ward must route to spell controller, not ward owner — check BundleBuilder.payCostsBundle() seatId
2. affectorId on ward-countered ZoneTransfer must be the ward trigger instanceId
3. Multiple ward triggers from one creature not tested

Additional observation (2026-03-22_13-39-53)

Ward trigger observed on Nervous Gardener (ability 141939 "Ward {o2}") when targeted by Pacifism. TriggeringObject pAnn fires with affectorId=ward ability iid, affectedIds=[targeting spell, targeted creature]. PayCostsReq sent to opponent (promptId=11). Ward cost was paid and Pacifism resolved. Consistent with prior findings.

Wire spec

docs/plans/2026-03-21-ward-counter-wire-spec.md

refs #37

[delebedev]

Observatory data (2026-03-22)

7 PayCostsReq instances across recordings. Full proto decoded via just conform-proto PayCostsReq <session> --seat 0.

promptId is wrong. Recording shows promptId=11 (7/7). Our code has PAY_COSTS=1244. Filed as #194.

Full PayCostsReq shape from raw proto:

prompt.promptId: 11
prompt.parameters: [{parameterName: "Cost", type: NonLocalizedString, stringValue: "o2"}]
payCostsReq.manaCost: [{color: Generic, count: 2, objectId: <spellId>}]
payCostsReq.paymentActions.actions: [ActivateMana entries per land]
payCostsReq.paymentSelection: {context: ManaPool, optionContext: Payment, listType: Dynamic, idType: ManaId}
payCostsReq.autoTapActionsReq: {autoTapSolutions with pre-computed tap sequences}
allowCancel: Continue

Key fields for implementation:

• paymentActions contains per-land ActivateMana actions with manaPaymentOptions (which colors each land can produce)
• manaSelections inside each action has validationType: NonRepeatable and color options
• autoTapActionsReq provides the client with a pre-computed auto-tap solution
• allowCancel: Continue — not No or Abort