3 Commits

Author	SHA1	Message	Date
prosolis	d76c63be0c	Review follow-ups A + B: armed abilities survive the fight, supply pool serialized ... A. An armed ability lasted one round of a turn-based fight. buildZoneCombatants called applyArmedAbility, which applies an ability's mods *and* clears ArmedAbility and saves the sheet. The turn engine calls that builder again on every !attack / !cast / !consume, so round 1 fired the ability and disarmed the character, and every later round rebuilt them with none of its mods. A Berserker paid stamina for a single round of BerserkerRage / RageMeleeDmg / PhysicalResistRage / FrenzyDmgBonus. Every entry in dndActiveAbilities had the same shape. mods.BerserkerRage was not merely unread at close-out — by then it no longer existed. Split arming into its two halves: consumeArmedAbility(c) mutates: disarms, saves, returns the id. Once, at fight start. applyAbilityByID(c, id, mods) pure: no DB write, no disarm. Safe on every rebuild. (No ability's Apply writes to the character, so this really is pure.) armAbilityForFight(c, mods) consume + apply, for the auto-resolve callers that build and fight in one breath. buildZoneCombatants now takes the already-consumed id and re-applies it. The id rides on ActorStatuses.ArmedAbility, seeded per seat at fight start, so partyCombatantsForSession reproduces the ability every rebuild and the close-out can still see that a rage fired. The close-out itself: postCombatBookkeeping now carries grantCombatAchievements + persistDnDPostCombatSubclass, and all four close-outs route through it — runDungeonCombat, runZoneCombatRoster, finishCombatSession, finishPartyCombatSession. It fires on every terminal status, not just a win: a Berserker who rages and loses is still exhausted, which is what auto-resolve always did. Also: buildFightSeats and runZoneCombatRoster consumed the ability before the checks that could sit a seat out, so a downed member was disarmed for a fight they never joined. The refusals now run first. B. Six unlocked read-modify-writes against the shared supply pool. updateSupplies rewrites supplies_json wholesale, so a caller folding its delta onto an *Expedition it read earlier discards whatever landed in between. Handlers run one goroutine per event, so those writers genuinely interleave. All six now go through withExpeditionSupplies, which takes advExpeditionLock, re-reads the row, hands the closure the fresh copy and persists what it returns: nightRolloverBurn (forage + burn in one write), grantTwoWeeksCache, advanceToNextRegion's transit burn, campPitch, pitchAutopilotCamp, and the ambient pack-rat drain. expeditionCmdAccept's hand-rolled lock folds onto the same helper. expedition_sim.go is left alone: single-threaded, takes no locks. Known consequence, for the balance track: trySimAutoArm used to live inside the rebuild, so a simulated Fighter (second_wind) or Cleric (healing_word) re-armed and re-spent a resource every round of every elite/boss fight. expedition-sim drives those through the turn engine, so every prior expedition-sim corpus overstates those two classes. Re-baseline after this, not before. Claude-Session: https://claude.ai/code/session_017mEwUmmS7aQTP2NQXj6rUa	2026-07-10 08:01:51 -07:00
prosolis	1f211564d9	Review fixes: party close-out, member soft-lock, supply race, elite loot, season crown ... Five bugs found reviewing n1-restoration end to end. beginCombatTurn settles any phase the engine owes before reading whose turn it is. That settle can end the fight — and the old code then answered "you're not in a fight" and returned. The terminal status was already persisted, so nothing ever paid the party out: no XP, no loot, no death recorded, no run teardown. The reaper cannot recover it either, because listExpiredCombatSessions filters on status='active'. Close the fight out there, the way the !fight start path and the reaper already do. A party member was permanently soft-locked when their leader extracted and never resumed. seatedExpeditionFor (the guard) spans 'extracting'; expeditionForMember (what !expedition leave resolved through) saw only 'active'. So the member was refused any new adventure by the guard and told "No active expedition" by the command the guard points them at, with nothing sweeping stale rows and only the leader able to clear one. Resolve the exit through the same lookup as the gate. updateSupplies overwrites supplies_json wholesale, and expeditionCmdAccept folded a member's packs onto a snapshot read before the coin debit, unlocked. Handlers run one goroutine per event, so two invitees accepting genuinely interleave and one member's packs vanish. advUserLock cannot help — it is keyed by sender, so racing members take different mutexes. Add advExpeditionLock and re-read the pool under it. Closes accept-vs-accept; the six other updateSupplies callers still race and are written up separately. runHarvestInterrupt picked an elite enemy and elite narration off a local `elite` flag, then passed a hardcoded false as isElite to closeOutZoneWin. dropZoneLoot gates masterwork on isBoss||isElite, so beating an elite interrupt skipped the masterwork roll and took standard treasure weight — while the same elite fought via !zone paid out correctly. arenaSeasonRollover marked its job complete even when recordArenaSeasonTitle failed, and JobCompleted short-circuits every later run for that quarter, so a transient SQLite BUSY lost the crown forever. Defer completion on failure; the insert is ON CONFLICT DO NOTHING against PRIMARY KEY (season, kind) and a past season's data is frozen, so the retry is safe. Also: drop dead partySurvivors, collapse the zoneCombatRoster alias into fightRoster, route partyCasualtyLine through joinNames, fold four copies of the expedition column projection into expeditionSelectCols, stop replyDM sending a blank DM, and correct two doc comments describing a path that no longer exists. Deliberately not fixed, with reasons, in gogobee_code_review_followups.md — most notably that both turn-based close-outs skip grantCombatAchievements and persistDnDPostCombatSubclass, which the auto-resolve paths run.	2026-07-10 07:20:14 -07:00
prosolis	08d3053368	N3/P6e: a party that fights every room ... Only elite and boss doorways seated a roster. Everything else -- exploration rooms, patrol encounters, harvest interrupts -- resolved through SimulateCombat against ctx.Sender, and P6d made the walk commands leader-only. So on a 38-room T5 expedition a party of three fought together twice and the leader soloed the other ~35, then died alone while two untouched members stood at full HP. The plan said the N-body core was already there and only the callers passed one player. It wasn't: SimulateCombat built a one-seat roster internally. But the resolution primitives already read st.c -- the cursor's Combatant -- because the turn engine has called them that way since P3. Only the round loop needed widening. combat_engine_party.go carries it: simulateParty, simulatePartyRound, roundInitiative, enemyTargetSeat. Every roster short-circuit collapses for one seat, copying P3's solo exemptions, so the RNG draw order is unchanged and SimulateCombat is now simulateParty([]Combatant{p}, ...).Seats[0]. TestCombatCharacterization is byte-identical; TestSimulateCombat_IsTheOneSeatPartyCase pins the delegation event-for-event across 40 seeds. zone_combat_party.go carries the callers' half: runZoneCombatRoster fans out the character-scoped close-out (HP, XP, achievements, subclass, heal items burned, Misty's repair) per seat, while loot, threat, kill records and death stay with whoever knows the room. runZoneCombat remains the explicit solo entry point -- the arena calls it, and an arena bout must never drag in a party. Death is read per seat off HP, never off the fight's terminal status: a timed-out party can still have lost somebody, and a solo player at 0 HP has already ended the fight, so PlayerEndHP <= 0 is exactly the old !TimedOut rule. Preserved deliberately: a solo player can win at 0 HP (a retaliate aura kills the swinger on the killing blow, and resolvePlayerAttack returns before enemyDown is consumed) and is not marked dead. A party marks its downed seats dead on a win, which is what finishPartyWin always did. Solo T5 re-sweep is unregressed (fighter 47-73%, cleric 20-33%). Party of 3 now clears 100% of every T5 cell, which is P8's problem: the enemy takes one turn per round and swings at one seat, so a party of N deals xN damage and each member takes ~1/N^2 of the solo incoming. An HP scalar cannot close that -- it restores the fight's duration, not the enemy's action economy.	2026-07-10 06:32:29 -07:00