ADR-053: Sharpen Principle #6 globally with the worldview-split test¶

Status: Accepted Date: 2026-05-11 Context: A live-played generated multiplayer scenario ("Technical Debt vs Feature Requests") surfaced as low-signal — its four options (full debt sprint / 20% ongoing / feature-driven refactoring / parallel hires) were tactical variations of the same goal, so the modal modern-eng-leader pick wins regardless of underlying values. The first attempted fix (ADR-052) framed this as a multiplayer-specific failure mode and added a constraint block keyed off participantIds.length > 1. That framing rested on an unverified claim about the multiplayer play loop — that picks are revealed to other players before rationales, creating a "flat reveal" social moment. Inspection of src/app/play/[sessionId]/page.tsx:1097 showed picks and rationales are submitted together and revealed simultaneously. With that established, multiplayer is mechanically just solo with more people — each player produces (option, rationale) as a unit, then everyone sees everyone's unit. The scenario's job is identical in both cases, and the convergence failure mode is a Principle #6 weakness that affects solo and multiplayer alike. Multiplayer just made it more visible because the discussion phase highlights flat option sets in a way solo's introspection doesn't.

At a glance

What it decides: Principle #6 ("four distinct worldviews, not tactics") is sharpened globally in the base generation prompt with a worldview-split test and a named anti-pattern. The multiplayer-specific machinery from ADR-052 is reverted.

Worldview-split test — each option must be defensible by a different reasonable person in good faith ("we genuinely disagree about what to prioritize"), not four tactical ways to reach the same goal.
Named anti-pattern in the prompt — the convergent "Technical Debt vs Feature Requests" scenario is included as a concrete failure example, because worked examples bite harder than abstract instructions.
Applies globally — solo, multiplayer, all themes; the convergence failure hurts solo too, just less visibly (no discussion phase to surface it).
Rejected: ADR-052's multiplayer-only block (rested on an unverified play-loop claim — picks and rationales actually reveal together) and a post-hoc convergence validator (brittle on short option labels; kept as a possible later complement).
Watch: if convergent-option scenarios still appear at non-trivial rates, the next lever is semantic-similarity post-hoc validation.

flowchart TD
    A["Generated scenario:<br/>4 options"] --> B{"Could a different reasonable<br/>person defend each option<br/>in good faith?"}
    B -->|Yes| C["Worldviews — choice carries signal<br/>(passes Principle #6)"]
    B -->|"No — same goal,<br/>four tactics"| D["Convergent — choice carries no signal<br/>(fails; e.g. Technical Debt scenario)"]

The worldview-split test as a per-scenario decision check.

Decision¶

Sharpen Principle #6 ("Four distinct worldviews, not tactics") in the base scenario generation prompt with two additions: a worldview-split test ("each option must be defensible by a different reasonable person in good faith — not 'we all want X, here are four ways' but 'we genuinely disagree about what to prioritize'") and a named anti-pattern using the technical-debt scenario as a concrete failure example. Apply globally — solo, multiplayer, all themes. Revert ADR-052's machinery: remove isMultiplayer from ScenarioGenerationContext, remove the multiplayer constraint block, restore the participantIds.length > 1 line in /api/sessions/start/route.ts to its prior shape. Restore the team-theme branch's "Collective team decision" bullet (which was dropped as a side-effect of ADR-052) — that one is genuinely team-substrate-specific and not redundant with the global Principle #6 sharpening.

Rationale¶

The base prompt already had Principle #6 — "options should reveal values, not just be different ways to achieve the same goal." The technical-debt scenario violated it. Either the model wasn't following the principle, or the principle wasn't worded sharply enough to bite. The fix is to make the principle sharper, not to add a parallel principle that fires under specific conditions.

Two reasons to keep this in Principle #6 rather than as a separate constraint:

It's not multiplayer-specific. A solo player picking among tactically-flat options also gets less signal — the rationale rescues some signal but the choice itself carries none. The "convergence failure" is real for solo too, just less visible because solo doesn't have a discussion phase that surfaces it socially.
Carving multiplayer-specific prompt paths invites accumulating distinctions that don't really exist. Each carve-out is a place where solo and multiplayer can drift apart in ways nobody intended. The mental model "scenario = scenario, regardless of how many people play it" is simpler and matches the actual mechanics.

