releases/ClaudeDo
2
0
Fork 0
Code Issues 1 Pull Requests 2 Actions Packages Projects Releases 24 Wiki Activity

Merge branch 'main' into claudedo/4e19605838a3404f98624cb0e90195da

Browse Source 
# Conflicts:
#	docs/open.md
#	src/ClaudeDo.Installer/CLAUDE.md
#	src/ClaudeDo.Installer/Pages/SystemCheckPage/SystemCheckPageView.xaml
#	src/ClaudeDo.Installer/Pages/SystemCheckPage/SystemCheckPageViewModel.cs
This commit is contained in:
mika kuns
2026-08-06 08:36:58 +02:00
parent 09e0772673 83ca1fc6dc
commit 1b0ecbe361
15 changed files with 570 additions and 231 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/ClaudeDo.Installer/CLAUDE.md
+17 -11
View File
@@ -128,12 +128,6 @@ The Apps & Features uninstall string and "Rerun Installer" both point at `<Insta
## Environment Checks
> **Merge status (2026-08-06): `Checks/`, `SystemCheckPage`, `ExecutableResolver`, and the
> "Claude Help Me" button below are on this branch.** The 2026-08-05 note about two unmerged
> task branches applied to an earlier state; the "Claude Help Me" button follow-up has since
> landed (see below). The Config-mode Diagnose section in `SettingsWindow` is still **not**
> implemented — see `docs/open.md`.
`Checks/` holds one `IEnvironmentCheck` per concern, run in parallel by `EnvironmentCheckService.RunAllAsync`:
| Check | Severity | What it verifies |
@@ -156,6 +150,10 @@ regardless of severity (an indeterminate result — e.g. the CLI not found, so v
can't be checked — must not strand the user; the underlying `Error`-severity check for the CLI
itself, `ClaudeCliCheck`, is what blocks in that case).
The check-row rendering and the check-run logic (busy state, summary text, Recheck command) live
in one place — `Checks/CheckListViewModel.cs` + `Checks/CheckListView.xaml` — composed by every
page that hosts a check list, not duplicated per page.
`SystemCheckPage` (`Pages/SystemCheckPage/`) hosts the check list in the **FreshInstall** wizard
only, registered via `PageResolver` at `Order = 1` (directly after `WelcomePage`); `WizardViewModel`
filters it back out in `Update` mode along with Paths/Service/UiSettings. Checks run automatically
@@ -164,8 +162,8 @@ on page entry (`LoadAsync`, guarded against double-entry). "Next" is disabled vi
subscribes to `PropertyChanged` on the current page so a live recheck can flip it back. A "Recheck"
button re-runs `EnvironmentCheckService.RunAllAsync` (disabled while already running).
**"Claude Help Me" button** (`Core/ClaudeHelpLauncher.cs`) — a second footer button next to
"Recheck", enabled only when `claude-cli` is `Ok` and `claude-auth` is not `Failed` (`Unknown`
**"Claude Help Me" button** (`Core/ClaudeHelpLauncher.cs`) — a second button below the shared
check-list footer, enabled only when `claude-cli` is `Ok` and `claude-auth` is not `Failed` (`Unknown`
stays enabled — an indeterminate login state shouldn't block the one feature that could help
diagnose it). `BuildReportAsync` renders all check results (Id/Severity/Status/Message table,
plus the full `Detail` of any `Failed` check) and system info (OS, `dotnet --list-runtimes`,
@@ -175,7 +173,15 @@ user) and deliberately excludes credentials/tokens/env-var dumps. `LaunchTermina
`wt.exe -d %TEMP% cmd.exe /k <claude> <prompt>` (or `cmd.exe /k <claude> <prompt>` if `wt.exe`
isn't resolvable) via the injectable `IProcessLauncher`, pointing the initial prompt at that
report file. Errors from either step surface as `ClaudeHelpError` on the page, never an
exception.
exception. It reads the last report via `CheckListViewModel.LastReport`, so it re-evaluates on
every check run.
**Not implemented:** a Diagnose section in `SettingsWindow` (Config mode) that re-runs the same
checks against the installed configuration — still speced as a follow-up, no code yet.
`DiagnosePage` (`Pages/DiagnosePage/`) hosts the same `CheckListView` in `SettingsWindow` (Config
mode only, `ShowInSettings = true` / `ShowInWizard = false`, `Order = 5` — after UiSettings).
Nothing here blocks navigation and checks do **not** auto-run on load — only on a "Recheck" click.
Unlike the wizard, its `InstallContext` is built from the **installed** configuration
(`InstallerWorkerConfig.Load()` for `ClaudeBin`/`SignalRPort`, the shared `InstallContext` for
`InstallDirectory`/`ExternalMcpPort`), refreshed on every `LoadAsync()` — not the wizard-default
`InstallContext` the DI container hands out, which is only populated once a page's `ApplyAsync`
(i.e. Save) runs. `DiagnosePage` intentionally has **no** "Claude Help Me" button — that one is
wizard-only.