fix(chargen): Campaign CC CC5 re-review residuals R1-R5 + nits — REVIEW-CLOSED

The narrow re-review of fix commits 0c8e1e7d+2d4168f9 found every code fix
oracle-verified but returned NOT CLOSED on five test/doc residuals plus
three nits and a follow-up filing. All fixed:

- R1: the claimed "external-change->user-commit->SetName" regression test
  for F1 (the deleted _suppressNextFieldEvent latch) never existed — the
  Runtime-layer randomize test doesn't touch the page. Added
  CharacterCreationUiControllerTests.SummaryNameField_RealCommitAfter
  ExternalRefreshWhileUnfocused_StillReachesSetName: drives Refresh with a
  revision bump + changed snapshot.Name while the field is unfocused (the
  programmatic SetText path that used to arm the latch), THEN performs a
  real user commit (field.SetText + field.Submit(), the actual event path),
  asserting SetName receives the player's typed text.
- R2: RetailSkillFormula.CalculateChargenScore and ChargenSkillScoreResolver
  had zero direct coverage (the F12(d) test substitutes skillId*10). Added
  a Untrained/Trained(+5)/Specialized(+10) theory, the divisor-zero skip
  path, and a six-way AttributeId theory (Str=1..Self=6) to
  RetailSkillFormulaTests.cs.
- R3: RetailSkillFormula.cs's doc comment claimed "no retail-authored skill
  sets MinLevel above Untrained=1" without ever reading the field — ACE's
  own SkillBase.cs hedges the same field "// 1-2?". MEASURED (not assumed)
  against the installed EoR dat's global SkillTable
  (CharacterCreationLiveDatTests.SkillTable_MinLevelDistribution_
  NeverExceedsTrained): 23 skills at MinLevel 1, 15 at MinLevel 2, zero
  above 2, of 38 priced skills. ACE's hedge was right; the doc comment now
  states the measured fact and leans on the structural argument (the gate
  holds for Trained/Specialized under any MinLevel in {1,2}) as load-
  bearing, not the unverified data claim.
- R4: filed AP-228 — the Summary/Skills skill-row KEY sources from
  ItemAppraisalTextFormatter.SkillName's hardcoded English switch, where
  retail's own key is DAT-sourced (SkillBase->_name via %hs,
  0x0047b90f-0x0047b915) — same divergence class as AP-226 filed the same
  round, reversed polarity, also present at CC4's Skills page. Softened
  AP-224's "ported exactly, not simplified" claim: it only ever covered the
  row's VALUE/template, never its KEY.
- R5: this commit corrects 0c8e1e7d's gate claim. "Release build zero
  warnings" was false: a clean `dotnet build -c Release -t:Rebuild` shows
  25 pre-existing warnings (18 in tests/AcDream.Core.Tests, 7 in
  tests/AcDream.App.Tests — Composition/HostInputCameraCompositionTests.cs,
  Composition/WorldRenderCompositionTests.cs,
  UI/Layout/OptionsPanelLiveMountProbeTests.cs), none in any file this
  campaign or its residual round touched. History is not amended; this is
  the correction.

Nits: the ChargenPreviewController ctor doc now also cites
gmCGSummaryPage::Update @0x0047baa0 (the per-heritage re-derive site — 0xc
Olthoi/0xd OlthoiAcid/else — not just the one-shot InitializePage seed) as
the stronger justification for why Rebuild re-derives the zoomed-out eye
per heritage on every change. RuntimeCharacterCreationState's F2 comment
("Finish becoming a permanent no-op") reworded: the same unconditional
_verificationPending = false assignment ran pre-fix too, so Finish was
never blocked — only the response FEEDBACK vanished (no dialog, no created
character, nothing), not the request itself. Filed #404 for
ChargenSkillScoreResolver's own independent SkillTable read alongside
ChargenTableReader's (cleanup follow-up, out of this round's scope).

Ledger: CC5 flipped REVIEW-CLOSED in the campaign plan (dual-lens
architectural PASS-with-items / retail-fidelity FAIL -> F1-F14 fix round
0c8e1e7d -> narrow re-review: all code oracle-verified, residuals R1-R5
test/doc -> this commit; re-reviewer pre-authorized lead diff-check close).
This commit's own sha is recorded by a follow-up ledger-only commit,
matching 2d4168f9's own pattern.

Gates: Release build 0 errors (25 pre-existing warnings, unrelated to this
round — see R5 above); App suite 5257/3 skips (was 5242/3), 0 failed;
Runtime suite 1726/0 (unchanged); the three new/measured tests (R1, R2's
ten cases, R3) all pass individually.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-08-16 01:57:07 +02:00
parent 2d4168f926
commit 356545c530
9 changed files with 277 additions and 13 deletions

View file