The technical-debt example earns its place in the prompt itself (not just in this ADR) because concrete anti-patterns are more reliable than abstract instructions — the model is much more likely to recognize "options are tactical variations of the same goal" when it has a worked example to pattern-match against.

Alternatives Considered¶

Keep ADR-052's multiplayer-only block. Rejected — the load-bearing claim about the multiplayer play loop turned out to be wrong, and the underlying failure mode applies to solo too. Keeping the multiplayer-only block would solve the symptom in one place while leaving the same weakness available in solo.
Add a post-hoc convergence validator. A validateScenario check that flags option sets where all four options are framed around the same goal. Rejected for now as a complement, not a replacement — semantic similarity detection across short option labels is fuzzy and would either over-reject (flagging legitimate distinct-worldview options that share vocabulary) or under-reject (missing convergence framed in different words). The prompt-side fix is cheaper and more direct. Worth revisiting if the prompt sharpening doesn't move the needle.
Sharpen Principle #6 silently without an ADR. Tempting because the change itself is small. Rejected because the diagnostic story (initial misdiagnosis as multiplayer-specific, corrected by checking the actual play loop) is exactly the kind of "I almost shipped a worse fix" learning that should be preserved. Future-me looking at the prompt will want to know why the worldview-split language is there and what it replaced.

Discussion¶

This is the second framing on the same problem. The first (ADR-052) was wrong because it rested on a speculative claim about the play loop ("picks are revealed before rationales") that I never verified. Once that claim was corrected — by reading the actual code — the entire case for multiplayer-as-structurally-different collapsed.

Two lessons worth keeping:

Verify load-bearing claims about UX flow before designing prompt changes around them. The multiplayer-specific framing felt sophisticated and was easy to defend at the abstract level, but it depended on a mechanical claim about the product that took thirty seconds to disprove. The pattern: when an argument hinges on "the user sees X before Y," check that X actually comes before Y.
Prefer simpler explanations. The user (Jonathan) intuited "multiplayer is just solo with more people" before I did, and was right. The carved-out distinction added a flag, a code path, an ADR, and an inconsistent quality bar between solo and multiplayer scenarios — all to address what turned out to be a single weakness in a single principle. The simpler fix is usually the right one when the carve-out is doing more work than the underlying difference justifies.

ADR-052 is left in place rather than deleted because the diagnostic trail is part of what makes the decision record valuable — future readers (and future-me) should be able to see that the multiplayer-specific path was tried and rejected, and why. Marking it Superseded with a pointer here is enough.

Open question kept open: whether the technical-debt example should also be added as a regex-matched validation failure (auto-reject any generated scenario whose options match the {full sprint / X% ongoing / Y-driven / parallel} structural pattern). Not done now — the prompt instruction may be sufficient, and pattern-matching on option labels is brittle. Revisit if the same shape recurs in generations after this ships.

Consequences¶

Solo and multiplayer scenarios run through the same prompt with the same quality bar — no inconsistent treatment, no isMultiplayer flag to thread through code paths, no separate validation rules.
Solo scenarios benefit from the sharpened Principle #6 too. Expected effect: small but positive. Solo's rationale step rescues some signal from convergent options, but stronger options + rationale produces stronger signal than weaker options + rationale.
The team-theme branch keeps its team-substrate framing intact (collective decision, no team-member naming, etc.) — those constraints are genuinely team-specific and not subsumed by Principle #6.
ADR-052 is marked Superseded but kept in place to preserve the diagnostic trail.
Watch for: whether convergent-option scenarios still appear at non-trivial rates after this lands. If they do, the next lever is post-hoc validation (semantic-similarity check on option framings). The technical-debt scenario shape would be the first test case to retry on the live generator.

Key files: - src/lib/ai/scenario-generator.ts — Principle #6 in SCENARIO_GENERATION_PROMPT extended with worldview-split test and technical-debt anti-pattern; ADR-052 machinery (isMultiplayer field, multiplayer constraint block) reverted; team-theme branch's "Collective team decision" bullet restored - src/app/api/sessions/start/route.ts — isMultiplayer line removed from generation context - docs/decisions/052-multiplayer-scenario-generation-constraints.md — marked Superseded