Implement Grumman collection and private stacked Terror choices
Add conserved token collection with four bank spice, owner-only stack selection, recovery proofs, controls and AI. Preserve unresolved removal and expansion release gates. Verified 3712 offline cases, types, lint, production build, 40 HTTP cases, three-seat desktop/mobile play, and unchanged 3081 preexisting saved games.
This commit is contained in:
1 parent
28ba1618ba
commit
1db11a0187
27 files changed
+2451
-43
No files matched your search
@@ -0,0 +1,44 @@
|
||||
# Grumman Collection and stacked Terror
|
||||
|
||||
Source audit, 10 September 2026. This supplements [HOMEWORLD_COLLECTION_RULES.md](HOMEWORLD_COLLECTION_RULES.md). It does not certify runtime integration or change release gates. The existing user question about unrevealed removal custody remains pending; this audit asks no duplicate question.
|
||||
|
||||
## Evidence and its limits
|
||||
|
||||
The original Grumman high face was visually inspected again in the [physical component photograph, BGG image 7767034](https://boardgamegeek.com/image/7767034/dune-ecaz-and-moritani), whose provenance is recorded in [HOMEWORLD_COMPONENT_AUDIT.md](HOMEWORLD_COMPONENT_AUDIT.md). It applies at 8–20 native Moritani reserves. During Spice Collection, Moritani may add a Terror token to a stronghold already holding one, or remove a board Terror token, then receive four bank spice. The face does not print an explicit repetition count or specify the removed token’s next custody zone.
|
||||
|
||||
Fresh publisher-indexed passages from the [official Ecaz & Moritani rulebook](https://www.gf9games.com/dune/wp-content/uploads/EcazMoritani-Rulebook-LOWRES.pdf) confirm:
|
||||
|
||||
- **p5:** six hidden physical Terror tokens; ordinary Mentat placement/movement targets an empty eligible stronghold; an opposing entry can permit revealing one token. Revealed tokens leave the game.
|
||||
- **p8:** Ecaz and its ally agree on desert allocation, with the stated fallback when they disagree. Both receive applicable Advanced shared stronghold income.
|
||||
- **p14:** storm/explosions do not remove Terror. A concealed No-Field placement can trigger it, including zero; revealing an existing No-Field or Face Dancer does not.
|
||||
- **p16:** Terror cannot be placed on Homeworlds. Canceling Enemy of My Enemy prevents its alliance but leaves the token revelation available.
|
||||
|
||||
The [designer’s expansion page](https://futurepastimes.com/dune-ecaz-moritani) was also checked. Bounded searches found no authenticated designer or publisher clarification of multiple revelations from one stacked entry, Grumman versus Ecaz timing, or unrevealed Grumman removal custody. Tournament rewrites and community implementations were not treated as official rulings. No new audio clarification is claimed.
|
||||
|
||||
## Supported composition
|
||||
|
||||
**One operation and one payment per Collection.** Treat the singular phase opportunity as one optional add-or-remove transaction. This follows ordinary phase-ability grammar; it is not an explicit Grumman FAQ answer. There is no authority for repeatedly adding/removing tokens to earn unlimited spice. The four-spice award follows a completed legal operation, so declining or lacking a usable operation does not pay. Keep its completion separate from ordinary Mentat placement usage.
|
||||
|
||||
**Owner chooses a physical token.** A stack makes several tokens candidates for the same ordinary entry opportunity. The existing singular revelation language supports choosing one eligible token rather than automatically choosing the first array element. No retrieved source expressly allows activating several tokens from that same entry. The bounded implementation should resolve one selected token or decline, leaving other tokens placed; resolving the effect must not manufacture another entry event. This is ordinary-trigger composition, not a stacking-specific clarification. Separate later arrivals retain their own opportunities and low-Grumman entry requirements.
|
||||
|
||||
The chosen token must remain bound to the original entry through Enemy of My Enemy, its refusal or cancellation, card discards and saved continuations. A refusal applies the selected token’s compulsory outcome. Canceling the alliance must not silently select a different token. Existing effect-specific implementation gates still apply to the selected token; a supported neighbor in the stack does not implement an unfinished effect.
|
||||
|
||||
**After Ecaz settlement is an implementation ordering.** Neither inspected component sets precedence between these two Collection opportunities. Resolving Grumman after existing Ecaz allocation and bank-income continuations is a coherent serializer for the supported effects: allocation changes balances, while Grumman changes token custody and awards fixed bank income; neither operation changes the other’s force count, token availability or allocation formula. No material conflict between those ordinary operations was identified.
|
||||
|
||||
Do not describe that serializer as printed priority. Revalidate current native population when the Grumman action is accepted. An allowed intervening effect that changes population, token custody or the phase must use the same continuation checks; a future noncommuting interaction would require review. Ecaz settlement cannot consume Grumman’s opportunity, and Grumman cannot overwrite an unresolved allocation. Its award is not desert collection and must not create a shared Ecaz allocation or Giedi collection trigger.
|
||||
|
||||
## Unresolved removal custody
|
||||
|
||||
Removal from the board is not revelation. The revelation disposal rule does not establish that an unrevealed Grumman removal is permanently spent. Conversely, other effects’ express return-to-supply instructions do not prove this removal returns to hidden supply. Neither result was authenticated by this audit.
|
||||
|
||||
Keep that operation guarded pending the existing question. Do not reveal its face, call the revelation handler, rotate it into reusable supply, or credit four spice before its destination is resolved. Addition can be implemented independently using an actual available token and a stronghold already containing Terror. It does not authorize Homeworlds, the Hidden Mobile Stronghold, an invented token or movement from another stack.
|
||||
|
||||
## Concrete code review findings
|
||||
|
||||
At the inspected checkpoint, `openTerrorEntry` in [engine.ts](../game/engine.ts) selects the first placed token at the destination. Stacking requires an owner-visible candidate choice, with hidden faces excluded from other seats, and a durable selected identity afterward.
|
||||
|
||||
[moritani-alliance-cancellation.ts](../game/moritani-alliance-cancellation.ts) separately requires exactly one placed token at the entry location. Replace that location-wide uniqueness assumption when stacking is introduced. Preserve uniqueness of the selected **physical ID**, its placed status, location, original entry proof and valid effect. Two distinct colocated tokens are legal candidates; two copies of the same physical ID remain corruption.
|
||||
|
||||
The registry, projection and ordinary placement quote have different responsibilities: permit multiple distinct placed tokens at one location in the registry, expose public stack size without hidden faces, and continue requiring an empty destination for ordinary Mentat placement. Preserve all unselected tokens, original entry counts and protected token custody across rejection and JSON/SQLite recovery.
|
||||
|
||||
Only this source document was written in this task. Local links and whitespace were checked. Runtime tests, browser checks and checkpoint publication are outside this audit.
|
||||
@@ -0,0 +1,46 @@
|
||||
# Grumman Collection and stacked Terror runtime
|
||||
|
||||
Development checkpoint, 10 September 2026. Grumman has Collection addition/decline controls and stacked Terror has an owned token-selection continuation. The checks below pass; this is not a complete Moritani, Homeworld or expansion implementation. Start and publication gates remain in force. Printed evidence, interpretation boundaries and the existing removal question are in [GRUMMAN_STACKED_TERROR_RULES.md](GRUMMAN_STACKED_TERROR_RULES.md).
|
||||
|
||||
## Current Collection behavior
|
||||
|
||||
[grumman-collection.ts](../game/grumman-collection.ts) validates the six physical Terror identities and current native population. At eight or more native Moritani reserves, the owner can add one available hidden token to an ordinary stronghold already holding Terror. The accepted transaction places that token and awards four bank spice. It neither relocates another token nor consumes ordinary Mentat placement. Storm does not exclude a placement destination; Homeworlds and the Hidden Mobile Stronghold are excluded. Declining changes no token and pays nothing.
|
||||
|
||||
The engine stages a separate [Collection receipt](../game/grumman-collection-return.ts) after ordinary collection, then opens the owned choice when Ecaz collection and other active continuations have settled. It checks population again on acceptance. A low-population waiting opportunity can expire when Collection ends; an open choice can always be declined. Recorded event, owner, turn, stage and outcome prevent inconsistent restoration or reapplying the same completed operation. The production room recovery detector recognizes waiting Grumman continuations.
|
||||
|
||||
One operation per Collection follows the card’s singular phase grammar. Serializing it after Ecaz settlement is implementation ordering, not a printed priority rule. The inspected ordinary operations do not change each other’s native force count, token availability or allocation formula. Grumman’s four bank spice is neither desert collection nor an Ecaz shared pool and does not trigger Giedi income.
|
||||
|
||||
[grumman-collection-options.ts](../game/grumman-collection-options.ts), [the owned controls](../components/grumman-collection.tsx), and all four bot profiles share the projected legal addition/decline choices. Opponents receive no available token faces or selectable destinations. Public logs describe the placement and four-spice award without disclosing the hidden token type.
|
||||
|
||||
## Stacked entry and selected-token recovery
|
||||
|
||||
An opposing entry into a stronghold containing multiple Terror tokens opens a private `select` stage. Moritani chooses one original candidate before the ordinary reveal/alliance offer, or declines the whole entry. Supported token effects use the existing handlers; resolving one token does not manufacture another entry to activate its neighbor. One chosen revelation is the ordinary-trigger composition described in the source audit, not a newly discovered stacking FAQ.
|
||||
|
||||
[terror-entry-receipt.ts](../game/terror-entry-receipt.ts) binds the original candidates and public entering group. The selected identity has its own consistency proof, which is also included in the entry signature after selection. This prevents removing the selection proof and rewinding a selected entry to the selection stage while retaining the original receipt. Enemy of My Enemy cancellation preserves the selected identity; its previous one-token-per-location check now validates the selected physical identity without rejecting legitimate colocated tokens.
|
||||
|
||||
Every unselected candidate remains reserved at its original location while the entry is unresolved. The selected token must also remain placed before revelation. Once Sabotage has actually consumed its token and discarded a card, the saved `terrorDiscard` child correctly expects that token to be removed while retaining all unselected tokens at the stronghold. Independent review reproduced and repaired the earlier false rejection of this genuine child. The regression captures the actual inner-dispatch discard and restores it; it does not claim a user-visible HTTP pause at that internal boundary.
|
||||
|
||||
[Map markers](../components/terror-board-markers.tsx) group colocated public tokens and display their count without consulting hidden faces. Only Moritani sees candidate identities/effects in the selection controls. Revealed effects follow their normal public rules; every still-hidden neighbor retains its private face.
|
||||
|
||||
## Boundaries retained
|
||||
|
||||
- Removing an unrevealed board token remains unavailable until its destination is established. The existing question is still pending; removal neither reveals/spends a token nor pays four spice.
|
||||
- Occupation lifecycle and occupied Grumman immunity remain outside this checkpoint. Other unfinished Terror effects and combined arrival/cancellation interactions retain their existing guards. Stacking does not implement them.
|
||||
- Deterministic signatures detect inconsistent saved fields; they are not cryptographic authentication against arbitrary coordinated rewriting of all stored state and proofs. Older entries missing all new metadata retain their documented legacy limitation; readers do not reconstruct an original entering group from current occupants.
|
||||
- Complete faction/expansion setup, combined games and the overall user goal remain unfinished. No gate is removed by passing these focused tests.
|
||||
|
||||
## Verification checkpoint
|
||||
|
||||
The five focused suites contain 30 cases: seven [pure quotes](../tests/grumman-collection.test.ts), seven [engine scenarios](../tests/grumman-collection-engine.test.ts), seven [production SQLite recovery cases](../tests/grumman-collection-recovery.test.ts), six [controls/markers/AI cases](../tests/grumman-collection-controls.test.ts), and three [selection/discard review cases](../tests/grumman-selection-integrity.test.ts). The shared [scenario fixture](../tests/fixture-grumman-collection.ts) uses genuine Moritani/Atreides/Harkonnen Homeworld setup and conserved later positions; Collection and paid entry receipts are generated by real actions.
|
||||
|
||||
The seven SQL cases and focused lint passed. SQL coverage includes competing addition/decline and token-selection writes, a lost addition response, the separate actual Mentat placement, one Robbery payment, all-seat privacy, unrelated-room preservation, and rejection without writes for inconsistent phase, custody, candidate, selected-token and completed-operation records.
|
||||
|
||||
- **`npm run check`: PASS**, including types, lint and all **3,712 offline cases** (90.4 seconds). The older delayed-Chemistry test now initializes the real six-token inventory when manually adding Moritani; production validation remains strict.
|
||||
- **`npm run build`: PASS.** Later edits only corrected that test fixture, clarified a code comment and recorded this documentation.
|
||||
- **`npm run test:integration`: PASS**, all **40 HTTP/session cases**.
|
||||
- **Browser:** isolated three-human QA room `HU6YUC7Z` used genuine initialized Homeworld state and conserved staged positions. Real keyboard actions ended movement, added Sabotage alongside Robbery for four spice, shipped one Atreides force into Arrakeen, selected Robbery privately, revealed it and took half the entrant’s remaining spice. The resulting version 10 has Moritani/Atreides/Harkonnen spice balances 34/9/20, one remaining hidden Sabotage token, and the consumed Robbery token. All three private seats refreshed successfully, with no opponent hand/spice or hidden-token leaks and no page errors. Both Collection and stacked-selection controls were visually inspected at desktop and 390-pixel phone widths; neither overflowed. The board exposed the public two-token count without exposing faces.
|
||||
- **Saved rooms:** after the browser scenarios and HTTP suite, all **3,081 preexisting room versions and state hashes remained unchanged**. The database contains 3,112 rooms, including this isolated QA room and 30 integration-test rooms. No database reset or migration occurred. The existing development server was reused; the preceding controlled restart was at 21:42 UTC on 9 September. This checkpoint does not claim a new restart.
|
||||
|
||||
Read-only browser restoration also passed for the earlier Caladan room `LV2TNQ88` (version 5) and revival room `463GUCY3` (version 7), with all three private seats in each room. Their saved resources and completed continuations remained intact.
|
||||
|
||||
Local verification logs: `/tmp/dune-grumman-verified-check.log`, `/tmp/dune-grumman-final-build.log`, `/tmp/dune-grumman-final-http.log`. Browser images: `/tmp/dune-grumman-desktop.png`, `/tmp/dune-grumman-phone.png`, `/tmp/dune-grumman-stack-desktop.png`, `/tmp/dune-grumman-stack-phone.png`. These temporary evidence files and private browser sessions are not shipped with the application.
|
||||
@@ -2,6 +2,8 @@
|
||||
|
||||
Primary-source audit, 9 September 2026. This document supplies a bounded implementation contract, not a runtime checkpoint. Occupation lifecycle and the separate low-Guild contributor-rounding questions remain pending; do not duplicate them.
|
||||
|
||||
The 10 September source follow-up is [GRUMMAN_STACKED_TERROR_RULES.md](GRUMMAN_STACKED_TERROR_RULES.md); current addition/selection wiring and its pending final verification are in [GRUMMAN_STACKED_TERROR_RUNTIME.md](GRUMMAN_STACKED_TERROR_RUNTIME.md).
|
||||
|
||||
## Evidence inspected
|
||||
|
||||
The original high faces were visually read again from `/tmp/dune-card-economy-homeworlds.jpg`, the 3024×4032 original photograph associated with [BGG image 7767034](https://boardgamegeek.com/image/7767034/dune-ecaz-and-moritani), posted by Jaakko/zaksalo on 2 October 2023. Grumman and Giedi Prime are both legible in its bottom row. The photograph is primary component evidence; the photographer's opinions are not rules authority. The [component audit](HOMEWORLD_COMPONENT_AUDIT.md) records all face provenance.
|
||||
|
||||
@@ -1,5 +1,9 @@
|
||||
# Giedi collection and low Grumman entry
|
||||
|
||||
The later high-Grumman addition and stacked-entry development checkpoint is in
|
||||
[GRUMMAN_STACKED_TERROR_RUNTIME.md](GRUMMAN_STACKED_TERROR_RUNTIME.md). Its final
|
||||
verification remains separate from the historical checks below.
|
||||
|
||||
This checkpoint connects two population effects. The complete Homeworld module,
|
||||
Moritani faction and expansion starts remain gated. Printed component evidence,
|
||||
the No-Field composition and Grumman's unresolved removal destination are in
|
||||
|
||||
@@ -1,5 +1,7 @@
|
||||
# Dune implementation status
|
||||
|
||||
**Grumman Collection and stacked Terror checkpoint, 10 September 2026:** [GRUMMAN_STACKED_TERROR_RUNTIME.md](GRUMMAN_STACKED_TERROR_RUNTIME.md) records one hidden-token addition with four bank spice, separate Mentat placement, private stacked-token selection, shared controls/AI and durable discard/alliance continuations. Review fixed selected-choice rewinds and restoration of a consumed Sabotage token during its genuine discard child. **3,712 offline cases, types, lint, production build and 40 HTTP/session cases pass.** Desktop/phone keyboard Collection, shipment, token selection, Robbery payment, public stack count and three-seat private refresh passed. All 3,081 preexisting room versions/hashes remained unchanged. Removal custody, occupation, unfinished effects and complete expansion games remain unresolved; no release gate opened. The existing server was reused and the removed automation stays removed.
|
||||
|
||||
**Caladan victory reinforcement checkpoint, 10 September 2026:** [HOMEWORLD_VICTORY_REINFORCEMENT_RUNTIME.md](HOMEWORLD_VICTORY_REINFORCEMENT_RUNTIME.md) records the actual high-Caladan post-victory one-force transfer, current population and survivors, original battle location, exact native/visitor custody, owned controls and all-profile AI. Shared Ambassador arrivals preserve the original reinforcement and its nested children. Independent review reproduced and fixed arrival-to-choice rewinds and a deleted preceding cleanup choice; new revival returns also carry version-bound independent progress, while legacy completed QA saves remain readable. Final types, lint, **3,682 offline cases** (89.9 seconds), production build and **40 HTTP cases** pass. Eight Caladan production SQLite cases cover competing writes, reloads, private projections, nested arrivals and corruption. Two older Face Dance fixtures now explicitly decline the preceding guarded Caladan option, without choosing the unresolved placement order. Desktop and phone keyboard placement and three-seat refresh passed; final restart restoration passed for both Caladan and revival QA games. All **3,051** pre-existing room versions/hashes remain unchanged after restart and additive HTTP work. Low-Tupile public contact/once-per-faction quoting has seven cases but no playable disclosure action. Face Dancer ordering, guarded entry combinations, occupation, other missing effects and complete expansion games remain unfinished; no release gate opened. User workflow optimizations remain in use and automation stays removed.
|
||||
|
||||
**Homeworld revival deployment checkpoint, 10 September 2026:** [HOMEWORLD_REVIVAL_DEPLOYMENT_RUNTIME.md](HOMEWORLD_REVIVAL_DEPLOYMENT_RUNTIME.md) records newly revived Fedaykin placement and Tleilax ordinary Free Revival deployment, exact typed groups, normal/Emperor-extra/Ghola source distinctions, owned controls and all-profile AI. Signed return, income and Ambassador completion records preserve nested arrivals and CHOAM sale restoration. Independent review found and fixed altered-offer acceptance and deleted-child premature completion. Final types, lint, **3,634 offline cases**, production build and **40 HTTP cases** pass; seven new production SQLite cases cover competing writes, lost responses, nested Ambassador restoration and corruption. The final suite also made an older auction test deterministic when the purchased Karama creates a second income responder. Desktop and phone keyboard placement, Ghola decline, refresh and three private seats passed without overflow or page errors. The hourly restart preserved all **3,050** saved room versions/hashes and restored the QA seats. First-reaching-high timing, partial/split groups, storm/arrival classification, occupation and complete expansion games remain unfinished; no release gate opened. User workflow optimizations remain in use and the automation stays removed.
|
||||
|
||||
Reference in new issue
Block a user