acdream/docs/research/2026-08-11-op2-review-mechanism.md

# Campaign OP slice OP2 — MECHANISM-FAITHFULNESS review

**Date:** 2026-08-11
**Commit under review:** `df9c7a35` — "feat(ui): Campaign OP slice OP2 — tab control,
template ListBox, UIOption widget mappings"
**Lens:** retail-mechanism fidelity + contract fidelity against
`docs/plans/2026-08-10-options-panel-campaign.md` §4 OP2 and
`docs/research/2026-08-10-options-panel-structure.md`.
**Mode:** READ-ONLY. No build, no test run, no launch. Every claim below is either a
quote from committed source, a decode of a committed fixture, or an extract from
`docs/research/named-retail/acclient_2013_pseudo_c.txt`.

## VERDICT: **REJECT**

Two independent MUST-FIX classes, each with hard evidence:

1. **The unconditional `Type 8` mapping (and the `Type 5` mapping) silently rewires four
   already-shipped windows and nine already-shipped list boxes at runtime.** The committed
   test suite cannot see it because the 27 pre-existing fixtures were deliberately NOT
   regenerated, so they deserialize with `TabTable`/`TemplateList` empty. One
   already-committed test (`EffectsUiControllerTests.cs:135-137`) encodes the pre-OP2
   contract and would fail against real DAT data. The slice's own acceptance criterion
   ("no change to any existing widget's behaviour") is false as landed.
2. **The retail mechanism for both new widgets is fully present in the named decomp and
   was not consulted.** `UIElement_Panel::Update/OpenTab/SetupTabPageHash` (Type 8 is
   `UIElement_Panel`, **not** a class called `UIElement_TabControl` — that class does not
   exist in the PDB) and `UIOption_CheckboxBitfield64::CreateChildren/ListenToElementMessage/
   Refresh` are all decompiled. Reading them confirms most of the port, refutes
   `UiCheckboxBitfield64`'s checked-state predicate, refutes its "the dat authors nothing"
   premise, and makes TS-72's stated unknown a non-unknown.

The parts the prompt asked me to independently verify — the two structural identities, the
tab-table decode, the template-list decode, the effective-state discipline, the conformance
pins — are **all correct**. This is a REJECT on blast radius and on two mechanism defects,
not on the Options-panel data work, which is clean.

---

## 1. Property readers (0x2E / 0x64 / 0x72)

### 1.1 Tab table `0x2E` — decode CORRECT, entry filtering DIVERGES

`ElementReader.ReadTabTable` (`src/AcDream.App/UI/Layout/ElementReader.cs:508-527`) decodes
`{0x30 button, 0x31 page, 0x32 isDefault}` and preserves authored array order.

Independently decoded from the committed fixture
`tests/AcDream.App.Tests/UI/Layout/fixtures/options_2100002B.json`, element `0x10000208`
DirectState:

```
P0x58 = Enum(0x1)
P0x2E = Array[4]
    Struct{0x30=Enum(0x1000020D), 0x31=Enum(0x10000212), 0x32=Bool(True)}
    Struct{0x30=Enum(0x1000020E), 0x31=Enum(0x10000211), 0x32=Bool(False)}
    Struct{0x30=Enum(0x1000050B), 0x31=Enum(0x1000050C), 0x32=Bool(False)}
    Struct{0x30=Enum(0x1000020F), 0x31=Enum(0x10000213), 0x32=Bool(False)}
P0x57 = Enum(0x1000001A)
```

This matches research §1.3 / §10.1 exactly (Gameplay default, entry 0; Chat third at
`0x1000050B`/`0x1000050C`). The `Enum`/`DataId`/`Integer` coercion in `ReadStructMemberId`
(`:554-564`) is the right tolerance — the authored kind here is `Enum`.

Retail's own reader is `UIElement_Panel::SetupTabPageHash @0x0046C2E0`. Three filters
acdream does not implement:

| Retail | acdream | Impact |
|---|---|---|
| `BaseProperty::GetPropertyName(entry) != 0x2F` → **skip entry** (`0x0046C3A6`) | any `Struct` accepted | NOTE — every authored entry is `0x2F` |
| `InqProperty(0x30)` or `InqProperty(0x31)` missing → **skip entry** (`0x0046C3E5`, `0x0046C3FC`) | entry added with `0` for the missing member | **SHOULD-FIX** — a partial entry yields `UiTabTableEntry(0, pageId, …)` that still participates in `SwitchTo` and can hide a page |
| `tab != page` required (`0x0046C46B`) | not checked | NOTE |

### 1.2 Template list `0x64` — decode EXACT

`ReadTemplateList` (`:529-545`) decodes `{0x63 layout DID, 0x62 element id}`, in that order.
Retail: `UIElement_ListBox::AddItem(BaseProperty*) @0x0046F170` reads
`InqStructElement(0x63)` then `InqStructElement(0x62)` and calls
`AddItem(did, elementId, parent)`. **Byte-for-byte the same pair, same order.** ✔

