147 lines
24 KiB
Markdown
147 lines
24 KiB
Markdown
# Richese allied No-Field shipment contract
|
||
|
||
Primary-source audit, 2026-09-06. This narrows the broad integration warnings in the earlier No-Field audits. Ordinary turn ownership, consent and typed force selection can be composed without inventing extra faction powers. The genuinely unresolved payment and interruption intersections below remain distinct. The ordinary contract is now implemented in development fixtures as recorded below; this document does not activate a mode or certify all combinations.
|
||
|
||
## Native rate cancellation and fresh approval — 15 October 2026
|
||
|
||
Guild-recipient loans now expose native discount cancellation before any
|
||
payment or compulsory old-marker reveal. Desert half1 becomes full2 for one
|
||
marker, not zero/five materialized forces. The standing provisional bank-only
|
||
payee is retained. An independent played Karama price still takes precedence.
|
||
|
||
Supplier whole-price approval1 cannot become2 automatically. Release keeps
|
||
both wallets, recipient allowance and prior deployed three-marker unchanged;
|
||
a new full-price offer and recipient consent authorize the replacement.
|
||
Actual390px controls then spend Richese10→8, materialize its prior three
|
||
at Red Chasm and five Guild forces at Imperial Basin10, while Guild wallet10
|
||
stays unchanged. This scene is explicitly controlled, not original action-only.
|
||
|
||
The actual surface found a missing quote bridge: fresh lender UI/AI offers
|
||
previously used their own view and displayed1 after the recipient’s rate was
|
||
canceled. They now consume the authoritative authorized-pair `allyPricing`
|
||
descriptor, with full2 and bank-only policy; no recipient wallet is projected.
|
||
The canonical price helper requires explicit independent/native source
|
||
booleans, preventing accidental use of an incomplete GameView as server state.
|
||
[Current permission/price/loan source contract and proof](GUILD_RATE_KARAMA_RULES.md#permission-purchase-and-allied-marker-composition--15-october-2026).
|
||
|
||
## Advanced discounted shipment follow-up — 8 October 2026
|
||
|
||
The Basic prototype below now also applies in Advanced. Supplied physical
|
||
p36 D permits allied off-planet shipment and p37 C supplies the Guild
|
||
rounding rule; the specific price/payee precedence remains provisional.
|
||
No extra Karama is spent and no additional shipment is granted. The
|
||
existing Advanced Guild-stop window still precedes payment/materialization,
|
||
including the uniform window on a Guild recipient's own shipment.
|
||
|
||
Two before/after direct Advanced scenarios cover Guild and an actual native
|
||
Karama purchase, private one-spice offers, Easy consent and five arrivals.
|
||
Only Richese's one spice is spent, Guild income stays unchanged and only
|
||
the recipient's shipment is used. GameTable SSR supplier/recipient panels
|
||
show the provisional policy in Chromium, with enabled consent.
|
||
No broad suite, recovery campaign or deployed acceptance was run.
|
||
|
||
|
||
## Basic discounted allied shipment prototype — 8 October 2026
|
||
|
||
The Basic-first pass connects Guild recipients and already-active Karama
|
||
shipment rates. **Provisional price/payee policy:** use the rounded
|
||
one-force Guild fee, one spice for either printed destination class, and
|
||
send the entire payment to the bank even when Richese funds it. This
|
||
chooses the ordinary discounted-rate reading for a usable first version;
|
||
it is not a publisher answer to the precedence conflicts below.
|
||
|
||
`alliedNoFieldShipmentPricing` supplies the same immutable price/policy
|
||
quote to the engine, supplier controls and legal AI. Private pending-offer
|
||
and recipient-consent views carry the explanatory `pricingPolicy` only
|
||
to the pair. One payer funds the one-spice cost; the two-spice equal split
|
||
is not offered for this price. Native acceptance/commit revalidation,
|
||
token history, recipient force composition, cancellation/prevention,
|
||
prior-marker reveal and shipment ownership remain in their original paths.
|
||
Karama must already have been played through its own grant; this does not
|
||
spend a second card implicitly or grant another shipment.
|
||
|
||
The Guild income adapter routes these Basic payments entirely to bank;
|
||
Guild gains no self-shipment/donor fee. The native Heighliner call still
|
||
uses the force recipient, not the token supplier. Advanced now shares this
|
||
policy as described above. Ordinary undiscounted allied prices, on-planet
|
||
Fremen exclusion, destination restrictions and public-mode gates
|
||
are unchanged.
|
||
|
||
**Brief smoke:** both old Basic guards reproduced. Guild-recipient and
|
||
actual native Karama-purchase scenarios now reach a private one-spice
|
||
offer and legal Easy consent, materialize five actual recipient forces,
|
||
spend only the supplier's one spice, leave Guild income unchanged and
|
||
consume only the recipient shipment. Supplier/consent SSR controls were
|
||
observed in Chromium with matching price and provisional warning. Types
|
||
pass; no broad suite, recovery campaign or deployed acceptance was run.
|
||
|
||
## Sources checked
|
||
|
||
- **R2**, [GF9 CHOAM & Richese rulebook](https://www.gf9games.com/dune/wp-content/uploads/2021/11/CHOAM-Rulebook-low-res.pdf), pp6,11–12: allied offer, prior-marker reveal, shared last-use history, explicit one/two-spice payment and either payer, Guild-recipient Heighliner exception, No-Field cancellation. The full publisher-authored mirror `/tmp/dune-rules/choam-lelekan-mirror.pdf` and `.txt` were read; fresh official-domain search results reproduced the relevant pages. Mirror provenance is in `RICHESE_NO_FIELD_RULES.md`.
|
||
- **B19**, [GF9 base rulebook](https://www.gf9games.com/dunegame/wp-content/uploads/Dune-Rulebook.pdf), pp9,12,14,16,18–19: a player's one shipment followed by movement, allies paying shipments, special Guild prevention, Fremen reserve location, typed troops and Guild shipment/income/rates. Local `/tmp/dune-rules/base.txt`.
|
||
- **F20**, [GF9 November 2020 FAQ](https://www.gf9games.com/dune/wp-content/uploads/2020/11/Dune-FAQ-Nov-2020.pdf), p5: Fremen reserves are on the planet in one off-board territory, permitting Guild cross-shipment; Guild half prices round upward; ordinary allies can fund shipments. Fresh official-indexed page text was retrieved. This is the later FAQ, not the superseded April answer about worm movement.
|
||
- **I20**, [GF9 Ixian & Tleilaxu rulebook](https://www.gf9games.com/dunegame/wp-content/uploads/2020/09/IxianAndTleilaxuRulebook.pdf), pp4,9: Heighliner eligibility and both Cyborg/Suboid types shipping normally. Full local `/tmp/dune-rules/ix-official-mirror.txt`.
|
||
- The updated physical Karama face previously verified in `/tmp/dune-rules/choam-cards-gallery1.jpg` includes alliance abilities in one-use cancellation, and routes its shipment-rate purchase to the bank. Its image provenance is in `RICHESE_COMPONENTS.md`.
|
||
|
||
Searches were restricted to publisher domains for additional rulings. No new official result reconciled the specific Guild-recipient or active-Karama payment cases below. Tournament and community rewrites were not used.
|
||
|
||
## Defensible ordinary contract
|
||
|
||
| Question | Contract and reasoning |
|
||
| --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||
| Whose turn and allowance? | Use the receiving ally's current, unused shipment opportunity, before that ally's movement. B19 gives each player one own shipment in its turn; R2 supplies an alternative way to ship those forces, without granting an additional shipment or an out-of-turn action. The recipient's `shipped` is consumed on success; Richese's is unchanged. Guild timing, when otherwise allowed, determines when Guild's own turn occurs rather than creating a separate Richese turn. |
|
||
| Who owns the power and token? | Richese voluntarily offers its own available token. The recipient cannot spend Richese's token, reveal its old marker or debit Richese's spice unilaterally. Token inventory and nonconsecutive-use history remain Richese-owned across own/allied shipments. |
|
||
| Who chooses destination? | The force owner must agree to its forces' shipment. A Richese proposal containing token, destination and payer, accepted by the ally, is equivalent to the ally requesting those terms. The text does not prescribe which player must speak first or require an extra acknowledgement after agreement. A two-step network offer/accept is an implementation of that consent, not an additional game power. |
|
||
| How many forces? | The token determines the quantity, capped by the recipient's available reserves. Do not let the recipient choose any smaller convenient amount when enough units exist; it chooses the eligible composition of that quantity. Denomination is a physical-unit count, not battle strength. No concealed allied marker remains after success. |
|
||
| Who chooses typed units? | The recipient selects its own ordinary/elite mix, within the actual reserve pools and the token's total. I20 expressly makes Cyborgs and Suboids ordinary shipments; their different strength is a battle rule. Sardaukar likewise are physical troops, not a two-slot shipment. Use existing `eliteChoice`-style bounds: elite at least the shortage of ordinary units and at most the smaller of total shipped and elite reserves. Preserve ordinary and elite reserve conservation. Do not reject all typed factions merely because R2 does not repeat their definitions. |
|
||
| Price and payer for an ordinary non-Guild recipient | One spice to a stronghold, two elsewhere, regardless of whether the denomination is zero, three or five, with ordinary destination restrictions. Either Richese or the recipient can pay the whole amount. Ordinary allied funding rules also support a split. Current controls permit each ally to pay one for a two-spice destination; the one-spice price requires one full payer. Do not calculate the fee from the revealed number of units. |
|
||
| Payment recipient | For an ordinary recipient, pay Guild when present and otherwise bank. Payer identity does not make Richese the owner of the shipped forces. Validate the chosen payer's available funds and any existing reservations before committing. A pledge and a direct voluntarily agreed payment must not be debited twice. Guild-as-recipient and active Karama modifications are addressed separately below. |
|
||
| Heighliner | Trigger for the off-planet shipment, except when the shipped ally is Guild, as R2 explicitly says. Use the **force recipient** for this exclusion, not Richese as supplier or the spice payer. Reveal is not a second shipment and cannot accrue a second payment. |
|
||
| Destination and resulting stance | Apply recipient-based map legality, storm, stronghold occupancy, alliance and stance rules. No-Field does not grant an extra mobile-stronghold/Homeworld permission or unrestricted crossing. A directly shipped BG group follows ordinary direct-shipment stance rules; the mechanism is not itself Spiritual Advisors. |
|
||
|
||
### Fremen is not an ordinary off-planet recipient
|
||
|
||
R2 specifies shipping an ally's forces from off-planet. B19 locates Fremen reserves on the far side of Dune, and F20 p5 explicitly calls them an on-planet off-board territory; this is why Guild **cross-shipment** can retrieve them. The No-Field allied paragraph does not grant cross-shipment. Accordingly the ordinary Fremen reserve pool does not meet this method's off-planet source condition. Keep that pool ineligible unless a later applicable module or explicit ruling changes its source. This is a specific ordinary-rule composition, not a general statement that Fremen cannot benefit from allies or pay for shipment. Do not convert it into a free, unlimited-range No-Field shipment using the Fremen normal free-reinforcement rule.
|
||
|
||
## Consent, cancellation and prior marker
|
||
|
||
An implementation can persist Richese's exact proposal `{supplier, recipient, token, destination, payer, event}` while the active recipient accepts and selects its typed mix or declines. Only the participants need the proposed denomination before shipment; do not publish the private token ID or full unused inventory in a response. Once shipped, the allied token and resulting units are immediately public. Do not automatically conceal typed composition after this explicit reveal.
|
||
|
||
On acceptance, revalidate reciprocal alliance, recipient's current shipment allowance, token history/event, location, forces and exact funding. The updated Karama and R2 cancellation table support a response against Richese's use of the alliance No-Field advantage. Guild's special Karama then applies to a declared off-planet shipment through the existing shipment-prevention contract. The special Guild power itself is not an ordinary cancelable faction advantage. Keep the identity of the ability owner separate from the force recipient throughout these responses.
|
||
|
||
**Recommended transaction order:** proposal → recipient consent/composition → Richese ability cancellation → applicable Guild stop → commit. At commit, reveal any old Richese marker using Richese's then-available reserves; next place the agreed different token and immediately reveal/materialize the recipient's forces; debit the agreed shipment payment and consume the recipient's shipment opportunity exactly once. The old marker's reveal has to precede the new deployment, but R2 does not require that prerequisite disclosure at mere proposal time. Deferring it until the allowed shipment commits is a defensible composition: a canceled shipment never occurred. Preserve the old hidden marker, funds, forces and token history on a declined or canceled proposal. This ordering should be labelled a transactional implementation interpretation, not a newly found explicit FAQ sequence.
|
||
|
||
If Richese already voluntarily revealed its marker in a separate completed action, later cancellation cannot undo that revealed information or return its units to reserves. The two cases must not be conflated. Switching turns does not clear the most-recent-token restriction; the newly used token becomes the shared face-up last-use marker even when its denomination is zero.
|
||
|
||
Before any irreversible stage, check that all supported arrival continuations can be represented. The old marker's reveal is not a fresh entry; the allied shipment is. A new Guild income/BG/CHOAM/Terror/Ambassador reaction cannot overwrite an existing decision. If unsupported simultaneous arrivals would fail after an accepted proposal, validate that boundary before accepting or preserve a recoverable exact pending state; do not strand an already passed response whose commit always throws. Revealing zero produces no physical casualties or reserve debit. Its shipment/arrival triggers need an explicit effect-by-effect interpretation: the general one-force marker rule applies before reveal, but no new hidden allied presence exists afterward.
|
||
|
||
## Material exceptions requiring resolution or an explicit guarded policy
|
||
|
||
1. **Guild recipient price and payee.** R2 p11 unqualifiedly answers one/two spice and payment to Guild if present. B19 gives Guild half the normal fee and only income when other factions ship; the recipient is Guild in this case. Thus ordinary composition suggests half-price paid to bank, while the more specific R2 answer can be read as a fixed fee. The explicit Heighliner Guild exception proves this recipient is contemplated but does not choose between those payment readings. Do not silently charge five units at half price, pay Guild its own fee as income, or certify either one/one versus one/two without stating the policy. A narrow Guild-recipient guard is appropriate pending a ruling; ordinary non-Guild recipients do not share this conflict.
|
||
2. **Already active Karama shipment rate.** Generic Karama supplies Guild rate and bank routing; R2 allied FAQ states one/two and Guild routing. The new No-Field shipment price is not permission to consume two card effects with an invented order. Either resolve this particular rate/destination precedence or keep active-discount combinations unavailable. This is distinct from the unambiguous ordinary Richese-own shipment rule “pay for one force,” to which normal faction rates already apply in current code.
|
||
3. **Prevention settlement policy.** Existing Guild special prevention has a provisional policy for consuming the stopped shipper's shipment opportunity. This No-Field integration should reuse it rather than quietly alter it, and should not consume Richese's independent turn. Likewise a canceled Richese token use does not authorize an automatic ordinary fallback shipment; return control for a separate legal choice, subject to the existing cancellation-use policy.
|
||
4. **Optional and simultaneous effects.** Smuggler's FAQ specifically concerns Richese's own shipment; it does not establish an extra recipient unit on every allied offer. Homeworlds, HMS entry, multiple arrival effects and zero allied arrival triggers remain separate compositions. These should not prevent normal typed shipment or ordinary recipient consent from being implemented.
|
||
|
||
## Required evidence for implementation
|
||
|
||
Test supplier-versus-recipient turn ownership, both full payers and any supported split, refusal, stale offer, changed alliance, depleted/reserved funds, exact quantity/typed mix, no consecutive token reuse, existing-marker reserve shortage, cancellation before prior reveal, Guild-stop continuation, zero materialization, appropriate Heighliner actor, Fremen source rejection, and guarded Guild/active-rate exceptions. Compare every viewer before consent, during both response windows and after immediate reveal. Persist/reload the exact offer and compete action versions so neither the old marker nor the new shipment can settle twice. Exercise all four AI profiles and inspect the recipient's acceptance/payment/force controls. The initial audit changed no runtime files. The implementation checkpoint below records the subsequent integration.
|
||
|
||
## Implemented ordinary contract before final checks
|
||
|
||
**Implementation — Partial.** The engine opens `richeseAllyOpportunity` once for the active eligible recipient's unused shipment, holding that turn for Richese to offer or pass. `richeseAllyShipment` requires recipient consent and legal typed composition, or decline. Ordinary full/equal-split funding remains supported. Guild and already-active Karama recipients use the explicit discounted prototype in both modes. Fremen's ordinary on-planet reserves remain ineligible.
|
||
|
||
Prevention precedes commitment. At successful commit the prior owner marker reveals first, the new allied token materializes immediately, exact funding settles once and only the recipient’s shipment is consumed. Decline/cancellation preserves the prior concealed marker and custody. This is the documented transaction composition above, not an explicit publisher FAQ about online action ordering.
|
||
|
||
**Player controls — Partial.** `components/richese-allied-no-field.tsx` presents the supplier’s offer/pass window and destination/token/payment choice, followed by private recipient terms, force composition and accept/decline controls. Hidden recipient funds are not exposed to the supplier through proposal validation. Public observers do not see private denomination, token IDs or typed offer details before commitment; Guild’s stop window exposes one declared marker. Browser QA has checked the owner proposal saved at real version 10 and awaiting consent; recipient browser acceptance and mobile remain unverified.
|
||
|
||
**AI — Partial.** All four profiles use their personalized opportunity/consent views, prefer safe positive owner-funded tokens and select a legal recipient mix or decline. Their conservative policy does not proactively choose split funding. Actual `runBots` tests cover both seating orders, autopilot, declined opportunities and a human Richese supplier holding an AI ally’s shipment with `botsPending: false` until the human acts. No supplier action is performed on the human’s behalf.
|
||
|
||
**Documentation — Partial.** This source audit and the No-Field rules, hook audit and in-app five-facet checklist distinguish this implemented ordinary subset from price precedence, optional containers, mixed battle and whole-plan disclosure gaps. The physical No-Field inventory remains separate from actual force arrays.
|
||
|
||
**Verification — Partial.** Ten engine cases (`tests/richese-allied-no-field.test.ts`), seven independent cases (`tests/richese-allied-no-field-review.test.ts`), seven all-profile AI cases (`tests/richese-allied-no-field-bots.test.ts`) and three persisted/API cases (`tests/richese-allied-no-field-recovery.test.ts`) pass. They exercise full/split payment, consent privacy, typed conservation, prior reveal, zero arrival/Terror, cancellation, Guild stopping, deferred Heighliner, stale events and concurrent restored acceptance. The complete persisted/API suite passes 90/90; the expanded rules rerun and final type/lint remain pending. The old fixture that skipped the newly required opportunity was corrected and its ten focused checks pass. No complete Richese game or full expansion acceptance is claimed.
|
||
|
||
|
||
## 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.
|