Support Advanced Sapho Charity suspension

docs/ADVANCED_CHARITY_ORDER.md

@@ -53,16 +53,16 @@ once. The original physical First Player order stays unchanged. No extra claim,
 repeated completed turn, refund or reset is granted. Basic and already-opened
 unstamped concurrent Charity phases have no fabricated ordered scope.
 
-Only an actual accepted `scope: charity` use creates version2 `charityOrder`
+Only an actual accepted `scope: charity` use creates reordered `charityOrder`
 with original order, actual remaining/completed opportunities, current-start
 state and public use history. Untouched version1 frames retain their stored
 shape; native `charityTurn` receipts establish whether the current turn started.
 Once a native claim has been accepted, including a later canceled wealthy BG
-claim, that current player finishes unchanged. Under the standing recommended
-interpretation authority, a different unstarted holder may reorder the later
-tail; first then means first after the started actor. The holder cannot split
-its own started turn. This queued timing is **provisional software composition**,
-not a newly found publisher answer.
+claim, a different unstarted holder may reorder the later tail; first then
+means first after the started actor. The current player finishes unchanged
+unless that same holder voluntarily pauses its own opportunity under the
+separate policy below. This queued timing is **provisional software
+composition**, not a newly found publisher answer.
 
 The persistent panel names the protected actor, explains the later queue and
 keeps one claim per player. Its normal card/scope/event/mode packet carries no
@@ -74,6 +74,31 @@ discard reaction and resumes once, retaining the claim receipts and turn.
 
 Broader optional-module interactions, full-mode and final acceptance remain.
 
