ship(O): Phase O — DatPath Unification — SHIPPED

ONE thing touches the DATs. WB code lives in our repo:
- src/AcDream.Core/Rendering/Wb/ — pure helpers (5 files, ~782 LOC)
- src/AcDream.App/Rendering/Wb/ — GL infra + mesh pipeline (~27 files, ~7K LOC)

Project references to WorldBuilder.Shared + Chorizite.OpenGLSDLBackend
dropped from AcDream.App.csproj and AcDream.Core.csproj.
references/WorldBuilder/ remains in-tree as read-reference only.

DefaultDatReaderWriter eliminated; DatCollection is the only dat reader.
WbMeshAdapter consumes our DatCollection via DatCollectionAdapter
(O-D7 fallback adapter; ObjectMeshManager has 26 _dats.X call sites,
exceeding the 20 refactor threshold).

Visual side-by-side passed: Holtburg town, inn interior, dungeon all
render identically to pre-O.

Doc updates:
- CLAUDE.md: rewrote WB integration cribs to point at extracted code.
  Code Structure Rules rule 2 updated to remove stale seam names.
  "Currently working toward" flipped from Phase O to M1.5 resumption.
- docs/architecture/worldbuilder-inventory.md: Phase O banner added.
  Status/integration model updated to post-O ownership. Workflow
  section updated to reference our extracted tree, not WB project ref.
- docs/plans/2026-04-11-roadmap.md: Phase O moved to shipped table.
  Phase O "ahead" block collapsed to SHIPPED note. M1.5 block updated
  to ACTIVE (Phase O shipped; resuming from 2026-05-20 baseline).
- docs/plans/2026-05-12-milestones.md: M1.5 heading updated to ACTIVE;
  Phase O ship writeup prepended to the M1.5 block.

Phase O ship closes Tasks O-T1..O-T7 shipped across this session.
Specs + audit + plan: docs/superpowers/{specs,plans}/2026-05-21-phase-o-*

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

docs/architecture/worldbuilder-inventory.md

@@ -1,35 +1,55 @@
-# WorldBuilder Inventory — what we take, adapt, or leave
+# WorldBuilder Inventory — what we extracted, adapted, or left behind
 
-**Status:** load-bearing reference. As of 2026-05-08 acdream's strategy is
-to **rely heavily on WorldBuilder** for rendering and dat-handling rather
-than re-port retail algorithms ourselves. WorldBuilder is MIT-licensed, is
-verified by visual inspection to render the AC world correctly (terrain,
-scenery, slabs, dungeons, slopes, particles), and uses the same Silk.NET
-+ .NET stack we already target.
+> **Phase O shipped 2026-05-21.** The ~33 WB files we actually use have
+> been extracted into our tree. `references/WorldBuilder/` stays as a
+> **read-reference only** — nothing in `src/AcDream.*` references it as a
+> project dependency. `DatCollection` is now the only dat reader in process.
+>
+> Use this document to:
+> 1. Know **where our extracted code lives** (look for the "Extracted to"
+>    column / notes in each section below).
+> 2. Know **what WB still has** that we haven't needed yet — grep
+>    `references/WorldBuilder/` if you ever need to add something.
+> 3. Know **what WB never had** (the 🔴 list) — those are always ours.
 
-**Integration model:** **fork upstream WorldBuilder** at
-`github.com/Chorizite/WorldBuilder`, depend on our fork, delete editor-only
-code, expose hooks for our network state to feed scene data in. Sync with
-upstream via merge so we inherit fixes. This document tells you, before
-you write code, whether the thing you're about to port already exists in
-WorldBuilder.
+**Pre-O status (archived for context):** As of Phase N.4 (2026-05-08)
+acdream relied heavily on WorldBuilder as a project reference for rendering
+and dat-handling. WorldBuilder is MIT-licensed, verified by visual inspection
+to render the AC world correctly (terrain, scenery, slabs, dungeons, slopes,
+particles), and uses the same Silk.NET + .NET stack we target.
 
