fix: reject an unsupported saved repository at load instead of crashing [patch]

[matt-edmondson]

Fixes #427

What was wrong

GitRepository registers AzureDevOpsRepository as a [JsonDerivedType], so a saved options file carrying one deserializes without complaint. Nothing then acts on it — all six sites that pattern-match a repository handle GitHubRepository and throw new InvalidOperationException("Only GitHub Repos are supported at this time") otherwise.

UpdateClonedStatus runs from the constructor's RefreshPage(), so the throw landed on the very next launch, before the user could open the UI to delete the entry causing it. That made it unrecoverable without hand-editing the file.

The fix

The issue offered two routes: finish the Azure path everywhere, or drop the registration. This takes a third that gets the acceptance criteria without doing either.

Deserialization is the only boundary an unsupported repository can arrive through. GitRepository.Create returns a GitHubRepository or null and cannot produce anything else, so no other path can introduce one. Rejecting it at that single boundary is what turns every later is GitHubRepository test into a genuine invariant rather than a live branch that throws on the render thread — rather than guarding six call sites separately and having to keep doing so for the seventh.

Each rejection is named in the application log. The [JsonDerivedType] registration deliberately stays, so an existing options file still parses; it is the live object that is refused, not the document. Dropping the registration instead would make the whole options file fail to load, which trades one startup crash for another.

A selection or clone record naming a rejected repository is cleared with it. The panels reach for a selection through Options.Repos[Options.BaseRepo] once something is selected, so leaving one behind would turn one crash into another. An empty selection is the state a fresh install starts in, which the surrounding TryGetValue checks at lines 459 and 554 already handle.

The second commit: the dev directory default off Windows

The first commit left the constructor's post-load block uncovered, and SonarCloud failed the PR at 75% coverage on new code. The reason nothing could drive that block is a real defect in its own right:

System.ArgumentException: Cannot convert "C:\dev" to AbsoluteDirectoryPath
   at ktsu.ProjectDirector.ProjectDirectorOptions..ctor() in ProjectDirectorOptions.cs:21

DevDirectory defaulted to a hardcoded C:\dev, which is not an absolute path off Windows, so AbsoluteDirectoryPath rejected it in the field initializer — meaning ProjectDirectorOptions could not be constructed at all on Linux or macOS. Not by a test, and not by the application: it cannot start on either, and this repository runs its tests on both.

So the second commit gives the default a platform-aware fallback — Windows keeps the path it has always had, everywhere else gets ~/dev. Only a fresh install reads it, so a saved options file keeps whatever the user chose.

With options constructible, the constructor block collapses to a single MakeLoadedOptionsSafe call that is driven end to end against real options.

I flagged this as wanting its own issue when I opened the PR. It turned out to be load-bearing for testing #427's own fix, so it is here rather than deferred; happy to split it out if you would rather review it separately.

Tests

ProjectDirector.Test/UnsupportedRepoTests.cs, following the pattern CLAUDE.md sets out — the part with a rule in it is a plain method, drivable without a live ImGui context.

AnAzureDevOpsRepositoryDeserializesIntoALiveObject pins the premise: the type discriminator alone is enough to produce one, which is exactly what a hand-edited file or a leftover from a partially built feature looks like. If that ever stops holding, the test says so and the rule can go.

LoadedOptionsCarryingAnUnsupportedRepoAreMadeSafe covers the whole of what the constructor does after loading: the crashing entry goes, the selection naming it is cleared, a selection naming a survivor is left alone, the clone record goes, and the rejection is reported once.

Verified by substituting the unfixed behaviour back in (rejecting nothing, so an unsupported repo survives into the six throwing sites): AnUnsupportedRepoIsDroppedAndTheSupportedOnesAreKept, ACloneRecordedAgainstADroppedRepoIsCleared, EveryRepoBeingUnsupportedLeavesAnEmptyButUsableState and LoadedOptionsCarryingAnUnsupportedRepoAreMadeSafe all fail against it and pass against the fix.

Full suite on this branch: 52 total, 50 passed, 0 failed, 2 inconclusive (both need git-lfs, unrelated and present on main). dotnet build --configuration Release is clean. Coverage on new code goes from 75% to 96%.

🤖 Generated with Claude Code

https://claude.ai/code/session_01EdV5iCFkUxFqkLZQAGLAVT

[sonarqubecloud]

Quality Gate passed

Issues
19 New issues
0 Accepted issues

Measures
0 Security Hotspots
96.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud