Dune/docs/RICHESE_NO_FIELD_RULES.md

Richese No-Field rules and integration

Audit date: 2026-09-06. This document distinguishes the printed token lifecycle from engine integration and unresolved combinations. It does not certify Richese, Homeworlds, or any other gated game mode.

Advanced first versions — 8 October 2026

Advanced ordinary mixed battles and discounted allied shipments now reuse the explicitly provisional policies below. Supplied physical p36 B gives reserve-limited materialization and p36 D permits allied off-planet forces; p37 C gives the rounded Guild fee. These passages do not specifically adjudicate the mixed dial cap or price/payee precedence. Combined Ecaz Occupy and whole-plan inspection remain guarded; mode gates are unchanged.

Battle.mixedNoFieldPlayers and the owner-only battle.mixedNoField notice apply in both modes. Native Advanced support is committed separately and paid at battle resolution; token revelation does not grant free support. Minimal AI may form mixed groups using its existing private force quote. Two direct battle smokes cover unsupported and two-spice-supported plans: physical2 + token3 gives private5, the first seal keeps the marker hidden, the second materializes3 once, and ordinary losses/aftermath finish. Two allied smokes cover Guild and actual native Karama rates with Easy consent, physical5, bank1 and only the recipient's shipment consumed. Actual GameTable SSR controls were observed in Chromium, including the Advanced mixed-pool warning and discounted consent. This is isolated surface evidence, not deployed or full-game acceptance.

Basic discounted allied price prototype — 8 October 2026

Guild recipients and already-active Karama rates now have a connected Basic first version: rounded one-force Guild price, one spice, entirely to bank even when Richese pays. Supplier and recipient controls label this as provisional; it does not settle the printed price/payee precedence. The shared quote supplies engine, controls and AI without charging for the materialized unit count or granting another shipment. Canonical payment contract. Two before/after direct engine cases cover a Guild recipient and an actual native Karama purchase, private offers, Easy consent, five actual arrivals and one bank payment. Advanced now shares this provisional policy above.

Basic mixed battle prototype — 8 October 2026

The Basic-first pass now admits an ordinary Richese battle containing both physical forces and a concealed No-Field. It reuses the existing private prospective pool: physical forces already in the territory plus min(token value, current reserves). This is a visibly provisional mixed-pool interpretation, not an adjudication of the FAQ's reserve-cap ambiguity below. Combined Ecaz Occupy remains guarded; Advanced ordinary mixed battles now use the same policy as described above.

Battle.mixedNoFieldPlayers retains initial mixed participation. Only the participating owner's view receives battle.mixedNoField and its private prospective bounds. The actual Battle Wheel explains the formula and its provisional status; marker-only wording no longer claims that the mixed pool consists entirely of reserve materialization. Basic and Advanced AI may form mixed groups and use the authoritative own force quote, without consulting an opponent's hidden denomination.

The existing sealed-plan path materializes the token once after both plans are submitted, preserving ordinary physical units. Native losses and aftermath then operate on actual counters. Ordinary Atreides dial secrecy, the whole-plan inspection guard, token history and public-mode gates are unchanged. Reserve changes during sealed plans and wider mixed-sector, typed-unit, skill and allied interactions remain for refinement.

Brief smoke: reproduced the old Basic admission rejection; the same two-force/three-token fixture now quotes five fighters privately, provides legal Easy plans, keeps the first plan concealed, materializes three once, and completes native losses/aftermath with twenty total physical counters. Chromium observed actual GameTable SSR Battle Wheel/plan controls and the five-fighter provisional warning. Types pass. No broad suite or deployed acceptance was run.

Authority

• GF9 CHOAM & Richese rulebook, printed pp.5–6,10–12. The full publisher-authored PDF was read from /tmp/dune-rules/choam-lelekan-mirror.pdf and its extracted text; fresh publisher-indexed excerpts corroborate the No-Field paragraph and FAQ. The official direct URL is inaccessible from this environment, while the older local files named choam-primary.pdf and choam-publisher-audit.pdf are HTML errors.
• GF9 Ecaz & Moritani rulebook, pp.10,14: Homeworld framework and explicit Terror placement/reveal distinction. Local /tmp/dune-rules/ecaz-audit.txt and publisher-indexed p.14 were checked.
• GF9 base rulebook: ordinary shipment, movement, sectors, storm shelter, battle and victory remain applicable unless superseded.

No new publisher FAQ was found for the unresolved combinations below. No tournament or community rules are used as authority.

Verified lifecycle

