acdream/docs/research/2026-08-24-campaign-ct-dat-ground-truth.md

Campaign CT slice CT1 — DAT ground truth for the character panel (0x2100002E)

Status: RESEARCH COMPLETE 2026-08-24. No production code changed in this slice. Findings feed CT2–CT6 (docs/plans/2026-08-24-character-panel-parity-campaign.md).

Method: temporary Assert.Fail probe tests (deleted before commit; the pattern is preserved in tests/AcDream.App.Tests/UI/Layout/ScrollbarSkinLiveDatTests.cs and its sibling CharacterPanelLiveDatTests.cs written by this slice) against the installed DAT set (%USERPROFILE%\Documents\Asheron's Call), driven through LayoutImporter.ImportInfos / ElementInfo (src/AcDream.App/UI/Layout/ElementReader.cs, src/AcDream.App/UI/Layout/LayoutImporter.cs).

1. Header elements (gmStatManagementUI content, sub-layout under 0x2100002E)

All header elements are DUPLICATED — the imported 0x2100002E tree carries two structurally identical copies of the whole header block, one reached through the Attributes page chain (0x10000227 > 0x1000022B > 0x10000226 > 0x10000230) and one through the Skills page chain (... > 0x1000022C > ...). The two copies are geometrically and stylistically IDENTICAL — this is the "duplicated stat-management branches" quirk documented on PrepareSkillScrollbar in CharacterStatController.cs. Caveat: this "identical" claim rests on the deleted probe tests, not the committed pins. CharacterPanelLiveDatTests.HeaderElements_AuthorExpectedFontsAndColors only asserts font/color/margin equality across the two copies (and the 2-count) — it does not assert X/Y/W/H geometric equality between them. Treat "geometrically identical" as probe-session observation, not a pinned fact, until a future slice adds a geometry-equality assertion.

Coordinate frame: every X,Y below is parent-relative, not page-relative — e.g. Name 0,0 means the top-left of its immediate parent container (0x10000230), not the top-left of the Attributes/ Skills page. Cross-reference docs/research/2026-06-25-character-window-faithful-spec.md for the page-relative numbers if you need the header block's position within the page itself; do not mix the two frames when placing elements.

Element	Id	X,Y	W×H	HJustify	VJustify	FontDid	FontColor	Outline	Margins
Name	0x10000231	0,0	230×20	Center	Center	0x40000001	white (1,1,1,1)	false	0
Heritage line	0x10000232	0,20	230×15	Center	Center	0x40000002	white (1,1,1,1)	false	L5 R5
PK line	0x10000233	0,35	230×15	Center	Center	0x40000002	white (1,1,1,1)	false	0
Level	0x1000023B	235,35	65×50	Center	Center	0x40000010	(1, 0.9490196, 0.49803922, 1)	true	0
Total XP	0x10000235	130,70	100×18	Right	Center	0x40000000	white	false	0
XP meter	0x10000236 (Type 7)	0,88	230×17	—	—	—	—	—	—
XP-next label (child of meter)	0x10000237	0,0	130×17	Left	Center	0x40000000	white	false	0
XP-to-level value (child of meter)	0x10000238	130,0	100×17	Right	Center	0x40000000	white	false	0
Luminance label	0x100005C5	0,52	110×18	Left	Center	0x40000000	white	false	0
Luminance value	0x100005C6	110,52	120×18	Right	Center	0x40000000	white	false	0

Header block container (0x10000230) is 300×110 inside the shared prototype layout 0x21000045 — the character content column itself is only 230px wide (name/heritage/PK/XP all live in that 230px column), with a 5px vertical divider (0x10000239, X=230, W=5) separating it from the level box (X=235..300, matching the plan's "Level area (65,50)" spec).

Confirmations vs. the owner report / plan:

• Item 4 (PK line pure white): CONFIRMED — 0x10000233 FontColor is exactly white, not the "color off" state the owner reported. The bug is purely in CharacterStatController.Bind's runtime color choice (Body = parchment (0.92,0.90,0.82,1)), not a DAT-reading gap. CT4 must switch the PK-line color to Vector4.One.
• Item 5 (level color): CONFIRMED DIVERGENT. DAT-authored level color is (1, 0.9490196, 0.49803922, 1) (a pale gold, ~RGB 255/242/127) with Outline=true. CharacterStatController.Gold is currently (1, 0.82, 0.36, 1) (a deeper orange-gold) with no outline applied. CT4 should read the DAT FontColor + Outline directly instead of hand-picking a runtime color, matching how LevelId's dat FontDid is already honored.

2. Stat list (0x1000023D) + row templates

0x1000023D (Type 5 ListBox) is duplicated the same harmless way as the header (once per Attributes/Skills page chain, identical geometry both times): X=0 Y=112 W=300 H=160, ScrollbarElementId=0x1000023E (scrollbar at X=281 W=16 H=160, i.e. always reserved, whether or not it's shown). Its authored TemplateList (dat property 0x64) names FIVE same-layout-family entries, all in LayoutDesc 0x21000045:

0x10000248, 0x10000249, 0x1000024A, 0x1000024B, 0x1000024C

These are NOT reachable by walking ImportInfos(dats, 0x21000045u)'s built tree — LayoutImporter.ImportInfos intentionally filters out same-layout template-list targets (the #375 fix documented in LayoutImporter.ImportInfos's own comment: "retail never instantiates a template-list element as a live widget… building them here parked two live prototype rows… over and outside the framed panel"). The correct read path — and the one CT5 must use — is the targeted single-root overload: LayoutImporter.ImportInfos(dats, 0x21000045u, templateElementId), the same seam UiTemplateListBox's TemplateResolver already uses for other authored row templates.

Dumping all five with that overload:

0x10000248 — the ONE shared data-row template (icon + name + value)

Id=0x10000248 Type=3 (container)  X=0 Y=0 W=282 H=20
  StateMedia[Normal]    File=0x06004CC2 DrawMode=1
  StateMedia[Highlight] File=0x06000F93 DrawMode=1
  Id=0x10000129 Type=3 (icon slot)   X=0   Y=0 W=20 H=20   (no own media — set per-row at runtime)
  Id=0x1000012A Type=0xC (name text) X=25  Y=0 W=150 H=20  HJustify=Left  FontDid=0x40000001 white
  Id=0x1000012B Type=0xC (value text)X=175 Y=0 W=100 H=20  HJustify=Right FontDid=0x40000001 white

This is the single row template used for BOTH the attribute rows AND the skill rows (retail's gmAttributeUI/gmSkillUI share it). Ground truth for item 1 (icon alignment) and item 2 (value-column gutter):

• Icon: 20×20, flush at the row's left edge (X=0), full row height. Current code (CharacterStatController.IconSize = 16f, RowPadX = 4f) draws a 16×16 icon at X=4 — smaller AND offset from retail's flush-left 20×20. This is the "icons misaligned" bug (item 1).
• Name column: X=25, W=150 (fixed pixel widths, not a width fraction). Current code computes nameX = RowPadX + IconSize + IconGap (4+16+6=26, off by one from retail's 25) and nameW = width * 0.60 (a content-relative fraction retail does not use at all — retail's name column is a FIXED 150px regardless of the 282px row width).
• Value column: X=175, W=100, right-justified. Value's right edge sits at X=275. The row template itself is 282px wide, so there is a 7px gap between the value's right edge and the row's own right edge — this is the "authored margin between the value column and the border" the owner reported (item 2), confirmed as exactly 7px at the row-template level.
• The bare authored rectangles (no derived arithmetic — see the caveat below): ListBox 0x1000023D is X=0 Y=112 W=300 H=160; its scrollbar 0x1000023E is X=281 W=16 H=160; the data row template is W=282; the value column inside the row is X=175 W=100, right-justified, 7px from the row's own right edge (282 - (175+100) = 7).
• These numbers do NOT compose into a tidy "gutter" story — do not infer one. 300 - 281 = 19, not the row's 282px width's complement (300 - 282 = 18); and the 282px row actually OVERLAPS the 281px scrollbar band by 1px (281 < 282). An earlier draft of this doc described the row as "inset by 18px to clear an always-reserved scrollbar gutter" and summed 18+7=25 — that decomposition does not close against the authored numbers above and is inference, not fact; withdrawn. CT5 must implement the authored numbers directly (row width 282 — matches the existing SkillContentWidth = 282f constant already in the code; value column X=175 W=100; scrollbar X=281 W=16), never a derived listWidth - 18 or similar formula.
• Row background: Normal state file 0x06004CC2. The description "generic panel-chrome fill used elsewhere client-wide" is UNVERIFIED — no cross-reference sweep for other consumers of 0x06004CC2 was run this slice; only the file id itself, as authored on this specific template, is pinned. Highlight state file 0x06000F93.

SEALED VERDICT: RowHighlightSprite is wrong, not merely flagged

Retail's selected attribute/skill row draws the row template's Highlight state media — 0x06000F93, not CharacterStatController's current 0x06001397u. This is no longer a hedge; the decomp confirms the mechanism end to end:

• gmAttributeUI::UpdateSelection @0x0049DEE0 calls SetState(selected ? 6 : 1) on the row.
• InfoRegion::SetState @0x004F0EE0 forwards that state to the row element instantiated from template 0x10000248 — the exact template this slice dumped, whose Highlight-state file is 0x06000F93.
• State 6 IS UIStateId.Highlight — so the selected row draws 0x10000248's own Highlight media, not a separately-chosen sprite.

CharacterStatController.cs's comment near lines 111–113 ("matches retail... sprite 0x06001397 visual intent") is falsified for this element. CT5 must correct RowHighlightSprite to 0x06000F93 for the STAT rows and should reconsider UseSelectionBars/HighlightBg, which currently emulate the wrong sprite's art (a translucent gold tint tuned to look like 0x06001397's dark bars, not 0x06000F93's actual look).

0x06001397 is not a phantom constant — it is legitimate ELSEWHERE. The spellbook row prototype 0x10000343 has a separate selected-overlay CHILD element 0x10000342 whose media IS 0x06001397 (UIElement_UIItem::SetSelectedState @0x004E1240 mechanism — a different code path from InfoRegion::SetState, and a different visual composition: an overlay child, not a state-swap on the row itself). CT5 must correct the STAT rows ONLY and must NOT touch SpellbookRowStyle.cs or its tests — 0x06001397 is correct there.

0x10000249 / 0x1000024A / 0x1000024B / 0x1000024C — skill SECTION HEADER captions

Id=0x10000249 Type=0xC  X=0 Y=0 W=280 H=20  HJustify=Left  Margins L5 R5  FontDid=0x40000001  StateMedia[]=0x06000F90
Id=0x1000024A Type=0xC  X=0 Y=0 W=280 H=20  HJustify=Left  Margins L5 R5  FontDid=0x40000001  StateMedia[]=0x06000F86
Id=0x1000024B Type=0xC  X=0 Y=0 W=280 H=20  HJustify=Left  Margins L5 R5  FontDid=0x40000001  StateMedia[]=0x06000F98
Id=0x1000024C Type=0xC  X=0 Y=0 W=280 H=20  HJustify=Left  Margins L5 R5  FontDid=0x40000001  StateMedia[]=0x06000F89

These are single full-width caption bars (no icon/name/value split), 280px wide (2px narrower than the data row — no scrollbar-gutter inset needed since they never scroll independently). Their sprites are an EXACT match for the existing constants already in CharacterStatController.cs:

Constant	Value	Probe file	Match
SkillHeaderSpecializedSprite	0x06000F90	0x10000249	YES
SkillHeaderTrainedSprite	0x06000F86	0x1000024A	YES
SkillHeaderUntrainedSprite	0x06000F98	0x1000024B	YES
SkillHeaderUnusableSprite	0x06000F89	0x1000024C	YES

These four are correctly ported already; no CT5 work needed here.

Row-height divergence (CT5 gold, found this fix round)

The row template above authors H=20 (line Id=0x10000248 Type=3 (container) X=0 Y=0 W=282 H=20, already pinned by CharacterPanelLiveDatTests.AttributeRowTemplate_...). Current code matches this for skill rows (CharacterStatController.SkillRowHeight = 20f) but NOT for attribute rows, which use a separate CharacterStatController.RowHeight = 22f constant. CT5 must fix the attribute-row path to 20px; there is no authored basis for 22 anywhere in the row template.

Row instantiation + icon-DID anchors (CT5 gold, found this fix round)

InfoRegion::InfoRegion @0x004F1450 instantiates each stat row via AddItemFromTemplateList(listBox, 0, ...) — template index 0, i.e. 0x10000248, the shared data row confirmed above — and binds 0x1000012A (label), 0x1000012B (value), 0x10000129 (icon) via UIRegion::SetImageByDID(icon, did, 3) (icon draw mode 3). Per-attribute icon DIDs come from DBObj::GetDIDByEnum(statEnum, category 0x10000002) in gmAttributeUI::PostInit @0x0049DB70 — a THIRD consumer of the GetDIDByEnum master-map mechanism documented in §5 below (alongside the title EnumMapper/StringTable pair and RetailKeyNames), which is enough precedent that CT2/CT5 should factor a shared GetDIDByEnum(enumValue, category) helper instead of hardcoding a third independent DID pair.

gmSkillUI::RebuildSkillList @0x0049C3A0 adds template indices 1–4 (0x10000249..0x1000024C) for the section-header captions, confirming the section-header order already pinned by SkillSectionHeaderTemplates_MatchExistingSpriteConstants above: Specialized, Trained, Untrained, Unusable.

3. Titles page (0x10000539 subtree, imported as part of 0x2100002E)

0x10000539 (Type 0x10000046, the Titles page container) is NOT duplicated like the Attributes/Skills content — it appears once, as a direct child of the tab-control root 0x10000227 (siblings with the Attributes/Skills tab buttons and the Titles tab button 0x10000538). Geometry: X=0 Y=25 W=300 H=575 (fills the window below the 25px tab bar).

Element	Id	X,Y	W×H	Notes
(unlabeled caption)	0x1000052E	8,20	270×18	Left, margin L6, FontDid 0x40000001 white — likely "Current Title:" caption
Current display title text	0x1000052F	8,40	270×18	Center, margins L5 R5, FontDid 0x40000001 white
divider	0x10000530	0,60	300×9	sprite 0x06001420
(unlabeled caption)	0x10000531	8,70	270×18	Left, margin L6 — likely "Titles Earned:" caption
Title ListBox	0x10000532	8,90	270×455	ScrollbarElementId=0x10000533; TemplateList: LayoutDid=0x2100005E, ElementId=0x10000536
Title scrollbar	0x10000533	280,90	16×455	shared RetailScrollbarChrome media (thumb/up/down ids identical to the base skin pinned by ScrollbarSkinLiveDatTests)
divider	0x10000534	0,550	300×9	sprite 0x06001420
"Set as Display Title" button	0x10000535	53,560	200×32	MinWidth=65, margins L7 R7, FontDid 0x40000001 white, DefaultState=Ghosted (matches the plan's UpdateButtons ghost-when-current contract); three-slice chrome children 0x100002CE/CF/D0 with Normal/Normal_rollover/Normal_pressed/Ghosted states each

Title row template — LayoutDesc 0x2100005E, element 0x10000536

Id=0x10000536 Type=3 (container)  X=0 Y=0 W=270 H=24
  StateMedia[DirectState, key ""]  File=0x06004CCA DrawMode=3
  StateMedia[Highlight]            File=0x06001AAF DrawMode=1
  Id=0x10000537 Type=0xC (text)  X=0 Y=0 W=270 H=24  HJustify=Left  Margins L6 R6  FontDid=0x40000001 white

A single-line text row, no icon column (titles have no per-row icon in retail) — 24px tall vs. the stat rows' 20px. Row width 270 matches the ListBox content width exactly (0x10000532 is 270 wide, with its scrollbar 0x10000533 living OUTSIDE that width at X=280 — unlike the stat list, the title row template does NOT need its own internal scrollbar-gutter inset because the ListBox width itself already excludes the scrollbar column).

Same targeted-root import gotcha as the stat templates applies here: LayoutImporter.ImportInfos(dats, 0x2100005Eu) (the whole-layout overload) returns the SAME element 0x1000052D, but does NOT surface 0x10000536 as a reachable child. 0x1000052D is not a throwaway container — per the BaseElement/BaseLayoutId table in docs/research/2026-06-25-character-window-faithful-spec.md (line ~19), 0x1000052D is the authored BaseElement that the Titles page root 0x10000539 inherits its content from (0x10000539's BaseLayoutId is 0x2100005E, BaseElement is 0x1000052D) — it is the real authored Titles-page content, just reached by a different path than the live-mounted tree. Use LayoutImporter.ImportInfos(dats, 0x2100005Eu, 0x10000536u) (the targeted single-root overload) to reach the row template 0x10000536 underneath it.

4. Window min/max constraints

Character window (0x2100002E) root

LayoutImporter.ImportInfos(dats, 0x2100002Eu) returns element 0x10000227 (Type 0x8, TabControl) as the tree root — this IS the top-level element retail's RetailUiRuntime.MountCharacter() mounts via RetailWindowFrame.Mount(..., layout.Root, ...). It authors NO MinWidth/MinHeight/MaxWidth/MaxHeight properties (dat properties 0x3F/0x3E/0x3D/0x3C all absent — probe shows every one of MinW/MinH/MaxW/MaxH blank for 0x10000227 and every element under it, including the footer, header, and Titles page).

Chat window (0x2100006F) root, for comparison

LayoutImporter.ImportInfos(dats, 0x2100006Fu) returns element 0x10000600 (Type 0x10000050, a self-contained "window" element that directly includes its own dragbar (Type 2), border frame (Type 3), and FOUR resize-grip corners (Type 9) as children — none of which the character layout's root has). It DOES author constraints: MinWidth=300, MinHeight=100, MaxWidth=2000, MaxHeight=2000.

Correction to the plan

The plan's "Already in-tree" section states: "The character window registers with DatConstraintSource — authored min/max plumbing exists in RetailWindowFrame; Y-resize for this window and the list-scrollbar contract do not." Read literally this implies the character window's RetailWindowFrame.Mount call already sets DatConstraintSource. It does not. RetailUiRuntime.MountCharacter() (src/AcDream.App/UI/RetailUiRuntime.cs, ~line 4043) constructs RetailWindowFrame.Options with ResizeY = true, ResizableEdges = ResizeEdges.Bottom, ConstrainResizeToParent = true — but no DatConstraintSource, MinHeight, or MaxHeight field at all, unlike e.g. MountSideVitals() (~line 1474) which explicitly sets DatConstraintSource = info from its own imported root. This is consistent with what CT1 also found in the DAT itself: 0x2100002E's root authors no size constraints to plumb through in the first place — chat's window-frame elements are its own self-contained LayoutDesc, while 0x2100002E is CONTENT ONLY (tab bar + pages), with retail's window chrome supplied by a separate mechanism.

Treat the "Already in-tree" plan bullet as inaccurate: start CT6 from the decomp for the window-frame class instead of assuming the wiring is already 90% done. The paragraph below replaces this doc's earlier "likely a hardcoded ResizeTo/SetMinSize call" guess with the verified mechanism.

Verified resize mechanism (2026-08-24, supersedes the hypothesis above)

UIElement::ResizeTo @0x00463C30 clamps ONLY via element attributes — 0x3C (clamp-max-height), 0x3E (clamp-min-height), 0x3D (clamp-max-width), 0x3F (clamp-min-width) — read off this, the element actually being resized. A decomp-wide grep for writers of those four attributes turns up NOTHING: no runtime code ever sets them at runtime. The clamp source is exclusively authored DAT properties on whichever element ResizeTo is called against, full stop. There is no hardcoded SetMinSize call anywhere in the class hierarchy; the earlier "likely a hardcoded ResizeTo/SetMinSize call" phrasing in this doc was a guess and is WRONG.

The element ResizeTo is called against is not 0x2100002E's own root. Per docs/research/2026-07-17-retail-shared-main-panel-pseudocode.md (lines ~83-107) and the slot table in docs/research/2026-08-11-fa-panel-structure.md (row for 0x1000018E), retail's Character/Skills tab content is one child slot inside the SHARED gmPanelUI host, LayoutDesc 0x2100006E:

gmPanelUI host          0x100005FE   310 x 372
content parent          0x10000180   300 x 362 (anchored all edges)
Character/Skills slot   0x1000018E   panel id 11, 300 x 362
top-center Dragbar      0x1000065C   Type 2
bottom-center Resizebar 0x10000660   Type 9

gmPanelUI::ResizeTo @0x004BC6E0 is a bare tailcall into UIElement::ResizeTo — the HOST is what gets resized (via its Resizebar), not 0x2100002E's content root; the content root's own absent MinHeight/MaxHeight (confirmed above) is therefore consistent with retail's actual mechanism, not evidence of a missing DAT property.

NOT PROBED by CT1. The host elements above (0x100005FE, 0x10000180, 0x1000018E, 0x1000065C, 0x10000660) were read from the cited pseudocode doc, not re-probed live against the installed DAT this session. CT6's first step is to probe those host slots directly (min/max + resize authoring) before porting anything, then read UIElement_Resizebar::StartMouseResizing @0x0046B7E0 verbatim for the drag-time clamp application.

Size tension for CT3/CT6 to resolve. 0x2100002E's own root is authored 300×600 (the Titles page alone is 300×575, plus the 25px tab bar = 600 — §3), but retail mounts that content into the host's 300×362 slot (0x1000018E). CT3's title ListBox height (0x10000532 is 270×455 per §3) and CT6's resize contract both assume a taller available area than the host slot's authored 362px. This doc does not resolve which number governs at runtime (scroll-clipped content inside a fixed slot vs. the slot itself growing to accommodate) — CT6 must resolve it from the decomp before implementing the resize contract, not infer it from either number in isolation.

5. The title-string table (DAT ground truth for CharacterTitleTable::GetCharacterTitleFromID)

Decomp chain (named-retail, docs/research/named-retail/acclient_2013_pseudo_c.txt)

CharacterTitleTable::GetCharacterTitleFromID @0x005c6ed0 does not read a StringTable directly. It goes through TWO independent enum-mapper indirections:

1. EnumMapper::GetString(0x10000006, titleId, &rawName) (the static 3-arg overload @0x0041ac40) — internally calls DBObj::GetDIDByEnum(&did, 0x10000006, /*category*/1) to resolve the title EnumMapper object's DID, then dispatches on MasterDBMap::DivineType (0x24 = EnumMapper) to call EnumMapper::GetString(titleId, &rawName) on it, giving a raw canonical string name (NOT yet localized/hashed).
2. compute_str_hash(rawName) (ELF-style hash, already ported byte-exact as DatStringResolver.ComputeHash — see its own citation of compute_str_hash @ 0x00413110).
3. StringInfo::SetStringIDandTableEnum(&info, hash, 0x10000007) (@0x0042c760) — internally calls DBObj::GetDIDByEnum(&did, 0x10000007, /*category*/4) to resolve the title StringTable's DID.
4. StringInfo::GetString(&info) (@0x0042e760 → InqString → StringTableMetaLanguage::UnescapeString) resolves the final localized text — the same StringTable.Strings[hash] lookup DatStringResolver.Resolve(tableId, stringId) already performs.

DBObj::GetDIDByEnum(enumValue, category) (@0x004153a0 → DBCache::GetDIDFromEnum @0x00413940) is itself a two-level indirection through a master map object (this->m_MasterMapID): look up category in the master map to get an intermediate category-map DID, then look up enumValue in THAT map to get the final DID. This is the exact same mechanism already ported (empirically, not by name) as RetailKeyNames' 0x2300000A/0x2300000B/0x23000007 constants (src/AcDream.App/UI/Layout/RetailKeyNames.cs, citing "DBCache::GetDIDFromEnumStatic category 4") — this slice confirms those three constants ARE exactly the category-4 (STRINGTABLE) map's enum 4/5/3 entries (see table below), so the existing RetailKeyNames port is independently cross-validated by this investigation.

Live-DAT resolution (verified end-to-end this session)

The master-map / category-map tables and the RetailKeyNames cross-validation below are UNPINNED probe output — they come from the same deleted Assert.Fail probe tests as the rest of this doc and are not backed by a committed InstalledDatFact assertion (unlike the TitleStringTable_ResolvesWarMageEndToEnd pin, which DOES commit the final two DIDs and the end-to-end string resolution). Treat the category-4 dump and the RetailKeyNames match column as this session's observation, re-derivable from the DAT but not regression-guarded.

DatReaderWriter.DBObjs.EnumIDMap (ACE's historical name: DidMapper, file-type byte 0x25) is the object type both master and category maps use; DatReaderWriter.DBObjs.EnumMapper (file-type byte 0x22 on the installed dat) is the flat id→string table type.

Master map, DID 0x25000000 (ClientEnumToID/ClientEnumToName, 22 entries) — the categories relevant here:

category enum	name	category-map DID
1	EMAPPER	0x25000001
4	STRINGTABLE	0x25000004

Category 1 (EMAPPER) map, DID 0x25000001 — relevant entry:

enum	name	DID
0x10000006	CharacterTitle	0x22000041

Category 4 (STRINGTABLE) map, DID 0x25000004 — full dump (12 entries), confirming the RetailKeyNames constants along the way:

enum	name	DID	cross-check
0x00000003	KeyMap	0x23000007	= RetailKeyNames.DelimiterTableId ✓
0x00000004	KeyNameOverride	0x2300000A	= RetailKeyNames.KeyNameTableId ✓
0x00000005	MetakeyNameOverride	0x2300000B	= RetailKeyNames.MetaKeyNameTableId ✓
0x10000007	CharacterTitle	0x2300000E	(this slice's target)
0x10000001	UI	0x23000001
0x10000002	UI_Pregame	0x23000002
0x10000003	Preference	0x23000003
0x10000004	UI_Options	0x23000004
0x10000006	Options	0x2300000D
0x00000002	Calendar	0x23000006
0x00000006	CommandSetup	0x2300000C
0x00000007	ActionDescription	0x23000005
0x00000008	ServerEngine	0x23000010

So: the title EnumMapper is DID 0x22000041; the title StringTable is DID 0x2300000E.

End-to-end verification (ACE's CharacterTitle enum, WarMage = 13)

EnumMapper(0x22000041).IdToStringMap has 873 entries, including:
  titleId 0  -> ID_CharacterTitle_Invalid
  titleId 1  -> ID_CharacterTitle_Adventurer
  titleId 5  -> ID_CharacterTitle_Life_Mage
  titleId 13 -> ID_CharacterTitle_War_Mage
  titleId 14 -> ID_CharacterTitle_Wayfarer

ComputeHash("ID_CharacterTitle_War_Mage") = 0x0543AF05
DatStringResolver(dats).Resolve(0x2300000E, 0x0543AF05) = "War Mage"

Byte-exact confirmation the chain is understood correctly end to end — titleId 13 round-trips through the EnumMapper canonical-name lookup, the retail hash function, and the StringTable localization lookup to produce exactly "War Mage".

What CT2 needs to port

1. Two GetDIDByEnum-shaped lookups (master map 0x25000000 → category map → target DID) — CT2 can either hardcode the two resolved DIDs (0x22000041 for the EnumMapper, 0x2300000E for the StringTable, the way RetailKeyNames hardcodes its three) or port the two-level indirection generically. A THIRD consumer has now appeared (found this fix round): gmAttributeUI::PostInit @0x0049DB70 resolves per-attribute icon DIDs via DBObj::GetDIDByEnum(statEnum, category 0x10000002) — see the "Row instantiation + icon-DID anchors" note in §2. With RetailKeyNames (category 4) and the title chain (categories 1 and 4) already hardcoding resolved DIDs, this third independent category (0x10000002) is the point where CT2/CT5 should factor a shared GetDIDByEnum(enumValue, category) helper instead of adding a fourth ad-hoc hardcoded pair.
2. EnumMapper.IdToStringMap[titleId] → raw canonical name (already readable via dats.Portal.TryGet<DatReaderWriter.DBObjs.EnumMapper>).
3. DatStringResolver.ComputeHash(rawName) (already exists, no new code).
4. DatStringResolver.Resolve(0x2300000Eu, hash) (already exists, no new code) for the final localized display string.

No new DAT-reading primitives are required — EnumMapper/EnumIDMap are already exposed by DatReaderWriter.DBObjs, and DatStringResolver already does steps 3–4 for other consumers.

Corrections to the plan (summary)

1. Window constraints are NOT already 90% wired — and the clamp mechanism is now VERIFIED, not guessed. The plan's "Already in-tree" bullet claims DatConstraintSource registration for the character window; the actual MountCharacter() call sets no such field, and the DAT layout itself authors no MinHeight/MaxHeight on its root to source one from even if it were wired. UIElement::ResizeTo @0x00463C30 clamps only via element attributes 0x3C–0x3F, which nothing writes at runtime — the clamp source is always authored DAT properties on the resized element, full stop, and the resized element is the SHARED gmPanelUI host (0x2100006E, slot 0x1000018E), not 0x2100002E's own root. See §4's "Verified resize mechanism" for the full chain and the unresolved 300×600-vs-300×362 size tension CT6 must still resolve.
2. The row-template elements are not walkable via the normal ImportInfos(dats, layoutId) overload. #375's prototype-skip logic deliberately excludes same-layout template-list targets from the built tree. CT5 must use ImportInfos(dats, layoutId, elementId) (the targeted single-root overload) to read 0x10000248 (LayoutDesc 0x21000045) and 0x10000536 (LayoutDesc 0x2100005E) — documented here so CT5 doesn't waste a cycle rediscovering the same "NOT FOUND" dead end this slice hit first.
3. RowHighlightSprite IS wrong — SEALED, not merely flagged. The DAT's row-template Highlight state is 0x06000F93, reached via gmAttributeUI::UpdateSelection's SetState(6) → InfoRegion::SetState on the row itself; the current constant in CharacterStatController.cs is 0x06001397, which belongs to a DIFFERENT mechanism (the spellbook row's selected-overlay child, UIElement_UIItem::SetSelectedState). CT5 must correct the STAT rows' RowHighlightSprite to 0x06000F93 and must NOT touch SpellbookRowStyle.cs — see §2's "SEALED VERDICT" note for the full anchor chain.
4. Everything else in the plan's "Retail recon" section (the Titles page element roster, the header element ids, the PostInit binding order) checks out exactly against the live DAT — no other corrections.
5. Several findings above are probe-session observations, not committed pins — flagged this fix round so CT2–CT6 don't cite them as regression-guarded facts: the header block's "two copies geometrically identical" claim (only fonts/colors are pinned, not full geometry — §1), the 0x06004CC2 "generic panel chrome" characterization (§2), and the master-map/category-map dump plus the RetailKeyNames cross-validation table (§5). The title chain's final two DIDs and end-to-end string resolution ARE pinned (TitleStringTable_ResolvesWarMageEndToEnd).