-**Workflow change:** Before re-implementing any AC-specific rendering or
-dat-handling algorithm, **check this inventory first**. If WorldBuilder
-has it, port from WorldBuilder (or call into our fork once it's wired
-up), not from retail decomp. Retail decomp remains the oracle for things
-WorldBuilder lacks — animation, motion, physics collision, networking.
+**Post-O integration model:** Extracted WB code lives in two locations in
+our tree (see CLAUDE.md for the full breakdown):
+- `src/AcDream.Core/Rendering/Wb/` — pure helpers (no GL): `TerrainUtils`,
+  `TerrainEntry`, `RegionInfo`, `SceneryHelpers`, `TextureHelpers`.
+- `src/AcDream.App/Rendering/Wb/` — GL infrastructure + mesh pipeline:
+  `ObjectMeshManager`, `WbMeshAdapter`, `WbDrawDispatcher`, texture cache,
+  shader infra, EnvCell/portal/scenery/terrain-blending pipeline classes.
+
+`DatCollectionAdapter` bridges our `IDatCollection` to the `IDatReaderWriter`
+interface WB's internals expect (O-D7 fallback; `ObjectMeshManager` has 26
+internal `_dats.*` call sites — above the 20-site inline-swap threshold).
+
+**Workflow:** Before re-implementing any AC-specific rendering or dat-handling
+algorithm, **check this inventory first**. If we already extracted it (🟢
+sections), it's in `src/AcDream.App/Rendering/Wb/` — use our copy. If WB has
+it but we haven't extracted it yet, grep `references/WorldBuilder/` and extract
+as needed. Retail decomp remains the oracle for things WB never had (🔴 list).
+
+Attribution: WorldBuilder is MIT-licensed. `NOTICE.md` includes WB attribution.
 
 ---
 
-## Repo layout (as of cloned snapshot under `references/WorldBuilder/`)
+## Read-reference layout (under `references/WorldBuilder/`, not project-referenced)
 
-- **`Chorizite.OpenGLSDLBackend/`** — full OpenGL renderer (Silk.NET).
+- **`Chorizite.OpenGLSDLBackend/`** — full OpenGL renderer (Silk.NET). The
+  components we use are extracted into `src/AcDream.App/Rendering/Wb/`.
 - **`WorldBuilder.Shared/`** — data models, dat parsers, landscape module.
-- **`WorldBuilder/`** — Avalonia desktop app shell (NOT taken).
-- **`WorldBuilder.{Windows,Linux,Mac}/`** — platform entry points (NOT taken).
-- **`WorldBuilder.Server/`** — collab editing backend (NOT taken).
-- **`Tests/` + `WorldBuilder.Shared.Benchmarks/`** — test harness (study).
+  The helpers we use are extracted into `src/AcDream.Core/Rendering/Wb/`.
+- **`WorldBuilder/`** — Avalonia desktop app shell (not taken).
+- **`WorldBuilder.{Windows,Linux,Mac}/`** — platform entry points (not taken).
+- **`WorldBuilder.Server/`** — collab editing backend (not taken).
+- **`Tests/` + `WorldBuilder.Shared.Benchmarks/`** — test harness (study only).
 
 **Upstream NuGet dependencies** (these stay as NuGet packages, we don't
 vendor them):
@@ -234,17 +254,28 @@ WorldBuilder is a dat editor; it does not have:
 
 ---
 
-## What this means for the workflow
+## What this means for the workflow (post-Phase O)
 
 The CLAUDE.md "grep named → decompile → verify → port" workflow stays
 the rule for everything in the 🔴 list (network, physics, animation,
-movement, UI, plugin, audio, chat). For anything in 🟢, the new rule is:
-**check this inventory FIRST**. If WB has it, port from WB. Re-porting
-from retail decomp when WB already has a tested port is no longer
-appropriate — that's how we got the scenery edge-vertex bug.
+movement, UI, plugin, audio, chat).
 
-When the inventory says "take wholesale or adapt" and we discover a
-behavior mismatch with retail (rare — WB is verified), the resolution
-is: reconcile WB ↔ retail decomp ↔ holtburger ↔ ACE ↔ ACViewer (the
-existing reference hierarchy in CLAUDE.md). WorldBuilder ranks at the
-top of that hierarchy for anything 🟢.
+For anything in 🟢 that we've already extracted: **the code is in our
+tree at `src/AcDream.{Core,App}/Rendering/Wb/`**. Read it there — don't
+grep `references/WorldBuilder/` unless you want to compare against the
+original. Re-porting from retail decomp when we already have a tested
+port is still how we'd get the scenery edge-vertex bug back.
+
+For anything in 🟢 that we have NOT yet extracted: grep
+`references/WorldBuilder/` to find the source, then extract it using the
+Phase O pattern (verbatim copy → adapt constructor to accept
+`IDatCollection` via `DatCollectionAdapter` where needed → add to
+`src/AcDream.App/Rendering/Wb/`). Do NOT add a new project reference back
+to `WorldBuilder.Shared` or `Chorizite.OpenGLSDLBackend` — Phase O
+permanently removed those.
+
+When we discover a behavior mismatch with retail (rare — the extracted
+code is the same as the original), the resolution is: reconcile extracted
+code ↔ retail decomp ↔ holtburger ↔ ACE ↔ ACViewer (the existing
+reference hierarchy in CLAUDE.md). Our extracted code ranks at the top
+of that hierarchy for anything 🟢.