diff --git a/docs/plans/2026-08-15-character-creation-campaign.md b/docs/plans/2026-08-15-character-creation-campaign.md
index 8ac616e9..85bd2a60 100644
--- a/docs/plans/2026-08-15-character-creation-campaign.md
+++ b/docs/plans/2026-08-15-character-creation-campaign.md
@@ -1,7 +1,12 @@
 # Campaign CC — retail character creation
 
-**Status:** All seven slices (CC1-CC7) are REVIEW-CLOSED; the campaign is
-CODE-COMPLETE pending the user's own connected gate. CC7 (the final slice)
+**Status: CLOSED — USER-ACCEPTED 2026-08-16.** All seven slices (CC1-CC7)
+REVIEW-CLOSED; the connected gate ran as one extended round (findings
+GF-1..16, re-tests R2-1..8 / R3-1..9 / R4-1..4, fix batches A-G + closeout
++ two re-test rounds, final build `1.0.2-cc.o`) and the user declared
+**"Gate pass!"** on 2026-08-16. The campaign's headline milestone — the
+FIRST live character created by acdream against ACE — was reached
+mid-round on build `1.0.2-cc.g`. CC7 (the final slice)
 closed out the campaign's implementation: the Create button un-ghosts and
 opens chargen for real, the full 0xF656/0xF643 flow is proven end-to-end
 against a real WorldSession, the launcher status-payload cycle is proven
