feat(evals): firmer, individually binding referee VOTE wording (webchat Werewolf)

[Poytr1]

What

Stacked on #984/#985 (retargets as they merge). Eval-side only — no product code.

Measured motivation: the 7-player real game completed a perfect six-speaker sequential discussion and then stalled at day-vote with one ballot cast — zero hop refusals, zero gated wakes, zero lost replies. The polite "now says their vote out loud" invitation read as optional to players with no strong read.

The referee's vote announcement now binds each player personally: every living player MUST cast exactly one vote, in your next message; having no strong read does not excuse you; not voting forfeits your voice. The machine-parsed prefix (VOTE <n>. Discussion is closed.) and the Living players: list are byte-identical, so the scripted players' parsing is untouched — both CI games pass unmodified. The real effect shows in the 7-player runs.

🤖 Generated with Claude Code

[agentconnect-md-test]

Requesting one targeted wording fix. The strengthened vote prompt now labels a concrete player-2 ballot as the “exact form,” but player-2 can be removed before a later-round vote. A real player following that literal instruction can submit a dead target; the referee rejects that vote and waits forever for every living voter, recreating the stall this change is meant to prevent. Please make the example target a currently living player or use explicit replaceable placeholders.

I verified the review checkout is the trusted synthetic merge of base eaa18e9e6cb550c3dec506667159b361d6e74096 and head 5cc4b4178575509f2fba104fa9ee9c6fc3a876ab, and inspected the complete one-file patch. I could not execute the focused Vitest suite because this isolated checkout has no installed dependencies.

_{sent by review-bot (Codex · gpt-5.6-sol) · open in session}

[agentconnect-md-test]

The new “exact form” makes player-2 look like a required literal target, but this same referee can reach later rounds after player-2 was killed or lynched. parseStatedTarget then produces player-2, the this.alive.has(intent.target) check rejects the ballot, and the day cannot resolve because it waits for every living player's vote. This was only a loose example before; the stronger wording amplifies it into a likely real-player failure. Please use placeholders that explicitly require substitution, or generate an example whose target is living in the current round.

[agentconnect-md-test]

The previous blocking issue remains in this synchronized revision. The strengthened prompt calls "<name>: I vote for player-2" the “exact form,” but player-2 can already be dead in a later round. A real player following that literal instruction submits a target rejected by this.alive.has(intent.target), while the referee waits for every living voter before resolving the day. Please use explicitly replaceable placeholders or generate a concrete example with a currently living target.

I verified the checkout is exactly trusted head 4dd79075681fce8e72b8e43b597ad381bb0b27b1 and inspected the complete base-to-head patch. The focused Vitest suite remains unavailable in this isolated checkout because dependencies are not installed.

_{sent by review-bot (Codex · gpt-5.6-sol) · open in session}

[agentconnect-md-test]

This still promotes player-2 from a loose example to the required “exact form.” On any later day after player-2 was killed or lynched, a model following the literal prompt posts an invalid ballot; the alive-target check discards it and the all-voters condition can never complete. Please make the target a current living player or use an explicit placeholder that must be replaced.

[agentconnect-md-test]

The prior later-round vote issue is fixed in this revision. The example now uses two aliases from the current living roster and clearly tells each recipient to use their own name plus one living target, so a removed player-2 can no longer turn the strengthened instruction into an invalid ballot. The machine-parsed VOTE <n>. Discussion is closed. prefix and Living players: list remain intact, and I found no blocking issue in the complete one-file patch.

I verified the checkout is exactly trusted head 183a295154ea4ec4a690c05c2a50b01ca05911dd. I did not run the focused Vitest suite because this isolated checkout has no installed dependencies.

_{sent by review-bot (Codex · gpt-5.6-sol) · open in session}