I have completed the adversarial verification against the raw decomp, the CFG, the sibling templates, and the data-binding source files. Every load-bearing claim in the spec was checked. Here is the corrected verdict.

---

# ADVERSARIAL VERIFY — MessageBoard reconstruction spec

**Bottom line:** the spec is **substantially CORRECT and ready-to-implement**. All addresses, `sizeof`, ctor offset writes, the base class, the methodDescription row set, the Make/dtor conventions, and the DEFERRED-data verdict are verified against the binary. The spec's **three header corrections are all genuinely correct**, and its **correction of the task hint** (source is BTPlayer status queue, *not* SubsystemMessageManager 0xBD3) is verified. I found **one wrong citation**, **one fidelity deviation to flag**, and **two small notes**. No blocking errors.

## What I verified as CORRECT (accept as-is)

- **Identity / addresses** (all confirmed `part_014.c`): Make `@004cb678:3825`, ctor `@004cb704:3849`, dtor `@004cb788:3872`, TestInstance `@004cb7e4:3892`→`FUN_004448ac`, no-op slot `@004cb7f4:3903`, BecameActive `@004cb7fc:3913`, SetSource `@004cb818:3925`, Execute `@004cb82c:3936`, vtable `PTR_FUN_0051bddc` (`:3858/:3876`). Base = `GraphicGauge` (`FUN_00444818`), ends at 0x90.
- **sizeof 0xA4 == Make alloc** `FUN_00402298(0xa4)` (`:3832`). ✓
- **ctor offset writes** (`:3859-3864`): `[0x25]`=stripImage(0x94), `[0x26]`=color(0x98), `[0x24]`=trackedMech(0x90)=0; `SetOrigin(x,y)` via `localView` vtbl+0x10. ✓
- **The three header fixes are all correct:**
  - `enabled` → **`Entity *trackedMech`**: 0x90 is a pointer dereferenced at `+0x190` (`iVar1 = *(*(param_1+0x90)+400)`, `:3950`) and written only by `SetSource` (`:3928`). It is not a bool. ✓
  - **previousMessageId / previousNameId are SWAPPED** in the current header. Binary proof: BecameActive writes `0x9c=-1, 0xa0=-2` (`:3916-3917`); Execute compares **messageId vs 0xa0** (`:3960`) and **nameEntity(iVar5) vs 0x9c** (`:3983`). ⇒ `0x9c=previousNameId(-1)`, `0xa0=previousMessageId(-2)` — exactly the spec's relabel, and it matches the prose at `btl4gau3.cpp:784`. ✓
- **methodDescription rows** match the CFG call `messageBoard(E, ModeAlwaysActive, btsmsgs.pcx, 0)` at `L4GAUGE.CFG:4913-4917` under the `offset=(113,607)` at `:4912` → 4 rows `typeRate/typeModeMask/typeString/typeColor`; position threaded from the `offset` directive; **entity param ignored** (binary Make never touches `param_4`, `:3825-3843`). This is exactly the PilotList template (`btl4gau3.cpp:218-239`), except MessageBoard *does* use `position` (SetOrigin). ✓
- **Make presence-check + return** is byte-faithful *and* matches the codebase template `VertTwoPartBar::Make` (`btl4gaug.cpp:1099-1107`: `Get(string); if NULL return False; Release; return True`). `content/GAUGE/BTSMSGS.PCX` exists → returns True in practice. ✓
- **dtor** correctly omits the base-dtor call (`FUN_00444870` is compiler epilogue glue, `:3880`) — avoids the double-dtor bug. `FUN_004700ac` is the string-dup helper used across widgets; freeing via `delete[]`/`FUN_004022e8` is consistent. ✓
- **Data-binding blocker — CONFIRMED on both legs:**
  - **SetSource (`FUN_004cb818`) has ZERO callers** anywhere in `reference/decomp/all/` (grep returns only its own definition) → `trackedMech` stays NULL. ✓
  - **`StatusMessagePool = 0`** — the NULL stub is real (`btstubs.cpp:62`), and the only writer of `BTPlayer+0x1dc` is gated `if (sender_owner && StatusMessagePool)` (`btplayer.cpp:508`) → no messages ever created. ✓
  - **Task-hint correction is right:** `SubsystemMessageManager` (`messmgr.cpp`) *is* reconstructed but is the per-mech damage/explosion hub (`ConsolidateAndSendDamage`/`weaponExplosions`), not a `{msgId,nameEntity}` source; MessageBoard never references it. `mech+0x190`=owningPlayer confirmed (`btplayer.cpp:68`, `MECH_OWNING_PLAYER`); `DAT_004efc94`==application (App+0xc8 name cache, `btplayer.cpp:53`). ✓