Decoded from the committed fixtures (all three arrays, verbatim):

```
0x100001FA (Character) P0x64 = 3 × {0x2100002B, 0x10000216 / 0x10000217 / 0x10000218}
0x10000200 (Config)    P0x64 = 8 × {0x2100002B, 216,217,218,21A,222,220,21D,221}
0x1000050D (Chat)      P0x64 = 9 × {…same 8…, 0x10000520}
```

Identical to research §1.5's table. ✔

### 1.3 Scrollbar `0x72` — correct value, imprecise semantics, missing sibling

`ReadReferencedElementId(info, 0x72)` (`:569-579`) is correct: the authored kind is `Enum`
and retail reads it with `InqEnum`.

Exact retail semantics, from `UIElement_Scrollable::OnSetAttribute @0x00474630` (not cited
anywhere in the commit):

```
0x71 -> m_eHorizonalScrollbarID   (+ UpdateScrollbarSize_(1))
0x72 -> m_eVerticalScrollbarID    (+ UpdateScrollbarSize_(0))
```
resolution is `UIElement::FindRelative(this, id)` validated by `DynamicCast(0xB)` and a
mutual-relative check (`GetScrollbarPointer_ @0x00473EC0`).

- **NOTE:** `ElementInfo.ScrollbarElementId` / `UiTemplateListBox.ScrollbarElementId` should
  be named *vertical*; `0x71` (horizontal) is unread. `0x71` IS authored in already-committed
  fixtures (`vendor_…` `0x100000BD`/`0x100000C5`/`0x100000CE`, `combat_…` `0x100000B6`) — not
  on the Options ListBoxes, so no OP2-observable gap, but the asymmetry deserves a comment.

### 1.4 The round-5 N1 lesson — CORRECTLY OBSERVED

All three readers resolve through `ElementInfo.TryGetEffectiveProperty` (`:215-235`), which
is DirectState-as-base then effective-default override — **not** a per-state first-wins scan.
`ApplyCanonicalLegacyProjection` is invoked from both entry points
(`LayoutImporter.ToInfo` and `ElementReader.Merge:410`), and the three new fields are
*recomputed* from the merged state rather than scalar-merged, which is strictly correct.
No N1 reintroduction. ✔

- **SHOULD-FIX (coverage):** the new conformance tests read `TabTable`/`TemplateList`/
  `ScrollbarElementId` off the **serialized** fixture fields — `LayoutImporter.Build` does not
  re-run the projection at load. So `ReadTabTable`/`ReadTemplateList` are exercised only at
  fixture-generation time and a future regression in either reader would not fail a single
  test. One synthetic `ElementInfo` + `States[Direct].Properties[0x2E]` unit test per reader
  closes this for ~20 lines.

---

## 2. `UiTabControl` — right behaviour, wrong class, wrong lookup, invented fallback

**The core behaviour is confirmed against retail.** `UIElement_Panel::Update @0x0046BD00`:

```
if (arg2 != m_OpenPageToken && arg3 != m_OpenTabToken) {
    m_OpenTabToken = arg3; m_OpenPageToken = arg2;
    foreach (tabId -> pageId) in m_TabPageHash {
        visible = 0; state = 0xB;                                   // Closed
        if (m_OpenTabToken == tabId && m_OpenPageToken == pageId) { visible = 1; state = 0xC; }  // Open
        page = GetChildRecursive(this, pageId);  if (page) page->SetVisible(visible);
        tab  = GetChildRecursive(this, tabId);   if (tab)  tab->SetState(state);
    }
    UIElement::BroadcastElementMessage(this, 0x2C, 0, 0);
}
```

`UiTabControl.SwitchTo` (`src/AcDream.App/UI/UiTabControl.cs:88-103`) does exactly this:
exactly one page `Visible`, every tab button driven to `Open`/`Closed` via
`RetailTabBinding.SetOpen` → `RetailUiStateIds.Open = 12` / `Closed = 11`
(`src/AcDream.App/UI/IUiDatStateful.cs:15-16`) = retail's `0xC`/`0xB`. ✔ The authored data
corroborates independently: the four tab buttons are `Type 0xC` text elements with
`DefaultStateId = 11 (Closed)` and authored state-11 grey `ARGB(255,127,127,127)` vs state-12
`ARGB(255,204,204,204)` font colours.

**The authored default IS honoured on mount** — `OnChildrenAttached` (`:65-81`) picks the
`IsDefault` entry and `SwitchTo`s it, and the fixture proves entry 0 (Gameplay,
`0x1000020D`/`0x10000212`) is the sole default. Retail takes the last `0x32==true` entry;
acdream's loop does too. ✔

Four defects:

- **MUST-FIX (citation).** The class is documented as retail `UIElement_TabControl`
  (`UiTabControl.cs:7`, `DatWidgetFactory.cs:108-109`). **No such class exists** —
  `grep UIElement_TabControl docs/research/named-retail/symbols.json` returns nothing. Type 8
  is `UIElement_Panel` (`UIElement::RegisterElementClass(8, UIElement_Panel::Create)` at
  `0x0046C6B7`). CLAUDE.md's phase checklist requires a named symbol + address; citing a
  fictional class is what let items 2–4 below through. Correct anchors:
  `UIElement_Panel::SetupTabPageHash @0x0046C2E0`, `::Update @0x0046BD00`,
  `::OpenTab @0x0046BE20`, `::InqTabFromPage @0x0046BEB0`,
  `::ListenToElementMessage @0x0046BF90`.
- **SHOULD-FIX.** `FindDirectChild` (`:105-111`) scans immediate children only; retail uses
  `GetChildRecursive` for **both** the tab and the page. Fine for `0x2100002B` (all direct),
  wrong for the Configure Keyboard tab host `0x1000049B` (research §8) this widget is
  explicitly meant to also serve.
- **SHOULD-FIX.** `defaultEntry ??= _tabs[0]` (`:78`) is invented. Retail leaves
  `m_OpenPageToken/m_OpenTabToken` at 0 when no entry authors `0x32`, so `Update(0,0)` hits the
  guard and **no switch happens at all**. Either match retail or file a register row.
