drwily/Pete
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

adventure: mark ask 6 shipped, record the one-ring correction

Browse Source
This commit is contained in:
prosolis
2026-07-17 10:05:04 -07:00
parent 6c6de56539
commit 8a5fea78ba
1 changed files with 31 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
adventure_expansion_spec.md
View File

@@ -522,7 +522,37 @@ page reflects the row.
5. **Ask 2 (LLM dispatches)** — last, because the prose guard is the only piece 5. **Ask 2 (LLM dispatches)** — last, because the prose guard is the only piece
here that fails *publicly* if it is wrong. here that fails *publicly* if it is wrong.
## 6. Item comparison — "is this backpack item an upgrade?" (scoped 2026-07-17) ## 6. Item comparison — "is this backpack item an upgrade?" (SHIPPED 2026-07-17)
**SHIPPED 2026-07-17 (session 5):** gogobee `7e59697`, Pete `6c6de56`. All tests
green both sides, gofmt-clean, screenshot-verified day + night (all six verdict
chips, including the purple `new` chip the theme-contrast history warned about).
NOT deployed. Additive private `Compare` field → safe deploy order either way.
**The one both-sides error, and it overturned a settled design decision: the game
only ever wears one ring.** `DnDSlotRing2` is declared and looped over as a valid
slot, but nothing in live code assigns to it — every ring in the registry is
`Slot: ring_1`, and the only equip path (`applyMagicEquip`, the same one ask 5's
web button drives) equips to `mi.Slot`. So "weaker of the two worn rings" (the
verified-at-scope proposal below) describes a trade that can't happen. The shipped
behaviour: a backpack ring compares against the `ring_1` occupant — which collapses
the ring special-case entirely, since **every** item's compare target is just
`mi.Slot`. Even a section written after verifying both repos carried the class of
error the rest of the spec did; the ring-slot subtlety was flagged "confirm before
building" and the confirmation is what caught it. (Owner was asked; chose ring_1.)
Everything else below shipped as written: strict-dominance verdict, engine-computed
deltas over tempered effects (reusing `magicItemEffectFor`, no Pete-side math), the
inert override that counts bonds *after* the slot's occupant is evicted, always-
visible verdict chip (no hover — phones don't have one) with deltas beside it. Chip
colours mix a fixed hue into `--ink`/`--card` so they survive all four phases by
construction (the map's trick), NOT a `dark:` variant. The mobile hover→tap
disclosure the spec proposed was dropped: deltas are short (≤3 chips), so showing
them inline is simpler and needs no JS.
---
A sixth ask, scoped after all five shipped. On the owner's own page, hovering a A sixth ask, scoped after all five shipped. On the owner's own page, hovering a
backpack magic item shows a **compare card**: the item currently worn in that backpack magic item shows a **compare card**: the item currently worn in that