docs(AS): AS3 REVIEW-CLOSED (APPROVE, no fix round); R3 legend hedge settled at source

The AS3 dual-lens review verified the armor-level trio, sentinel, legend,
and monster-path exclusion at offset level and disproved the R3
BN-flattening theory structurally (legend sits outside the InqCreature
block, pseudo-C line 189962). The ratings adjudication resolved in the
implementer's favor: the pre-AS3 composer already had retail's per-row
gating and spacer discipline. NITs 11/12 + the AP-110 narrowing ride AS4.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-08-25 09:26:15 +02:00
parent 1616cd3d39
commit bc48e3216a
2 changed files with 12 additions and 5 deletions

View file

@ -216,10 +216,16 @@ auto-fail. Guid-not-found → `Flags=0, Success=0` only.
52 is absent for players; harmless either way.
- **R2 (Int 323 HealingBoost):** retail reads it and never renders it; we
keep discarding it. Do not add a row.
- **R3 (`* = Unenchantable` legend unconditional):** port as the decomp
shows — unconditional at the end of the char extras (it may be a BN
flattening; the CONNECTED GATE explicitly asks the owner to check retail
side-by-side; flip to conditional only on live evidence).
- **R3 (`* = Unenchantable` legend unconditional):** SETTLED AT SOURCE at
the AS3 review — the legend at `004b5d7d-004b5dcd` sits OUTSIDE the
`if (InqCreature(...))` block (opened `004b4638`, closed at pseudo-C line
189962), so the BN-flattening theory is dead: retail adds it
unconditionally, into the same `m_extraInfoList` (0x10000335), text in
the LABEL slot. Retail's outside-the-gate placement is unobservable in
practice (the dispatcher only routes to CharExamineUI when a creature
profile exists), so "always, on the character path" is the faithful
port. The connected gate keeps its side-by-side check for the VISUAL
question only; do not re-investigate the structure.
- **R4 (ratings spacer discipline):** the BN output lost the flag
assignments in CharExamineUI; use `CreatureExamineUI::SetAppraiseInfo
@0x004B3FF0`'s clean version of the SAME logic: one spacer before the