- **NOTE.** Retail's `BroadcastElementMessage(this, 0x2C, …)` after each switch, its
  `SetMouseVisible(1)` per tab button during setup (`0x0046C4FB`), and its
  `ListenToElementMessage` handling of `idMessage 0x18` (a page becoming visible re-opens its
  tab; the panel follows its open page's visibility) are unported. Retail also drives
  switching from a child element message (`0x19`/`0x29` → `OpenTab`) rather than a per-button
  click delegate — acdream's `RetailTabBinding.SetClick` adaptation is consistent with the
  existing character/vendor/spellbook tabs, but it is an adaptation and OP3 will need the
  `0x2C` notification for the `OnVisibilityChanged` apply/revert semantics (research §3.6).

### 2.1 **MUST-FIX — the Type-8 arm is unconditional and rewires four shipped windows**

`DatWidgetFactory.cs:110` maps **every** Type-8 element to `UiTabControl`. Type 8 =
`UIElement_Panel`; a Panel without a `0x2E` array is just a panel. Two consequences, both
regressions relative to the previous `_ => new UiDatElement(info, resolve)` fallback:

* `UiTabControl : UiElement` has **no `OnDraw`** — the authored DirectState media is not drawn
  (`UiDatElement.OnDraw`, `src/AcDream.App/UI/Layout/UiDatElement.cs:193-216`).
* `UiElement.ClickThrough` defaults **false**; `UiDatElement` sets it **true**
  (`UiDatElement.cs:111`). Every converted panel now swallows clicks that miss a child.

I decoded the raw `States` bag of every committed fixture (the raw property survives even
though the projected field does not). Pre-existing Type-8 elements:

| Fixture | Element | Size | Authored `P0x2E` | Media | Consequence |
|---|---|---|---|---|---|
| `vendor_21000012_100000B7.json` | `0x1000008D` | 800×20 | **none** | **yes** (`0x06004…`, DirectState) | loses its fill; `RetailUiRuntime.cs:2287` comments that this element "provides its own fill" |
| `vendor_…` | `0x100000B8` | 800×110 | 3 entries (`B9/BC`, `BA/C4`, `BB/CD`) | no | live tab control fights `VendorUiController` |
| `character_2100002E.json` | `0x10000227` (window root) | 300×600 | 3 entries (`228/22B`, `229/22C`, `538/539`) | no | live tab control; entry 3 is the **Titles** tab `CharacterStatController.cs:432` deliberately keeps inert |
| `spellbook_21000034.json` | `0x100002A8` (window root) | 300×600 | 2 entries | no | live tab control vs `SpellbookWindowController` |
| `combat_21000073.json` | `0x100000A2` | 800×60 | **8 entries** (`A3/AA` … `5C2/5C3`) | no | **no controller rebinds these** — `UiTabControl` takes ownership outright and hides 7 of the 8 stance pages |

`VendorUiController`/`SpellbookWindowController`/`CharacterStatController` re-bind their tabs
after import, so their click hijack is overwritten; but `UiTabControl.OnChildrenAttached`
still runs first and mutates `Visible`/state, and **combat has no re-binder at all**.

The minimum correct fix is (a) gate the arm exactly like the Type-5 arm
(`8 when info.TabTable.Count > 0`) so media-bearing plain panels such as `0x1000008D` keep
`UiDatElement`, (b) give `UiTabControl` `UiDatElement`'s media draw + `ClickThrough`
semantics, and (c) explicitly reconcile the four pre-existing hosts — either `UiTabControl`
owns their switching and the duplicated controller code goes, or Type 8 is not mapped
outside `0x2100002B` in this slice.

### 2.2 **MUST-FIX — the same class of regression on the Type-5 arm**

`DatWidgetFactory.cs:99-105` justifies the gate with "none currently reach this factory". That
is refuted by the same raw-property decode. Pre-existing Type-5 elements that **do** author
`P0x64`, and therefore flip from `UiDatElement` to `UiTemplateListBox` at runtime:

| Fixture | Element | Media | Referenced by |
|---|---|---|---|
| `effects_positive/negative_2100001B.json` | `0x10000123` | no | `EffectsUiController.ListId` |
| `examine_2100006B_100005F2.json` | `0x10000149`, `0x10000335`, `0x1000032D` | no | `AppraisalUiController.CreatureStatsListId` / `CreatureExtraListId` / `SpellFormulaListId` |
| `character_2100002E.json` | `0x1000023D` | no | `CharacterStatController.ListBoxId` |
| `character_2100002E.json` | `0x10000532` | **yes** | Titles page list |
| `spellbook_21000034.json` | `0x10000464` | no | `SpellbookWindowController.ComponentListId` |
| `mini_game_2100001E.json` | `0x10000174` | **yes** | mini-game board |

`UiTemplateListBox : UiPanel` zeroes `BackgroundColor`/`BorderColor` (`UiTemplateListBox.cs:92-93`)
and draws no authored media, is not `ClickThrough`, and inserts an anchored `UiScrollablePanel`
as child 0.

**Smoking gun:** `tests/AcDream.App.Tests/UI/Layout/EffectsUiControllerTests.cs:135-137`
already asserts

```csharp
UiElement listHost = Assert.IsType<UiDatElement>(layout.FindElement(EffectsUiController.ListId));
UiItemList list = Assert.IsType<UiItemList>(Assert.Single(listHost.Children));
```

Against real DAT data both assertions now fail (wrong type; two children). It passes only
because `effects_positive_2100001B.json` predates the `TemplateList` field.

**This is also why the commit message's fixture-drift paragraph is wrong.** It states the
regenerated drift was "an Outline/OutlineColor field pair added by an earlier commit,
bcc34ee3". The pre-existing fixtures contain **neither** `Outline`/`OutlineColor` **nor**
`TabTable`/`TemplateList`/`ScrollbarElementId` (grep count 0 for all five in
`character_2100002E`, `vendor_…`, `spellbook_…`, `combat_…`). Regeneration would have
populated the three new fields too — i.e. the decision to revert the drift is exactly what
suppressed the evidence of §2.1/§2.2. Regenerating those 27 fixtures is the acceptance gate
for any fix here.

---

## 3. `UiTemplateListBox` — mechanism faithful

`AddItemFromTemplateList(index)` (`src/AcDream.App/UI/UiTemplateListBox.cs:104-118`)
resolves `Templates[index]` through `TemplateResolver(layoutId, elementId)` and appends the
built subtree. Retail (`UIElement_ListBox::AddItemFromTemplateList @0x0046F2B0` →
`AddItem(BaseProperty*) @0x0046F170` → `AddItem(did, elementId, parent) @0x0046EDC0` →
`UIElementManager::CreateChildElementByDid(this, did, elementId)`) does the same thing: build
the named element out of the named LayoutDesc as a child of the list box, then append.
Instantiating through `LayoutImporter.ImportInfos(dats, layoutId, elementId)` + `Build` is the
correct acdream analogue of `CreateChildElementByDid`, and it is the same overload
`RetailDialogFactory` already uses. ✔ Out-of-range and no-resolver both return null, matching
retail's null returns. ✔

Scrollbar linkage is carried as data (`ScrollbarElementId`) for a page controller to bind to
`Scroll`; that mirrors `ChatWindowController`'s existing pattern. Acceptable for a
"mechanism-only" slice — see §1.3 for the naming/`0x71` notes.

- **NOTE.** Row stacking uses `_viewport.ContentHeight` as the next row's `Top`
  (`:114-116`). Retail sizes the box from `CalculatePaperSize` and the ListBox owns row
  placement; the acdream model is equivalent for uniform top-anchored rows and is the same
  model `CharacterStatController.RebuildActiveList` already uses. Fine.
- **NOTE.** Authored dat children of a `UiTemplateListBox` land as siblings of the internal
  viewport (the class does not override `AddChild`), while template rows go inside it. Benign
  for the Options ListBoxes (no authored children) but relevant to §2.2's converted lists.

---

## 4. The two structural identities — **BOTH CONFIRMED** (independent check)

I decoded the fixture myself rather than taking the commit message's word.

### 4.1 `UIOption_Slider 0x10000037` ≡ horizontal `UIElement_Scrollbar` — **CONFIRMED**

`options_2100002B.json` element `0x1000021C`:

```
0x1000021C T=0x10000037 (146,4) 120x12  DirectState image 0x060012C5
  P0x7B=Bool(True) P0x86=Float(0.5) P0x7C=Bool(True) P0x7E=Bool(False)
  P0x82=Bool(False) P0x83=Bool(True)   [+ P0x47/P0x48/P0x4B, see below]
  child id=1 T=0x1 7x12  DirectState image 0x060012C6
```

Compare the real `Type 0xB` scalar slider in `combat_21000073.json`, element `0x1000004F`
(gmCombatUI desired-power):

```
0x1000004F T=0xB 707x14
  P0x7B=Bool(True) P0x86=Float(0.5) P0x7C=Bool(True) P0x7E=Bool(False)
  P0x82=Bool(False) P0x83=Bool(False)
  child id=1 T=0x1 12x14   child id=4 T=0x3   child T=0x7 (meter)
```

**Identical property fingerprint, identical `child id = 1` thumb convention, `W > H`.**
`BuildScrollbar`'s horizontal branch (`DatWidgetFactory.cs:223-279`) reads exactly
`DefaultImage(info)` for the track and `child id 1` for the thumb. The identity holds; the
mapping is correct and the conformance test (`OptionsPanelFixture_SliderControl_BuildsAs…`)
pins `Horizontal == true` and a non-zero thumb sprite. ✔

### 4.2 `UIOption_Menu 0x10000038` ≡ `UiMenu`'s shape — **CONFIRMED**

```
options_2100002B  0x10000224 T=0x10000038 120x18
  P0x2 P0x6 P0x7=DID(0x21000043) P0x8 P0x9 P0xA=DID(0x21000043) P0x13  [+0x47/0x48/0x4B]
  children: 0x10000355 T=0xC 100x18 (label)   0x10000356 T=0x3 17x19 (arrow cap)

vendor_…         0x100000BF T=0x6 (UIElement_Menu) 117x18
  P0x2 P0x6 P0x7=DID(0x21000043) P0x8 P0x9 P0xA=DID(0x21000043) P0x13
  children: 0x1000034D T=0xC 100x18 (label)   0x1000034E T=0x3 17x19 (arrow cap)
```

Same seven properties, the same popup-template DID `0x21000043`, the same 100×18 label +
17×19 arrow-cap child pair. `new UiMenu()` is right, and it matches how the existing Type-6
arm is built. ✔

- **NOTE (both identities).** The `UIOption_*` family carries an extra authored triple
  `P0x47=Enum(0x10000397)`, `P0x48=DID(0x21000041)`, `P0x4B=Bool(True)` that the plain
  Type-6/Type-11 counterparts do not. It is on the slider, the menu, **and** the already-mapped
  `UIOption_Checkbox 0x10000219`, so it is a pre-existing uniform gap rather than something
  OP2 introduced — but somebody should establish what `0x21000041/0x10000397` is (it looks like
  a shared tooltip/option-chrome base pair) before OP4–OP6 rely on those rows rendering
  completely.

---

## 5. `UiOptionToggleSlider` / `UiCheckboxBitfield64` and TS-72

### 5.1 `UiOptionToggleSlider` — consistent with the authored templates ✔

Fixture-verified: `0x10000220` (272×20) and `0x10000221` (272×36) are both
`T=0x10000036` and both contain exactly one `0x10000219` (`T=0x10000035`, checkbox) and one
`0x1000021C` (`T=0x10000037`, slider); `0x10000221` additionally carries the two range-label
`Type 0xC` children `0x1000021E`/`0x1000021F`. Composing rather than consuming children is
right, and `OnChildrenAttached` (`src/AcDream.App/UI/UiOptionToggleSlider.cs:33-42`) picks the
first `UiButton` and first `UiScrollbar`, which is unambiguous for both templates. The
"labelled slider row `0x1000021D` is a plain `Type 3`, not `0x10000036`" test is a genuinely
good data-driven discriminator. ✔

### 5.2 `UiCheckboxBitfield64` — **MUST-FIX ×2**

**(a) The checked-state predicate is wrong.** `IsSet` (`src/AcDream.App/UI/UiCheckboxBitfield64.cs:137-138`)
requires **all** mask bits set. Retail `UIOption_CheckboxBitfield64::Refresh @0x004859C0`:

```
lowHit  = m_current.low  & mask.low;
highHit = m_current.high & mask.high;
allSet  = (lowHit == mask.low && highHit == mask.high);      // computed…
ebx     = ((lowHit | highHit) != 0) ? 0 : 1;                 // …but the VISIBLE flag is ANY-set
row     = UIElement_ListBox::GetItem(this, i);
cb      = UIElement::GetChild(row, 0x10000219);
UIElement::SetAttribute_Bool(cb, 0xE, ebx == 0);             // checked  <=>  ANY mask bit set
```

Retail checks the box when **any** bit of the mask is set; acdream only when **all** are. This
matters immediately: 8 of the 13 Chat filter masks are multi-bit
(Gameplay `0x83912021`, Combat `0x00600040`, Magic `0x00020080`, AreaSpeech `0x00001004`,
Tells `0x00000018`, Allegiance `0x00040C00`, …). The click direction is derived from the
displayed state on both sides, so a wrong predicate inverts the next click too.

**(b) The toggle math is NOT unknown — TS-72's premise is false.**
`UIOption_CheckboxBitfield64::ListenToElementMessage @0x00485AE0`:

```
if (idMessage == 1
    && GetAttribute_Int (pElement, 0x10000084, &index)      // row index stamped at build time
    && GetAttribute_Bool(pElement, 0xE, &onOff)             // the row checkbox's new state
    && index < childCount)
{
    BitUtils::SetBitsOnOrOff(&m_current, m_rgChildValues[index].mask, onOff);
    vtable+0x2D4 (1);                                        // Apply(1)
}
return UIElement_ListBox::ListenToElementMessage(this, edi);
```

`SetBitsOnOrOff(value, mask, on)` **is** "on ⇒ OR mask, off ⇒ AND-NOT mask" — so
`ToggleRow` (`:140-155`) is *correct*, and TS-72's claim that "the decompiled excerpt this
campaign pulled covers `Apply`'s WRITE side, not its own click-handler's bit math" describes
what the campaign grepped, not what exists. Every method is in
`acclient_2013_pseudo_c.txt` and `symbols.json`: `CreateChildren @0x00485DF0`,
`AddChild @0x004862A0`, `Refresh @0x004859C0`, `ListenToElementMessage @0x00485AE0`,
`GetValue @0x00486150`, `Changed/SaveCurrentValue/RestoreSavedValue/RestoreDefaultValue`
`@0x004856A0…0x00485780`. **TS-72 is therefore not an accurate statement of what is and is
not verified.** It should be rewritten (or retired) to say: the OR/AND-NOT half is
byte-confirmed correct; the checked-state predicate is byte-confirmed **wrong**.

**(c) "The template authors zero children" is refuted by the committed fixture.**
`BuildCheckboxBitfield64` (`DatWidgetFactory.cs:810-815`) reads nothing from `ElementInfo`,
and the class doc (`UiCheckboxBitfield64.cs:11-14`) plus the commit message assert the
template "carries NO children and NO media". The actual authored element:

```
0x10000520 T=0x10000044 272x100
  P0x64        = Array[1] -> Struct{0x63=DID(0x2100002B), 0x62=Enum(0x10000521)}
  P0x10000082  = DID(0x06004D17)
  P0x10000083  = DID(0x06004D19)
```

It authors **its own row-template list** — the very `0x64` property this commit taught the
reader to decode — naming `0x2100002B/0x10000521`, plus two RenderSurface DIDs (which are the
LED sprite's `Highlight`/`Ghosted` images, `0x06004D17`/`0x06004D19`). `0x10000521` is a
272×20 container holding `0x10000219` (`Type 1`, base `0x21000044/0x10000329`) with the 13×13
five-state LED child `0x10000328` — i.e. exactly the row art. Research §1.5 flagged
`0x10000521` as "UNKNOWN consumer"; **this fixture closes that unknown** (research U10 too),
and the decomp confirms it:

```
UIOption_CheckboxBitfield64::CreateChildren @0x00485DF0
  for i in 0 .. m_rgChildValues.m_num-1:
      row = UIElement_ListBox::AddItemFromTemplateList(this, 0, nullptr);   // template idx 0
      cb  = GetChildRecursive(row, 0x10000219)->DynamicCast(1);
      SetAttribute_Int(cb, 0x10000084, i);
      UIElement_Text::SetStringInfo(cb, childValues[i].siLabel);
      UIElement::SetTooltip       (cb, childValues[i].siTooltip);
  ResizeTo(GetWidth(), CalculatePaperSize(0, -1));
  Refresh();
```

`UIOption_CheckboxBitfield64` **is a `UIElement_ListBox`** — it calls
`UIElement_ListBox::AddItemFromTemplateList`/`GetItem`/`CalculatePaperSize`/
`ListenToElementMessage` on itself. So the faithful acdream port is
`UiCheckboxBitfield64` composing the `UiTemplateListBox` mechanism **this same commit
shipped**, not a hand-rolled `UiPanel` of synthesized `UiButton`s. As written, `AddChild`
(`:108-135`) fabricates an `ElementInfo{Type=1, Height=RowHeight}` with a hand-injected
`0x0B` property and an invented `RowHeight = 14f` whose comment claims "No authored row
height exists for this block (it is unauthored in the dat)" — the dat authors 272×20 with a
260×14 checkbox inset at (6,2). Consequences as landed: no LED art, no authored font
(`0x40000002`), no authored colour (`0x1B`), no authored label insets (`0x23`/`0x25`), no
justification (`0x14=Left`), no tooltip plumbing, and no outline seeding.

`AddChild(uint64 mask, uint32 labelId, uint32 tooltipId) @0x004862A0` is also confirmed to be
pure bookkeeping (append a `ChildInfo{mask, StringInfo(label, tableEnum **0x10000006**),
StringInfo(tooltip, 0x10000006)}`) — note the table enum is `0x10000006`, not the `0x10000003`
used for headers/labels elsewhere. Worth pinning for OP5.

---

## 6. Outline seams (`aa6635ae` / AP-192) — **PRESERVED**

I scanned all five new fixtures for authored `0x21`/`0x22`. Every occurrence (32 total) is
`0x21 = Bool(True)` **in state 3 only**, on `Type 1` buttons: the three
Apply/Reset/Defaults buttons on each of Character/Chat/Config, and the seven Gameplay-tab
buttons. Those build through the untouched `BuildButton`, whose effective-default resolution
correctly yields outline-off — precisely the AP-192 deferral, unchanged. No authored `0x22`
anywhere; no authored `0x21` on any element reaching a *new* build path. ✔

- **NOTE.** `new UiMenu()` for `0x10000038` does not seed `Outline`/`OutlineColor` — but
  neither does the pre-existing Type-6 arm, and `UiMenu`'s own doc records "No authored menu
  element carries it today", which the Options menu `0x10000224` confirms (no `0x21`/`0x22`
  on it or its label child). Unchanged, not regressed.
- **NOTE (folds into §5.2c).** `UiCheckboxBitfield64`'s synthesized rows have no outline
  seeding either — but that is a symptom of bypassing the authored template, not a separate
  defect. Building the rows through `AddItemFromTemplateList` gets the seam for free via
  `BuildCheckbox`.

---

## 7. Conformance tests vs research §10.1 — **ACCURATE**, coverage thin in two places

I spot-checked every pinned constant against the research doc and the fixtures. All correct:

| Test | Pins | Research §10.1 / §1.3 / §1.5 | Verdict |
|---|---|---|---|
| `…TabControl_HasFourEntriesInAuthoredOrder_GameplayDefault` | `020D/0212 default`, `020E/0211`, `050B/050C`, `020F/0213`, `Assert.Single(IsDefault)` | identical | ✔ |
| `CharacterListBoxFixture_TemplateList_…` | 3 × `{0x2100002B, 216/217/218}` | identical | ✔ |
| `ConfigListBoxFixture_TemplateList_…` | 8, order `216,217,218,21A,222,220,21D,221` | identical | ✔ |
| `ChatListBoxFixture_TemplateList_…` | 9, + `0x10000520` | identical | ✔ |
| scrollbar linkage ×3 | `0x100001FB`, `0x10000201`, `0x10000201` | identical | ✔ |
| `CharacterListBox_TemplateMechanism_ReachesSixHeadersAndFortyNineToggles` | `{3,15,6,11,7,7}` = 49 under 6 headers; `6*22 + 49*20` content height | §7 counts; template heights 292×22 / 272×20 confirmed in fixture | ✔ |
| `UiTabControl_*` ×5 | default mount, exactly-one-visible, Open/Closed flip, click-through, no-op | matches `UIElement_Panel::Update` | ✔ |

Two gaps:

- **SHOULD-FIX.** No test pins the reader itself (see §1.4) — every "reader" test actually
  reads a serialized field.
- **SHOULD-FIX.** `UiCheckboxBitfield64_AddChild_TracksMaskAndTogglesOnClick` deliberately
  picks the single-bit `Error` mask (`0x04000000`) because it "round-trips cleanly" — which is
  exactly the case that cannot distinguish acdream's all-set predicate from retail's any-set
  predicate. A multi-bit mask (Combat `0x00600040`) against a partially-set current value is
  the test that would have caught §5.2a.
- **NOTE.** The plan's OP2 contract cites "tab-button ↔ page-slot switching per lane A §5".
  §5 is the Chat-tab row map; the tab control is §1.3 and its host is §1.4. The implementer
  cited the right sections; the plan's cross-reference should be corrected so OP8 does not
  chase §5.

---

## Summary of classifications

**MUST-FIX**
1. `DatWidgetFactory.cs:110` — unconditional `Type 8 → UiTabControl` converts four shipped
   Type-8 hosts (vendor `0x100000B8`, character `0x10000227`, spellbook `0x100002A8`, combat
   `0x100000A2` — the last with **no** controller re-binder) and strips `UiDatElement` media
   drawing + `ClickThrough` from the media-bearing vendor backdrop `0x1000008D`.
2. `DatWidgetFactory.cs:104` — the Type-5 gate's "none currently reach this factory" is false;
   nine shipped ListBoxes author `P0x64` (effects, examine ×3, character ×2, spellbook,
   mini-game). `EffectsUiControllerTests.cs:135-137` already encodes the pre-OP2 contract and
   fails against real DAT data. Fixture staleness — not correctness — is what keeps the suite
   green; regenerating the 27 fixtures is the acceptance gate for the fix.
3. `UiCheckboxBitfield64.cs:137-138` — checked-state predicate is all-bits-set; retail
   (`Refresh @0x004859C0`) is any-bit-set.
4. `UiCheckboxBitfield64` / `DatWidgetFactory.cs:810` — the template `0x10000520` **does**
   author content (`P0x64 → 0x2100002B/0x10000521`, plus `P0x10000082`/`P0x10000083`); retail
   `CreateChildren @0x00485DF0` builds every row through `AddItemFromTemplateList(0)`. The
   synthesized `ElementInfo` + invented `RowHeight = 14f` must be replaced by the authored
   template path, and the false "unauthored in the dat" comments removed.
5. `UiTabControl.cs:7` / `DatWidgetFactory.cs:108` — cite `UIElement_Panel`
   (`SetupTabPageHash @0x0046C2E0`, `Update @0x0046BD00`, `OpenTab @0x0046BE20`); the named
   class `UIElement_TabControl` does not exist in the PDB.
6. `docs/architecture/retail-divergence-register.md` TS-72 — inaccurate as written; the click
   math is in the decomp, the OR/AND-NOT half is confirmed right and the predicate half is
   confirmed wrong. Also missing rows for the invented bitfield row geometry and the dropped
   `0x64`/`0x10000082`/`0x10000083` authored data.

**SHOULD-FIX**
7. `ReadTabTable` must skip entries missing `0x30`/`0x31` (retail `0x0046C3E5`/`0x0046C3FC`).
8. `UiTabControl.FindDirectChild` → recursive descendant lookup (retail `GetChildRecursive`).
9. `defaultEntry ??= _tabs[0]` is invented; retail performs no switch when nothing authors
   `0x32`.
10. Add reader-level unit tests for `0x2E`/`0x64`/`0x72` (fixture tests only pin serialized
    values).
11. Add a multi-bit-mask `UiCheckboxBitfield64` test.

**NOTE**
12. `0x2F` MasterPropertyId and `tab != page` filters unimplemented (harmless today).
13. `0x72` is specifically the **vertical** scrollbar (`UIElement_Scrollable::OnSetAttribute
    @0x00474630`); `0x71` (horizontal) is unread though authored in vendor/combat layouts.
14. `BroadcastElementMessage(0x2C)`, `SetMouseVisible(1)`, and the `idMessage 0x18`
    visibility-follow path are unported — OP3 needs the first for §3.6 semantics.
15. The `UIOption_*` `P0x47/P0x48/P0x4B` triple (`0x21000041/0x10000397`) is unread across the
    whole family, including the pre-existing checkbox mapping.
16. `UIOption_CheckboxBitfield64::AddChild` uses string table enum `0x10000006`, not
    `0x10000003` — pin for OP5.
17. Research §1.5's "`0x10000521` … UNKNOWN consumer" and §10.5 U10 are now closed by the
    committed fixture; the research doc should be updated.
18. The plan's OP2 contract cites "lane A §5" for the tab host; the correct sections are §1.3
    (tab table) and §1.4 (host).
19. The commit message's fixture-drift paragraph understates the drift (three new fields, not
    one pair).