- **Systemic checks:** leaf `GraphicGauge` (not a container) that overrides both Execute and a non-inactivating BecameActive → Container-Execute/Fail rule satisfied. No shadow/alias/phantom fields (all new slots 0x90–0xA3, ends exactly at 0xA4). Raw `mech+0x190`/`player+0x1dc`/`+0x1e0`/App+0xc8 reads kept out of the widget TU via the `BTResolveMessageBoard` bridge (databinding trap avoided). Every-mech crash risk: none (early return on NULL). `/FORCE` stub for the bridge required. ✓

## CORRECTIONS (the list of what I changed)

1. **[Citation fix — §2, §5, §6] `StatusMessagePool`'s NULL definition is `btstubs.cpp:62`** (`MemoryBlock *StatusMessagePool = 0;`), **not** `btplayer.cpp:135/508`. Those btplayer lines are the `extern` decl and the guard site; the actual stub lives in `btstubs.cpp`. The conclusion (feed is dead) is unchanged — only name the correct file so the follow-up (wiring the pool) edits the right place.

2. **[Fidelity deviation — §4.8, must be flagged, not fixed] The Execute name-cell path is a STRUCTURAL simplification, not byte-faithful.** The binary stores the *previous name ENTITY POINTER* at 0x9c and, when the sender changes to "none", looks up that previous entity's name bitmap via its `+0x1e0` key and **erases** it with `DrawBitMap` (vtbl+0x54, `:3992-3996`). The spec collapses 0x9c to a boolean `nameState` (0/1) and drops the erase-previous path. **While DEFERRED this is functionally identical** (nameEntity always 0, previousNameId init −1 → first Execute takes the `iVar5==0 && prev==-1` clear branch, `:3986-3990`, matching the binary), so it is safe for the landing. **But it changes `previousNameId`'s semantics from pointer→int**, so when the status feed goes live the entity-pointer tracking + erase branch must be restored for correct name repainting. Keep the spec's body for the deferred landing; add a code comment marking this as the restore point. (The spec does acknowledge the deviation; I am raising it to an explicit action item because it silently redefines a member.)

3. **[Minor note — §1/§4.5] The no-op vtable slot `@004cb7f4` ("ShowInstance"):** the binary override is a bare `return`. The spec omits it and inherits (per the PilotList/PlayerStatus precedent). This is only byte-faithful **if** the `GraphicGauge` base slot is itself trivial for this call site; if strict fidelity is wanted, add an empty override. Low risk (leaf widget, slot rarely hit) — accept the omission but note it.

4. **[No change, confirmation] Make's `bool` return on a missing bitmap** is binary-faithful and template-matched; because `BTSMSGS.PCX` is present it returns True, so registration/parse is unaffected. No action.

Everything else in the spec — the layout table + `static_assert` locks, ctor/dtor/BecameActive/TestInstance/SetSource/Make bodies, the `BTResolveMessageBoard` bridge + returns-`False` stub in `btplayer.cpp`, the `methodDescription` literal, and the registration line inserted before `&BTL4ChainToPrevious` in `btl4grnd.cpp` (after `GeneratorCluster`) plus adding `static MethodDescription methodDescription;` to the class — is **verified and should be implemented as written**.

## FINAL CONFIDENCE: **HIGH**

- Layout/methods/registration/sizeof/offsets: **HIGH** — fully recovered and cross-checked against `part_014.c:3823-4013` and the `PilotList`/`VertTwoPartBar` templates.
- DEFERRED/empty verdict: **HIGH** — both blockers independently confirmed in-source (`btstubs.cpp:62` NULL pool; SetSource zero callers).
- Only residual **UNKNOWN** (non-blocking, for the *alive* path, not the landing): the exact `Player__StatusMessage` record layout (`+0xc` messageId, `+0x10` nameEntity) and the App+0xc8 name-bitmap cache shape needed inside `BTResolveMessageBoard` once `StatusMessagePool` is wired — decode `FUN_0042e580` (AddStatusMessage) + the message-record ctor `FUN_0042d990` to expose them as compiled accessors. The default landing (safe no-op) does not touch these.