james.maesandClaude Opus 5.5
839fb72bec
## What Brings AppKit into conformance with [KofTwentyTwo/standards](https://github.com/KofTwentyTwo/standards). Reviewable commit by commit: | Commit | Change | | --- | --- | | build | Quality gate from `configs/dotnet` (analyzers incl. Meziantou, warnings as errors), `packages.lock.json` per project, locked-mode restore | | style | Kingsrook layout and LF line endings, produced mechanically by `dotnet format` (formatting only) | | docs | SPDX license header on every C# file | | refactor | Real code changes: analyzer findings fixed (one type per file, regex timeouts, async void, …) and header comments on every type and member | | ci | Old workflows replaced by callers of the shared standards workflows (PR gates, security, CodeQL, .NET CI, NuGet release with SBOM + attestation + trusted publishing), Scorecard | | docs | README, CONTRIBUTING (GitHub Flow, DCO, signing), SECURITY, CODEOWNERS, templates, Dependabot, threat model, ADRs, RELEASING | Also includes `dev`'s CI fix, so it supersedes #1; the `dev` branch goes away under GitHub Flow. ## Why AppKit is the first Product repository to adopt the standards. Static conformance before: 16 FAIL; after: 0 FAIL, 0 WARN (the remaining UNKNOWN rows are GitHub settings and rulesets, applied separately). ## How tested Locally with `CI=true` (lock files enforced): locked restore x64 and ARM64; zero-warning x64 build; 115 unit tests with 100% line coverage of `KofTwentyTwo.AppKit` and `KofTwentyTwo.AppKit.Updates`; 12 FlaUI UI tests (WinUI + WPF samples); `dotnet format --verify-no-changes --severity warn` clean; pack produces 4 packages + symbols; actionlint, zizmor (pedantic), gitleaks clean. The UI tests caught a regression introduced while fixing MA0147 (the WPF splash stopped dismissing because no UI context existed yet); fixed by starting the countdown through the dispatcher in both packages. ## Notes - `ci.yml` and `release.yml` are pinned to KofTwentyTwo/standards#3's head commit; they are repinned after that PR merges. - This pull request's new check names become required checks once the repository's rulesets are updated. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Signed-off-by: James Maes <james@kof22.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
1.5 KiB
1.5 KiB
ADR-0001: Build the WinUI and WPF views in code, not XAML
- Status: Accepted
- Date: 2026-10-09
- Pull request: recorded retroactively for the initial design
Context
The splash, About, and log viewer screens are shared by every KofTwentyTwo app through
NuGet packages. Most of those apps ship unpackaged through Velopack, not as MSIX. A
WinUI XAML library compiles its markup into .xbf and .pri resources that the host
app must merge into its own resource index; that merge is reliable for packaged apps
and fragile for unpackaged ones (missing-resource crashes at runtime that no build
step catches).
Options considered
Option A: XAML user controls in the libraries
- Pros: familiar authoring, designer support.
- Cons: resource merging in unpackaged hosts; two build pipelines (WinUI and WPF XAML compilers) inside libraries; harder to keep the WinUI and WPF versions identical.
Option B: views built in C#
- Pros: a plain assembly with no resources to merge, so it works the same packaged or not; WinUI and WPF versions can mirror each other line for line.
- Cons: layout is more verbose to read and write.
Decision
Option B. The UI packages construct their visual trees in C#. Host apps still use XAML for their own windows.
Consequences
- The packages work in packaged and unpackaged apps without extra setup.
- Views are a little harder to restyle; theme resources are looked up at runtime.
- Security: none.
- The FlaUI tests drive the sample apps to prove the views render and behave.