adventure: correct the spec where building it proved it wrong

Three claims in §4 were wrong, and each was only visible by reading both
repos together: equipped and inventory are disjoint sets (so the spec'd
attuned field was undefined, and the worn set it never asked for was the
actual gap); effects are modeled after all, by the engine's own summary
function; skill_source is dual-use and needs filtering, not forwarding.

Keeping the wrong text with the corrections above it — the pattern is worth
more than the fix. The spec was written a side at a time, so §§1-3 and 5
should be assumed to have the same class of error until checked.

adventure_expansion_spec.md

@@ -284,6 +284,38 @@ argues for the one-hop cut on size grounds as well as secrecy.
 
 ## 4. Richer item view
 
+**SHIPPED 2026-07-17** — gogobee `b6d4e4c`, Pete `4ce025a`. Neither deployed.
+
+The section below is kept as written, because three of its claims were wrong
+and the corrections are the useful part. What actually shipped:
+
+- **`Equipped []ItemView` on `PlayerDetail`, which this section never asked
+  for.** Equipping *moves* the row from `adventure_inventory` into
+  `magic_item_equipped` (`magic_items_gameplay.go:679-690`) — the two sets are
+  disjoint. So `attuned` on a backpack item, below, can never be true: bond
+  state there isn't false, it's *undefined*. The real gap was that worn items
+  weren't sent at all. `equippedViews` is where `Attuned` means something.
+- **Stat modifiers ARE modeled** — see "What does not exist", which is wrong.
+  `magicItemEffectFor`/`magicItemEffectSummary` (`magic_items_gameplay.go:211`,
+  `:538`) produce a player-facing delta ("+15% damage, -8% damage taken"). The
+  fear below — that a display-only approximation lies the first time it and the
+  engine disagree — doesn't apply: this *is* the engine's summary, the same
+  function the game speaks with, so there's nothing to drift from. Sent as
+  `effect`. Raw per-stat numbers still aren't modeled and still aren't sent.
+- **`skill_source` must be filtered, not forwarded.** The column is dual-use:
+  `"mining"` on masterwork gear, and the internal `"magic_item:<id>"` registry
+  pointer on magic-item rows (`magic_items_gameplay.go:521-533`). Sending it raw
+  puts gogobee IDs on a page, and Pete can't tell the two apart to filter them.
+  The push site sends only the skill name.
+
+Pete-side note: an ItemView can't tell you which panel it's in, and that decides
+whether an unbonded attunement item reads as "inert" (worn, doing nothing) or
+"needs a bond" (just not worn yet). `internal/web/who.go`'s `itemRow` carries it.
+
+Still open from this ask: **equipping from the web** is ask 5, not this one.
+
+---
+
 Partly buildable now, partly not. Being precise about which is which.
 
 ### What exists and is being dropped
@@ -461,8 +493,10 @@ page reflects the row.
 
 ## Suggested order of work
 
-1. **Ask 4 (items)** — additive fields with real sources, no deploy-order
-   hazard, no security surface. Smallest thing that visibly improves the page.
+1. ~~**Ask 4 (items)**~~ — **done** (gogobee `b6d4e4c`, Pete `4ce025a`). Read the
+   corrections at the top of §4 before trusting any other section here: this spec
+   was written from one side at a time, and every claim it got wrong was one that
+   only breaks when you read both sides together. Assume the same of §§1-3, 5.
 2. **Ask 3 (map)** — the graph exists; the work is the one-hop cut and the
    rendering. Check the roster size cap.
 3. **Ask 5 (equip)** — the architectural step, but a well-trodden one now.