CASINO -- BUILD PLAN

APPROVED TO BUILD -- Brandt ruled on all 19 decisions on 2026-09-12 via /game-decisions (Section 2). Nothing is built yet; Phase 2 starts first. Everything below was read from C:\Deflekt\Source\Deflekt\ on 2026-09-12 by a 20-agent audit (14 subsystem reads + 6 adversarial verifications of the claims the plan leans on, 1,280 file reads); every line cite is verified, not inferred, and the eleven cites the plan leans on hardest were re-read by hand before this was written. Where a claim came from the web (ratings, store policy, asset listings) it says so.

Headline numbers up front, because they set every design decision that follows:

• DEFLEKT has ONE map (Content\Maps\Arena.umap, 28 KB) and every world is spawned by C++ at runtime (DFKGameMode.cpp:33-39, DFKArenaDirector.cpp:180-229). The only map transition in the game is the exit to the title (DFKPlayerController.cpp:3831). The casino is built the same way.
• Zero skeletal animation code exists. No USkeletalMeshComponent, UAnimInstance, ACharacter or spring arm anywhere in 68 source files. Pilots are nine 2D portraits (DFKHUD.h:59, Content\Textures\T_DFK_Pilot1..9). The walking pilot and every NPC are greenfield.
• A rigged UE5 mannequin with idle/walk/run is already on disk AND in the shipped pak (Content\CastleofEternalMist\Demo\Characters\Mannequins, 405 MB, cooked because that pack is not on the never-cook list). It is a free prototyping body. It has no sit animation.
• Economy scale: a HARD campaign run pays ~+218 DANERRENS (real log), Invasion pays 45-88 capped at 300 (DFKGameState.cpp:736); the whole shop is ~18,900 (pilots 12,550 + skins 850 + GLASS 400 + specials 5,100). Every bet ladder below is denominated against those three numbers.
• The package is 9.88 GB for a $4.99 game, and ~7.7 GB of it is two packs the code never references (CastleofEternalMist 4.97 GB, STF LandscapePro 3.1 GB; Saved\Cooked\...\ReferencedSet.txt).
• Handheld gate: the Z1 Extreme auto-lands on MEDIUM (DFKGameState.cpp:309-330); the last perf sweep already sat at the 50 % render-scale floor on the planet. The casino has no measured headroom.
• Honest effort: ~83 working days across the 17 phases you asked for. The INVASION 2 sub-mode plan was 8-11. This is the biggest thing since launch and I want that said in the first screen.

0. THE SPEC, IN YOUR WORDS

Dated 2026-09-12. Verbatim where I have it; the flow bullets are your brief as I hold it.

• A new selectable mode on the Main Menu: CASINO.
• Flow: title -> CASINO -> existing pilot select -> existing aircraft select -> existing music select -> load a 3D neon casino district the player flies over.
• Casinos are original, fictional, themed on DEFLEKT lore. "DO NOT copy real casinos, recognizable buildings, trademarks, logos, names, architectural designs, or copyrighted/protected branding."
• Near a casino press Y -> menu with casino name/info -> ENTER CASINO / CANCEL.
• Cinematic dive transition; the ship must not just teleport.
• Interior: the player walks as their pilot character (third person) among NPCs who walk, sit at and leave ~30 slot machines of ~8 distinct types, each with its own visuals, theme, art, animations, SFX, UI and personality.
• Walk up -> prompt -> slot gameplay screen: reels, symbols, spin/win/loss animations, SFX, bet selection, currency display, feedback, exit, polished UI.
• Currency = Danarrens via the existing system. Loop: play -> earn -> gamble -> maybe win -> return.
• "There must be: No real-money gambling, No real-money wagering, No cash-out system, No connection between Danarrens and real-world money. Danarrens should remain fictional in-game currency."
• Reuse architecture, don't break existing modes, polished not prototype. "Do NOT start coding immediately." "If additional tools are needed, tell me exactly what they are for and why." "Before making major architectural changes, explain what you intend to change and why."
• Procurement: "when it is time, tell me what I need to buy by giving me links and I will buy the assets."

One spelling note: the code and every shipped screen spell the currency DANERRENS (DFKGameState.h:81, DFKHUD.cpp:984). This plan uses the code spelling; the casino will draw whatever the rest of the game draws.

1. THE SIX ANSWERS

1. What can be reused -- more than expected on the menu/flow side, almost nothing on the interior side. Section 4 is the table. Short form: the title row, the whole loadout screen, the PICK YOUR MUSIC overlay, the DANERRENS wallet and its save, the NOT-ENOUGH dialog, the loading-screen machinery, the ship + follow camera + thruster + engine audio for the flyover, the hangar-pad "near a thing, press Y" pattern, the killcam as the dive template, the staged multi-frame world builder, the PizzaBuildings sci-fi kit and neon glow-map material, the ISM/HISM factory, the pooled particle system and the bought explosion families for win VFX, the ElevenLabs SFX pipeline, the ui_matrix / perf / Doppel rigs, Sentry breadcrumbs.
2. What must be new -- Section 5. The mode identity and ~20 gates; a walking third-person pilot pawn and camera; a C++ animation driver (no AnimBP allowed); an NPC crowd with seat reservation and collision-aware walking; the slot engine (RNG, paytables, reel presentation, resolve-before-animate); a wallet API (there is none -- every credit is a raw +=); casino audio (the game has never played a sound at a location); the dive cinematic (no fade, no camera blend, no sequencer exists); 3D casino content of every kind (zero slot machines, casino props, neon signs, sit animations or pilot bodies exist anywhere on this machine).
3. Skills / systems required -- UE5 skeletal animation in pure C++ (UAnimSingleNodeInstance, then possibly an FAnimInstanceProxy graph), ACharacter movement + spring-arm camera, simple crowd steering on an aisle lattice, slot-machine mathematics (RTP, volatility, paytable derivation), Canvas UV-strip rendering for reels, spatialised audio with concurrency caps, editor-side IK retargeting of bought animations, and the house disciplines (1080p pixel-identical HUD gate, staged loads behind bLoadingActive, append-only enums/details, Mac path-case lint, save 3-site pattern).
4. Tools / assets -- Section 9 is the phase-gated shopping list with links. One new engine module dependency (animation runtime) is needed; no new plugins, no NavMesh/AIModule (a lattice walker keeps the "simple reactive AI" rule and avoids an approval-class install). Everything else is content.
5. Recommended plan -- Section 8, your 17 phases in your order, each with build / reuse / assets / code / dependencies / problems / tests, with day estimates. Phase 1 (audit) is this document.
6. Decisions before implementation -- Section 2. Nine of them. Two gate everything: the age-rating question and the art-direction fork. Neither is a code decision.

2. LOCKED DECISIONS -- Brandt, 2026-09-12, via https://deflekt.games.mayd-it.com/game-decisions

The reasoning that was put to him follows, kept as the record of why each option existed. Where a ruling went against my recommendation, what it costs the build is stated under it, once.

D1. Age rating and the Steamworks content survey (decide first, before any code). From web research this session, not the repo: Steam permits simulated gambling with fictional currency. PEGI rates any game containing simulated gambling 18 automatically since 2020, including in-game-currency slot machines, and it is not retroactive -- so the CASINO patch would be the moment DEFLEKT becomes PEGI 18 in PEGI territories. ESRB would add a "Simulated Gambling" descriptor (often Teen). Ratings are mandatory only in Germany and Indonesia; since 2024-11-15 Steam hides unrated games from German customers, and Valve derives the German rating from your Content Survey answers. The repo documents no rating step at all (Steam\STEAM_LAUNCH_RUNBOOK.md:18-21 lists only AI disclosure, OS and controller). Recommendation: open Steamworks -> your app -> Content Survey, read the gambling question, and decide whether a reel-based slot with a house edge is a trade you want for this title. If the answer is no, the honest alternative is a skill-flavoured "arcade" floor (timing-based machines, no reels, no house edge) -- a different game, and I would re-plan.

RULED GO. Reels and a house edge ship. The Steamworks Content Survey gambling question is still his to answer when the casino patch goes up (Phase 17 owner step); Valve derives the German rating from it, and the AI-disclosure paragraph is revised in the same sitting.

D2. Art direction: coherent low-poly (Synty) vs stylised-realistic (Fab), proven for $0 first. The only owned exterior kit is PizzaBuildings, which you rejected as a flown-over city on the planet (DFKPlanet.cpp:28-30). The only owned furniture is Elvish fantasy. The only owned humanoids are grey mannequins. A casino built from owned assets alone is three vendors in one room -- the exact failure Docs\INVASION2-ART-STRATEGY.md:56-63 warns about. Recommendation: one vendor for the whole casino. Synty POLYGON is the only vendor with a casino interior, a cyberpunk city and a character set in one consistent style, it is mobile-safe (no Nanite/Lumen dependency, cheap on the Z1), and it publishes a free Starter Pack. Phase 3 imports the free pack, applies the DEFLEKT glow-map recipe, and photographs it in the district before you spend a dollar (your rule: approve backgrounds before import). If you hate the look, we take the Fab route in Section 9 instead.

RULED, in three steps. GO Synty on the card; refused in chat on seeing the store page ("it doesn't look that good"); re-asked as d2-2-art-route -> SHOW ME FIRST; photographed (Phase 3 look test, one Tripo-made facade beside one kit-bashed facade in the district at the real flyover camera) -> A - OURS. The art direction is therefore MATCH THE GAME: the casino is made the way the fifteen arena dioramas and every boss were made, and it is coherent with them by construction. What that costs: roughly a week more of my time across the asset phases (one concept + one Tripo job + one glow-map import per piece, each photographed for his approval), and no vendor to blame. What it saves: two exterior packs and a casino interior pack that would have arrived as grey shells for code to dress, three vendors in one room, and the Nanite/Lumen/4K screening every realistic pack has failed so far.