---

## Appendix — retail extracts used (all from `docs/research/named-retail/`)

| Symbol | Address | Used for |
|---|---|---|
| `UIElement::RegisterElementClass(8, UIElement_Panel::Create)` | `0x0046C6B7` | Type 8 identity |
| `UIElement_Panel::SetupTabPageHash` | `0x0046C2E0` | `0x2E` entry filters, default selection, `Update(page, tab)` tail |
| `UIElement_Panel::Update` | `0x0046BD00` | one-visible-page + `SetState(0xB/0xC)` + `Broadcast(0x2C)` |
| `UIElement_Panel::OpenTab` / `InqTabFromPage` / `ListenToElementMessage` | `0x0046BE20` / `0x0046BEB0` / `0x0046BF90` | switching entry points, `0x18`/`0x19`/`0x29` messages |
| `UIElement_ListBox::AddItemFromTemplateList` | `0x0046F2B0` | `0x64` array indexing |
| `UIElement_ListBox::AddItem(BaseProperty*)` | `0x0046F170` | `0x63`/`0x62` struct member order |
| `UIElement_ListBox::AddItem(did, elementId, parent)` | `0x0046EDC0` | `CreateChildElementByDid` seam |
| `UIElement_Scrollable::OnSetAttribute` | `0x00474630` | `0x71` horizontal / `0x72` vertical |
| `UIElement_Scrollable::GetScrollbarPointer_` | `0x00473EC0` | `FindRelative` + `DynamicCast(0xB)` validation |
| `UIOption_CheckboxBitfield64::CreateChildren` | `0x00485DF0` | rows built from template index 0 |
| `UIOption_CheckboxBitfield64::ListenToElementMessage` | `0x00485AE0` | `SetBitsOnOrOff` click math |
| `UIOption_CheckboxBitfield64::Refresh` | `0x004859C0` | any-bit-set checked predicate |
| `UIOption_CheckboxBitfield64::AddChild` | `0x004862A0` | `ChildInfo{mask,label,tooltip}`, table enum `0x10000006` |
| `UIElement::RegisterElementClass(0x10000037/38/36/44, …)` | `0x0048522A` / `0x0048436A` / `0x00484A3A` / `0x00485EDA` | the four UIOption class ids |

Fixture decodes were performed with a throwaway JSON reader over the committed
`tests/AcDream.App.Tests/UI/Layout/fixtures/*.json` (scratchpad only, not committed). Nothing
in the repository was modified except this document.