F1: the crash reporter comment claimed the launcher never holds a password
in any field - false (ProfileEditorDialogViewModel, AccountProfile.Password,
StartRequest.Password). Reworded to the true, narrower invariant (no throw
site interpolates a credential VALUE into an exception message) and pinned
it with CrashReportNeverContainsAStoredPassword: a real STJ failure over a
profiles document containing a known password, corrupted after the
credential, must yield a crash file with the stack and without the value.
F2: the co-deploy Inputs covered only Bake own sources; a Content edit
never refreshed the 83 MB exe. Now the full reference closure. Fixing it
surfaced two more incrementality traps, both fixed and comment-documented:
SkipUnchangedFiles left the output older than the triggering input (target
re-ran forever - added an explicit Touch), and %(Item.Metadata) in a plain
Include does not batch (the literal percent-text became a permanently
out-of-date phantom input - globs are now spelled per project). Verified:
Core edit retriggers, then two consecutive clean incremental builds.
F3: RID publishes ran BOTH co-deploy paths (two self-contained bake
publishes). Build-time target now guarded on _IsPublishing; verified a
real win-x64 publish runs zero build-target co-deploys and still ships
both exes.
F4: comment misattributed PublishBakeTool=false to CI lanes; it is
target-local recursion guarding. F5: the x:Name reflection sweep now walks
the markup as XML and tolerates template-scoped names (no generated field
exists for those). F6: dead using removed. Hardening: the crash reporter
positional --data-dir fallback requires a fully-qualified path so a
relative or flag-shaped value cannot create ./crash-reports at an
arbitrary CWD.
Launcher 67/67, Launcher.Core 317/317.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Falsification-proven: 12/12 fail against AvaloniaXamlLoader.Load (the #398
crash shape), 12/12 pass against InitializeComponent. Launcher tests 66/66
on Windows and native Ubuntu, no display required. xunit -> xunit.v3 in the
launcher test project (required by Avalonia.Headless.XUnit 12.1.1 net10.0).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
#398 was a crash on every modal open/close caused by MainWindow's
constructor calling AvaloniaXamlLoader.Load(this) instead of the
generated InitializeComponent() — only InitializeComponent assigns the
x:Name backing fields, so every named control was null and the first
Dispatcher.UIThread.Post callback in OnViewModelPropertyChanged threw
NullReferenceException, killing the process. It reached the user gate
because no test in tests/AcDream.Launcher.Tests (ViewModel-only) ever
constructed a MainWindow. #399 is the process gap that let that class of
defect through 14,012 green tests.
Adds Avalonia.Headless.XUnit 12.1.1 to the launcher test project. Its
net10.0 dependency group targets xunit v3, so the project migrates
xunit 2.9.3 -> xunit.v3 3.2.2 (drop-in: all 54 pre-existing tests compile
and pass unchanged under dotnet test via xunit.runner.visualstudio 3.1.4,
which already supported v1/v2/v3; two call sites needed
TestContext.Current.CancellationToken per the new xUnit1051 analyzer).
TestAppBuilder.cs wires [assembly: AvaloniaTestApplication] to a headless
AppBuilder.Configure<App>() so the real App.axaml FluentTheme is live in
tests.
MainWindowViewTests.cs adds 12 [AvaloniaFact]/[AvaloniaTheory] tests:
- an explicit non-null + type check of every x:Name field the
code-behind dereferences (ProfilesTree, ServerNameTextBox,
AccountNameTextBox, CharacterNameTextBox, EditorSubmitButton,
FirstRunDatDirectoryTextBox, FirstRunCloseButton, UpdateCloseButton)
- a reflection sweep over every x:Name found in MainWindow.axaml, so a
future named control without a matching non-null field fails loudly
- one open+close round trip per ProfileEditorKind (all seven, including
Remove), plus the first-run wizard and the update prompt, each pumping
Dispatcher.UIThread.RunJobs() so the queued focus callback actually
executes instead of just being asserted vacuously
- a dedicated test for the _focusBeforeModal-restore branch (not just
the ProfilesTree.Focus() fallback), anchored on a real focusable
button since ProfilesTree (TreeView) has Focusable="False" under
FluentTheme — its own tab stops are TreeViewItem rows, so the
close-path assertions check "no exception escaped the dispatcher"
rather than "focus landed on ProfilesTree"
Falsification (required evidence): reverting MainWindow's constructor to
AvaloniaXamlLoader.Load(this) and rerunning gives 12 failed / 0 passed —
10 tests throw NullReferenceException at MainWindow.FocusActiveModal,
propagating cleanly out of Dispatcher.UIThread.RunJobs() (confirming
dispatcher exceptions are not silently swallowed), and the 2 reflection
tests fail on an explicit "x:Name 'ProfilesTree' was null after
construction" message. Restoring InitializeComponent() gives 12 passed /
0 failed. Full launcher suite: 66 passed / 0 failed, reproduced on both
Windows and native Ubuntu (WSL, no display/Xvfb — Avalonia.Headless needs
none). AcDream.Launcher.Core.Tests: 317/317 unaffected.
No CI workflow change needed: .github/workflows/headless-portability.yml's
portable-launcher job already runs dotnet test on the launcher test
project on both windows-latest and ubuntu-latest with no display setup,
which is sufficient for Avalonia.Headless.
Closes#399.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Two gaps found launching the launcher for the LA11 gate.
1. acdream-bake was co-deployed only AfterTargets=Publish with a RID, so a
plain `dotnet build` left the launcher with no bake tool beside it while
App.OnFrameworkInitializationCompleted resolves it at
AppContext.BaseDirectory/acdream-bake[.exe]. A developer-built launcher
therefore reached the first-run wizard with an installer it could never
run. CoDeployBakeToolToBuildOutput does for Build what the publish target
does for Publish: still NO Launcher -> Bake project reference, still a
self-contained single file so exactly one file lands beside the launcher
rather than scattering Content/Chorizite assemblies into its output.
Staged through obj/ because publishing straight into the launcher output
makes the inner publish delete what the outer build just wrote.
Inputs/Outputs keep it incremental - verified: 79.6 MB bake exe present,
--help exits 0, and a second build skips the republish in ~1 s.
2. #398: the top-level guard printed only ex.Message, so the crash that
preceded this commit surfaced with no file, line, or frame. The full
exception now goes to a crash-reports file under the resolved data root
and stderr names the path. The first implementation wrote to the machine
real data root when option parsing itself failed, which broke LA11 process
local roots during an isolated run; the reporter now reads --data-dir
positionally for that fallback. Verified: report lands inside the isolated
root and the real root stays empty.
The redaction comment states exactly what is guaranteed - args/environment
are never serialized, while exception text may quote an option name or path,
which is safe only because credentials never enter launcher state.
Launcher.Core 317/317 green.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
#399 (HIGH, process class): no test constructs MainWindow — the launcher
test project is ViewModel-only with no Avalonia headless package, which is
how a crash on every modal open/close passed 14,012 green tests and reached
the user gate. Fix direction is Avalonia.Headless.XUnit plus a view test
that drives every modal open/close, catching the class rather than one
spelling.
#398 (MODERATE): the top-level guard prints only ex.Message, so the fatal
NullReferenceException fixed at d54b8a78 surfaced with no file, line, or
frame; diagnosis needed a temporary code edit and rebuild. Fix direction is
a redaction-scanned crash file under the data root.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Every click in the launcher exited the process. MainWindow ctor called
AvaloniaXamlLoader.Load(this), which loads the XAML tree but never assigns
the generated x:Name backing fields, so ProfilesTree, ServerNameTextBox,
AccountNameTextBox, CharacterNameTextBox, EditorSubmitButton,
FirstRunDatDirectoryTextBox and UpdateCloseButton were all null. Opening or
closing any modal calls Focus() on one of them via
OnViewModelPropertyChanged, so the NullReferenceException escaped the
dispatcher and Program's top-level guard exited 74. A fresh isolated-root
start auto-opens the first-run wizard and hit the same line with no click
at all.
App.axaml.cs keeps AvaloniaXamlLoader.Load - that is the correct idiom for
Application.Initialize(), which has no named controls.
Verified live: the isolated-root launch that died instantly now stays up
with the first-run wizard open and the window responding.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
