4 Commits

Author	SHA1	Message	Date
prosolis	d538f91cf7	Combat engine: pay off the N-body debt, and hire Pete ... N3 widened the combat *roster* from 1 to N but never widened the action model, the scaling model, or the test net to match. Building the hireable companion walked into all three. Only one of the four defects found was the companion's; the rest have been live in prod for every human party since N3. The party golden did not exist (§5) Solo combat is pinned exhaustively (7468 lines); the entire N-body layer had nothing. That is why a healer class that cannot heal shipped without a test going red. Adds party_characterization.golden (9 scenarios x 5 seeds, incl. weak and dying seats) and TestPartyCharacterization_OneSeatIsStillSolo, so the N-body path can never quietly stop being a superset of the balance corpus. Regenerate only on purpose: -update-party. No action could target another seat (§1) Every heal in the engine was self-scoped. A party cleric could not put one hit point on a friend. Adds turnActionEffect.AllyHeal/AllySeat, `!cast <spell> @user` and `--target @user` -- the latter has been advertised in !help and silently swallowed by parseCombatCast since SP2 ("reserved for SP3"). The auto picker uses it too (simPickAllyHeal), so away-players and engine-driven healers behave like competent ones. It will not raise the dead. Corpses kept buffing the boss (§2b) enemyActionsThisRound counted len(st.actors), dead included -- so a party that lost a member kept paying for them, and the survivor faced a boss still swinging at two-player cadence, alone. A death spiral with the arrow pointing the wrong way. Now counts livingActors(). Party golden moved deliberately for this. An engine-driven seat was a bool any command could clear (§3) autoDriveCombat drives a party by dispatching each seat's turn AS that seat, so a companion's own auto-played move arrived at beginCombatTurn looking like a player returning to the keyboard and cleared the latch that was moving him. He then stood in the fight doing nothing while the boss he had inflated killed everyone. ActorStatuses.EngineDriven is now a persisted seat property that no command clears, and the driver calls driveEngineSeat instead of impersonating. "The party" could be empty (§4) A solo expedition has no expedition_party rows, so asking the roster who was in the party answered "nobody" -- and every caller fell back to something plausible. That is how the companion got hired at level 1 for exactly the player the feature exists for. expeditionParty()/partyHumans() always include the owner. The companion himself (!expedition hire [class] / !expedition dismiss) Day 1, leader only, costs coins, role-fills the gap, globally exclusive. He is an NPC seat and must never become a player: no player_meta, no dnd_character, no inventory, no DM room -- mint him a player_meta row and ensureDnDCharacterForCombat will auto-build the news bot a real character, and he starts appearing in the graveyard and filing death notices about himself. Mail and seats are different sets: he fights, he does not get written to. Measured on millenia, n=750/arm. Before these fixes he was -28pp -- worse than no companion at all. After: solo 48.5% -> 63.9% clear (+15.3pp), with +28.0pp for trailing players and +2.0pp for leaders. Help, never a carry. The solo golden is byte-identical throughout: solo combat provably did not move, and the balance corpus is intact. Known gap: the companion cannot cast (castActionForSeat loads a sheet from the DB and he has none by design), so a hired Cleric is still just a bad fighter. Claude-Session: https://claude.ai/code/session_01J5SQZWoLmL3M3mw2XmHHdy	2026-07-11 12:39:01 -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	a063e0ccd0	N3/P6d: a party where every member can see the dungeon ... Every ownership lookup in the adventure module keys on a user id, and a party member owns neither the expedition row nor the zone run. So each player-facing read quietly told them they were not playing. Rewire them. Reads a member should see resolve through activeExpeditionFor / activeZoneRunFor. Leader-only actions answer with copy that names the leader instead of denying the expedition. Three busy-guards had to start refusing a member outright: !zone enter, !expedition start and !sell all keyed on the sender's own row, so a seated member could open a private dungeon, outfit a rival expedition, or run a shop from the boss room. Four things the rewire itself exposed: !resources looks like a read but seed-persists harvest nodes, and saveHarvestNodes rewrites the entire region_state blob — kills, event gates, temporal stack — last-write-wins. Reaching it as a member would revert the leader's walk from a stale snapshot. Persist only for the owner; seedRoomNodes is pure, so a member re-derives the same nodes. !zone taunt moves the party's shared mood, which is intended and safe: applyMoodEvent lands an atomic delta. Its neighbour applyMoodDecayIfStale writes an absolute gm_mood from the caller's snapshot, and every command takes the *sender's* lock — a member running it against the leader's run holds the wrong mutex. The owner check now lives on that function. A seat outlives status='active'. releaseParty deliberately skips the seven-day 'extracting' limbo, so the roster persists while activeExpeditionFor goes blind — long enough for a member to open a run that wins every lookup once the leader !resumes. seatedExpeditionFor spans both statuses; it is what the busy-guards ask. !expedition run was still member-blind. It is the same walk as !zone advance, reached by its other name. isPartyMember replaces `run != nil && !isLeader`: activeZoneRunFor reports isLeader=false for a player with no run anywhere, so the bare test sends a solo player to go ask their leader. Golden byte-identical; solo T1 expedition clears end-to-end.	2026-07-09 23:56:16 -07:00
prosolis	0f144fa335	N3/P6a: let a member find the run they're standing in ... Every ownership lookup in the adventure module keys on a user id, and a party member owns no row: not the expedition, not the zone run. P4 gave them activeExpeditionFor; this gives them activeZoneRunFor, and gives the DM seams the audience they never had. - activeZoneRunFor(user) -> (run, isLeader, err). An owner's lookup is exactly getActiveZoneRun, side effects and all -- in particular the §4.3 idle reap, which force-extracts the wrapping expedition. A member must never re-enter it, or glancing at the map would end the leader's run. Pinned. - expeditionAudience / fanOutExpeditionDM. Briefing, recap and digest all DM'd id.UserID(e.UserID) alone. They now loop the roster, which partyMemberIDs collapses to exactly the owner when there is none -- so a solo expedition sends the same bytes to the same user it always has. The briefing's body is expedition-scoped but its pet prefix is not: each member has their own pet and their own sheet, so the roll rides a per-reader decorator (the shape P5 settled on for combat narration). The digest's A6 event anchor rolls per member for the same reason. - releaseParty on every terminal transition. A seated member is barred from adventuring elsewhere, so a roster outliving its expedition strands the party. Deliberately NOT on 'extracting': that is a 7-day resumable limbo and !resume must bring everyone back. The roster clears when the window lapses to 'failed', which routes through completeExpedition like the rest. Rosters are still empty in production -- nothing seats a member yet -- so every loop here has exactly one element and the whole change is a no-op until P6b. Golden byte-identical, go test ./... green.	2026-07-09 22:18:40 -07:00