Richese has three tokens numbered 0,3,5. A shipment may use a concealed token at the one-force price. Until reveal it counts as one force, including zero, and moves like a force. At most one may be on the planet. Successive own/allied uses cannot repeat the same token. Revealed tokens stay faceup until another is placed. Voluntary reveal is permitted before Battle; battle reveal occurs with the Battle Plan. Revelation materializes the indicated reserves, capped by reserves available. Storm/worm exposure reveals and loses the indicated forces. Allied shipment immediately reveals; an existing token must first be revealed. Atreides cannot inspect the token battle's dial, and zero still plays a leader/cards. Gamont forces reveal and returns one force if present. The marker collects as one force. Heighliner activates except when shipping Guild as ally. Allied cost is one in a stronghold, two elsewhere; either ally may pay Guild/bank. Smuggler can add one in an empty territory. Karama prevents the No-Field shipment. Richese also blocks Fremen's Tuek victory condition. R2 pp.5–6,10–12

Terror can trigger when a No-Field enters, including zero. Materializing an already-present token does not trigger Terror again. R3 p.14

Pure model contract

The isolated module owns three physical token identities, their private values, the single deployed marker, and the most recently shipped token identity. It does not own player force arrays, reserves, Tanks, payment, turn order, card effects, reaction windows, movement allowance, or engine authorization.

History must be separate from board custody. Revealing or destroying a marker returns the same physical component to the faceup used position; it does not reset which token was last shipped. An allied immediate reveal updates the same history. Placing another token releases the previous faceup token for a later use. Turn changes do not make the last token reusable by themselves.

The engine supplies stable distinct token IDs and legal map locations. Public projection exposes a single concealed board presence and, when no token is deployed, the last faceup value. It never exposes the deployed token ID, ordered supply identities or other remaining values: those can reveal the concealed denomination by correlation or elimination. The owner receives the full token model. Force reserves must not be decremented on concealed placement merely to display a token; materialization is the later physical transfer.

A reveal returns the token's value, controller, exact location and reserve-limited materialized quantity. The caller then applies the appropriate physical outcome. This is deliberately different from the public effective count of one. A zero token returns zero materialized forces and still returns its used component/history normally. An allied shipment is a deploy-plus-reveal transition; it cannot leave a second hidden marker or silently forget the first.

The module uses an exact territory/sector location so the engine can distinguish the marker's exposed sector from sheltered forces elsewhere in a multi-sector territory. Location validation here checks structure only; the board engine must supply map membership, occupancy, path and shelter legality.

Original integration responsibilities

This table records the original adapter contract. The implemented subset and current evidence are listed in the integration checkpoint below; unqualified responsibilities in the table are not completion claims.

Trigger or consumer	Engine responsibility and evidence status
Own shipment	Validate one-force price, reserves/shipment eligibility, selected token, hand/Truthtrance restrictions, location, occupancy and applicable Guild/BG responses. Set history only after the shipment power is allowed; a canceled declaration cannot consume the token or alter last use.
Allied shipment	Resolve Richese permission and payer, reveal an existing own marker first, then deploy and immediately reveal the selected different token using the recipient's reserves. No hidden allied marker remains. Typed elite/regular unit allocation belongs to the recipient's force rules, not token denomination arithmetic.
Voluntary reveal	Enforce the printed pre-Battle timing. Materialize at the marker's exact sector, clear concealed board custody and retain last-use history. This is not a fresh shipment/movement and must not consume another action.
Battle plan reveal	Keep marker presence for battle eligibility even at zero; do not erase a declared battle because materialization yields no forces. Use reserve-constrained planning before reveal and materialize once when the plan is revealed. Retain a battle flag for Atreides dial restrictions after the token leaves the map.
Storm movement	Ask the board/storm engine whether this exact marker sector is caught and sheltered. Reveal only when exposed; map token arithmetic must not independently expand a sector hit into whole-territory losses. The caller moves actual resulting casualties to Tanks once.
Movement into/through storm	The token moves as a force; ordinary path and storm restrictions still apply. No-Field supplies no immunity. Existing faction/card protections need their own applicable-rule check.
Worm	A worm's applicable territorial scope, protections and any extra-worm rules belong to the engine. An exposed marker reveals; do not leave a hidden marker after resolving its materialized losses.
Shield Wall destruction	Reuse the actual storm-exposure check for affected locations. The token text creates no independent shelter or special destruction radius. No marker in an unaffected sector may be removed just because the same territory has other losses.
Trip to Gamont	Reveal first, then return one materialized Richese force if one exists. A zero result still consumes the card/power under the FAQ. Existing unrelated physical forces and return allocation require the card's normal rules.
Lasgun/shield, traitors and other battle losses	Reveal at battle-plan timing before ordinary battle resolution, then feed materialized forces into existing custody/Tanks rules. Do not both lose the marker's denomination and lose those same materialized units again.
Spice collection	Treat the unrevealed marker as one collecting force, including zero; use the applicable two/three-spice rate and combine with actual forces without counting any hidden reserve quantity.
Stronghold occupation/victory	Public effective one-force presence participates in occupancy/stronghold checks by the FAQ's all-effects rule. Revealing zero can remove that presence. Preserve Richese's explicit addition to the Fremen special-victory exclusion.
Heighliner	Resolve the shipment's tech income once, respecting the explicit Guild-allied shipment exception. A later reveal is not a second shipment and cannot generate another tech payment.
Smuggler	The FAQ permits the extra force into an empty territory; model that as a real force accompanying the marker, not an extra unit added to its secret value or another token. The skill module and empty-territory check remain separate.
Terror	Entry can trigger even at zero. Reveal/materialization does not trigger it. Preserve the entered marker and exact pending entry while a response or Terror decision is open.
BG arrival/Intrusion, Ecaz Ambassador	Token presence is one for ordinary occupancy, but the applicable entry trigger and simultaneous-response ordering must still be reconciled with the engine's existing source decisions. The isolated model does not choose a priority.
Homeworlds, HMS, discoveries	Location and force-container rules differ from ordinary Arrakis sectors. Do not serialize them as an arbitrary planet territory and accidentally permit unsupported shipments or count a second off-planet marker. See unresolved boundaries below.

