# Slot library, guided builds and core rewards

7 October 2026. Implements the user's approved [ability-menu plans](Design/AbilityMenu/IMPLEMENTATION.md) in the main menu and stage reward UI.

## Result

- A persistent seven-slot strip and compatible ability library replace the menu's ability dropdowns. Search and semantic role filters inspect without editing. Equip and deliberate swaps change a validated draft, with effect/recharge facts, lost-benefit details and before/after totals.
- Three editable guided examples explain their loop and trade-off. They replace the ability draft atomically, preserve weapons and return to slot editing. Apply saves/submits the combined loadout; Discard restores both weapons and abilities. Ready requires acknowledgement of that exact pair.
- Core rewards show actual effect, rarity, recipient and current-to-next rank. Categories explicitly award a random compatible core immediately, followed by an installed receipt. Read-only build/core inspection stays inside mandatory rewards. A host-replicated aggregate shows completed choices without exposing private offers.
- Ability definitions, numerical tuning, drop rules, eligibility, RNG, saved-loadout schema and travel conditions are preserved. The completion observer is pure; receipts still block completion until acknowledgement. Matching rebuilt peers are required for the additional snapshot integer.

## Automated and Editor evidence

- Initial RED: 488 passed / 17 expected missing-feature failures (`TestResults/ability-menu-red.txt`). Intermediate library/reward RED and GREEN checkpoints are retained separately.
- Final EditMode: **523 passed, 0 failed** (`TestResults/ability-menu-reviewed-editmode.json`), covering atomic swaps/recipes, unlock rejection, real asset facts including Haste, UI controls, pure completion observation, receipt/deferred semantics and snapshot serialization/equality.
- Final PlayMode: **3 passed, 0 failed** (`TestResults/ability-menu-final-playmode.json`). The actual MainMenu document receives production search/recipe/discard events; rehosting recreates one application/lobby; an attached reward view receives wheel and Escape events, closes inspection without confirming, and retains mandatory input blocking.
- Unity 6000.6.4f1 imports/compiles the changed C#, UXML and USS. Metadata is retained. Unity tooling encountered a PlayMode scenario assertion and HTTP main-thread timeouts during reload; these were recovered, and subsequent tests/captures completed. These tooling errors are not counted as game test failures.
- **36 ability and 42 core captures** use production controls at 1920×1080, 1920×1200 and 2560×1080, scales 100% and 125%. They include search, guided actions, last list entries, expanded candidate previews, specific/category/receipt/waiting rewards and expanded last installed-core detail. Outputs: `TestResults/ability-menu-visuals` and `TestResults/feedback-core-visuals`. Fixtures use deterministic presentation data (core context HP45/shield50); they do not prove live networking.

Representative production captures:

![Slot library](Design/AbilityMenu/implemented-slot-library.png)

![Guided builds](Design/AbilityMenu/implemented-guided-builds.png)

![Core rewards](Design/AbilityMenu/implemented-core-rewards.png)

## Independent reviews

Three independent gpt-6.1-sol/medium perspectives reviewed the approved design before implementation and the integrated result. The technical review traced authority, lifecycle and serialization; gameplay traced actual recipes and fixed/scaled runtime effects; UX inspected fresh production renders across the requested scales and aspect ratios.

Resolved findings: Haste now states its actual percentage/duration; acceptance cleanup uses writable typed registry operations; short candidate layouts retain readable facts and fixed actions; core inspection clips within its scroll viewport; compact core spacing exposes effect/rank/recipient at ultrawide 125%; final installed-detail captures scroll after expanded layout. Reviewers accept the integrated scope; matching-build online checks below subsequently passed.

## Build and online acceptance

- Windows development build: **Succeeded, 0 errors / 532 warnings**, 6m55s (`TestResults/ability-menu-build-result.txt`). Build proof records native executable, game assembly and resource hashes (`TestResults/ability-menu-build-proof.json`); game assembly SHA256 `E2711B30B3FB2DF2D49E804D14EF11D061F75657B14A2B0E1877B9E3274FD057`. Retained template/debug shader and development/package warnings remain; no C#, UXML or USS compilation errors were found.
- Matching menu acceptance: **10 phases passed**, two/four players, 75ms delay per endpoint / 15ms jitter / 1% loss (`TestResults/main-menu-d71c105c9c3841f6855e2a0f8332443a/result.json`). Includes real library inspect/equip/discard/recipe/Apply, exact host acknowledgement, inspection preserving ready, invalid/unready start rejection, synchronized locked builds, four kit effects, host-loss cleanup/recovery and a second run. Cleanup errors: none.
- The acceptance harness preserves existing standalone loadout preferences. Binary bytes and string values/types were restored after an intentional invalid-executable launch failure and successful online acceptance (`TestResults/ability-menu-preference-restore.json`). Test sentinels were removed afterward; other preference keys were untouched.
- Matching full-stage reward/travel acceptance: **23 phases passed**, two/four players at the same 75/15/1 simulation (`TestResults/encounter-polish-7d36e19129d5422087827c2736c468f6/result.json`). Both groups complete two stages with 82 unique team kills per run, locked offers, exactly-once category awards, duplicate category rejection, receipt acknowledgement, preserved inventory/build/scaling during travel, defeat/results delivery, menu return and fresh rehost. Unacknowledged receipts never report the entire team complete; TravelCountdown requires the aggregate equal connected participants; active stages and new runs reset the display to zero. Cleanup errors: none. Seven transient report reads were retried successfully by the existing harness.
- The build's tool request exceeded its 300 s timeout; the Editor continued and the final BuildReport confirmed success after 6m55s. Hashes stayed unchanged throughout acceptance. Deferred-only reward semantics have unit coverage; a dedicated deferred-only network run and disconnect during selection were not exercised. The disconnect denominator path was independently reviewed in source.
- Final Editor state: authored `Assets/_Project/Scenes/MainMenu.unity` open, outside Play Mode. No scene regeneration or authored scene changes were needed.

## Remaining human acceptance

Automated UI events are not physical keyboard/mouse playtesting. Human onboarding, readability, controller expectations, gameplay balance/feel, independently controlled four-player play and separate-network acceptance remain unverified in this batch. Permanent unlock progression remains a separate roadmap item.