D3. Mode identity: append EDFKMode::Casino or run as Solo + a flag (tutorial pattern). The enum is append-only because its ordinal is frozen into Steam leaderboard Details[6] (DFKGameState.h:13; writer DFKLeaderboardSubsystem.cpp:167, reader :496). Appending is serialization-safe -- BUT the verification found ~18 negative-check consumers that treat "not Versus, not Invasion" as CAMPAIGN (run-end DANERRENS DFKGameState.cpp:729-768, campaign boards DFKLeaderboardSubsystem.cpp:272-285, BestScore folds :649/:1169/:1356, volcanoes DFKVolcanoSystem.cpp:225, tornado palette DFKTornado.cpp:98), ~6 Solo-only ternaries that flip to the 2-player path (DFKPlayerController.cpp:1971, 2671, 3153-3155, 3194; DFKHUD.cpp:1892, 2944) so a solo CASINO could never launch, and the title->mode cast is clamped 0..3 (DFKPlayerController.cpp:1783) so a new ordinal is unreachable anyway. The shipped TUTORIAL is the precedent for a side mode: it runs as Solo with bTutorialActive and inherits every "no boards / no meta / no waves" guard by one flag at five sites (DFKArenaDirector.cpp:2762, DFKLeaderboardSubsystem.cpp:137, DFKGameState.cpp:728/773/787). Docs\INVASION2-MODES-PLAN.md:163 already states the law "do not add EDFKMode enumerators". Recommendation: Solo + bCasinoActive + a transient ECasinoPhase {District, Dive, Interior, AtMachine}, exposed as IsCasino() beside IsWild() (DFKGameState.h:668). Casino posts to no leaderboard and has no death bucket, so the enum buys nothing in v1. Recorded as an ADR in Phase 2.

RULED B -- a new enumerator. His call; the build follows it. What B costs, stated once: Casino is appended after Invasion (ordinal 4, DFKGameState.h:13); the title id 14 branch sets Mode = Casino explicitly and the 0..3 clamp at DFKPlayerController.cpp:1783 is never widened; every one of the ~18 negative-check consumers and ~6 Solo ternaries listed above gets an explicit Casino case in Phase 2 (the checklist is the grep for EDFKMode::, 130 hits in 14 files) instead of inheriting the tutorial's guards; the INVASION2-MODES-PLAN law "do not add EDFKMode enumerators" is superseded by this ruling and the ADR records that; leaderboard readers already degrade an ordinal-4 row to absence (ModeTag default at DFKHUD.cpp:641-651, the website's mode filter), so a month-behind Mac client hides rather than mislabels. What B buys: the crash breadcrumb logs the true mode for free, IsCasino() is a one-line Mode == EDFKMode::Casino, and a casino leaderboard or death bucket is possible later without a second migration. Phase 2 grows from 4 to 5 days.

D4. Single-player only. Nothing in the brief has a second pilot in the casino. Solo+flag makes this free: the P2 join branch on the music picker (DFKPlayerController.cpp:1971) and the loadout ghost seat never fire. Recommendation: yes, solo. Add an explicit !bSplitScreenActive guard so co-op can never reach the casino by accident.

D5. Wallet model and your 2026-08-02 "every spend asks first" law (DFKGameState.h:420-423, StageBuyConfirm defaults to NO at DFKPlayerController.cpp:3616-3627). A YES/NO modal on every pull is unplayable; ignoring the law breaks a rule you set. Recommendation: direct DANERRENS as you asked, with one confirm when you sit down ("PLAY THE GOLDEN MANTA? Bets 5-50 DANERRENS. The house keeps 8 %.") and none per spin; the SPIN press is the explicit act. Raising the bet above 25 asks once more. The existing NOT-ENOUGH dialog fires whenever bet > balance (StageBuyDenied, DFKPlayerController.cpp:3604-3614). Alternative kept alive: a per-visit CHIP wallet bought once at a cashier (the Invasion Credits[] precedent, DFKGameState.h:225) -- one confirm, one debit, one credit per visit, and the house edge never touches the pilot fund mid-session.

D6. Casino wins must NOT raise LifetimeDanerrens / Mastery Rank. Every existing earn site increments both (DFKGameState.cpp:739-740, 762-763, 777-778, 1288-1289); LifetimeDanerrens drives the RANK badge on the title (:801-811, DFKHUD.cpp:1990). A gambled LEGEND badge devalues the one career stat the game has. Recommendation: wallet-only. The new CreditDanerrens helper makes this the deliberate exception.

D7. The pilot body. You asked to "walk as your pilot character". Pilots have no 3D form; the Tripo/fal pipeline has only ever produced static meshes; nine bespoke rigged, canon-accurate humanoids are weeks of an asset pipeline this project does not have. Recommendation for v1: one body in the chosen art style, tinted PilotColor(i) (DFKGameState.cpp:898-909), helmet/visor, name tag from PilotName(i), and the portrait on the HUD chip. Nine bespoke bodies go to the V2 backlog. What walks when SelectedPilot == 0 (NO PILOT, DFKGameState.cpp:103) needs your call: force a real pick at the loadout, or an anonymous body.

D8. Sitting. No sit/stand animation exists anywhere; buying one and retargeting it is a phase of work by itself (Section 9, Phase 8). Recommendation: buy it -- but read WHAT I WOULD CUT first, because stand-up cabinets make the whole seated pipeline disappear.

D9. Package ceiling. The casino needs room. Recommendation: never-cook STF (zero references) and CastleofEternalMist except its SkySphere (the one mesh the planet uses, DFKPlanet.cpp:1942), and re-home the mannequins under /Game/Casino/ first. That is a cook + verify + a near-full depot re-upload (Steam\app_build_deflekt.vdf depot replaces recursively). Your call whether to pay that in Phase 2 or stack the casino on 9.88 GB.

RULED STACK. The package is left alone and the casino is added on top. The mannequins therefore stay under the vendor Demo folder; the casino references them by literal path from its single owner file and cook.ps1 gets a $PathLoadedAssets row for them, so any future trim of that pack fails the cook loudly instead of silently deleting the casino's bodies. Every casino asset decision still states its cooked cost.

Smaller rulings the build needs, defaults in brackets: title row gets a 6th pill [yes; logged in INTENTIONAL_1080P_DELTAS.md]; CASINO carries a NEW badge and INVASION 2 keeps IN BETA TEST [badge table generalised]; music = the player's chosen set rotating one level track per casino entered [yes; no new soundtrack]; DIFFICULTY stop on the loadout [hidden in casino]; a minimum reserve below which you cannot bet [none -- losing is the point -- but the first-entry card states the house edge]; pilot law in the casino [campaign ownership, not WILD skins].

3. LOCKED BY THE CODE

Not opinions. Each is a line that bites if ignored.