Unresolved or compositional boundaries

1. Reserve shortage when destroyed. Voluntary/battle text explicitly caps by reserves; the destruction sentence says to lose the indicated quantity without repeating the shortage clause. The pure model caps materialization to avoid creating physical units, but that is conservation-based composition for storm/worm losses, not an independently answered FAQ. It does not select substitute losses from unrelated board forces.
2. Mixed forces and battle dials. The FAQ forbids dialing more than reserves in a No-Field battle. A territory can also contain ordinary forces (the Smuggler answer demonstrates mixed presence), but no retrieved answer expressly defines that limit with existing forces, multiple sectors, typed units or independently committed reserve uses. Basic and Advanced prototypes use an explicitly provisional additive pool; this does not settle the source question. Combined Occupy remains guarded.
3. Full-plan special Karama and structured Truthtrance. The ordinary Atreides dial prohibition is explicit. Whether a broader entire-plan power or a particular promise question overrides it was not resolved by a retrieved specific answer. Do not leak the value through private legal-plan previews, public maximum dials, error strings or bot reasoning.
4. Homeworld use. R3 recommends Richese in a Homeworld combination but supplies no retrieved No-Field-specific rule defining off-planet hidden custody, one-on-planet versus off-planet coexistence, or homeworld threshold disclosure. General module availability is not an answer to those lifecycle questions. The isolated model represents a single Arrakis marker and does not authorize Homeworld placement.
5. Capturing, transferring or returning a concealed marker as a force. Movement-as-a-force and Gamont's explicit forced reveal do not establish a general conversion for every card or Guild transport-to-reserves. A generic return helper must not erase a hidden token without a source-backed reveal/custody cause. This module exposes no such automatic escape from last-use history.
6. Allied discounts and reserve source. Ordinary consent, typed allocation and funding are integrated. Guild-recipient and already-active Karama price/payee use the explicitly provisional prototype in both modes. Ordinary Fremen reserves are on-planet and remain ineligible for this off-planet method. See RICHESE_ALLIED_SHIPMENT_AUDIT.md.
7. Supply orientation. Concealed denomination is explicit. Hiding unused IDs/values in public JSON is the minimum privacy consequence, not a claim about an otherwise undocumented physical supply layout. The last revealed used face is public until another deployment; historical log knowledge may legitimately remain.

Required verification

The isolated tests should cover exact 0/3/5 inventory, independent IDs, one-deployed limit, nonconsecutive own/allied history, movement without history change, capped reveal including zero, repeated/stale reveal rejection, allied immediate reveal and existing-marker rejection, immutable failures, JSON recovery, and projection invariance across all hidden values. Engine acceptance separately needs actual force/Tanks conservation, board-sector legality, every response/reveal trigger, mixed groups, battles at zero, private plan restrictions, all four AI profiles, and persisted CAS at pending shipment/reveal boundaries. Passing pure-model tests cannot release existing game-mode gates.