@ -48,11 +48,24 @@ internal static class RetailSkillFormula
/// typed <c>SkillBase.MinLevel</c> field is the same value cleanly), is
/// satisfied for both callers of this method (Specialized=3 and
/// Trained=2 are the only two advancement classes CC5's Summary listbox
/// still shows — AP-224 — and no retail-authored skill sets
/// <c>MinLevel</c> above Untrained=1) so it is not reproduced as a
/// separate branch; a future caller passing <see cref="ChargenSkillAdvancementClass.Untrained"/>
/// or <see cref="ChargenSkillAdvancementClass.Inactive"/> would need
/// that gate ported for real.
/// still shows — AP-224) FOR ANY <c>MinLevel</c> in <c>{1, 2}</c> — that
/// structural argument, not an assumption about the data, is what makes
/// omitting the branch safe. CC5 re-review residual round, R3
/// (2026-08-16), corrects the data claim this comment used to make in
/// place of that argument ("no retail-authored skill sets MinLevel
/// above Untrained=1"): ACE's own <c>SkillBase.cs</c> annotates the
/// identical field <c>// 1-2?</c>, a hedge this port never checked.
/// MEASURED against the installed EoR dat's global SkillTable
/// (<see cref="AcDream.App.Tests.UI.Layout.CharacterCreationLiveDatTests.SkillTable_MinLevelDistribution_NeverExceedsTrained"/>):
/// of the 38 priced skills, 23 carry <c>MinLevel == 1</c> and 15 carry
/// <c>MinLevel == 2</c> — ACE's hedge was correct (real 2s exist), and
/// no skill in the installed table exceeds 2, so the gate stays
/// satisfied — but the ORIGINAL claim ("no skill sets MinLevel above
/// Untrained=1") was false as written, unrelated to whether omitting
/// the branch happens to still be safe. A future caller passing
/// <see cref="ChargenSkillAdvancementClass.Untrained"/> or
/// <see cref="ChargenSkillAdvancementClass.Inactive"/> would need that
/// gate ported for real regardless of MinLevel's observed range.
/// </summary>
public static uint CalculateChargenScore(
SkillBase skillBase,

View file

@ -204,9 +204,20 @@ internal sealed class ChargenPreviewController :
/// eye literal <c>(0, -2.5, 0.95)</c> at <c>~0x0047bd14-0x0047bd44</c> —
/// exactly <see cref="ChargenPreviewCamera.ResolveZoomedOutEye"/>'s
/// default-heritage value, NOT the zoomed-in one this controller used
/// before the fix). Summary has no zoom buttons at all (retail's own
/// viewport there is fixed-framing), so this is a permanent camera
/// profile for the controller's whole lifetime, not a toggle.</param>
/// before the fix). CC5 re-review residual round, nit 1 (2026-08-16):
/// <c>InitializePage</c> alone only justifies the ONE-TIME seed below —
/// the STRONGER citation for why <see cref="Rebuild"/> re-derives this
/// same eye PER HERITAGE on every heritage/gender change (not just
/// once) is <c>gmCGSummaryPage::Update @ 0x0047baa0</c>, which re-sets
/// the camera on every update using the identical per-heritage mapping
/// <see cref="ChargenPreviewCamera.ResolveZoomedOutEye"/> already
/// implements (<c>0xc</c> Olthoi → <c>(0, -3.8, 1.15)</c>, <c>0xd</c>
/// OlthoiAcid → <c>(0, -5.7, 1.65)</c>, else → <c>(0, -2.5, 0.95)</c>) —
/// confirming the per-heritage re-derive below is retail-correct, not
/// an acdream-only elaboration on a one-shot init value. Summary has no
/// zoom buttons at all (retail's own viewport there is fixed-framing),
/// so this is a permanent camera profile for the controller's whole
/// lifetime, not a toggle.</param>
public ChargenPreviewController(
IChargenPreviewRenderer renderer,
ChargenPreviewCamera camera,

View file

@ -1870,8 +1870,17 @@ public sealed class RuntimeCharacterCreationState : IDisposable
// Concrete effect: ACE's disabled-Olthoi Pending rejection
// (CharacterHandler.CharacterCreateEx's olthoi_play_disabled
// branch) now surfaces a visible dialog instead of silently
// resetting verification state with Finish becoming a
// permanent no-op.
// resetting verification state. CC5 re-review residual
// round, nit 2 (2026-08-16): "Finish becoming a permanent
// no-op" overstated the old symptom — this same
// unconditional `_verificationPending = false` assignment
// above ALSO ran pre-fix, so Finish was never blocked and
// each click still sent a fresh CharacterCreate request.
// What actually vanished was the FEEDBACK: every response
// produced no player-visible outcome at all (no dialog, no
// created character, nothing), so repeated Finish clicks
// looked identical to doing nothing, even though each one
// was a real round trip to ACE.
string reason = response.AsCode.ToString();
_lastRejection = new RuntimeCharacterCreationRejection(
response.RawCode,