task 3 brief

Task 3: Taking a drop in play (board #1455)

Files:

• Modify:
  • src/lib/engine/core/dungeons/templeSystem/chests.ts, src/lib/engine/core/dungeons/TempleSystem.ts
  • src/lib/services/temples/RoomInteractions.ts (the monster/miniboss/boss case), src/lib/services/temples/roomInteractions/vocabulary.ts (RoomIntent, RoomSheet)
  • src/hooks/temples/useTemple.ts (claimChestItems), src/app/Console/TempleGrounds/templeGrounds/templeReveals.ts (useChestReveal), src/app/Console/TempleGrounds/templeGrounds/useRoomOutcomes.ts (the openChest case)
  • the engine's doors code (src/lib/engine/core/dungeons/templeSystem/doors.ts) for the bug below
• Test: tests/unit/RoomInteractions.spec.ts, tests/unit/FightDrops.spec.ts

Interfaces:

• Consumes: roomDrops, dropKey, BOMB_ITEM (src/lib/services/temples/fightDrops.ts, in master); chestLoot (src/lib/services/temples/ChestLoot.ts).

• Produces:

  • markDropTaken(runs, templeId, level, position): void and isDropTaken(runs, templeId, level, position): boolean in chests.ts, filed in TempleState.openedChests under dropKey. TempleSystem has public wrappers with the same names (without runs).
  • RoomIntent gains 'takeDrop'; RoomSheet gains drop?: 'waiting'.
  • useTemple: dropContents: ComputedRef<ChestLoot[]> and claimDropItems(selected: string[]): void.
  • useChestReveal: showDropReveal(): void; the reveal's Take routes to claimDropItems while a drop is shown.

• Step 1: Write failing tests in RoomInteractions.spec.ts, each a monster quest room with a small-key drop:

  • Status lurking: no "Take it" action and no drop.
  • Status cleared: a "Take it" action with intent takeDrop and drop: 'waiting'.
  • Status notYours and status away: "Take it" too.
  • A classic room not yet cleared: no "Take it".
  • After markDropTaken: no "Take it", and "Search the room" is still offered. The keys are separate: isRoomSpent stays false.

  In FightDrops.spec.ts, with TempleSystem:

  • A blood-moon restart (openedChests cleared) makes isDropTaken false again.
  • A daily quest restoring the room does not.

  For the doors bug (below), in the spec that covers doors.ts (find it with chemx q blowBombableSide): a cracked side into a boss room, once blown by a Bomb, still needs the Boss Key (doorKind reports it as the Boss door).

• Step 2: Run chemx test tests/unit/RoomInteractions.spec.ts. Expected: FAIL.

• Step 3: Implement.

  • The sheet: offers the drop when roomDrops(room) && !isDropTaken(...) && !fightIsLive. The fight is live for a quest room when questWords.fight; for a classic room, while !isRoomCleared. The sheet line is "Something glints where the beast fell." as a raw string like the rest of the file (lead ruling: the file's idiom wins for this one line).
  • claimDropItems: hands items out exactly as claimChestItems does, through one extracted local handOutItems(selected), then calls markDropTaken.
    • A drop is taken whole: if any restorative or Bomb has no room in the bag or storage, nothing is taken and the message says the bag is full.
    • A Bomb from a chest or a drop goes into the bag as { name: 'Bomb', kind: 'consumable', faIcon: 'bomb', qty: 1 }, as the temple shop does. claimChestItems gains that too.
  • The doors bug (pre-existing, lead ruling): blowBombableSide records the blown side in openedDoors, so doorKind lets a Bomb open a cracked wall into a boss room without the Boss Key. Bombs never open locked doors: a cracked side into a boss room stays a Boss door after the blast.
  • useTemple.ts is large: extract handOutItems and the drop logic into a small helper module beside it if that keeps every file under 500 lines.

• Step 4: Run both specs (and the doors spec). Expected: PASS.

• Step 5: Commit feat(temples): a beaten beast drops what its room holds, and it waits there for a hero with no fight.