Implemented isolated exports: createRicheseNoField, validateRicheseNoField, deployRicheseNoField, moveRicheseNoField, revealRicheseNoField, shipAlliedRicheseNoField, and projectRicheseNoField. Public view is {deployed: {controller, location, effectiveForces: 1} | null, lastUsed: 0 | 3 | 5 | null}. The owner's view additionally contains private, a cloned full token state. Reveal returns {state, tokenId, controller, location, value, forces, cause}; this is an internal result, not an automatic public projection. Engine action event/version fences must distinguish later reuses of the same physical token; the pure model rejects absent/wrong-token custody but does not generate network operation IDs.

Validation: all 12 focused tests in tests/richese-no-field.test.ts passed, including every modeled cause across 0/3/5 and seven reserve quantities. Global TypeScript and targeted lint passed. No engine, UI, board, package or availability-gate file was changed by this subtask.

Independent follow-up caught a sparse-array constructor loophole: array iteration skipped an absent physical slot. Validation now densifies iteration before checking identities/values; a regression covers sparse constructor inputs, in-memory token holes and their JSON null representation. The correction changes no normal token rules. All 12 model tests, TypeScript and targeted lint pass.

Root integration review also corrected the Polar Sink address: its ordinary board location is polar_sink:0, which the initial structural check incorrectly rejected. A thirteenth regression now accepts that address while rejecting zero-sector HMS/Homeworld containers. This is location compatibility only; engine map membership and legal movement remain required. All 13 model tests pass after the correction.

Current bounded engine, UI and AI checkpoint

Implementation — Partial. Player.noField and its changing event fence now keep the physical component separate from forces. Concealed own shipment pays for one force, preserves reserves and can be prevented by Karama before custody/payment; Guild shipment prevention and payment continue through their own stages. Normal or Guild-allied rates and exact pledged shares are tested. Marker-only and marker-plus-physical-group movement preserve real units and rotate the event. Voluntary reveal works before Battle and materializes at the exact marker sector once. Allied No-Field shipment is now separately integrated: an authoritative opportunity holds the active ally’s unused shipment for Richese to offer or pass. A private exact proposal requires recipient consent and typed-force selection. Either player may pay the full fixed one/two-spice price, or each pays one for a two-spice destination (payer: both). After prevention resolves, commit reveals the old Richese marker first and immediately materializes the selected allied token from recipient reserves; only the recipient’s shipment is consumed.

game/force-presence.ts distinguishes presence from actual units, and map/occupancy, battle discovery, collection and control use that distinction. A marker is one collector even at zero. Storm checks the exact exposed marker sector before materialization/casualties; sheltered Imperial Basin and other sectors are preserved in focused checks. Unprotected worm destruction runs the actual reveal/casualty path, including a real Thumper trigger. Protected-worm and additional removal effects remain bounded by the source interpretations above.

Marker-only battle admission computes the owner's prospective pool from denomination and remaining reserves. The view exposes that pool only to its owning combatant; another player sees its own pool or none. Both plans seal before public reveal materializes the marker. The battle's noFieldPlayers flag persists, so zero still has its leader/cards/traitor resolution. Ordinary Atreides dial prescience is rejected on the server and avoided by controls/AI. Basic and Advanced physical-plus-marker admission use the provisional prototype above; combined mixed admission and special whole-plan inspection remain guarded. Broader Truthtrance remains an audit boundary.

Player controls — Partial. components/richese-no-field.tsx provides concealed board markers plus owner-only denomination inventory, last-use status, token selection, ordinary one-force price/ally-share feedback and authoritative unavailable reasons. The parent table adds explicit marker movement selection and private prospective battle bounds. Token identifiers and hidden values are absent from rival board projections. The separate components/richese-allied-no-field.tsx supplies owner opportunity/proposal/payment controls and private recipient accept/decline/typed-force controls. Own shipment, marker movement and invitation/reveal have passed browser checks; an allied owner proposal was checked, but recipient browser acceptance and mobile remain pending.

AI — Partial. game/bots.ts selects eligible private own denominations, emits one-force shipments with exact funding, moves marker-only groups as forces: {} with explicit token/event, and reveals positive materializable tokens before a new shipment or after movement. It keeps a zero or exhausted-reserve marker concealed. Ordinary group candidates avoid combining with the owner's concealed marker while mixed battles are guarded. The battle policy uses the projected private force pool; opponent valuation uses public one-force presence. Responses, decisions and Truthtrance take priority. All four profiles also handle allied opportunity and acceptance from their entitled views, prefer positive safe owner-funded offers, decline unusable offers and avoid repeated automatic offers. Actual scheduling tests cover both seating orders, autopilot and a human supplier holding an AI ally’s shipment until explicit choice. Optimal strategy and complete Richese games are not claimed.