+## Own started Sapho suspension — 27 October 2026
+
+At a clean ordered Advanced Charity boundary, the player who has already
+claimed may provisionally discard its own Sapho to pause that same started
+opportunity and resume it last. The accepted native claim, its actual payment,
+the physical First Player order and all completed turns remain unchanged. No
+second Charity claim, payment or extra opportunity is created. Pending
+responses and preparations must finish before this action; another holder
+continues to queue behind the started player rather than displacing them.
+
+The first own-started suspension creates a version3 order frame with the
+paused player and the original public use history. The native claim receipt
+remains authoritative while the player waits and the started marker returns
+on resumption. Untouched version1 and version2 frames retain their stored
+format and history. Existing Basic and unstamped concurrent phases do not gain
+a manufactured order. Controls use the original card, scope, event and mode
+packet; minimal policies receive the same legal option.
+
+The Sapho face permits first/last in a player-ordered phase but does not give
+a partial-turn procedure. The suspension and queue are explicitly provisional
+online timing, not a publisher clarification. They supersede the earlier
+own-started restriction below. Wider interactions, complete-mode and deployed
+acceptance remain open.
+[Sapho scope](JUICE_OF_SAPHO_RUNTIME.md#own-started-advanced-charity-turn--27-october-2026).
+
 
 ## Initial ordered-phase evidence
 
@@ -105,12 +130,12 @@ final rules/recovery/privacy and deployed acceptance remain due.
 
 ## Sapho focused evidence
 
-Sapho now takes its holder first/last among remaining Advanced Charity turns.
+This earlier evidence covered Sapho first/last among remaining Advanced Charity turns.
 Actual use creates version2 order history; untouched version1 frames retain
 original bytes. An accepted current native claim provisionally protects that
 actor before another holder reorders the later tail. Completed turns, one claim
-per player and physical First Player order remain. Own started turns cannot
-split. Basic/old unstamped concurrent phases have no manufactured scope. The
+per player and physical First Player order remain. It predates the separate
+own-started suspension above. Basic/old unstamped concurrent phases have no manufactured scope. The
 persistent controls name the protected actor, and native claims/Finish follow
 the changed queue. This is provisional retained-current timing, not a new
 publisher ruling. [Source and contract](ADVANCED_CHARITY_ORDER.md#juice-of-sapho--27-october-2026).

docs/CURRENT_STATUS.md

@@ -20,6 +20,15 @@ open mode gates.
 Keep identified Basic-function gaps ahead of Advanced and wider interactions.
 Prototype labels and final acceptance gates remain.
 
+**Advanced Sapho Charity suspension — 27 October. Prototyped / Partial.** At a
+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).
+
 **Agreed extra turns and Basic simultaneous victory — 27 October. Prototyped /
 Partial.** The public continuation now covers Basic qualifiers and tied
 Advanced solos, with a saved final-turn marker for agreements at turn ten and
@@ -42,8 +51,8 @@ Partial.** Sapho can provisionally pause a clean started Revival turn and resume
 it last with spent allowances and legacy order records preserved. Simultaneous
 unallied Advanced qualifiers are ranked by stronghold count before prediction;
 ties, Tech counting and other simultaneous victory sources retain the documented
-provisional composition. The 12-file affected union passes 144 cases. The
-unanimous option to play another turn and broader acceptance remain open.
+provisional composition. The earlier 12-file affected union passed 144 cases;
+the follow-ups above connect the unanimous option, while broader acceptance remains open.
 [Revival](ADVANCED_REVIVAL_ORDER.md) · [Victory](ADVANCED_PREVIEW.md).
 
 **Advanced Sapho own-turn suspension — 27 October. Prototyped / Partial.** The

docs/IMPLEMENTATION_STATUS.md

@@ -1,5 +1,15 @@
 # Dune implementation status
 
+## 27 October 2026 — Advanced Sapho Charity suspension
+
+A player may provisionally pause its own started Charity turn at a clean
+boundary and resume last while retaining its completed claim and payment. The
+queue retains older records, and Semuta claim/pass restores the same paused
+turn. Related v3 Charity and Revival controls now let the actual actor continue;
+nine files pass 51 cases and the production build passes. Wider combinations and
+deployed acceptance remain open. The separate optional
+[two-person, four-faction setup](TWO_PLAYER_TWO_FACTIONS.md) remains missing.
+
 ## 27 October 2026 — Basic agreements and extended victory calendar
 
 The publisher FAQ agreement now applies to multiple qualifying Basic sides,

docs/JUICE_OF_SAPHO_RUNTIME.md

@@ -1,5 +1,28 @@
 # Juice of Sapho: finite ordering implementation
 
+## Own started Advanced Charity turn — 27 October 2026
+
+**Prototyped / Partial.** At a clean boundary in ordered Advanced Charity, the
+current holder may use Juice of Sapho to pause its own started opportunity and
+resume it last among the remaining turns. Its accepted claim and actual payment
+remain in place; the same opportunity resumes without a second claim or refund.
+Pending responses and other preparations must finish before the order changes.
+Another holder cannot displace a different player's started turn and may
+reorder only the later unstarted tail.
+
+The first actual own-started suspension upgrades the order frame to version 3,
+recording the paused player alongside the original public Sapho use history.
+The started marker returns when that player becomes current again. Existing
+version 1 and 2 frames retain their prior format until a qualifying suspension;
+Basic and already-opened unstamped concurrent Charity phases stay unchanged.
+
+The Sapho face permits first or last in an ordered phase or action but does not
+specify suspension of a partially completed Charity opportunity. This is a
+provisional online composition, not a publisher clarification. It supersedes
+the earlier own-started Charity exclusion; wider interactions, full rules and
+browser/deployed acceptance remain open.
+[Native Charity order](ADVANCED_CHARITY_ORDER.md#own-started-sapho-suspension--27-october-2026).
+
 ## Own started Advanced Revival turn — 27 October 2026
 
 **Prototyped / Partial.** At a clean boundary in ordered Advanced Revival, the

docs/RULE_DECISIONS.md

@@ -1,5 +1,15 @@
 # Rule decision index
 
+## 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
+boundary. The holder's accepted claim and any payment remain unchanged while
+the same opportunity pauses and resumes last. Other holders still cannot
+displace an already-started actor; pending responses must finish first. The
+printed card does not explain splitting a turn, so this is an online timing
+interpretation, not a publisher clarification. Older order records retain
+their original version. [Scope](ADVANCED_CHARITY_ORDER.md).
+
 ## Advanced simultaneous solo stronghold victories — 27 October 2026
 
 The authorized supplied revision, physical p. 14 (printed p. 12), awards a

docs/TWO_PLAYER_TWO_FACTIONS.md

@@ -0,0 +1,116 @@
+# Two players controlling two factions each
+
+## 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)
+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
+threshold. The supplied PDF stays local; its identity and precedence are in
+[the decision index](RULE_DECISIONS.md#authorized-source-amendment--1-october-2026).
+The similarly titled movie game's double-faction rules are a different game
+and are not authority for this mode.
+
+Neither cited classic passage says whether the two factions controlled by one
+person are automatically allied, how their holdings combine for victory, or
+how controller identity affects every faction-counted ability. Do not silently
+adopt the movie game's automatic alliances or blended inventories. A practical
+first version can retain independent faction records, actual alliance choices,
+and a four-stronghold target per eligible victory side as an explicitly
+provisional policy. Resolve combined holdings and any conflicting interaction
+from authoritative sources or document the chosen interpretation; this design
+does not certify those answers.
+
+## Model and setup
+
+Keep four distinct `Player` faction records and their normal physical forces,
+leaders, decks, private hands, turns and faction identities. Add an explicit,
+lobby-validated association of those four distinct faction seats with exactly
+two controllers, two seats per controller. A controller is not itself a
+faction or a new recipient of faction income. Validate the complete mapping
+before starting and reject ambiguous, duplicate, missing or stale assignments;
+changing an assignment or faction clears readiness. Existing two-seat games,
+already-started games, and saved positions without the new mode retain their
+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
+still permits ordinary two-seat play and separate one-faction controllers.
+
+## Separate controllers from faction seats
+
+The `players` array currently represents faction seats, not physical humans.
+For this option `game/victory-progress.ts` must use the validated controller
+count for the printed two-player threshold; `players.length === 2` alone is
+incorrect for four faction seats. Apply any agreed threshold increase through
+the same shared victory projection and quote, and retain explicit ordinary,
+alliance, Ecaz and special victory ordering. Never infer controller count by
+names, cookies, browser tabs, AI labels or faction alliances.
+
+Audit each other count before changing it. Faction turn order, physical pieces,
+dealt cards, faction-specific payments and action ownership can still depend on
+the four faction seats. Optional-module eligibility and phase rules referring
+to players must be checked against their specific source; for example, existing
+Tech Token gates use `players.length >= 3` in `game/engine.ts` and
+`game/faction-module-profile.ts`. A global substitution of controller count
+would silently change unrelated rules. Record uncertain interpretations and
+keep unsupported combinations visibly provisional rather than fabricating a
+new setup or automatic alliance.
+
+## Authentication and switching
+
+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
+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 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,
+control or recovery request must authenticate that selected credential and
+verify its actual `player_id`; the selector itself grants no access. Apply the
+same room-control, revocation, origin, retry, version and removal checks as
+today. Preserve existing seat cookies and single-seat clients; use additive
+schema or durable mapping changes if required, never reset the room database.
+No secret token belongs in source, client-visible game state or logs.
+
+On a faction switch, `app/page.tsx` should advance its existing request epoch,
+discard stale cross-seat results and fetch the selected authorized view. Fence
+in-flight actions and responses by room, selected seat and version so a delayed
+response from the other faction cannot overwrite or act through the current
+view. Explicitly handle refresh and recovery of both distinct credentials,
+individual revocation, host assignment and relinquishment; a recovered or
+revoked seat must not accidentally grant the other seat or an opponent. Keep
+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.
+
+## Integration and evidence
+
+- Implement one shared controller/seat contract through lobby creation,
+  assignment, setup, the projected active seat, action dispatch and the
+  shared stronghold progress and victory quote. Retain source-specific faction
+  counts and provisional boundaries rather than just adding a selector or
+  changing the victory number.
+- Include focused engine tests for valid/invalid mappings, original and changed
+  thresholds, faction-specific private state, controlled faction decisions,
+  ties and the intended victory-side interpretation. Exercise a real setup and
+  a meaningful sequence using both factions of each controller; include legal
+  minimal bot participation and usable action controls.
+- Test authenticated add/switch/read/action with distinct credentials, denied
+  target seats, stale or concurrent switches and independent private views. Do
+  not expose or reset unrelated rooms; use isolated dedicated test records.
+- Broader recovery, revocation, privacy and custody assurance, valid module
+  combinations, complete human/AI games, browser/mobile acceptance and deployed
+  verification remain required after the rules-first prototype. A passing
+  focused test or this document does not certify a complete mode or change the
+  publication gates.