ADR-052: Multiplayer constraints apply to all multiplayer generation, not just team-themed¶

Status: Superseded by ADR-053 Date: 2026-05-11

Superseded same-day. This ADR's framing — that multiplayer needs a structurally different prompt because players see picks before rationales — was based on an unverified claim about the play loop. The actual flow (src/app/play/[sessionId]/page.tsx:1097) submits pick + rationale together and reveals both simultaneously. With that established, multiplayer is just solo with more people — the convergence failure mode applies to both, and the fix belongs in Principle #6 globally, not in a multiplayer-only branch. ADR-053 captures the corrected decision. Keeping this ADR in place to preserve the diagnostic trail.

Context: A live-played generated multiplayer scenario ("Technical Debt vs Feature Requests") surfaced as low-signal — convergent options that read as tactical variations of the same goal rather than distinct worldviews. Investigation traced the cause to a long-standing gap in the scenario generation prompt: it has never had multiplayer-specific instructions on the boardroom path. The May 8 team-themed scenarios commit (952ff5c) was the first code anywhere in the system that recognized multiplayer needs different prompt guidance — but it scoped that recognition to a theme.id === 'team' && teamContext branch only. Generic multiplayer (the default boardroom path, with no team context) has always fallen through to the base prompt, which is written for a single decision-maker reading a brief. Likely surfaced now because (a) the team-context infrastructure made multiplayer easier to spin up so play volume is higher, and (b) solo scenario quality has steadily ratcheted up (case-study voice — ADR-034, lock-in test in Principle #8, name diversity, AI-era realism), so multiplayer's flat baseline now contrasts more visibly against the raised solo floor.

Decision¶

Multiplayer constraints attach to the session shape (2+ participants), not to the theme. Add an isMultiplayer flag to ScenarioGenerationContext and a multiplayer constraint block in buildScenarioGenerationPrompt that fires whenever the flag is true, regardless of theme. The team-theme branch keeps its richer team-substrate framing but no longer uniquely owns the multi-player perspective constraint.

The new constraint block carries two requirements: 1. Collective decision framing — the dilemma is one the group faces together, not one a designated leader faces with bystanders watching. 2. Good-faith worldview split on options — the four options must each be defensible by a different reasonable team member; "tactical variations of the same goal" is explicitly called out as a failure mode.

/api/sessions/start/route.ts sets isMultiplayer = participantIds.length > 1 when building the generation context.

Rationale¶

The team-theme branch (added 2026-05-08, commit 952ff5c) correctly identified that multiplayer changes what makes a scenario good — but scoped its fix to the case where a team had also paid the cost of writing team_context. The boardroom multiplayer path (the most common path, and the on-ramp for new groups) was never given the same treatment. Not because the team commit broke it, but because the underlying recognition — "multiplayer is structurally different and needs prompt instructions to match" — only got applied where team substrate existed. We're generalizing that recognition to all multi-seat sessions.

Why this matters specifically: the base prompt's Principle #6 ("four distinct worldviews, not tactics") is satisfiable by a single thoughtful player picking among four options that could feel tactical to a group. When 2+ players actually play the same scenario, convergent-but-tactically-different options collapse into noise — most players pick the same one for the same surface reason, and the round produces no signal about who reasons differently. The "Technical Debt" example: full sprint / 20% / feature-driven / parallel hires are recognizably the same conversation, and the modal modern-eng-leader answer (B or C) wins regardless of underlying values.

Attaching the constraint to session shape rather than theme also keeps the prompt honest about what's actually being requested — the model sees "this will be played by N people" and can shape options accordingly.

Alternatives Considered¶

Patch only the boardroom path. Add a mirror of the team-theme constraint specifically when theme === 'boardroom' && multiplayer. Rejected because the same gap exists for any non-team multiplayer theme (underground, custom worlds, etc.) — the signal-quality issue is about the session being multiplayer, not about which world it's set in.
Strengthen base Principle #6 instead of adding a multiplayer branch. Tempting because it would catch convergent options on solo too. Rejected because solo and multiplayer have different failure modes — solo can tolerate options that are "different routes to the same value" because the player narrates why they picked one route; multiplayer needs the options themselves to discriminate without rationale-reading. The constraint earns its place as multiplayer-specific.
Detect convergent options post-hoc with a validator. Considered as a complement, not a replacement. A validator would have to model what "different worldviews" means semantically, which is more expensive and lossy than instructing the generator up front. Worth revisiting if the prompt fix doesn't move the needle.
Do nothing; rely on the team-context path to grow. Rejected — quick-round multiplayer (no team context) is the on-ramp for new groups; if it produces low-signal scenarios, those teams never reach the team-context tier.

Discussion¶

The initial diagnosis framed this as a regression introduced by the May 8 team-theme commit, but git history disproved that — git log -S "multiplayer" on the generator file shows May 8 was the first time multiplayer-specific text ever appeared in the prompt. The boardroom multiplayer path has always been using the single-player prompt; the failure mode (convergent options that don't discriminate worldviews across players) was always possible, just lower-rate or less visible. The team-theme commit is what made the gap legible, not what created it. Worth recording because the regression framing was tempting and would have led us to look for "what changed" instead of "what was always missing."

There's a related concern from the scenario corpus imbalance memory: 39.5% of the curated corpus is ethical_dilemma-tagged. The multiplayer convergence problem is partly a corpus-shape issue too — convergent options are easier to generate in domains where most thoughtful actors agree on the modal answer. But the fix here addresses the generation-side lever; corpus-side levers (driver/trigger gap weighting per ADR-049) are separate work.

Cici's lens from May 9 (sync_score as agent permission threshold) is also relevant: if multiplayer is increasingly the surface where teams calibrate trust against each other, the signal from those rounds has to discriminate worldviews — otherwise the trust calibration is noise. This change is small but it's load-bearing for the multiplayer-as-trust-substrate direction.

Open question deferred: whether the multiplayer constraint should also tighten the role framing. Currently the base prompt says "Clarify the user's role" (singular). For genuinely shared decisions this is wrong. Left alone for now to keep the diff minimal; revisit if the worldview-split requirement alone doesn't fix the convergence pattern.

Consequences¶

All multiplayer scenarios — boardroom, underground, custom worlds — now generate against a prompt that knows it's a multi-player session and asks for options that discriminate worldviews across players.
Team-theme scenarios still get the additional team-substrate framing (team_context as scene-setting, no team-member naming, etc.) — that branch loses only the "Multi-player perspective" bullet, which is now redundant with the new global constraint.
Generated multiplayer scenario quality should approach curated quality on the option distinctness axis. If it doesn't, the next lever is post-hoc convergence validation.
The isMultiplayer flag is a one-line addition to ScenarioGenerationContext and is computed from participantIds.length > 1 in src/app/api/sessions/start/route.ts. No migration needed.
Watch for: regressions on solo scenarios (none expected — the new branch is gated on the flag), and whether multiplayer scenarios start showing better worldview spread in actual play. A future check should compare the rate of "all 4 players picked the same option" between pre-fix and post-fix multiplayer rounds.

Key files: - src/lib/ai/scenario-generator.ts — adds isMultiplayer to ScenarioGenerationContext and a new multiplayer constraint block in buildScenarioGenerationPrompt - src/app/api/sessions/start/route.ts — sets isMultiplayer from participantIds.length > 1 when building the generation context - docs/decisions/033-team-judgment-layer.md — the team-substrate work this builds on - docs/decisions/043-scenario-tagging-driver-trigger.md — corpus tagging that quantifies the convergence pattern