Documentation — Partial. The in-app richese-no-field topic now documents the above controls and five facets. RICHESE_NO_FIELD_ENGINE_AUDIT.md retains the hook audit and current resolution notes. Source-confirmed Gamont requires reveal whenever its selected location contains the marker, then returns one actual force if present; the card is still used when zero results. Gamont engine/UI integration now follows that rule even when ordinary units also occupy the selected marker sector; its options label the reveal consequence without a separate target mode. Canceling the CHOAM power keeps the token concealed. Root reports 29 passing focused scenarios: 19 existing Gamont regressions plus the 10-case No-Field engine file, including two new Gamont scenarios covering 0/3/5, colocated zero/two ordinary forces, scarce reserves, cancellation and stale restored events. Allied shipment and typed allocations are integrated; mixed battles, Guild/Karama allied pricing and broader power interactions remain explicit unfinished work. No game-mode gate was opened.

Verification — Partial. Current named focused results: tests/richese-no-field.test.ts (13), tests/richese-no-field-engine.test.ts (10), tests/richese-no-field-review.test.ts (8), tests/richese-no-field-bots.test.ts (9). The independent review compares complete opponent projections across 0/3/5 both before and after shipment, and after private plan sealing; checks payment/rates, storm shelter/sectors, actual worm activation, voluntary timing, later physical-token reuse with stale event, atomic BG/Terror entry rejection, stale CHOAM continuation and synthetic inventory validation. AI tests run every profile through Basic/Advanced marker-only zero/3/5 battles, including scarce reserves and repeated JSON restoration, to finite battle completion with conservation. Seven ordinary shipment-budget and four special-acquisition AI regressions also pass, with targeted lint and TypeScript. These focused checks are supplemented by the integrated acceptance updates below; complete Richese-game acceptance is not certified.

Integrated acceptance update

At the earlier own-No-Field checkpoint, the registered suite passed 1,176 rules/client scenarios and 87 persisted/API scenarios, with TypeScript, lint and production build passing. Four No-Field persisted-room tests cover private projections/reopening, cancellation after reload, competing shipment CAS, movement stale events and duplicate reveal. Browser room QPNV5XJJ exercised shipment of token 5, marker-only movement, fresh invitation recovery and voluntary reveal to five actual forces. The owner inventory/board layout was visually inspected. Full battle/Gamont/mobile browser checks and complete Richese games remain outstanding. Logs and exact QA state are recorded in IMPLEMENTATION_STATUS.md.

Allied integration checkpoint before final checks

All five progress facets remain Partial. Ten allied engine, seven independent review, seven AI and three persisted-room tests pass. Evidence lives in tests/richese-allied-no-field.test.ts, tests/richese-allied-no-field-review.test.ts, tests/richese-allied-no-field-bots.test.ts and tests/richese-allied-no-field-recovery.test.ts. These cover exact full/split funding, private consent, typed reserves, old-marker reveal, cancellation and Guild-stop custody, stale/restarted offers, concurrent acceptance, zero Terror arrival and deferred Heighliner accounting. The persisted/API suite passes 90/90. An obsolete rules fixture was corrected to answer the new opportunity; its ten focused tests pass, while the complete expanded rules rerun and final type/lint checks are pending.

Browser QA reached a real saved owner proposal at version 10, awaiting recipient consent. This confirms the owner journey only; it does not certify recipient browser acceptance, mobile, complete battles or full Richese games. The earlier 1,176/87 result above is the previous own-No-Field checkpoint, not the current expanded suite total. Full game-mode gates remain unchanged.

Final allied checkpoint

The integrated suite passes 1,207 rules/client and90 persisted/API tests. TypeScript, lint and production build pass. Eleven allied engine cases now include recoverable arrival preflight and an AI decline fallback, alongside seven independent review, seven AI and three persisted cases. The supplier’s real browser offer survived the controlled09:10UTC restart with all995 saved tables unchanged. Recipient acceptance was then exercised through real controls in a deliberately swapped synthetic-role fixture; three actual forces arrived, only the recipient’s shipment was used, and the supplier paid once. This is browser coverage of both interfaces, not a claim of real seat switching. Exact logs, backup paths and fixture transitions are in IMPLEMENTATION_STATUS.md. Complete Richese games and unresolved optional/pricing combinations remain outstanding.