@@ -286,4 +291,4 @@ the user gate.
 | CC6b-PRE | PRE-MOUNT HALF CODE-COMPLETE 2026-08-15 (the mount-independent scope only — idle animation, rotation, zoom for the chargen preview; the page-mount half — Appearance page, spin controls, color wheels, viewport wiring — is a SEPARATE follow-up landing after CC4 merges, per the original CC6 split) | `8dfee111` (pre-mount half), plus a same-round review fix commit (F1-F7 + the F11-concession rewrite) | Dual-lens review returned architectural PASS with reservations + retail fidelity PASS with reservations, merge after F1 — landed this round along with F2-F7 and the ALSO item (the reviewer's claim-2 barber refutation was UPHELD; claim-1's idle-by-default CONCLUSION was correct but its "elided ctor byte" argument was unsound, replaced with the real `InitializePage` evidence) | **Idle animation loop, TS-83 RETIRED:** decomp re-read of `gmCGAppearancePage::Update`'s own trailing gate (~0x0047EF01-0x0047EF12: `if (m_bZoomedIn == 0) StartAnimation(); else StopAnimation();`, unconditional on every Update call — heritage/gender change or page becoming visible) plus the DIRECT ASSIGNMENT evidence located at the re-review — `gmCGAppearancePage::InitializePage @0x0047FDD0` writes an explicit `m_bZoomedIn = 0` at `0x004802C3`, right after setting the camera to the zoomed-IN per-heritage eye at `0x00480286-0x0048029E` (the null-tween quirk); the earlier elided-ctor-byte argument was UNSOUND (heap-new members are indeterminate, not zero) and is superseded — settles a fact CC6a's own TS-83 row left as "not yet located precisely": **retail's chargen preview defaults to the idle loop PLAYING, not the frozen rest pose** — the rest pose only appears once the user presses Zoom In, which retail's own `ZoomIn`/`ZoomOut` (`0x0047CF00`/`0x0047D050`) call `gmCG3DView::StopAnimation`/`StartAnimation` for IMMEDIATELY (before the camera's own 0.6s tween even starts). New Core primitive `RetailAnimationCyclePlayback` (`src/AcDream.Core/Physics/`, pure, unit-tested) ports `CPhysicsObj::set_sequence_animation @ 0x0050F6F0`'s effect (advance-with-wrap + lerp/slerp) — the SAME algorithm this codebase's App layer already carries inline for its no-`AnimationSequencer` NPC idle path (`LiveEntityAnimationPresenter.Present`'s legacy branch); the two call sites are NOT consolidated this round (that file is live, heavily-tested, in-flight production entity-rendering code unrelated to this preview-only feature — a deliberate blast-radius call, not an oversight, noted in the new type's own doc comment for a future mechanical pass). New App type `ChargenPreviewAnimator` (`src/AcDream.App/Rendering/`) owns the per-tick idle-frame advance / rest-pose freeze swap; `ChargenPreviewEntityBuilder` gained `TryBuildAnimated` (returns a `ChargenPreviewAnimatedBuild`: the entity, resolved drawable parts, precomputed rest pose, resolved idle Animation + frame range) alongside the ORIGINAL `TryBuild` (kept RESULT-identical, not byte-identical internally — F6: it now also resolves the idle DID and loads the idle Animation before discarding them; a thin wrapper now, all 3 of its existing tests still pass unchanged) — `ResolveIdleAnimEnum` resolves `m_didAnimation`'s enum key (0x10000006 standard, 0x10000011 Olthoi, 0x10000013 OlthoiAcid) alongside the existing `ResolveRestPoseEnum` (0x10000005/0x10000011/0x10000013) — **Olthoi and OlthoiAcid use the SAME enum key for BOTH idle and rest** (retail quirk, decomp-confirmed at ~0x004ee7e9/0x004ee7ff and ~0x004ee892/0x004ee8a8: those two heritages show no visible difference between "playing" and "zoomed in and frozen"). **Rotation controller:** new `ChargenPreviewRotationController` (`src/AcDream.App/Rendering/`) ports `gmCGAppearancePage::Rotate`/`DoRotation` (`0x0047CB50`/`0x0047CA80`) verbatim — toggle-to-stop-same-direction, `deltaDegrees = ((now - lastRotateTime) / RotationSecondsPerRevolution) * 360`, a SINGLE-PASS ±360 clamp (not a full modulo — retail's own tail only corrects once, reproduced as-is rather than "improved"), the `-1.0` sentinel `Rotate()` writes to invalidate `m_dLastRotateTime` (bit-confirmed: high dword `0xbff00000` + zero low dword). `ECG_ROTATE_CLOCKWISE=1`/`ECG_ROTATE_COUNTERCLOCKWISE=2` confirmed from `acclient.h:6848-6852` — CLOCKWISE adds to heading, everything else subtracts. Applies to the ENTITY's heading via `MoveToMath.SetHeading` (the exact existing `CPhysicsObj::set_heading` port, reused rather than reinvented), not the camera — confirming CC6a's own architecture note. **Zoom tween:** new `ChargenPreviewZoomController` ports `ZoomIn`/`ZoomOut`/`DoZoomAnimation` (`0x0047CF00`/`0x0047D050`/`0x0047C960`) — a LINEAR (not eased — the decomp shows a straight `(targ-start)*t+start` per axis with no easing curve anywhere in the function) 0.6s tween between `ChargenPreviewCamera`'s already-recorded default/zoomed-out eye profiles, using the same `-0.1` invalidation-sentinel idiom as rotation; `ZoomIn`/`ZoomOut` call into `ChargenPreviewAnimator.SetZoomedIn` IMMEDIATELY (synchronously, inside the button-press method itself — not gated on the tween's own completion), matching the decomp's call ORDER exactly. **Fix round F2:** the controller and the animator originally kept two INDEPENDENT `IsZoomedIn` bools synced only through a nullable animator argument on `ZoomIn`/`ZoomOut` — a null pass, or a direct `ChargenPreviewAnimator.SetZoomedIn` call bypassing the controller, could desync the camera target from the animation pose. Retail's `m_bZoomedIn` is a SINGLE field gating both, so `ChargenPreviewZoomController` now takes its `ChargenPreviewAnimator` as a required constructor dependency and `IsZoomedIn` reads straight through to the animator's own flag — one owner, matching retail's own shape, with no second bool left to disagree. **`m_alternateSetupID` (MUST-COVER item 1) — RESEARCH CORRECTION, not a straight port:** re-reading the decomp function-by-function (not just address-by-address) found that ALL FIVE `m_alternateSetupID` write sites — including the two the CC6a review fix round cited, Penumbraen crown `@0x004DFB3F` and Undead no-flame `@0x004E0C54` — belong to `gmBarberUI`, not `gmCGAppearancePage`. Enclosing-function table (every write site, confirmed by scanning each site's containing function body for sibling calls that only make sense in one class): `@0x004DFB5B` sits inside `gmBarberUI::ListenToElementMessage` (sibling evidence: `gmBarberUI::SetSelection`/`gmBarberUI::Rotate` calls in the same body, which ends in a `CM_Character::Event_FinishBarber` wire call — a barber-shop-only message); `@0x004E0C54` (Penumbraen crown), `@0x004E0D42`, and `@0x004E0DB1` all sit inside the SAME `gmBarberUI::InitializePage` (sibling evidence: `m_pOption1Checkbox` reads and `UIElement_Text::SetStringInfoWithFont` calls on barber-specific string ids in that body); the ONLY thing `gmCGAppearancePage` itself ever does with the field is READ it generically through the shared `gmCG3DView` ctor/`::Update` (every `gmCG3DView` owner does this) — `gmCGAppearancePage`'s own field list (`acclient.h:56373-56428`, checked exhaustively) has NO `m_pOption1Checkbox`-equivalent member and none of its own methods write `m_alternateSetupID`. `gmBarberUI` is the POST-CREATION barber-shop appearance-editing screen — a wholly separate UI class from character creation's `gmCGAppearancePage`. **For character creation, `m_alternateSetupID` is therefore ALWAYS `INVALID_DID` in retail — the barber shop's crown/flame variant checkbox is not reachable during chargen at all**, and is out of this campaign's scope entirely. **Directive for CC6b-mount: do NOT build an option checkbox for Penumbraen-crown/Undead-no-flame variants on the Appearance page — retail has no such control there.** `ChargenAppearanceFactory.TryCompose` still gained a real, decomp-cited `alternateSetupIdOverride` parameter (default `InvalidDid`, i.e. no-op for every existing caller) implementing `gmCG3DView::Update`'s own generic precedence exactly (`~0x004EEA46-0x004EEA53`: the override, when present, REPLACES the hairstyle/gender-resolved setup outright, not additively) — a real mechanism reserved for a hypothetical future non-chargen (barber-shop) consumer of this same factory, not a fabricated chargen feature; 5 new hand-built tests prove the precedence chain and the `INVALID_DID` sentinel discipline. **RetailHeldPose extraction (MUST-COVER item 2) — DONE, clean mechanical extraction:** new `src/AcDream.App/Rendering/RetailHeldPose.cs` shares `ResolvePoseDid` (master-map-slot-7 DID lookup) and `ComposePartTransform` (`Scale*Rotate*Translate`) between `RetailPaperdollPoseApplicator.Apply` (paperdoll, refactored to call the shared helper, behavior byte-identical) and `ChargenPreviewEntityBuilder` (both the pre-existing rest-pose path and the new idle-frame path) — the two sites' surrounding per-index LOOP shapes stayed separate (paperdoll walks an already-filtered `WorldEntity.MeshRefs`; chargen walks the pre-filter Setup-part-indexed scratch list), matching the MUST-COVER's own "only if it stays clean" bar. **Bookkeeping:** TS-83 retired in `docs/architecture/retail-divergence-register.md` (§4 count 50→49, row removed, RETIRED clause added to the header narrative); the CC6a ledger row above now cites its real commit SHAs (`55bfd9ca`, `1774d8b2`) instead of "HEAD of `campaign-cc6a`". **Tests:** `RetailAnimationCyclePlaybackTests` (10, Core), `ChargenAppearanceFactoryTests` (+4, the override precedence/sentinel), `ChargenPreviewRotationControllerTests` (10, +1 this fix round — F7's clockwise-past-360 clamp case), `ChargenPreviewZoomControllerTests` (9, +2 this fix round — F2's null-ctor-throws and read-through-no-independent-state cases; every pre-existing case rewritten for the now-required-animator constructor), `ChargenPreviewAnimatorTests` (7, hand-built fixtures — no dat needed since a `ChargenPreviewAnimatedBuild` is constructible entirely in memory), `ChargenPreviewEntityBuilderTests` (+5, installed-DAT-gated — `TryBuildAnimated` resolves a real idle cycle for Aluvian AND Olthoi, the unknown-setup null path, both Olthoi/OlthoiAcid shared enum keys resolve to a real installed DID). Counts: Core.Tests 4786/1 skip (unchanged this fix round — F1-F7 were doc/API-shape/allocation fixes, no new Core tests), Content.Tests 147/0 skips (unchanged), App.Tests 5152/6 skips (+3 from 5149/6, the F2/F7 additions) — zero failures, full solution Release build green. Two PRE-EXISTING flakes noted across repeated full-solution runs, neither caused by this round and neither reproducing in isolation: `AcDream.Core.Net.Tests.Transport.NakEmissionTests.LossSoak_TwoPercentBidirectional_ZeroMessageLoss_LedgersConverge` (randomized-loss-injection timing, zero files under `src/AcDream.Core.Net/` touched) and `AcDream.Content.Tests.DecodedTextureCacheTests.GetOrCreate_ConcurrentMissRunsFactoryOnce` (a concurrency race under full-solution parallel load, zero files under `src/AcDream.Content/` touched this round either) — both pass 100% run standalone; both projects' full suites otherwise pass clean. **OWED (CC6b page-mount half, separate follow-up):** the Appearance/Summary viewport mount (`0x100003bb`/`0x10000406`), binding the Zoom In/Out and Rotate Clockwise/Counter-Clockwise buttons to `ChargenPreviewZoomController.ZoomIn`/`ZoomOut` (now parameterless — F2 made the animator a required constructor dependency, not a per-call argument) and `ChargenPreviewRotationController.Toggle`/`Tick`, spin controls, color wheels, and the INITIAL HEADING: `gmCGAppearancePage::InitializePage @0x0047FDD0` sets `m_fCurHeading = 180f` at `0x00480235` and pushes it via `SetPlayerHeading` at `0x0048023F` (overriding the ctor’s 0°; cross-confirmed at `gmBarberUI::PostInit @0x004DE330` and the summary page’s `0x0047BD54`) — the mount half must seed `ChargenPreviewRotationController.HeadingDegrees = 180f` or the character faces AWAY from the camera at the user gate. **Explicitly NOT owed:** an option checkbox for Penumbraen-crown/Undead-no-flame variants — see item 4's enclosing-function table above; `gmCGAppearancePage` never had one, so CC6b-mount must not invent one. |
 | CC7 | REVIEW-CLOSED 2026-08-16 | `9cf6c522`, `ddcbf1fb`, F1-F9 review-fix round `2176ba76` | CLOSED (dual-lens: both lenses PASS-with-items → F1-F9 fix round this commit; lead diff-check close per the doc/test-only residual pattern) | **Create button un-ghosts** (`CharacterManagementUiController.cs`): retail's exact enable/ghost gate — `gmCharacterManagementUI::UpdateButtons @ 0x004ec240` (~0x004ec319-0x004ec32e, `_charSet.set_.m_num < _charSet.numAllowedCharacters_`, unconditional on selection, unlike Enter/Delete/Restore above it) — is now a real Runtime-owned field, `RuntimeCharacterSelectionButtons.CanCreate`, computed in `RuntimeCharacterSelectionState.BuildButtons` from `_entries.Length < _slotCount` and threaded through every one of that method's return branches (including the delete-in-flight `.None`-shaped ones, which retail's own gate does not couple to). The button's `OnClick` (new `RequestCreate` private method) is wired ONCE in the constructor and calls `_bindings.RequestCreate?.Invoke()`; a new optional `Action? RequestCreate` field on `CharacterSelectionRuntimeBindings` carries the seam. **Cross-controller wiring lives inside `RetailUiRuntime.ConfigureCharacterManagement`** (`src/AcDream.App/UI/RetailUiRuntime.cs`) rather than in the externally-composed bindings record: `RetailUiRuntime` is the one object holding BOTH `CharacterManagementController` and `CharacterCreationController`, so it supplies `bindings with { RequestCreate = () => CharacterCreationController?.Open() }` — a lazily-resolved lambda closing over `this`, safe even though `ConfigureCharacterCreation()` (which populates the creation controller) runs immediately AFTER, not before, `ConfigureCharacterManagement()` in `RetailUiRuntime`'s own mount sequence. `CharacterCreationUiController.Open()` is the SAME entry point the CC4-era `ACDREAM_OPEN_CHARGEN=1` dev seam already called — one code path, two ways to reach it (the seam itself is untouched and remains available for a create-only dev loop). **The chargen-exit return path needed no new code**: character-management is never hidden while chargen is open on top of it (both controllers tick independently, per CC4's own FixedCanvas-arbiter work), so chargen's `Close()` — hiding only its own root — is sufficient; this was PROVEN, not just claimed, by a new cross-controller test (`CharacterScreensFixedCanvasArbiterTests.CreateButtonClick_OpensChargen_AndExitConfirmReturnsToManagement`) that drives the full click→open→exit-confirm→close round trip, asserting management's root stays `Visible` throughout. **Corrected at the CC7 review-fix round, F7 (2026-08-16): the original fixture-ordering claim above was WRONG.** The shared fixture originally constructed chargen FIRST so its `Open` method existed to wire into management's `RequestCreate` binding — the OPPOSITE of production's real tick order (`RetailUiRuntime.Tick`: `_characterManagementMount?.Tick(); CharacterManagementController?.Tick(); _characterCreationMount?.Tick(); CharacterCreationController?.Tick();` — management always ticks first). The fixture now constructs management first, handing it a lazily-resolved closure over chargen's not-yet-existing `Controller.Open` — the SAME trick production's own `RetailUiRuntime.ConfigureCharacterManagement` uses (`bindings with { RequestCreate = () => CharacterCreationController?.Open() }`) — matching production's real construction AND tick order instead of contradicting it. The test also now asserts `Chargen.Controller.Root.ClickThrough == false` and a strictly higher `ZOrder` than management's root once both controllers have ticked with chargen open, pinning the `BringToFront` occlusion effect the reviewer had previously verified only by manual inspection. A second new test (`CharacterManagementUiControllerTests.CreateButton_GhostsWhenRosterReachesTheSlotCeiling_AndUnGhostsBelowIt`) proves the retail gate itself: a 5-character roster against the fixture's `SlotCount=5` ghosts Create, dropping to 4 characters un-ghosts it on the next Tick. **Full-flow tests vs ACE shapes** (`tests/AcDream.Runtime.Tests/Session/LiveSessionControllerCharacterCreationTests.cs`, extending CC3's existing harness rather than duplicating it — same `TestTransport`/`TestOperations`/`TestHost`/`BuildResponsePacket`/`InvokeProcessDatagram` fixtures, zero new helper classes beyond a decode record): `Finish_SendsEveryWireFieldByteExactAgainstACEsUnpackShape` builds a character touching EVERY 0xF656 field (heritage/gender/all fourteen appearance style-color slots/all six shades/template/an EXPLICIT `TrainSkill` beyond what the template alone applies/an explicit `SelectStartArea`/name), decodes the full body via a new `DecodeCreateRequestFull` (reusing `CharacterCreate.Request`/`Appearance`/`Attributes` directly rather than a second hand-rolled shape) and asserts every field including the trailing checksum. **Corrected at the CC7 review-fix round, F6 (2026-08-16): the checksum half of that claim overstated what the assertion proves.** `Assert.Equal(CharacterCreate.ComputeChecksum(r), decoded.Checksum)` (`LiveSessionControllerCharacterCreationTests.cs:537`) is a round-trip/purity check — it computes the SAME production `CharacterCreate.ComputeChecksum` on both the encode and the decode side, not an independent golden value. It still closes the one gap (`Finish_SendsExactly55SkillSlotsAndTheCorrectAttributesAndName`'s pre-existing test never touched: ~15 non-checksum fields were previously unverified); the checksum's actual golden value lives separately at `CharacterCreateTests.ComputeChecksum_ExactRetailAccumulationSet` (the 19-term sum, golden `205u`), now cross-referenced from this test's own doc comment. `Finish_ThenEachOtherRejectionCode_ProducesTheMappedFailureWithNoRosterOrEnterSideEffect` (`[Theory]`, 6 cases: Pending/NameBanned/Corrupt/DatabaseDown/AdminPrivilegeDenied/Undef — NameInUse excluded, already covered by the pre-existing dedicated Fact) proves CC5's F2 fix (Pending/Undef produce a real rejection, not a silent reset) holds over the REAL wire byte-decode path, not just the isolated `RuntimeCharacterCreationStateTests.ApplyCreationResponse_EachRejectionCode_...` state-machine Theory that already covered all 7 codes at the `ApplyCreationResponse` level directly. **Launcher payload cycle** (item 3): `TestHost` gained an optional `SessionStatusWriter? Writer` + `SessionId`, forwarded from `ApplyCharacterCreated`/`ApplyCreationFailed` EXACTLY the way `LiveSessionRuntimeFactory.Create` (App) and `HeadlessSessionHost` wire it in production (verified by reading both call sites, not assumed) — two new tests (`Finish_ThenOkResponse_WritesCharacterCreatedEvent_ParsedByTheRealLauncherTailer`, its NameInUse sibling) drive a REAL Runtime create/reject through a REAL `SessionStatusWriter` writing to a real temp file, then read it back with the REAL Launcher.Core `StatusFileTailer`/`StatusEventParser` (added as a test-only `AcDream.Runtime.Tests` project reference — `AcDream.Runtime` itself gained no new dependency), asserting the parsed `CharacterCreatedStatusEvent`/`CreationFailedStatusEvent` match §LA1's pinned contract fields exactly. **No gap was found**: `GameWindow`'s constructor already builds a real, non-disabled `SessionStatusWriter(options.StatusFilePath)` and `SessionPlayerComposition.cs` already threads it into `LiveSessionRuntimeFactory`'s constructor alongside the session id — the writer was ALREADY correctly wired on the graphical App host's real create path before this slice; CC7's tests close the missing cross-project VERIFICATION (Runtime's own state transition through the writer's bytes to the tailer's parser), not a functional hole. **Pre-existing test breakage found and fixed** (loudly, per the task's own instruction): adding `CanCreate` to the `RuntimeCharacterSelectionButtons` record broke 4 UNRELATED tests in `LiveSessionControllerTests.cs` (`RestoreCompletionDuringConfirmedDelete_PreservesDeleteUntilAck` ×2, `RestoreTimeoutDuringConfirmedDelete_PreservesDeleteUntilAck` ×2) whose hand-built expected values used `RuntimeCharacterSelectionButtons.None` — a real regression the App-layer and Runtime.Tests standalone runs would not have caught in isolation (each project's own suite is green independently; only the combined change surfaced it). Fixed by threading `with { CanCreate = true }` into all 5 affected `Assert.Equal` expectations (that fixture's roster of 2 sits below its `SlotCount` of 11 throughout), with an inline comment explaining CanCreate's independence from the delete-in-flight buttons those tests actually pin. **Register bookkeeping this commit:** AP-211 (filed at CC3, explicitly predicted "if CC4 later adds the ghosted Create button... revisit whether to keep both or retire this one") updated, not retired — both `TryBeginFinish`'s `RosterFull` local refusal AND the new Create-button gate are intentionally kept as retail-matching enforcement (the button) plus defense-in-depth (Finish's own refusal, for any caller that bypasses the UI). **Connected checklist doc** (`docs/research/2026-08-16-campaign-cc-test-script.md`, following the FA/OP pattern): §CC1 reaching the screen (both the launcher's `GUI — character select` flow and the `ACDREAM_RETAIL_UI=1`/`ACDREAM_OPEN_CHARGEN=1` dev shortcut) plus Create's enable state and the Exit/Back return path; §CC2 the six-page flow per page (the AP-214-retired opening roll + its gender-flip quirk, Random on each page, the nine known Appearance-page cosmetic gaps called out by number so they aren't mis-filed as new bugs); §CC3 every Finish outcome (happy path, NameInUse + the AD-100 double-send log note, the credit-warning confirm flow, the randomize-warning flow, the exit-warning flow, NameTooLong); §CC4 the two ACE-side landmines (the Arcane Lore over-deduction, MEASURED latent per the plan's risk item 8; disabled-Olthoi → Pending → NameDBDown, retail-correct); §CC-Not-Automated stating plainly that no automated create has touched a live ACE server — this gate is the first one. **Test deltas (Release):** Runtime 1735/0 (was 1726/0, +9: the full-field decode test, the 6-case rejection-code Theory, 2 launcher-payload tests), App 5256/3 skips (was 5254/3, +2: the Create-ghosting test, the cross-controller round-trip test), Headless 166/0 (unchanged), Launcher.Core 324/0, Launcher.Tests 67/0 (one earlier standalone run hit a Fail:1 Avalonia headless-platform-initialization failure that reproduced on no other run including a full-solution pass — a pre-existing environment flake, zero files under `src/AcDream.Launcher`/`tests/AcDream.Launcher.Tests` touched this slice), full solution 14,426 passed / 4 skipped / 0 failed in one complete pass across every project (Core.Net's NakEmission flake and Content's DecodedTextureCache flake did not reproduce this run either). **Review fix round (this commit, F1-F9), CC7 REVIEW-CLOSED:** F1 files AP-229 for the screen-layering divergence the reviewer flagged (retail's `UIFlow::UseNewMode` destroys/reconstructs the current UI framework on every mode switch; acdream keeps both `CharacterManagementUiController`/`CharacterCreationUiController` mounted for the whole lifetime and only reveals/occludes), records what the reviewer confirmed already works (selection/world-name persistence, click-through isolation, one coherent `Modal` stack), and the narrow residual risk it left open (the shared `RetailDialogFactory` can hand `UiRoot.Modal` to a dialog opened by the still-ticking, occluded management screen's `ReconcileDialogs` on an inbound `CharacterError` — a race retail cannot have since the occluded screen simply does not exist there). F2 rewrites the connected-gate script's roster-full step with the exact `@modifylong max_chars_per_account` recipe (ACE default 11, confirmed against `references/ACE/Source/ACE.Server/Command/Handlers/AdminCommands.cs:4393`) and the pending-delete-counts-too note. F3 adds AP-221's exact console-diagnostic lines to §CC2's known-gaps paragraph so a session-permanent dead preview reads as a known gap, not a fresh bug. F4 adds an empty-name/AP-227 step to §CC3 so the tester expects acdream's `NoNameWarning` dialog instead of retail's silent keep-old-name behavior. F5 adds an App-layer source-text pin (`GameWindowLiveSessionOwnershipTests.LiveSessionRuntimeFactoryBindsCharacterCreatedAndCreationFailedToTheStatusWriter`) for the `CharacterCreated`/`CreationFailed` delegate wiring inside `LiveSessionRuntimeFactory.cs:229-236` the reviewer proved was deletable without breaking any test — no practical seam exists to construct the factory end-to-end without a `GameWindow` (confirmed: its one production construction site is deep inside `SessionPlayerComposition.cs`, and no test in the repo constructs it directly), so the pin follows this same test file's own established source-text pattern (`ProductionWindowConstructsOnlyTheCanonicalRuntimeRoot`, `DisplacedLifecycleBodiesAreAbsent`) rather than a contrived full construction; the exact payload SHAPE these delegates produce was already pinned separately at `SessionStatusWriterTests.CharacterCreatedAndCreationFailed_WriteThePinnedShape`, so the new test plus that existing one together cover "bound" and "correct payload." F6/F7 correct this row's own wording above (checksum-assertion circularity; fixture construction order) and strengthen `CharacterScreensFixedCanvasArbiterTests` per F7's fix. F8 records a known flake found under full-solution parallel load on both reviewer runs (passes standalone, unrelated to CC7 — an allocation assertion sensitive to concurrent load): `AcDream.Runtime.Tests.Physics.RuntimeCollisionReportingStateTests.WarmedSteadyContactRefreshDoesNotAllocate`, joining the existing Core.Net NakEmission / Content DecodedTextureCache / App SocialPanelLiveMountProbeTests known-flake set. F9 adds a one-line note to §CC2's Heritage-page Random step that a uniform pick over 13 heritages can repeat the current one. **Campaign status: all seven slices (CC1-CC7) are REVIEW-CLOSED; the campaign is CODE-COMPLETE pending the user's own connected gate** (`docs/research/2026-08-16-campaign-cc-test-script.md`) — no automated live character creation has touched ACE yet; that gate remains the sole outstanding acceptance step. |
 | CC6b-MOUNT | CODE-COMPLETE 2026-08-15 (the page-mount half CC6b-PRE deferred — Appearance page, spin controls, color-wheel family, viewport wiring — landing after CC4 merged, closing out Campaign CC's CC6 slice); REVIEW-CLOSED 2026-08-15 (dual-lens re-review of the F1-F13 fix round returned NOT CLOSED with residuals R1-R3 + 2 nits, all fixed this round, re-reviewer pre-authorized a diff-check-only close) | `34c6fceab0bc300ab638339b88c5e5f98ae4d724`, `d2a71152`, (this commit — the R1-R3+nits closeout) | CLOSED (dual-lens: architectural PASS-with-items, retail-fidelity FAIL → F1-F13 fix round `d2a71152` → narrow re-review: F1-F13 verified against the decomp, residuals R1-R3 + 2 nits → this commit; re-reviewer pre-authorized diff-check-only close) | **Appearance page** (`CharacterCreationAppearancePage`, `src/AcDream.App/UI/Layout/`, wired into `CharacterCreationUiController` beside the four sibling pages): gender buttons (`0x100003a7`/`a8` -> `SelectGender(2)`/`SelectGender(1)`, decomp `ListenToElementMessage` cases `0x9d`/`0x9e`); Face/Clothes sub-tabs (`0x100003a9`/`aa`, cases `0x9f`/`0xa0`) toggling the `0x100003ae`/`b4` choice containers and defaulting the "current part" to Hair/Headgear respectively; nine spin controls (hair/eyes/nose/mouth/skin `0x100003af-b3`, headgear/shirt/trousers/footwear `0x100003b5-b8`) reproducing retail's two-arrow-plus-body-click composite through `UiButton.OnClickAt`'s local x coordinate — decrement zone x=[80,127), increment zone x=[127,174), else selects the part with no index change (cases `0xa5-0xa9` and their headgear/shirt/trousers/footwear mirrors) — since `DatWidgetFactory` consumes each spin's two locally-reused arrow children (`0x1000030a`/`0x1000030b`) into ONE flat `UiButton` with no separate addressable arrow widget; nine color swatches (`0x1000030f-0x10000317` -> `SetColor(0..8)`, gated on the current part's own color-list length exactly like retail's `iNumColors > N` check); the shade scrollbar (`0x10000321`) bound via `ScalarChanged`; zoom/rotate buttons delegating to a late-bound `IChargenPreviewControl` seam. **Per-part routing table** (`StyleSlotFor`/`ColorSlotFor`/`ShadeSlotFor`), decomp-derived from `SetColor @0x0047DD50` and `SetShade @0x0047C860`: Hair has its own color AND shade; Eyes has color but NO shade (retail's `SetShade` switch has no case 1 — independently confirmed against CC6a's own "eye color has no shade indirection" finding); Nose/Mouth/Skin have NO color and ALL route their shade to SKIN shade (cases 2/3/4 share one decompiled body — a genuine retail quirk, not a porting shortcut); Headgear/Shirt/Trousers/Footwear each have their own color and shade. **Wrap semantics** (`CharacterCreationAppearancePage.CycleIndex`, internal static, unit-tested via 10 `[Theory]` cases): plain `[0,count)` modulo wrap for every style spin except Headgear; Headgear alone gets the decomp-derived `(count+1)`-position RING including the `Unset` ("no headgear") position — `CharGenState::SetHeadgearStyle`'s literal signed-int32 comparison shape (`0x0047F4B5`-`0x0047F530` decrement, `0x0047F7D8` increment): decrementing FROM style 0 lands on Unset, incrementing FROM Unset lands on style 0, decrementing FROM Unset wraps to the LAST style, incrementing past the last style lands on Unset — a real closed ring of `count+1` positions, not a plain wrap. **Review fix round F1 correction (2026-08-15):** every OTHER style spin ALSO has a decomp-observable Unset-cycling case, in the SAME switch the headgear ring was ported from — the shared decrement tail (`label_47f065`/`label_47f6d9`, reached from Hair's own decrement case `@0x0047f465-0x0047f486` and inlined per-part for Eyes/Nose/Mouth/Shirt/Trousers/Footwear) computes `new = cur - 1` on the raw signed int32 (Unset = -1), giving `new = -2`, which wraps to `count - 1` — the SAME "wrap to the last index" shape headgear's own ring uses. Incrementing from Unset (`new = -1 + 1 = 0`) was already correct in acdream. The original claim here ("no decomp-observable Unset-cycling case... starts at style 0 for BOTH directions") is WRONG for decrement; fixed in `CharacterCreationAppearancePage.CycleIndex` and its own corrected doc comment. **Heritage 6/0xc/0xd gate** (`gmCGAppearancePage::Update @~0x0047EB46-0x0047EE95`): Gearknight/Olthoi/OlthoiAcid hide the Clothes sub-tab (making all four clothing spins unreachable, matching the OWED item's "four clothing spins hidden" framing through retail's OWN mechanism — hiding the tab, not each spin individually) plus the Nose/Mouth spins directly, and disable the Eyes spin's arrows (`_eyesArrowsDisabled`, since Olthoi/Gearknight forms have fixed eyes); **review fix round F3 correction (2026-08-15):** forces `SetChoice(FACE)`/`SetSelection(HAIR)` UNCONDITIONALLY whenever the gate engages (`@0x0047eac6/0x0047eacf` Gearknight, `@0x0047ee32/0x0047ee3b` Olthoi/OlthoiAcid) — NOT only when Clothes happened to be showing, the original (wrong) framing here. A conditional gate left Nose/Mouth as the current part when the Face tab was already active, stranding the shade control on a now-hidden part; retail always snaps back to Hair. **Preview wiring** (`ChargenPreviewController`, `src/AcDream.App/Rendering/`, new): bridges a real architectural gap the CC6a/CC6b-PRE foundation left open — `ChargenPreviewRenderer` only ever built its OWN private `ChargenPreviewCamera` with no injection seam, but `ChargenPreviewZoomController` needs a SETTABLE camera to tween. Fixed at the root: `ChargenPreviewViewportCamera` gained a `ChargenPreviewCamera`-accepting constructor overload, `ChargenPreviewRenderer` gained an optional `camera` parameter using it, and `ChargenPreviewController` owns the ONE shared `ChargenPreviewCamera` instance handed to both. `ChargenPreviewController` consolidates the per-frame `IPrivateEntityViewportFrame` owner role (mirrors `PaperdollFramePresenter`, self-timing via `Stopwatch` rather than touching the shared frame-phase interface) with the `IChargenPreviewControl` seam the page's buttons bind against (constructed before the graphics backend exists, so the page cannot receive the real renderer at construction time — assigned late by `LivePresentationComposition`, exactly mirroring the paperdoll's own late `viewport.Renderer = ...` assignment). `Rebuild` recomposes via `ChargenAppearanceFactory.TryCompose` + `ChargenPreviewEntityBuilder.TryBuildAnimated` on ANY heritage/gender/appearance-selection change (no-op if identical to the last composed selection) but only SNAPS the camera to the heritage's default eye on a HERITAGE OR GENDER change (decomp-cited: `gmCGAppearancePage::Update`'s only two confirmed direct call sites are `InitializePage` and the two gender-button handlers; spin/color/shade changes call the narrower `SetSelection`/`SetColor`/`SetShade`, none of which touch `m_vectCurPosition`) — a fresh `ChargenPreviewAnimator` is unavoidable on every rebuild (it owns the resolved drawable-part list, which changes with the mesh) but is immediately restored to the PREVIOUS zoom state via `SetZoomedIn`, and the CURRENT accumulated rotation heading (not the retail default) is threaded into the rebuild, matching retail's `m_bZoomedIn`/`m_fCurHeading` both living on the PAGE and surviving `Update`. Mounted as the THIRD private creature viewport beside paperdoll/creature-appraisal: `RetailUiRuntime` gained `ChargenPreviewViewportWidget`/`ChargenPreviewControl`/`IsChargenPreviewPageVisible` (computed through `CharacterCreationUiController`'s new `AppearanceViewport`/`AppearancePreviewControl`/`IsAppearancePageVisible`, the last one gating on BOTH the page root's own Visible AND the whole screen's `Root.Visible` since `Close()` only ever hides the latter); `LivePresentationComposition` constructs the renderer+catalog+controller and wires `viewport.Renderer`/`page.PreviewControl` through the same lease/`AdoptRelease` pattern paperdoll uses; `FrameRootComposition`'s `PrivateEntityViewportFrameGroup` gained the controller as its third member; `GameWindow`/`GameWindowLifetime` gained the matching guard fields and `RenderShutdownRoots` disposal entries. **Testability seam:** `IChargenPreviewRenderer`/`IChargenPreviewFrameView` (mirroring `IPaperdollDollRenderer`/`IPaperdollFrameView`) let `ChargenPreviewControllerTests` (6 cases, installed-DAT-gated, fake renderer/view — no live GPU) exercise the REAL `ChargenAppearanceFactory`/`ChargenPreviewEntityBuilder` composition path against the installed EoR dat: same-selection no-op, heritage-change camera reset, appearance-only-change camera preservation, zoom-state preservation across an appearance rebuild, the 180° heading actually reaching the built entity's `Rotation` after `Render()`, and the invisible-page render skip. **Color-wheel scouting (campaign plan risk item 4, RESOLVED via live-DAT probe against the installed EoR dat — `CharacterCreationLiveDatTests.AppearancePage_HasGenderChoiceSpinsSwatchesShadeAndViewport`/`AppearancePage_SpinArrowGeometryIsUniformAcrossAllNineSpins`):** NO new `DatWidgetFactory` widget type was needed anywhere on this page. The nine swatch buttons author Type 1 -> `UiButton`; their nine Type-3 companion "selected"-ring overlays (`0x10000318-0x10000320`) and the GradCircle (`0x1000030e`) author Type 3 -> the generic `UiDatElement` fallback; the shade scrollbar (`0x10000321`) authors Type 0xB -> `UiScrollbar`, matching the decomp's own `DynamicCast(0xb)`. The nine spin containers and their two locally-reused arrow children all author Type 1 -> `UiButton`. Two narrow, DECIDED visual substitutions from this finding are filed as AP-215: swatches use their own `.Selected` highlight instead of toggling the separate companion overlay (retail's `SetColor`'s `m_tColorWheel[...]->SetVisible` mechanism), and the four icon-only style spins (hair/eyes/nose/mouth — CC1's `ChargenHairStyle`/`ChargenEyeStrip`/`ChargenFaceStrip` carry only an `IconId`, no name) show a 1-based ordinal instead of retail's icon thumbnail; the four clothing spins DO show their real `ChargenGearOption.Name`. **The `@140355` gender-flip-on-init oddity (campaign plan risk item 5, RESOLVED via decomp alone — no live cdb needed):** `gmCGAppearancePage::InitializePage`'s own gender-read-then-FLIP-to-the-opposite code (`~0x004802DA-0x00480303`) is real and ALWAYS fires, because `gmCharGenMainUI`'s own constructor (`~0x004e81f5-0x004e8218`, BEFORE any page constructs) calls `CharGenState::RandomizeCharacter(state, hasToD) @0x005c6d80` — retail's chargen screen is NEVER actually blank on open; it always starts with a fully random heritage/gender/appearance/clothing/template/start-area already rolled, which the Appearance page's own init code then immediately flips to the opposite gender. Filed as AP-214, the same unported-primitive gap AP-212 already tracks for the Random button (`RandomizeHeritageGroup`/`RandomizeAppearance`/`RandomizeClothing`/`RandomizeTemplate`/`RandomizeStartArea` are the SAME six primitives `RandomizeCharacter` calls) — acdream's chargen screen opens honestly blank instead, by design, this round. **AD-101 RETIRED** (register §2, 79->78 active rows): `CharacterCreationHeritagePage.Select` no longer auto-selects a gender after a heritage click — the Appearance page's real gender buttons are now the only gender-selection path, matching the review fix round's own retirement-sequencing correction (must land no later than CC5's Finish un-ghosting, which it does — CC5 has not yet un-ghosted Finish). Retail's own default is verified NOT blank (AP-214, above) but acdream's honest-blank choice is deliberate, not an oversight. Updated `CharacterCreationUiControllerTests`'s shared fixture (`FakeRuntime`/`BuildOptions`) with real non-empty Hair/Eyes/Nose/Mouth/Headgear/Shirt/Trousers/Footwear/ClothingColors lists (previously all empty placeholders — no existing test depended on the empty state) and a real `BuildAppearancePage()` layout fixture (uniform spin geometry matching the live-DAT-measured 80/127/174 zone boundaries) so the new dispatch tests exercise the SAME `OnClickAt` zone math production code uses; the one pre-existing gender-side-effect assertion (`HeritageButton_SelectsHeritage_AndAutoSelectsFirstGender`) is renamed/corrected to assert NO gender side effect. **TS-82 NARROWED** (register §4): closed out for the Appearance page specifically (now real, not content-inert) — the row now covers Summary only, CC5's remaining scope. **Register bookkeeping this commit:** AD-101 retired (row deleted, count 79->78); AP-214 filed (the `RandomizeCharacter`-at-ctor / gender-flip finding, count 149->150); AP-215 filed (the two Appearance-page visual substitutions, count 150->151); TS-82 narrowed (Summary-only, count unchanged). **Scope-addendum work (folded into this same commit, not a separate round):** `ChargenPreviewRotationController.HeadingDegrees`'s doc comment corrected to name BOTH the ctor's `0f` (`gmCGAppearancePage::gmCGAppearancePage @0x0047CDAC`) and `InitializePage`'s override to `180f` (`@0x0047FDD0`, write at `0x00480235`, pushed via `SetPlayerHeading` at `0x0048023F`) as retail's OPERATIVE starting heading; DECIDED to change the controller's own parameterless-constructor default from `0f` to a new `RetailDefaultHeadingDegrees = 180f` constant (option (b) of the two offered) rather than requiring every future mount site to remember a separate "seed to 180" call at construction — every real `gmCG3DView` owner (Appearance, Summary `@0x0047BD54` — confirmed a SEPARATE `gmCG3DView` instance/page, CC5's own scope, not touched here — and `gmBarberUI`) converges on 180° before its first visible frame, so a controller whose default silently faces the character away from the camera is exactly the trap the addendum warned about; existing pure-math tests updated to pass `0f` explicitly (keeps their relative-delta assertions simple and unchanged in meaning) plus one new test pinning the parameterless-constructor 180° default at the seam a real consumer experiences, and a second, end-to-end confirmation inside `ChargenPreviewControllerTests` that `Render()` actually applies that heading to the built entity's `Rotation`. **Tests:** `CharacterCreationLiveDatTests` (+2 permanent structural/geometry tests replacing the temporary scouting probe), `CharacterCreationUiControllerTests` (+23: gender/spin/wrap/swatch/shade/zoom-rotate dispatch, the Olthoi clothing-hide gate, the 10-case `CycleIndex` wrap-semantics theory, the renamed AD-101 test), `ChargenPreviewControllerTests` (+6, new file, installed-DAT-gated), `ChargenPreviewRotationControllerTests` (+1, the 180°-default pin). Counts (Release, full solution, `ACDREAM_PROBE_LIVE_MOUNT=1` + `ACDREAM_DAT_DIR` set so every installed-DAT-gated test in this round actually runs rather than skip-gating): Runtime 1713/0 (unchanged — `SetAppearanceIndex`/`SetShade` command plumbing already existed in `IRuntimeCharacterCreationCommands`/`GameRuntimeCommands.cs` from CC3, nothing new needed there), Core 4786/1 skip (unchanged), Content 147/0 (unchanged), App 5220/3 skips (5208/15 skips without the probe env vars — the 12-skip delta is exactly the installed-DAT-gated tests this round adds/exercises), Headless 166/0 (unchanged) — zero failures across two consecutive full-solution runs; one transient failure in `AcDream.Core.Net.Tests.Transport.NakEmissionTests.LossSoak_TwoPercentBidirectional_ZeroMessageLoss_LedgersConverge` reproduced on the FIRST full-solution run and passed clean both in isolation and on an immediate full-solution re-run — the SAME pre-existing, previously-documented flake CC6b-PRE's own ledger row already names (randomized-loss-injection timing, zero files under `src/AcDream.Core.Net/` touched this round either). **OWED for CC5+ / future:** the actual retail-icon rendering pipeline for hair/eyes/nose/mouth style spins (AP-215's own icon-label half) and the GradCircle's own retail-driven repaint (review fix round correction 2026-08-15: AP-215 does NOT name the GradCircle — that was this ledger row's own false claim; the GradCircle gap is filed separately as AP-217, REWRITTEN 2026-08-15 at the re-review of `d2a71152` (R3) after re-deriving from the decomp: `gmCGAppearancePage::ListenToElementMessage`'s own dispatch switch has NO case for the GradCircle's offset at all, so it is not a click target in retail either — `DoGradDisk` is a PAINT-only routine that blits the gradient art tinted with the current part's color (or blanks it for Eyes) whenever `SetColor`/`SetSelection` run; acdream's gap is that it never repaints the GradCircle at all, a cosmetic paint gap rather than a dead click target, and the nine swatch buttons already provide the full, decomp-cited color-selection INPUT path); a real `RandomizeCharacter` port (AP-214/AP-212's shared landing site) if a future connected gate wants retail's true randomized-on-open default instead of acdream's honest-blank one; the exact pixel-identical companion-overlay swatch highlight (AP-215) if a future visual gate demands it; **the current-part spin highlight itself, newly measured DEAD for all nine spins (AP-222, filed at the re-review of `d2a71152`, N2)** — none of the nine spins author Highlight-state media, so `RefreshColorAndShadeControls`'s `TrySetRetailState(Highlight)` call silently never changes what's drawn; unresolved whether retail's own spin art has the same gap or uses a different mechanism entirely, needs a decomp read of the real per-frame spin-face renderer before deciding a fix. |
-| Gate round 1 | CLOSED 2026-08-16 (batches A-G plus a dedicated closeout round; supersedes this ledger's "sole remaining acceptance step" framing above — that framing predates the user's connected gate, which found the six-page findings batch GF-1..GF-16, then re-tested and found R2-1..R2-8, both fully fixed across this round) | Batches: `1d9de5e0` (A — GF-15 input/GF-5 skills rows/GF-13 GM toggles), `7d09821f` (B — authored selection states/label state/zoom-swatch feedback), `0591b9a0`+`5190e169`+`2349f8b4` (C — rich text/labels/backdrops, client-wide un-consume carve-out, Summary how-to+scrollbar), `63bf64c9` (D — gmCG3DView environment backdrop), `e24ec208` (E — text origin/caption escapes/value rects/scrollbars/name prefill), `8c30aa18` (F — Skills page buckets/selection/info box/cost text/arrow states, partial — the four-bucket model itself deferred to the closeout below), `834c2547` (G — real color wheel DoColorSpots/DoGradDisk color computation, left INERT pending the closeout's wiring). Closeout round (this session, dedicated Sonnet implementer): `e1d7d095` (Group 1 — wires Batch G's two STOPPED items: `UiButton`/`UiDatElement` gain a `Tint` property, the flat-fill overlay is replaced by a genuine multiplicative sprite tint, and the DAT-backed color-source seams are threaded through the composition root), `0fed5fdd` (Group 2 — the Skills page four-bucket sorted model Batch F deferred: `ChargenSkillDetail`/`ChargenSkillFormula` thread `SkillBase.MinLevel`/`Description`/`Formula`, `CharacterCreationSkillsPage` groups/sorts/re-buckets, the info box gets its description+formula completion), `bd359d51` (Group 3 — the round review's remaining findings F4-F11/F14/F16: three UiButton corpus sweeps, a narrow `AuthoredInvisible` honor for the chat new-text indicator, `BoundedProcessOutputCapture`'s single-write `AppendLine`, a stale-comment correction, documented (not code-changed) numeric-asymmetry and harmless-set-membership findings, per-page `DatRichText.Compose` caching, and the Summary preview's own render-id pair closing a real cross-page `TextureCache` collision). Docs-only bookkeeping (register/ISSUES/findings-doc corrections for F3/F12/F15) lands in the commit immediately following this ledger update. | Register bookkeeping across the round: AP-216/AP-217 RETIRED (Group 1), AP-213 RETIRED (Group 2), AP-229/AP-230 amended with closeout addenda (F3/F5-F6), the AP section header's inverted "one high" note corrected to "one low" (F12), the AD section header recounted 77->79 (F12); new AP-231 documents the Skills page formula-connector-text approximation. Gates: full-solution Release build green throughout; App suite (live-DAT env) 5358/3, Runtime 1735/0 (unchanged), Core 4797/1, Content 154/0, Launcher.Core 338/0, and the complete solution (12 test projects) 0 failures / 4 skips at the closeout's own final run. | **STILL OWED:** the user's own connected-gate re-run against this closeout's build (nothing in this round replaces the user's own visual/behavioral confirmation of GF-1..GF-16/R2-1..R2-8's fixes); F3's literal ask (a test driving `RetailUiRuntime.Tick(double)` itself rather than its two components separately) was assessed and NOT implemented — `RetailUiRuntimeBindings` requires ~24 nested sub-binding records with no existing lightweight construction path, disproportionate to the value of strengthening an already-correct, already-tested tick-order guarantee (`Finish_EmptyName_RealEventPath_...` already pins the same order via direct calls); AP-231's formula-connector approximation remains unverified against a live retail capture. |
+| Gate round 1 | CLOSED 2026-08-16 (batches A-G plus a dedicated closeout round; supersedes this ledger's "sole remaining acceptance step" framing above — that framing predates the user's connected gate, which found the six-page findings batch GF-1..GF-16, then re-tested and found R2-1..R2-8, both fully fixed across this round) | Batches: `1d9de5e0` (A — GF-15 input/GF-5 skills rows/GF-13 GM toggles), `7d09821f` (B — authored selection states/label state/zoom-swatch feedback), `0591b9a0`+`5190e169`+`2349f8b4` (C — rich text/labels/backdrops, client-wide un-consume carve-out, Summary how-to+scrollbar), `63bf64c9` (D — gmCG3DView environment backdrop), `e24ec208` (E — text origin/caption escapes/value rects/scrollbars/name prefill), `8c30aa18` (F — Skills page buckets/selection/info box/cost text/arrow states, partial — the four-bucket model itself deferred to the closeout below), `834c2547` (G — real color wheel DoColorSpots/DoGradDisk color computation, left INERT pending the closeout's wiring). Closeout round (this session, dedicated Sonnet implementer): `e1d7d095` (Group 1 — wires Batch G's two STOPPED items: `UiButton`/`UiDatElement` gain a `Tint` property, the flat-fill overlay is replaced by a genuine multiplicative sprite tint, and the DAT-backed color-source seams are threaded through the composition root), `0fed5fdd` (Group 2 — the Skills page four-bucket sorted model Batch F deferred: `ChargenSkillDetail`/`ChargenSkillFormula` thread `SkillBase.MinLevel`/`Description`/`Formula`, `CharacterCreationSkillsPage` groups/sorts/re-buckets, the info box gets its description+formula completion), `bd359d51` (Group 3 — the round review's remaining findings F4-F11/F14/F16: three UiButton corpus sweeps, a narrow `AuthoredInvisible` honor for the chat new-text indicator, `BoundedProcessOutputCapture`'s single-write `AppendLine`, a stale-comment correction, documented (not code-changed) numeric-asymmetry and harmless-set-membership findings, per-page `DatRichText.Compose` caching, and the Summary preview's own render-id pair closing a real cross-page `TextureCache` collision). Docs-only bookkeeping (register/ISSUES/findings-doc corrections for F3/F12/F15) lands in the commit immediately following this ledger update. | Register bookkeeping across the round: AP-216/AP-217 RETIRED (Group 1), AP-213 RETIRED (Group 2), AP-229/AP-230 amended with closeout addenda (F3/F5-F6), the AP section header's inverted "one high" note corrected to "one low" (F12), the AD section header recounted 77->79 (F12); new AP-231 documents the Skills page formula-connector-text approximation. Gates: full-solution Release build green throughout; App suite (live-DAT env) 5358/3, Runtime 1735/0 (unchanged), Core 4797/1, Content 154/0, Launcher.Core 338/0, and the complete solution (12 test projects) 0 failures / 4 skips at the closeout's own final run. | **USER-PASSED 2026-08-16 on build `1.0.2-cc.o`** after two further re-test fix rounds this ledger row predates: re-test 2 (`7d6a7898`..`91f84dec`, R3-1..R3-9 — one-line captions per retail's OneLine gate, info-pane VJustify scoped fix + #410/AD-104, the single-sprite scrollbar-thumb fallback, retail's ReplaceColor spot bake replacing the tint approximation, the third exhaustive `[ Name ]` negative) and re-test 3 (`e6acb800`, R4-1..R4-4 — the base-inherited value-child reflow, the DrawTiled→single thumb marker, the pane-taller-than-frame clamp + AD-105, the PreserveEndOnLayout first-overflow pin). Residual notes carried: F3's literal ask (a test driving `RetailUiRuntime.Tick(double)` itself rather than its two components separately) was assessed and NOT implemented — `RetailUiRuntimeBindings` requires ~24 nested sub-binding records with no existing lightweight construction path, disproportionate to the value of strengthening an already-correct, already-tested tick-order guarantee (`Finish_EmptyName_RealEventPath_...` already pins the same order via direct calls); AP-231's formula-connector approximation remains unverified against a live retail capture. |
diff --git a/docs/research/2026-08-16-campaign-cc-gate-round1-findings.md b/docs/research/2026-08-16-campaign-cc-gate-round1-findings.md
index be181039..0dfe688e 100644
--- a/docs/research/2026-08-16-campaign-cc-gate-round1-findings.md
+++ b/docs/research/2026-08-16-campaign-cc-gate-round1-findings.md
@@ -1152,3 +1152,15 @@ unrelated to this batch's files). No client launches.
   (the shared `BuildAppearancePage` fixture gained the help box + its
   nested scrollbar child, StateMedia-bearing so `UiText`'s own dat-
   children carve-out actually builds it).
+
+## GATE PASSED — 2026-08-16, build `1.0.2-cc.o`
+
+The user's final pass on `1.0.2-cc.o` (carrying the R4 fixes) returned
+**"Ok works. Gate pass!"** — Campaign CC's connected gate is CLOSED
+USER-ACCEPTED. Every finding family in this doc (GF-1..16, R2-1..8,
+R3-1..9, R4-1..4) is fixed and user-verified, except the two explicitly
+dispositioned non-bugs: the `[ Name ]` prefill (three independent
+exhaustive negatives — retail's field is empty; closed as a recollection
+slip unless retail evidence surfaces) and the items deferred to their own
+tracked issues (#408 general authored-Invisible, #409 tooltips, #410
+VJustify default, AP-231's formula connector).