Prototype two-player four-faction setup

docs/CURRENT_STATUS.md

@@ -16,6 +16,18 @@ open mode gates.
 
 
 ## Current checkpoint and work
+**Two people, four factions — 27 October. Prototyped / Partial.** Each person
+can add a separately authenticated second faction and switch its private view
+and actions. Exactly two controllers with two seats each are required to start;
+ordinary victory uses the four-stronghold target. Independent factions and no
+automatic alliance are provisional. Focused setup, victory, UI and isolated
+HTTP cases pass; complete games, player-count interactions, comprehensive
+custody review and deployed acceptance remain open. Human seats are required;
+handover into a browser holding another active room seat remains unsupported.
+[A dedicated isolated browser room](TWO_PLAYER_TWO_FACTIONS.md) also exercised
+adding, switching and independently readying the host's two factions.
+[Scope](TWO_PLAYER_TWO_FACTIONS.md).
+
 **Next: remaining rule functions and native timing.**
 Keep identified Basic-function gaps ahead of Advanced and wider interactions.
 Prototype labels and final acceptance gates remain.
@@ -25,9 +37,8 @@ clean boundary the claiming player may provisionally pause its own started
 Charity opportunity and resume last, keeping the original claim and payment.
 The related nine-file union, including the repaired v3 Revival controls,
 passes 51 cases and the production build passes; broader combinations and
-deployed acceptance remain open. The optional
-two-human/four-faction setup is separately documented as missing in
-[its implementation contract](TWO_PLAYER_TWO_FACTIONS.md).
+deployed acceptance remain open. The separate optional two-human/four-faction
+setup has since been prototyped above.
 
 **Agreed extra turns and Basic simultaneous victory — 27 October. Prototyped /
 Partial.** The public continuation now covers Basic qualifiers and tied

docs/IMPLEMENTATION_STATUS.md

@@ -1,5 +1,18 @@
 # Dune implementation status
 
+## 27 October 2026 — Two people, four factions
+
+The provisional setup maps two controllers to four independent faction seats,
+with separate credentials, private views and actions, and a shared four-hold
+victory target. Fifty-nine focused offline cases and two isolated HTTP cases
+passed, including setup and initial storm decisions, selected-seat actions and
+scoped-seat recovery. The independent-faction interpretation, player-count
+interactions and broader acceptance remain provisional. Human seats are
+required; handover to a browser already holding a different active room seat is
+not supported. An isolated browser room additionally exercised adding, switching
+and independently readying the host's two factions; it did not cover a second
+human or a complete game. [Scope](TWO_PLAYER_TWO_FACTIONS.md).
+
 ## 27 October 2026 — Advanced Sapho Charity suspension
 
 A player may provisionally pause its own started Charity turn at a clean

docs/RULE_DECISIONS.md

@@ -1,5 +1,14 @@
 # Rule decision index
 
+## Two people, two factions each — 27 October 2026
+
+The classic rulebook and the supplied Advanced revision permit two people to
+play two factions each and use a four-stronghold victory target. The prototype
+provisionally keeps those factions independent: their inventories, holdings and
+alliances do not automatically merge. The sources do not explicitly settle
+that composition or all player-count interactions. It is an implementation
+interpretation, not an official ruling; see [scope and limits](TWO_PLAYER_TWO_FACTIONS.md).
+
 ## Juice of Sapho and an already-started Advanced Charity turn — 27 October 2026
 
 Extend the provisional own-turn Last composition to a clean ordered Charity

docs/TWO_PLAYER_TWO_FACTIONS.md

@@ -2,7 +2,7 @@
 
 ## Status and authority
 
-**Missing; design contract only.** The [GF9 classic rulebook, printed p. 6](https://www.gf9games.com/dunegame/wp-content/uploads/Dune-Rulebook.pdf#page=6)
+**Prototyped; wider rules and acceptance remain open.** The [GF9 classic rulebook, printed p. 6](https://www.gf9games.com/dunegame/wp-content/uploads/Dune-Rulebook.pdf#page=6)
 offers a two-player setup in which each person plays two factions, with the
 two-player four-stronghold victory requirement. The user-authorized revised
 Advanced source, physical p. 4 (printed p. 2), offers the same choice and
@@ -36,8 +36,8 @@ original interpretation and do not receive invented controller assignments.
 Expose this as an explicit two-player setup option. Let each person create or
 join their first seat and securely add/select their second faction before
 readiness, with clear names and a persistent active-faction indicator. Avoid
-claiming support for the mode until setup, both private faction views, legal
-actions, turn continuation and victory all work together. The existing model
+claiming complete support for the mode until complete games and wider
+interactions are verified. The existing model
 still permits ordinary two-seat play and separate one-faction controllers.
 
 ## Separate controllers from faction seats
@@ -66,13 +66,14 @@ Today `db/schema.ts` makes `seats.token_hash` the primary key;
 `db/rooms.ts` authenticates a token to one `player_id` and `act` rechecks that
 exact unrevoked room/player/token tuple before the versioned action. The normal
 `joinRoom` path returns `alreadySeated` for an authenticated caller. Room API
-routes currently use a single room-scoped HttpOnly cookie. Reusing one token
+routes retain the original room-scoped HttpOnly cookie and use separately
+scoped HttpOnly cookies for added faction seats. Reusing one token
 for two database rows, trusting a caller-supplied seat ID as authorization, or
 projecting both seats' private information into one general view would break
 those existing boundaries.
 
-One workable implementation is an explicit authenticated add-second-seat
-operation that atomically validates the lobby/controller assignment and creates
+The authenticated add-second-seat operation atomically validates the
+lobby/controller assignment and creates
 the second distinct seat credential. Provision separately random, room-scoped
 HttpOnly credentials for both faction seats. A public active-seat selector may
 choose which credential to present, but every API read, action, message,
@@ -94,6 +95,14 @@ the UI explicit about which faction owns each pending decision. Existing
 autopilot can operate a faction seat only under its existing authorization;
 until full AI refinement, each offered decision needs a minimal legal bot path.
 
+The current prototype requires human seats, permits ordinary existing
+seat-autopilot, and does not yet support accepting a handover into a browser
+already holding a different active seat for the same room. The mode cannot be
+disabled once a secondary faction is added. Recovery replaces an existing
+scoped credential for the recovered seat without overwriting another valid
+legacy seat. Comprehensive recovery, revocation and custody acceptance remain
+open.
+
 ## Integration and evidence
 
 - Implement one shared controller/seat contract through lobby creation,