• Pure C++. The vendor mannequins ship with Blueprint AnimBPs (ABP_Manny, ABP_Quinn) and a BP_ThirdPersonCharacter; none may be referenced. Animation is USkeletalMeshComponent::PlayAnimation + UAnimSingleNodeInstance::SetBlendSpacePosition (engine API, SkeletalMeshComponent.h:1258, AnimSingleNodeInstance.h:63) or a C++ UAnimInstance subclass.
• GS->Planet stays nullptr. It is THE switch for spherical clamps, planet camera and radar (DFKGameState.h:552-556, DFKPawn.cpp:1340, DFKPlayerController.cpp:475). Never overload InvasionMapIndex: IsWild() is == 1 (DFKGameState.h:668).
• Every heavy build goes behind bLoadingActive with a >1 frame delay, one stage per frame, cleared the frame the build ends (DFKArenaDirector.cpp:3011-3087), or the Steam overlay hangs it forever (C:\Deflekt\CLAUDE.md, overlay section). -NOSTEAM rigs cannot see this class of bug.
• Y is already three things: DEFLEKT BEAM in flight (DefaultInput.ini:98 -> DFKPawn.cpp:1857), the Invasion hangar shop toggle (DFKPawn.cpp:2096-2102), and INVITE A FRIEND on the 2P loadout (DFKPlayerController.cpp:2571-2576). Legacy input fires every action bound to a key (the E = Overdrive + Revive precedent, DefaultInput.ini:97,99), so the casino ENTER must be a mode-gated branch inside OnOverdrivePressed (the hangar pattern), never a second mapping on the same button.
• The main camera block rewrites ArenaCam every frame it is active (DFKPlayerController.cpp:1205-1306); the dive and the interior camera need a yield flag exactly like bKillcamActive (:480, :1205, DFKGameState.cpp:1226). No StartCameraFade, no SetViewTargetWithBlend, no sequencer, no UMG exist (Deflekt.Build.cs:9-29): fade = a full-screen DrawBar (DFKHUD.cpp:292), blend = VInterpTo.
• HUD: one UIs = Clamp(ClipY/1080, 1, 2.25); 1920x1080 pixel-identical on every existing screen; never size from ClipX; pulse amp <= base; new screens are early-return blocks sited with the others and drawn before the live-combat tail at DFKHUD.cpp:3980, which otherwise draws SCORE/LIVES over the casino. The "modal dialog" is not a primitive: it is hand-copied three times (DFKHUD.cpp:392-417, 442-472, 475-499) with a fourth hand-rolled at :3507-3511.
• Wallet: there is no credit/debit function. Four credits are raw += pairs, four debits live in one purchase switch (DFKPlayerController.cpp:3655/3666/3678/3690) that re-derives price from static tables -- no path for a variable stake. SaveBest is the only legal writer and rebuilds the whole file synchronously (DFKGameState.cpp:645-700). Every new saved field is four edits in three files plus the two-site SaveVersion literal (DFKSaveGame.h:79, DFKGameState.cpp:697) -- miss the load site and the first-frame SaveBest wipes it (:142, :221-225).
• Casino must never reach AwardMetaOnRunEnd/EvaluateChallenges (or FIRST BLOOD pays out on leaving), SubmitRun (or it posts to HighScore_Solo/Daily_* -- add a return beside the tutorial's at DFKLeaderboardSubsystem.cpp:137), or write GS->Score (or the BestScore fold clobbers the campaign record on the first music-style change, DFKGameState.cpp:649).
• Pack hygiene: /Game is blanket-cooked (DefaultGame.ini:13); every new pack's Demo/Maps/Blueprints folders get never-cook lines; every /Game/... literal lives in one owner file (DFKPlanetFx.h:19-27 pattern), matches on-disk CASE for the Mac, and gets a cook.ps1 $PathLoadedAssets row (Tools\cook.ps1:47-65). Printf-built paths escape both guards (mac_lint.ps1:108).
• Handheld: no per-frame GetAllActorsOfClass (42 sites already), instanced meshes for repeats, emissive not lights (GDFKMaxBoltLights, DFKBolt.cpp:115), textures <= 2K, no volumes indoors, caps verified by dfk.PerfLog soak on the handheld -- perf_planet.ps1 -Preset has never worked.

4. WHAT IS REUSED

5. WHAT MUST BE NEW

• Mode wiring: EDFKMode::Casino appended (ruling D3 = B), ECasinoPhase, IsCasino(), title id 14 (13 is the retired HANGAR id, DFKPlayerController.cpp:1763-1764), the 6th pill with count-derived centring, the pawn's literal ModeWalk unified onto TitleModeOrder (a live desync today: DFKPawn.cpp:808 walks {0,1,2,3,12} while the row draws {12,0,1,2,3}), dfk.StartMode 5, and the flag added to every hand-written gate list: cursor DFKPlayerController.cpp:1036-1041, crosshair DFKHUD.cpp:514-519, pawn early-returns DFKPawn.cpp:754-909, thruster DFKPawn.cpp:2195-2214, engine audio DFKPlayerController.cpp:1566-1573, agent feed DFKArenaDirector.cpp:2031-2034, render-scale freeze DFKGameState.cpp:562-568.
• Director gate: an early if (IsCasino()) { CasinoTick(); return; } before the phase machine at DFKArenaDirector.cpp:3183, keeping TickRenderScale/TickCrashBreadcrumb alive (:3002-3003); hazard gates in DFKVolcanoSystem.cpp:225, DFKStormSystem.cpp:248/379, DFKTornado.cpp:98; teardown of the boot-time campaign dressing the way BuildInvasionMap does (:634-656, plus the turret pillars it forgets).
• ADFKCasinoDirector (or a gated director section): owns the district table, the six casino entrances, the interior machine registry TArray<FDFKSlotMachine>{Pos, Yaw, SeatPos, ThemeIdx, ReservedBy}, the patron registry and cap, spawn cadence, the dive state machine, and teardown on exit (the HangarActors self-heal idiom, DFKArenaDirector.cpp:2710-2715).
• ADFKPilotPawn : ACharacter -- capsule, UCharacterMovementComponent, USpringArmComponent + UCameraComponent carrying the neon post-process block copied from CreateArenaCam (DFKPlayerController.cpp:591-610), its own input bindings (walk axes, camera axes, INTERACT), a skeletal body, and a C++ locomotion driver. Possessed under black; the ship pawn parked and hidden. 71 Cast<ADFKPawn> sites null-skip (HUD 19, controller 14, director 15, boss 7, pawn 5, planet 4, storm 3, state 2, bolt 1, pickup 1) and each unguarded one must be audited before the swap ships.
• ADFKCasinoPatron -- APawn + skeletal mesh + hand-integrated movement on an aisle lattice (BFS over <= 200 nodes at request time), reactive separation, FSM {Wander, GoToSeat, Seated, Leave}, seat reserve/release, dwell timers, spawn/despawn at doors with a neon puff, MaxPatrons constexpr starting at 24. No NavMesh, no AIModule (approval-class install, and against the "simple reactive AI" rule).
• Animation runtime: Tier A first -- PlayAnimation(BlendSpace) + SetBlendSpacePosition(speed), hard cuts between idle/walk/sit. Tier B only if the cuts read badly -- a UAnimInstance subclass with FAnimInstanceProxy::Evaluate blending two poses (AnimationRuntime.h:301). Adds AnimGraphRuntime to Deflekt.Build.cs. Montages are out (they need a Slot node an AnimBP provides).
• Slot engine: FDFKSlotTheme table (name, symbol strip texture, weights per reel, paytable, RTP target, max multiplier, volatility), an outcome resolver that decides the result before any reel moves, FDFKSpinState on GameState (per-reel offset/velocity/target/stop time, win lines, payout) that the HUD derives visuals from by elapsed time, and a [DFK][CASINO] spin machine=%d bet=%d win=%d balance=%d log line per resolved spin.
• Wallet API: bool ADFKGameState::TryDebitDanerrens(int32, const TCHAR* Reason) (atomic, rejects rather than clamps) and void CreditDanerrens(int32, const TCHAR* Reason) (Danerrens only, saturating). Refactor the eight existing raw sites through them (behaviour-preserving). Save v5 fields: CasinoSpins, CasinoWagered, CasinoWon, CasinoBiggestWin, CasinoJackpots, CasinoSpinsByMachine[], bCasinoBriefSeen.
• HUD: extracted DrawModal(x,y,w,h,accent) and DrawTwoChoice(title, body, A, B, sel, menu) (re-pointing the three existing copies, byte-identical at 1080p), a Tween/ease helper, DrawSprite (UV strip), bDisabled on DrawPlate3D with a byte-identical default, a pre-rasterised digit strip for JACKPOT numerals (the bitmap font is soft above 2.6x, DFKHUD.cpp:160-162), and four new early-return blocks: district HUD, ENTER/CANCEL prompt, interior HUD, slot screen. New EDFKUiMenu values appended after HangarBay with hover/click cases (DFKPlayerController.cpp:2958, 3016).
• Reel presentation: the seated player's reels are a Canvas UV-scrolled strip (1-3 tile items per reel, no clipping primitive needed -- there is none in the HUD); cabinets on the floor show a scrolling screen material (a Panner offset on a MID, the M_DFK_Beam precedent) for attract mode.
• Audio: a C++ casino sound table loaded lazily at casino BeginPlay (the LoadMus pattern, not the CDO enum which would grow by ~48 families); SfxAt(World, Event, Location) with a C++-built FSoundAttenuationSettings and a USoundConcurrency cap; a crowd bed component on the controller; footsteps for the nearest 3-4 NPCs only; a duck factor in the crossfade for jackpots.
• Dive: ECasinoPhase::Dive state machine ticked on FApp::GetDeltaTime (approach -> fade -> swap -> reveal, ~2.5 s), registered as a clock owner in RefreshBulletTime, ArenaCam VInterpTo toward the casino door, FadeAlpha drawn first in DrawHUD, teleport + possess + SetViewTarget under full black, and the reverse on exit. A flat-camera snap (reset CamCurrentBase) mirroring SnapPlanetCam.
• Content that exists nowhere on this machine: slot cabinets (8 themes), reel symbol art (~64 symbols), casino furniture and props in the chosen style, neon marquee signage, casino facades, a district ground/plaza kit, sit/stand animations, pilot/NPC bodies, casino SFX. See Section 9.

6. THE RULES, WITH NUMBERS

Bet ladder: 5 / 10 / 25 / 50. Max bet 50 = a quarter of one HARD run. Raising past 25 asks once (D5).

Top prize <= 100x = 5,000 DANERRENS at a probability that keeps its expected contribution under 2 % of RTP. That is ~25 runs of income -- a great night, not the catalogue. A 500x jackpot on a 100 bet would pay 50,000 and buy every pilot; that is the number the ladder exists to prevent.

RTP 90-95 % by machine, ~92 % overall. The casino is a net sink on average, which is what keeps the shop's pacing (~85-95 runs to buy everything) intact. Whether a player can gamble a 3,000 pilot fund to zero is D2's reserve question; I recommend yes, stated plainly on the first-entry card.

Eight machine types, a volatility ladder, all DEFLEKT lore, no real-slot iconography (no 7s, bars, cherries, bells):

Paytables are derived, not guessed: for each machine, symbol weights per reel are chosen, the hit frequency of every line is computed, and the multipliers are solved so the sum of (probability x multiplier) lands on the target RTP. The derivation is written into Docs\CASINO-ECONOMY.md in Phase 9, and dfk.CasinoAutoSpin 100000 on a scratch save proves each machine's measured RTP within +-0.5 % before it ships. Numbers in the table are targets until that harness runs.

Persistence cadence: one SaveBest() per resolved spin, after debit + credit + stats are applied together (a crash between them would eat a bet or grant a free spin). The game already saves on every volume tick, so one write per spin is within tolerance; per-reel is not.

Six casinos in the district, all fictional, all ours: THE GOLDEN MANTA, SLIPGATE PALACE, THE DEFLECTOR ROOM, HOLLY JO'S, GRID CITY GRAND, THE ANTIPODE CLUB. v1 opens one interior (the others are facades with a "COMING SOON" marquee and no ENTER); each later casino is a re-skin of the interior with a different machine mix. Names are suggestions; they are strings.

District scale: flat play box +-12,000 uu (twice the arena), casinos 6-8 s apart at cruise 1,550 uu/s, fixed-bearing -70 follow cam (your 2026-08-07 verdict against a chase cam stands, DFKPlayerController.cpp:94-103), casino footprints registered as solid blockers so the ship flies around them (DFKPawn.cpp:1427-1442 pattern). Interior built at world offset X = +400,000, resident and dormant from mode start so the dive is a pure camera move.

6b. WHAT MAKES IT WORTH SITTING DOWN -- the design verdict, 2026-09-13

Brandt, 2026-09-13: "when you sit down on the machine it will then just show the slot game. So it is ok that it is not perfect here but we will need to think about how we can make our slot machines addicting and fun. For example you can get bonuses and jackpots and all sorts of stuff."

Two consequences. First, the 3D cabinets are set dressing from here: the screen is the product, and cabinet polish stops (Phase 5 is closed at its current look). Second, the question above got a real design pass rather than my opinion -- five independent designers and three scoring lenses, briefed with every locked number in Section 6 and the hard no-real-money rules. This section is what they agreed on and what is left for Brandt to rule.

THE PROBLEM THEY WERE POINTED AT

The stake here is soft. DANERRENS are earned by playing arena runs (~200 a HARD run), the house keeps 8 %, so spinning is a -8 % trade against an income the player controls. A rational player concludes that flying beats spinning and never comes back. Bonuses and jackpots are the right instinct but they do not answer it on their own: a bigger pile of a currency you can always earn is not a prize.

THE THREE ANSWERS, WHICH COMPOSE

1. The house must pay in things the shop cannot sell. This is the Borderlands move: its slot machines paid out GUNS, not money. A 5,000 DANERREN top prize is inert for exactly the player most likely to hit it -- the one who has already bought out the shop. Casino-exclusive liveries, cabinet colourways, a lobby plaque with your pilot's name, the other five casinos opening: none of these touch RTP, because they are awarded on events rather than payouts. The player's FELT return climbs well above 100 % while the monetary return stays exactly 92 %. That is the structural trick and it is free.

2. A meter that only goes up while the money goes down. Four of the five designers invented this independently, under four names, which is the strongest signal in the whole exercise. A bar that fills one notch per spin REGARDLESS OF BET, is saved forever, and guarantees that machine's feature when it fills. It makes a losing session visibly productive, it makes thirty cabinets mean something instead of being one cabinet thirty times, it is the honest version of what a bonus-buy button promises (the feature is paid for in time, not currency, so a bigger bet can never rush it), and it is the reason Phase 6's walking pilot exists at all -- you walk the floor to pick the chair that is nearly full.

3. DEFLEKT's one button, inside the reels. The single most on-brand idea produced, and the thing a player would describe to someone else. A timed deflect on the reel screen, the same window and the same press the game spent forty hours teaching. Whether it is allowed to CHANGE a payout is a ruling (below); if it is not, it still belongs as an EV-neutral double-or-nothing after a win.

THE HOUSE RULES -- what this mode will never ship

Unanimous across all three judging lenses. These go in Docs\CASINO-ECONOMY.md and an ADR with their reasons, not in a code comment, because the failure mode is a future "juice it up" pass quietly adding one.

• No bonus buy, feature ante, or paid skip to a feature, in any dress -- including "fill the meter for currency". Every mechanic here exists to build tension toward a feature; a button that skips to it deletes the base game, and players press it exclusively.
• No player-facing auto-spin or turbo that removes the player from the anticipation window. dfk.CasinoAutoSpin stays a dev cvar behind #if !UE_BUILD_SHIPPING and never gets a UI. A slam-the-reels QUICK STOP covers the real impatience.
• No engineered near-misses and no virtual-reel weighting -- strips arranged to over-produce almost-wins, or a top symbol flown past a line it was never live on. It makes every derived paytable a lie. The honest fix for a machine that tests flat is a higher base hit rate.
• No hidden pity timers and no rubber-banding toward a payout. The disclosed meter does the same job in the open with its threshold printed on the cabinet, which is strictly better design.
• No real-clock dailies, streaks, login timers or energy. A $4.99 premium single-player game has no metric to feed and no server to enforce it; setting the clock defeats it in a second. Tie refreshes to ENTERING the casino or to completed arena runs instead -- both un-cheatable, both point back at the game.
• No second currency that DANERRENS can buy, no cashier, no chip bundles, and nothing shaped like a loot box even when nothing is purchasable. This mode will be screenshotted by people hunting for gambling mechanics in a cheap game, and the SHAPE of the UI is what gets photographed.
• No casino result on any Steam leaderboard, and no route to LifetimeDanerrens or Mastery Rank. D6 holds and is not reopened to buy engagement.
• No regret displays -- "you would have won 2,000 at bet 50", post-spin what-ifs. Regret farming, and unpleasant to read.
• No casino MusicSet in v1. 0.5-1 GB on a 9.88 GB package for a mode that has not yet proven anyone sits down twice. The ruled behaviour (keep the player's chosen set) stands.

BUILDABILITY -- the three calls that are day-one or never

From the cost lens, which read the repo. Each is cheap now and a rewrite later touching the resolver, the HUD, the input handler, the harness and the save at once.

1. FDFKSessionState as an argument to ResolveSpin, with bNextSpinFree, StripSet and the multiplier stack present even while all three are inert. A stateless ResolveSpin(Machine, Bet) makes free spins, respins, sticky wilds and hold-and-spin each a special case welded into the call site.
2. Physical reel strips as the authority (uint8 Strip[5][64]), with per-reel independent stop control and more than one strip SET per theme -- not weight vectors. Weights round when they expand, and without a per-reel lock mask you cannot hold a reel, which kills every respin feature.
3. Every paytable entry authored as a whole number of DANERRENS at bet 5, so Pay = PayAt5 * (Bet/5) with 5/10/25/50 dividing to 1/2/5/10. The entire pay path is exact integers with zero rounding, and RTP is provably identical at every bet -- a real fairness property, and free.

Also flagged, and it corrects this plan: the Phase 9 verification gate of 100,000 spins at +-0.5 % is statistically wrong. That tolerance is several times tighter than the sampling error at that N, so it will fail CORRECT high-volatility tables and invite a tuning pass that corrupts them. Replace with an offline exact solver that generates the table header (the gen_asm_header.py / DFKAssemblies.table.h precedent), plus a fixed-seed 10,000,000-spin harness gated on exact equality against the solver's number, a chi-square on the stop histogram, and four asserted invariants: balance never negative, LifetimeDanerrens unchanged, GS->Score never written, no win above the cap.

Two things that sound like variety and are a second renderer: any grid that is not 5x3, and cascading/tumbling reels -- cascades destroy the closed-form RTP solve permanently and tax every machine the project ever adds. Volatility comes from strips and paytables. The grid stays 5x3 forever.

RULED -- Brandt, 2026-09-13 21:34-21:38Z

Three NOs pointing the same way, and read together they are not three rejections but one instruction: the fun comes from inside the spin, or it does not come. He asked for "bonuses and jackpots"; the panel answered with meta-progression, a walk-away currency and a skill minigame -- scaffolding AROUND the machine rather than a better machine. He does not want scaffolding. That is a coherent position and it is the simpler one, so the design above narrows to what survives it.

WHAT SURVIVES, and now carries the whole mode. The highest-scoring design of the five (24/30, the anticipation-and-pacing one) is also the only one untouched by these rulings, because all of it lives inside the machine:

• The second acts. Bonus rounds are no longer one of three answers, they are THE answer, and he named them himself. Free spins with modifiers, hold-and-spin, respins, multiplier ladders, pick bonuses -- each machine's one signature verb, dressed in DEFLEKT lore.
• The 1.85 seconds between the press and the last stop. The anticipatory dip, 300 ms staggered stops with overshoot-and-settle, rising-semitone stop SFX, the AGONY STOP with its sustained rumble. Roughly a third of Phase 9 and it IS the product; everything else decorates it.
• The celebration ladder with the T0 rule -- wins under 1x bet get no ceremony at all, shown grey with the net beside them. Costs nothing to build (it is a branch that does LESS) and it is what makes every real win mean something.
• The volatility ladder across the eight machines, already in Section 6.
• Jackpots, which he asked for by name: a fixed top tier hit on the reels, inside the 100x / 5,000 cap. Not a progressive -- a pot only one player feeds is a savings account charged 8 % to use, and it makes RTP time-varying so 92 % stops being a provable statement about a spin.

WHAT THE RULINGS COST, stated once and not re-argued. Nothing now distinguishes one cabinet from another of the same type, so the thirty-machine floor is atmosphere and the machine TYPE is the entire unit of content -- which raises the bar on the eight being genuinely different games rather than eight skins. And a losing session now produces nothing at all except the session itself. That makes hit frequency load-bearing: the base game has to pay something often enough that losing still feels like playing. Hit frequency therefore becomes a SECOND TARGET on the paytable solver alongside RTP (roughly 42 % down to 12 % across the ladder), not a number that falls out of it. That is the single most important consequence of these three NOs and it goes into the solver from day one.

WHAT THE RULINGS BUY. They cut real scope and real risk. No reward plumbing reaching into the shop or INVASION 2 (F1). No skill input path through the resolver, and the solver targets one distribution instead of two (F2). No new save fields for meters, so save v5 stays exactly as Phase 11 already plans it and the hard deadline in F3 is gone (F3). Phase 10 shrinks to eight themes, eight strip sets, eight paytables and eight second acts.

F4 APPROVED, so the never-ship list above is law: it is written into Docs\CASINO-ECONOMY.md and Docs\ADR\0002-casino-house-rules.md with its reasons, where it outlives anyone forgetting.

WHAT WAS ASKED -- the four cards, kept as the record of why each option existed

Deliberately NOT reopened: the walking interior (Phases 6 and 8). The contrarian designer argued hard for cutting it to a flyover kiosk on cost -- roughly 16 days plus a greenfield skeletal-animation and crowd pipeline in a codebase with zero skeletal meshes. Brandt's brief has always had him walking as his pilot among patrons, and 2026-09-13's message ("when you sit down on the machine") assumes it. It stays. Recorded here so the argument is not re-made.

7. THE BUILD

Seventeen phases, your names, your order. Each ends in a Photograph or a VERIFY line naming the rig. Effort is my honest estimate in working days assuming the usual build-cook-verify loop and not counting asset lead time or your feel passes. Every phase carries STATUS: PLANNED.

Phase 1 -- Project audit (0 days remaining)

This document. The 20 per-area reports are on disk at ...\scratchpad\casino_audit\*.md (14 audits, 6 verifications) if you want the long form.

STATUS: DONE (2026-09-12)

Phase 2 -- Architecture (5 days) -- ships alone as a no-visible-change patch

STATUS: BUILT 2026-09-12 (b90bd42 on casino/phase-2-architecture) -- the evening the rulings landed. Verified: Development build clean, mac_lint 12/12, 37 matrix captures reviewed by eye (six-pill title at 720p/1080p/4K with both badges; one-seat casino loadout, no DIFFICULTY, pill reads ENTER; picker verb ENTER THE CASINO; casino in-game frame carries the corner logo only), ui_diff musicpick 1080p GATE HELD against the 2026-09-09 baseline, INVASION 2 planet still builds headlessly. Two extra casino gates the first capture demanded (the controls primer and the five-second how-to band, both about bolts and turrets) and one pre-existing 720p title defect (option column sized for the retired ninth row) were fixed on the way. Not yet cooked or merged: the branch merges to main with Phase 3, when there is something a player can see.

• Builds: EDFKMode::Casino appended after Invasion (ruling D3 = B), ECasinoPhase and IsCasino() on ADFKGameState; title id 14 with the INVASION 2-style branch in StartSelectedMode setting Mode = Casino (the 0..3 clamp is never widened); TitleModeCount 6 and count-derived centring at DFKHUD.cpp:2035, 2066; the pawn's ModeWalk literal replaced by TitleModeOrder (fixes the live stick-walk desync); badge generalised to an {id, text} table; dfk.StartMode 5; the mode added to every gate list in Section 5; an explicit Casino case at every negative-check consumer and Solo ternary named under D3 -- run-end economy (DFKGameState.cpp:729/773/787/996), boards (DFKLeaderboardSubsystem.cpp:136), the three BestScore folds (:649/:1169/:1356), the director's phase machine (DFKArenaDirector.cpp:2762), hazards (DFKVolcanoSystem.cpp:225, DFKStormSystem.cpp:248/379, DFKTornado.cpp:98), and the Solo-family ternaries (DFKPlayerController.cpp:1971/2558/2671/3153/3194, DFKHUD.cpp:1892/2944) -- most of them through one new helper, IsSoloFamily(); loading screen parameterised (LoadingTitle/Subtitle/Hint on GS); the music-picker gate widened and its START verb made mode-aware; TryDebitDanerrens/CreditDanerrens with the eight raw sites refactored through them; the director's TickCasino (loading gate + empty arena); dfk.TestMenu 6, dfk.ForceShipSelect 4; ADR at Docs\ADR\0001-casino-mode-identity.md. The HUD primitive extractions (DrawModal, DrawTwoChoice, Tween, DrawSprite, bDisabled) moved to the phases that first need them (7, 9, 12) -- each lands under the 1080p gate when it is used, not speculatively.
• Door closed in Shipping: TitleModeCount is 6 in Development builds and 5 in Shipping until the district exists, so the shipped title screen is byte-identical and players cannot reach an empty mode.
• Reuses: everything in Section 4 rows 1-6.
• Assets: none.
• Depends on: D3, D4, D9.
• Problems: the 6th pill changes 1080p pixels on title -- logged in INTENTIONAL_1080P_DELTAS.md; every shared-lambda change must be byte-identical by default; Doppel's menu_to_game.json assumes a title order that Patch 33 already broke -- fix it here.
• Tests: ui_matrix.ps1 full run, ui_diff GATE HELD on every existing 1080p screen except title; mac_lint.ps1 clean; freshinstall_check.ps1; a solo SOLO/CO-OP/VERSUS/INVASION/INVASION 2 smoke launch each (nothing else may change).
• Photograph: the title with six pills at 720p and 32:9 contact sheets; CASINO selected shows its description and the loadout opens.

Phase 3 -- Casino world: the district (5 days)

STATUS: BUILT 2026-09-12 (29fff44); photographed; RULED CHANGE 2026-09-13 00:14Z. His note, verbatim: "I think it's okay but the building should be way bigger and the road may be a little bit smaller and actually look like a road where you can land on. I don't know what all the other little buildings are next to the big buildings, but maybe we look at those and see if we can make them look better. I don't know, but let's first focus on adding all the buildings in the spots and making them bigger because the one you have looks fine as you can enter it in a certain way. Maybe you have a landing pad or something like that?" Read as four orders, in his priority: (1) all six facades on their lots (he picked A for every casino, cards f-*, 00:11-00:12Z) and WAY bigger (frontage 2600 -> 5200, lots moved out to Y +/-6000); (2) the road narrower (kerbs +/-3300 -> +/-2200) and a real road surface with a centre line; (3) a landing pad at every door (the plaza disc becomes a pad: ring + centre mark, lit gold when open); (4) the fill blocks read as unexplained clutter -- second pass, after the buildings; first pass here makes them a regular lattice of city blocks beyond the lots instead of scattered props. The first version's record: a new ADFKCasinoDistrict actor (the planet's shape: spawned by TickCasino behind the loading gate, BuildStep(0..2) one stage per frame -- DIMMING THE CITY 1 ms, RAISING THE SKYLINE 93 ms, PAVING THE STRIP 16 ms -- GS->CasinoDistrict is the one switch) owning the night pass, a +/-90000 dark ground, 7 tower ISMs (two rectangular rings just past the +/-12000 box plus ~320 low fill blocks the ship flies over), the boulevard kerbs and cross streets, six lots (the manta's facade on lot 0; dim tinted footprints + outline + gold plaza disc on the rest) and the blackboard it publishes: GS->CasinoLots (FDFKCasinoLot: Pos, Yaw, Frontage, Enter/ExitRadius, Door, Name, bOpen -- the ONE copy of a casino's identity) and GS->CasinoBlockers. GS->ArenaHalfX/Y = CasinoHalfExtent (12000) on the spawn frame; the pawn clamp reads runtime extents through UsesRuntimeExtents() (Invasion or Casino) and pushes out of CasinoBlockers through the same lambda as the cones; the casino is admitted to the follow camera (bFollow); the pawn publishes NearCasino (enter/exit hysteresis) and NearestCasino; the HUD draws the balance chip (the UPGRADES pill) and the name tag under the ship (COMING SOON for closed lots) as a sibling block after the combat tail. Dev lever dfk.GotoCasino N. The facade moved to /Game/Casino/Facades/SM_CasinoFacade_Manta (production, cooked); MeshImport/import_casino_facade.py takes DFK_FACADE_GLB / DFK_FACADE_NAME from the environment. Photographs: Docs/casino-look/district_p3_spawn.png, district_p3_manta.png. The look test below is the record of how the art ruling was reached; its code is gone (commit history keeps it). Ruling d2-2 = SHOW ME FIRST. Two gates, not one: the district skeleton is MODE-gated (every casino entry builds it; it compiles into Shipping, where the closed title door keeps it unreachable -- and StartSelectedMode now refuses id 14 outright when the door is closed, so the ini-settable dev launch levers cannot open it either); only the two candidate lots are behind dfk.CasinoLook 1 inside !UE_BUILD_SHIPPING, and facade A's path has no default in the binary (the rig passes dfk.CasinoLookA <package>.<asset>), because /Game/Casino/LookTest is never-cooked while the door is closed and cook.ps1 fails on any Source literal into a never-cook folder. The skeleton: boot dressing and torch glows torn down, the ancient-city floor hidden, night lighting (sun 0.30x cool, no dynamic shadows, sky violet at the level's own intensity), a ring of 40 owned sci-fi towers at 11000-16000 uu plus a 14-tower far-edge row at X 6200-7400 whose bases stand inside the visible ground (a row at 8600+ photographed as nothing: the -70 camera's horizon is above the frame, so anything tall at the top edge extends up and out of it) -- and two candidate facades on the lots ahead of the ship. A = Higgsfield concept -> Tripo H3.1 image-to-3D (Saved/CasinoLook/facade_a.glb, 56 MB) -> MeshImport/import_casino_look.py -> /Game/Casino/LookTest/SM_CasinoFacade_A with an MI off M_DFK_CityBuilding (its own base colour as the glow map, EmissiveBoost 3). B = SM_Skyscraper_Module14 from the owned PizzaBuildings pack, footprint scaled to the 2600 uu frontage and height capped separately (a uniform cap shrank it to a thin tower on a plaza), M_DFK_Neon roof bars on the WORLD bounds (local extents about the actor put them in a small square off one corner) and a gold roof disc (a standing marquee photographs as a sliver from -70), plaza slab in front, four lamps. Photograph and card pictures are TRACKED in Docs/casino-look/ (the frame district_test3_1080p.png, the labelled frame, the two equal crops and the side-by-side, cut by Tools/casino_look_sheet.py). Review of the diff (three lenses, twelve refuters) found one real defect, fixed before commit: the pause menu's RESTART RUN reached ResetArena -> EnterPhase(Intro) -> SetFloorTint, whose only latch was bInvasionMapBuilt, so dfk.EnvMode 2 re-spawned the level-1 diorama (SM_BG01 at +/-6400) in the middle of the strip and flashed LEVEL 1. SetFloorTint now latches on bCasinoDistrictBuilt too and the Intro banner is skipped in the casino; RESTART re-seats the ship and nothing else. TRAP for every later phase: any path that reaches EnterPhase/ResetArena is a campaign path until it is given a casino answer. Three capture windows were needed, one wasted: Git Bash rewrote /Game/Maps/Arena into a Windows path (run the editor with MSYS2_ARG_CONV_EXCL="*" or from PowerShell). Synty is out (refused on look). Nothing bought.

• Builds: ADFKCasinoDirector skeleton; a flat district built under bLoadingActive one stage per frame (ground, blocks, six casino footprints as blockers, sky/haze); teardown of the boot-time arena dressing; ArenaHalfX/Y set for the district; the ship pawn's clamp and blocker branches gated for casino; district HUD block (balance chip, nearest-casino name).
• Reuses: staged build, HISM factory, PizzaBuildings ISM recipe, FogAndCloud haze, follow cam, thrusters, engine audio, the player's chosen music set.
• Assets: the look test (above) decides the route; no purchase before his pick. (The free Synty Starter Pack line that stood here is dead: Synty was refused on look before anything was downloaded.)
• Depends on: Phase 2; D2.
• Problems: the district is the first ground-scale space in a game whose assets were all chosen for a -70 camera at ~10,900 uu; storms/volcanoes self-gate on mode and must be checked; the boot arena's turret pillars are not torn down by BuildInvasionMap either.
• Tests: perf_planet.ps1-style soak with dfk.StartMode 5, dfk.PerfLog 2 at MEDIUM; p99 and draw-call count logged; real Steam launch after upload for the overlay-during-load check.
• Photograph: the ship flying over six lit footprints with the loading screen reading CASINO / THE NEON STRIP; the Starter-Pack look test for your approval.

Phase 4 -- Buildings (4 days + asset lead time)

STATUS: BUILT + APPROVED 2026-09-13 04:02Z with the third district pass ("Yup looks good"). PHASE 4 CLOSED -- all six facades stand on their lots at frontage 5200; no purchase was needed (ruling A). His five A picks went Tripo H3.1 -> import_facades_batch.py -> /Game/Casino/Facades/SM_CasinoFacade_{Slipgate,Deflector,HollyJos,GridCity,Antipode} (native sizes 98x93x41, 98x84x62, 98x98x52, 96x92x84, 98x96x68; roofs at 5200 wide: 2194 / 3265 / 2733 / 4539 / 3611 uu, the manta 1895). Each casino is SOLID (blocker r 2300 covers the body; roofs stand above PlayHeight 1400) with a landing pad at its door on the road's edge (gold and lit for the open manta, dim grey for the five COMING SOON). Photographs Docs/casino-look/district_p3b_{spawn,manta,far}.png. RULED CHANGE 2026-09-13 00:45Z: "So this looks almost perfect. The only thing I would say is that the landing strip on some of the buildings is too close to the building so it kind of covers it ... maybe you need just a little bit more room and you should be good." Cause: pads, outlines and blockers were sized from the ASSUMED footprint (0.8 x frontage deep) while HOLLY JO'S and THE ANTIPODE CLUB are near-square scans (5200 deep), so their faces stood 520 past the assumed line and over the pad. Third pass BUILT + photographed (Docs/casino-look/district_p3c_{spawn,holly}.png): lots at Y +/-6600, and every lot's pad, outline and blocker read from the building's REAL placed bounds -- footprints measured 5200 x 4363 (manta), 4941 x 5200, 4425 x 5200, 5182 x 5200, 4997 x 5200, 5085 x 5200; pads 180-598 uu clear of the kerb; blockers r 2332 /

fine, just make it anyway and we can just address the steam stuff and disclosures and what not when we deploy to steam") -- the Content Survey answer and the AI-disclosure revision are Phase 17 owner steps, as already planned; the d1-rating card itself still shows WAIT in the store from the slip and is superseded by d1-recheck. (The same sitting he also re-pressed D1 to WAIT with the old GO note still attached -- flagged to him; nothing in Phases 3-5 depends on it.) Still owed from his note: a second look at the low fill blocks with him (now a regular lattice, not scattered), and the skyline ring photographs pale under the 0.30x sun -- a lighting pass when the interior's look is set. Five facade concepts x two variants generated from the manta's prompt template (gpt_image_2_5, Docs/casino-look/concepts/), reviewed by me against the manta (same backdrop, light, gold windows, four lamps, carpet, emblem not lettering, roof carries the identity) and put on /game-decisions as cards f-slipgate-palace, f-deflector-room, f-holly-jos, f-grid-city-grand, f-antipode-club (group 6). His pick feeds Tripo H3.1 -> import_casino_look.py (to be generalised to a table) -> a photograph on its lot -> kept. NEITHER regenerates from his note. Started ahead of Phase 3 proper because the approval loop is the long lead item; the district code runs in parallel.

1. APPROVED 2026-09-13 04:02Z ("Yup looks good"). PHASE 3 CLOSED. D1 recheck 04:04Z: GO stands ("I think we are

• Builds: six casino facades from a placement table (FDFKKitPiece shape), marquee signage on M_DFK_Neon primitives and/or a bought neon kit, per-instance colour via M_DFK_Particle custom data, a casino name/lore table, the "COMING SOON" state for the five unopened casinos.
• Reuses: kit placement table, ApplyCityEmissive name-matched emissive dials, StampAssembly if the generator (gen_asm_header.py, missing from the repo) is rebuilt.
• Assets: NO PURCHASE (ruling A). Six facades made through the look-test pipeline: one Higgsfield concept per casino (original, fictional, no real-world casino or brand), Tripo H3.1 image-to-3D, MeshImport/import_casino_look.py generalised to a table, glow map = the mesh's own base colour on M_DFK_CityBuilding. Each facade is photographed on its lot at the flyover camera and put to him as a card before it is imported for keeps. SM_CasinoFacade_A (the manta) is facade one unless he says otherwise.
• Depends on: Phase 3 approved look (DONE -- A).
• Problems: vendor emissive param names differ per master (DFKPlanet.cpp:1033-1037); any pack sold on Nanite renders only its fallback LOD on our SM5 cook; Mac path case.
• Tests: cook.ps1 $PathLoadedAssets rows for the pack; never-cook lines for its demo folders; mac_lint case check; draw-call delta vs Phase 3 soak.
• Photograph: all six facades from the flyover at 1080p and on the handheld.

Phase 5 -- Interior (5 days + asset lead time)

STATUS: APPROVED 2026-09-13 ("So the room looks fine ... the room size is fine"), with three notes acted on in a 5b dressing pass (card p5b-dressing). His notes were: refine the slot machines, "chandeliers or lights from the ceiling", and "make it look like the casino carpet floor". Built: the carpet -- our own tiling pattern through the facades' route (Higgsfield -> T_CasinoCarpet -> M_DFK_CasinoCarpet, a Tiling vector parameter and a Brightness scalar, laid on a single plane and repeated every 1.6 m because a 1 m repeat moired down the room); six chandeliers, one over each aisle, each a dark rod and three neon tiers with six drops, carrying that aisle's coloured fill so the light has a visible source (tiers at 1.3 intensity: at 2.5 the nearest disc clipped to flat white and lost its colour); seven-part cabinets -- plinth, body, angled button deck, screen bezel, screen, name plate, neon cap -- because a plain box read as a filing cabinet. Photographs Docs/casino-look/interior_p5b_{aisle,corner}.png + carpet_tile.png. Interior stages now 34 ms / 19 ms, 101 interior actors. Cabinets, plinths, decks and pillars cast into the key's shadow map; nothing else does.

BUILT 2026-09-13 ~04:30Z. What exists: ADFKCasinoInterior (its own actor at ADFKGameState::CasinoInteriorX = 400,000, GS->CasinoInterior the one switch; two stages RAISING THE HALL 7 ms / SEATING THE MACHINES 12 ms appended to the district's three through one running CasinoBuildStep with the bar's slope 0.72 / Total); the shell (2600 x 3200 clear x 700 high, floor at Z 1200 above the fog's dense layer, a 320-wide doorway on -X) from the shared kit DFKCasinoBuild (SpawnMesh / NeonBox / NeonDisc / DarkBox / SpawnPointLight / SpawnSpotLight -- the district now calls the same kit); every interior mesh and light on lighting channel 1, which stops the dimmed level SUNS (channel 0) but not the sky light -- a skylight is not channel-gated in UE 5.8, so the strip's violet ambient is this room's base light by design and re-tuning it re-lights both (measured in the engine shaders 2026-09-13; the header and the district's skylight block both say so); one shadow-casting spot key (480 cd, warm, with the cabinets and pillars as its casters) + six unshadowed cyan/magenta fills (80 cd) hung at head height IN the aisles -- at ceiling height they lit the ceiling 60x harder than the floor -- + a gold emblem wash; neon trim (cyan floor line, gold ceiling line, split around the doorway), four pillars, the manta emblem disc; the floor, walls and pillars COLLIDE, so Phase 6's pilot has a room to walk in rather than a picture of one; 30 ADFKSlotMachine actors (cabinet 60 x 70 x 170, screen at 125, theme-coloured cap, UBoxComponent blocker, SeatPos 95 in front) in three double-sided banks at Y -1000/0/+1000, published as GS->CasinoMachines (FDFKSlotMachine). Camera: ADFKPlayerController::ApplyNeonPost() is now the ONE copy of the flyover's post block; dfk.CasinoTeleport 1|2 stands CasinoInteriorCam in the entrance aisle / far corner with two interior deltas (BloomThreshold 1.15, MotionBlur 0.10) and sets GS->bCasinoCamOwned, the yield the arena camera tick honours beside bKillcamActive (and UpdatePlanetCameraLate). Interior HUD block keyed on CasinoPhase == Interior (chip, casino name via GS->CasinoInsideLot, machine count). Breadcrumb gained cas= (CasinoPhase). Photos Docs/casino-look/interior_p5_{aisle,corner}.png. Measured lesson: a 1400 cd key under locked exposure turned the near-black cabinets tan; 480 is a presence, not a sun. No purchase (ruling A): the shell is primitives + our materials.

• Builds (as planned): the interior shell at X = +400,000 built in the same loading pass; ~30 ADFKSlotMachine actors (static mesh, UBoxComponent blocker, screen MID, theme index, seat position) from a layout table; runtime lighting with one shadow-casting key and unshadowed fills (DFKPlanet.cpp:2013-2129 pattern); interior post-process profile; an interior HUD block.
• Reuses: staged build, runtime-lit pattern, neon primitives, kit placement.
• Assets: BUY the casino interior/props kit (Section 9, Phase 5 rows).
• Depends on: Phase 4.
• Problems: first close-camera space -- textures and LODs that passed at 60 px will be inspected at LOD0; keep textures <= 2K or the streaming pool thrashes (DefaultEngine.ini:98-109).
• Tests: dev cvar dfk.CasinoTeleport 1 drops the ship pawn's camera into the interior for capture; MEDIUM-preset soak; tex=/pool= fields in [DFK][PERF].
• Photograph: the empty floor from the future third-person eye height, contact sheet.

Phase 6 -- Pilot gameplay: walking (8 days)

• Builds: ADFKPilotPawn : ACharacter, spring arm + camera with the neon post block, walk/camera input mappings (legacy name mappings in DefaultInput.ini, the house convention), INTERACT action, the possess swap with the ship parked/hidden, bCasinoCamOwned yield in the three camera/clock blocks, the Cast<ADFKPawn> audit (71 sites), Tier A animation driver on the mannequin body, PilotColor tint + name tag + portrait chip.
• Reuses: the mannequin's SKM_*_Simple + BS_MM_WalkRun (re-homed under /Game/Casino/ first, D9), neon post block, NearestPlayerPawn gains a casino path.
• Assets: mannequin placeholder now; BUY the body pack in Phase 8 with the NPC bodies so player and crowd share one skeleton and one style.
• Depends on: Phase 5; D7.
• Problems: UCharacterMovementComponent needs bRunPhysicsWithNoController awareness for any controller-less use; the pawn Tick early-return lists and engine-audio gate must see the new state or flight logic runs under the floor; Apple Clang is where template-heavy animation code bites first.
• Tests: a casino DemoBot (wander the floor) for headless soaks; ui_matrix rows casino_interior; mac_lint.
• Photograph: the tinted pilot body walking between machines, third person, 1080p and handheld. This is a feel gate you play, not a bot.

Phase 7 -- Interaction (4 days)

• Builds: district NearCasino scan + Y branch at the top of OnOverdrivePressed (hangar pattern) opening a Tick-polled ENTER/CANCEL modal (world stays live; TickGameOverMenu edge-latch pattern, bIgnoreHeldUiClick set on open); interior NearMachine scan + E/Y prompt bound on the pilot pawn; EDFKUiMenu::CasinoPrompt hover/click cases; cursor and crosshair list entries.
• Reuses: hangar proximity/prompt/plate, DrawTwoChoice, device-aware glyphs.
• Assets: none.
• Depends on: Phases 3, 6.
• Problems: the beam must be gated on IsCasino(), not on charge (DFKPawn.cpp:2106); the friend invite (DFKPlayerController.cpp:2571) is already unreachable for a Solo-family mode.
• Tests: dfk.TestMenu 6 (prompt) capture row; a pad and a KBM pass each.
• Photograph: the ENTER CASINO / CANCEL card over THE GOLDEN MANTA with its lore line.

Phase 8 -- NPC population (8 days + asset lead time)

• Builds: ADFKCasinoPatron, aisle lattice from the machine table, BFS pathing at request time, reactive separation, FSM with dwell timers, seat reserve/release keeping the K nearest machines to the player free, door spawn/despawn cadence, MaxPatrons 24 -> soak -> maybe 40, per-component perf settings (VisibilityBasedAnimTickOption, URO, _Simple LODs, frozen pose when seated).
• Reuses: steering, waypoint constants, FindFreeSlot, best-of-N clearance, Flash/Pop puffs.
• Assets: BUY the character set and the seated + idle animation packs (Section 9, Phase 8 rows); one-time editor IK retarget of the animations onto the character skeleton, baked to UAnimSequence data assets (editor operation, no Blueprint).
• Depends on: Phase 6; D8.
• Problems: skeletal ticking is a CPU cost class the game has never paid; walking through cabinets unless the lattice is honest; patrons must be swept on RESTART/exit or they leak into the next arena.
• Tests: handheld soak at 24 and 32 patrons with dfk.PerfLog 2; p99 <= the district's.
• Photograph: a populated floor with patrons seated, walking and leaving; a 20 s recording (feel).

Phase 9 -- Slot framework (6 days)

• Builds: FDFKSlotTheme table, resolver (FRandomStream seeded per spin from FMath::Rand + time; outcome decided first), FDFKSpinState on GS, the Canvas UV-strip reel screen with ease-out stop cascade derived from elapsed time, win-line evaluation, [DFK][CASINO] log, dfk.CasinoForceOutcome and dfk.CasinoAutoSpin (latched, non-shipping), the RTP harness script under Tools\, and Docs\CASINO-ECONOMY.md with every derivation. Runs against a debug balance until Phase 11.
• Reuses: DrawSprite, Tween, slider row, pilot-carousel windowing idea, Sound-menu input shape.
• Assets: one placeholder symbol strip.
• Depends on: Phase 2.
• Problems: the world clock stops under pause and the Steam overlay pauses the game -- the visual is derived from elapsed time so a frozen spin resumes, never desyncs; the HUD is never the authority.
• VERIFY: dfk.CasinoAutoSpin 100000 on a scratch save logs measured RTP within +-0.5 % of target for the placeholder theme; balance never negative (Doppel assertion).
• Photograph: idle / spinning / win / deny frames via dfk.TestSlot 1-4.

Phase 10 -- Eight slot types (8 days + asset lead time)

• Builds: eight theme rows with weights and paytables solved to their RTP, eight symbol strips (the two owned sets first), cabinet screen materials per theme, per-theme SFX hookup, machine mix per casino.
• Reuses: portraits, ship art, boss stills, Foundry -> Tripo route for cabinets if no kit fits.
• Assets: BUY the slot cabinet source (Section 9, Phase 10 rows) or generate cabinets through the proven GLB import; symbol art via Higgsfield (standing authorisation; every image eye-checked).
• Depends on: Phases 5, 9.
• Problems: cabinets are static meshes -- verify no Blueprint-only logic is what the listing sells; eight 2K strips loaded on the first slot frame will hitch -- preload during the dive.
• VERIFY: the RTP harness per theme; cook.ps1 rows for strips and cabinets.
• Photograph: all eight machines on the floor; each theme's slot screen.

Phase 11 -- Danarren integration (3 days)

• Builds: spins through TryDebitDanerrens/CreditDanerrens; sit-down confirm via a new StageBuyConfirm Kind 6; NOT-ENOUGH via StageBuyDenied; one SaveBest per resolved spin; save v5 fields and SaveVersion 5 at both literals; casino excluded from AwardMetaOnRunEnd, SubmitRun, BestScore folds, RunsPlayed; LifetimeDanerrens untouched (D6).
• Reuses: wallet, save 3-site pattern, dialogs, title readout.
• Assets: none.
• Depends on: Phases 2, 9; D5, D6.
• Problems: the first-frame SaveBest wipes any field missing its load site; automated runs must copy DFKSave.sav aside (C:\Deflekt\CLAUDE.md).
• VERIFY: cold-load a real v4 save through the v5 build (pilots, hangar, balance intact); freshinstall_check.ps1 from zero balance reaches the NOT-ENOUGH dialog; hangar_check.ps1-style round trip of every v5 field.
• Photograph: the title DANERRENS readout before and after a session; the sit-down confirm card.

Phase 12 -- UI (5 days)

• Builds: bet selector, PAYTABLE card, win count-up and breakdown reveal, greyed SPIN below bet, balance pill, interior HUD chip (portrait + name + balance), digit strip for JACKPOT numerals, first-entry card ("Fictional currency. No real money. The house keeps X %."), device-aware hints.
• Reuses: every HUD primitive in Section 4.
• Assets: digit strip texture (rendered offline, the T_DFK_Hint precedent).
• Depends on: Phases 9, 11.
• Problems: DrawTextBold's outline is not UIs-scaled (DFKHUD.cpp:140-141); selected plates cost 108 tile items each -- budget the slot screen at the UPGRADES screen's draw count.
• Tests: ui_matrix rows slot_idle/spin/win/deny/paytable/prompt, contact sheets at six resolutions, ui_diff control run (reels animate).
• Photograph: the six new sheets.

Phase 13 -- Audio / VFX (5 days)

• Builds: casino sound table + lazy loader, SfxAt with attenuation and a concurrency cap, crowd bed on the controller, reel spin loop / stop / win tiers / loss per theme, jackpot duck term in the crossfade, footsteps for the nearest 3-4 NPCs, win-VFX ladder (Flash -> Pop -> Sty burst -> Shockwave + Rumble), FxSystem mote box gated off indoors, CREDITS-AUDIO.txt updated.
• Reuses: ElevenLabs pipeline, Sfx(), engine-loop recipe, crossfade, Cascade families, Flash/Pop/Shockwave.
• Assets: ElevenLabs generation (Creator/Pro tier confirmed before generating ship assets); a Kenney CC0 pass over C:\Game Art Library\Audio\SFX first (prefer bought/owned).
• Depends on: Phases 8, 10.
• Problems: no [Audio] section exists in DefaultEngine.ini; three music comps already play at volume 0; stereo ElevenLabs output must be downmixed to mono for panning.
• VERIFY: voice count in a 30-machine floor stays under the cap; every loop honours the SFX slider and MUTE ALL; every new path resolves through the game's own format on a verify script (Printf paths escape mac_lint).
• Photograph: a 30 s recording of a session with win tiers; the credits line.

Phase 14 -- Transitions / cinematics (4 days)

• Builds: the dive state machine on real time, ArenaCam approach, FadeAlpha layer, possess + SetViewTarget under black, flat-camera snap, reveal, the reverse exit to the district, GoToMainMenu made mode-aware, WELCOME banner allowance, breadcrumb fields for phase/machine/bet/balance.
• Reuses: killcam shape, DrawBar fade, banner, GoToMainMenu.
• Assets: an optional dive stinger (ElevenLabs).
• Depends on: Phases 6, 7.
• Problems: RefreshBulletTime fights any dilation not registered as an owner (DFKGameState.cpp:1218-1255); the pause gate list (DFKPlayerController.cpp:3373-3376) must allow pause in casino spaces but never mid-dive.
• Tests: dive 20 times from each casino side with the Steam overlay opened mid-dive on a real Steam launch; -DFKDumpFrames of the dive for a frame-by-frame review.
• Photograph: a contact sheet of the dive at 0 / 0.5 / 1.0 / 1.5 / 2.0 / 2.5 s. Feel gate: you.

Phase 15 -- Optimisation (5 days)

• Builds: casino-scoped cvar pins actor (r.HeterogeneousVolumes.Allowed=0 indoors, shadow radius threshold) via the refcounted Acquire/Release pattern (DFKPlanet.cpp:157-211); HISM cull distances for the district; URO and LOD policy for patrons; texture caps; a registry-based census (no world scans); fixing the dfk.TestVideoQuality runtime lever so headless MEDIUM numbers stop lying.
• Depends on: Phases 8, 13.
• VERIFY: handheld soak at MEDIUM: district p99, interior p99 at 24 and 32 patrons, slot screen draw count, tex=/pool= under the pool. Numbers written into the plan's TUNING TABLES.
• Photograph: the [DFK][PERF] percentile lines from the handheld, not the 3090.

Phase 16 -- Testing (4 days)

• Builds: Doppel adapter entries ([DFK][CASINO] telemetry, assertions: balance >= 0, measured RTP band, no leaderboard submit, LifetimeDanerrens unchanged), a casino menu_nav script, ui_matrix rows for every casino screen, freshinstall and cold-load runs, mac_lint, the five existing modes smoke-launched, a Night Shift soak.
• VERIFY: every assertion green over a 10,000-spin soak; every existing 1080p screen except title GATE HELD; SOLO/CO-OP/VERSUS/INVASION/INVASION 2 boards untouched (sync_leaderboard_names.ps1).

Phase 17 -- Polish (4 days)

• Builds: your feel passes folded in (walk camera, dive timing, reel stop rhythm, win pacing), lore lines per casino, machine "personality" lines on the prompt, patch notes Docs\PATCH-N-NOTES.md, the revised AI-disclosure paragraph for you to paste, the VDF Desc, and the store-page "fictional currency, no real money" line.
• Photograph: the final contact sheets and a 60 s recording of the loop: fly, dive, walk, play, win, leave.

Total honest effort: ~83 working days (5 + 5 + 4 + 5 + 8 + 4 + 8 + 6 + 8 + 3 + 5 + 5 + 4 + 5 + 4 + 4), plus asset lead time and your feel gates. Call it four months of patches, not a weekend.

8. SHOPPING LIST -- PHASE-GATED, LINKS, WHAT I VERIFY BEFORE YOU PAY

Nothing is bought before its phase. Every entry states the mechanic it serves and the asset type that mechanic needs (static vs skeletal-on-which-skeleton), because a pack that fails that test is a pack we own and cannot use. Before each purchase I check the listing for the five-rule spec (Docs\INVASION2-ART-STRATEGY.md:72-80): supported UE version reaches 5.x (5.8 import is then proven on the free pack), Mac listed, mobile listed (= no Nanite/Lumen dependency), "asset package" not "complete project", no VDB/Alembic. Prices are from listings read this session where stated; the listing is authoritative.

Route A (RULED 2026-09-12) -- our own pipeline for every casino piece; buy only what it cannot make

The two tables below are kept as the record of the routes he was offered. Route S is dead (Synty refused on look, nothing downloaded). Route F's exterior and interior rows are dead (ruling A); its Phase 8 rows moved into Route A above.

Route S (DEAD -- refused on look 2026-09-12) -- one vendor, Synty POLYGON

Synty also sells a subscription from $30/month that unlocks the whole library; whether assets downloaded during a subscription may ship in a game after cancelling is a licence question I have not verified -- worth one read of their terms before buying two packs outright.

Route F (exterior/interior rows DEAD by ruling A; Phase 8 rows live in Route A) -- Fab stylised-realistic

Explicitly NOT recommended: any "Slot Machine Blueprint / Slot Machine Game" listing -- the logic is Blueprint and unusable here; we only ever buy meshes, textures and animations. Any pack whose hero shots depend on Lumen (our SM5/DX11 cook cannot reproduce them; DefaultEngine.ini:13-22).

New tooling: one engine module dependency (AnimGraphRuntime in Deflekt.Build.cs) for the animation driver. No new plugins, no installs, no services.

9. RISKS AND TRAPS

• Rating (D1). Shipping simulated gambling without re-answering the Content Survey is an undocumented store-compliance exposure; PEGI 18 is a real change to who can buy the game in Europe. Decide first.
• Effort. ~82 days on a title whose prior plans were 8-11. Every earlier plan was "shipped assets recombined"; this one is four new subsystems (characters, animation, crowd, slots) and a content class that does not exist on this machine.
• The interior is a new render and CPU cost class on the Z1 Extreme, whose budget is already spent at the 50 % render-scale floor on the planet. Skeletal ticking has never run in this game. The patron cap is a soak result, not a design number, and the -Preset lever that would let me measure MEDIUM headlessly has never worked -- numbers come from the handheld or they are lies.
• Mode-branch sprawl. EDFKMode:: appears 130 times in 14 files; every default:/negative check is a place casino behaviour leaks into the arena or arena behaviour into the casino. The Solo+flag design shrinks the list; it does not remove it. The grep is the checklist.
• Y-button overload and the beam charging on any deflect: gate on IsCasino(), not on charge.
• The Steam overlay. Any casino load or dive not on bLoadingActive/an owner flag repeats the planet's hang, and no rig can see it. One real Steam launch per upload is mandatory.
• Economy variance vs the shop. A single oversized jackpot buys the catalogue; a house edge drains the pilot fund. Both are held by the ladder in Section 6 and by D6; both need the RTP harness, not intuition.
• Silent asset loss. String-loaded assets are invisible to the cooker; Printf-built machine-variant paths escape both the never-cook guard and the Mac case lint. Every family gets a cook.ps1 row and a verify script through the game's own path format (the Mus6 precedent).
• Vendor dependency on a demo folder. If the mannequins stay under CastleofEternalMist/Demo and that pack is later never-cooked for size, the casino's bodies vanish at runtime. Re-home first (D9).
• Vendor packs fail the spec 7 of 8 times (INVASION2-ART-STRATEGY.md:83-93, $427 rejected). Route S is chosen partly because low-poly cannot depend on Nanite/Lumen; Route F must budget rejection.
• 1080p gate collateral. The 6th pill and any shared-lambda change touch reference pixels; the bDisabled parameter is safe only with a byte-identical default.
• Mac. Interior lighting under Metal with Lumen/VSM off has never been seen; skeletal template code is the class mac_lint cannot catch; the monthly cadence hides a casino Mac bug for a month.
• Save migration v4 -> v5 on a live game: safe with zero defaults, but the cold-load must be proven on a real pre-update save before upload.
• Two open plans and one unrecorded patch sit under this one: Docs\PATCH-34-NOTES.md does not exist although the live VDF says PATCH 34; HANGAR Phase 6 is still PLANNED; INVASION2-MODES-PLAN is unapproved. Housekeeping in Phase 2.

10. WHAT I WOULD CUT

In order of what it saves, without touching the loop you asked for (fly -> dive -> walk -> play -> win/lose -> return):

1. Stand-up cabinets instead of seated play. Removes the seated animation pack, the retarget, the sit/stand transitions and the seat-position authoring. ~3 days and one purchase. Patrons stand at machines; the brief's "sit at" becomes "stand at".
2. One pilot body, tinted, instead of nine. Already the v1 recommendation (D7). Saves weeks and a pipeline that does not exist.
3. Neon silhouette crowd (one ISM, pure C++, ADFKFxSystem pattern) instead of skeletal patrons. Zero animation pipeline, one draw call, arguably more DEFLEKT than grey humans. Saves ~6 days and the largest perf risk. Silhouettes still walk (transforms) and "sit" (pose swap). I would hold this as the fallback if the Phase 8 handheld soak fails, not choose it up front.
4. Four machine types with two skins each instead of eight. ~4 days of art and tuning. Personality comes from the paytable and sounds, which stay distinct.
5. Sixteen machines instead of thirty. Cheaper floor, cheaper soak, the room still reads full with 24 patrons.
6. 2D audio with a nearest-machine distance volume instead of the first spatialised audio in the codebase. ~2 days; the floor reads flatter.

Minimum worth shipping ("the kiosk"): Phases 2, 3, 4, 7, 9, 10 (four types), 11, 12 and a shortened 14 -- fly the district, press Y at a casino, the slot screen opens over the flyover, play, leave. No interior, no walking, no NPCs. ~35 days. The whole economy loop and the district are real; the interior becomes the next patch. Your spec is what ships unless you say otherwise; this is here because you asked for honest options.

If everything is too big, ship Phase 2 alone. It fixes a live title-row bug, unifies three copies of the modal dialog, gives the wallet an API, and changes nothing a player can see.

11. V2 BACKLOG

• Nine bespoke pilot bodies matched to the approved portraits and Series\CHARACTER-CANON.md sheets.
• The five "COMING SOON" casinos opened as re-skinned interiors with different machine mixes.
• A casino soundtrack as MusicSet 7 (Mus8_*, ~0.5-1 GB; the add-a-set checklist has six count sites).
• Casino stats surfaced on a plaque in the lobby (never on a Steam board).
• Co-op casino (a second pilot on the floor) -- needs per-owner HUD registries designed now if ever.
• A skill-flavoured machine (timing-based) if D1 pushes away from reels.

12. OWNER STEPS -- BRANDT

1. ~~D1~~ RULED GO 2026-09-12. The Content Survey question moves to step 6, ship time.
2. ~~D2-D9~~ ALL RULED 2026-09-12 (Section 2 table). One card is still open: the reserve floor -- re-asked in chat in plain words.
3. Download the free Synty POLYGON Starter Pack (Unreal version) from https://syntystore.com/products/polygon-starter-pack and drop the zip in C:\Deflekt\_Incoming\ -- their store needs an account/checkout even at $0, which is yours to do. Phase 3 cannot start its look test without it. Then approve or refuse the photograph.
4. Purchases -- per phase, from Section 8, after my listing check comes back clean.
5. Feel gates -- Phase 6 walk camera, Phase 14 dive, Phase 17 reel rhythm. Your hands, not a bot.
6. AI disclosure -- paste the revised paragraph (Phase 17 drafts it) into Steamworks; the current text (Steam\STEAM_LAUNCH_RUNBOOK.md:45-53) does not cover characters, slot art or district geometry.
7. Upload and one real-Steam launch into CASINO with the overlay opened mid-load and mid-dive.

13. TERRAIN NOTES -- LIVE DEFECTS THE AUDIT FOUND (unrelated to the casino, fix in Phase 2)

• Title pad-stick walk is desynced from the drawn row. DFKPawn.cpp:808 walks {0,1,2,3,12}; the row is {12,0,1,2,3} (DFKGameState.h:263). Stick-right from INVASION jumps to the far-left pill; stick-left from INVASION 2 is dead. The header comment at DFKGameState.h:252-256 claims both walkers are unified; they are not.
• ~7.7 GB of unreferenced vendor content ships (CastleofEternalMist 1,639 packages incl. two Blueprint classes and Epic's third-person template; STF 488 packages, zero references).
• InvPregameStep is written once and never read (DFKGameState.h:545, DFKPlayerController.cpp:3165).
• Stale help/comments: dfk.GrantDanerrens says "add N" but SETS (DFKArenaDirector.cpp:1880 vs :2679); BuyConfirmKind comment lists kinds 1-3 but 4 and 5 exist (DFKGameState.h:425); PilotTexes says 1..7, code loads 1..9 (DFKHUD.h:59); dfk.StartMode help omits 3 and 4 (DFKPawn.cpp:106-109).
• Docs\PATCH-34-NOTES.md is missing; the live VDF Desc says PATCH 34.
• C:\Doppel\scripts\deflekt\menu_to_game.json assumes SOLO is the first pill; Patch 33 moved INVASION 2 there. Night Shift verdicts that depend on it are suspect until fixed.
• gen_asm_header.py, named as the generator of DFKAssemblies.table.h, is not in the repo; the table cannot be regenerated.
• DFKLeaderboardSubsystem.cpp:496 defaults a missing Details[6] to 0 (SOLO) where Ship/Pilot/Diff default to -1. Harmless today; fix if the details layout ever changes.