You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- unit tests currently use `NUnit` through the default `VSTest` runner
135
135
- UI tests live in `DotPilot.UITests` and are a mandatory part of normal verification; the harness must provision or resolve browser-driver prerequisites automatically instead of skipping when local setup is missing
136
136
- a canceled, timed-out, or hanging `DotPilot.UITests` run is a harness failure to fix, not an acceptable substitute for a real pass or fail result in CI
137
+
- when debugging or validating the browser UI path, do not launch the app manually outside `DotPilot.UITests`; reproduce and diagnose only through the real UI-test harness so failures match the enforced verification path
137
138
-`format` uses `dotnet format --verify-no-changes` as a local pre-push check; GitHub Actions validation should not spend CI time rechecking formatting drift that must already be fixed before push
138
139
- coverage uses the `coverlet.collector` integration on `DotPilot.Tests` with the repo runsettings file to keep generated Uno artifacts out of the coverage path
139
140
- desktop release publishing uses `dotnet publish DotPilot/DotPilot.csproj -c Release -f net10.0-desktop`; the validation workflow stays focused on build and automated tests, while the release workflow owns desktop publish outputs for macOS, Windows, and Linux
140
-
-`LangVersion` is pinned to `latest` at the root
141
+
-`LangVersion` is pinned to `14` at the root
141
142
- prefer the newest stable `.NET 10` and `C#` language features that are supported by the pinned SDK and do not weaken readability, determinism, or analyzability
142
143
- the repo-root lowercase `.editorconfig` is the source of truth for formatting, naming, style, and analyzer severity
143
144
- local and CI build commands must pass `-warnaserror`; warnings are not an acceptable "green" build state in this repository
145
+
- do not run parallel `dotnet` or `MSBuild` work that shares the same checkout, target outputs, or NuGet package cache; the multi-target Uno app must build serially in CI to avoid `Uno.Resizetizer` file-lock failures
144
146
- quality gates should prefer analyzer-backed build failures over separate one-off CI tools; for overloaded methods and maintainability drift, enable build-time analyzers such as `CA1502` instead of adding a formatting-only gate
145
147
-`Directory.Build.props` owns the shared analyzer and warning policy for future projects
- keep the Uno app project presentation-only; domain, runtime host, orchestration, integrations, and persistence code must live in separate class-library projects so UI composition does not mix with feature implementation
151
153
- GitHub Actions workflows must use descriptive names and filenames that reflect their purpose; do not use a generic `ci.yml` catch-all because build validation and release automation are separate operator flows
152
154
- GitHub Actions must be split into at least one validation workflow for normal builds/tests and one release workflow for CI-driven version resolution, release-note generation, desktop publishing, and GitHub Release publication
155
+
- meaningful GitHub review comments must be evaluated and fixed when they still apply even if the original PR was closed; closed review threads are not a reason to ignore valid engineering feedback
156
+
- PR bodies for issue-backed work must use GitHub closing references such as `Closes #14` so merged work closes the tracked issue automatically
153
157
- the release workflow must run automatically on pushes to `main`, build desktop apps, and publish the GitHub Release without requiring a manual dispatch
154
158
- desktop app build or publish jobs must use native runners for their target OS: macOS artifacts on macOS runners, Windows artifacts on Windows runners, and Linux artifacts on Linux runners
159
+
- desktop release assets must be native installable or directly executable outputs for each OS, not archives of raw publish folders; package the real `.exe`, `.snap`, `.dmg`, `.pkg`, `Setup.exe`, or equivalent runnable installer/app artifact instead of zipping intermediate publish directories
155
160
- desktop release versions must use the `ApplicationDisplayVersion` value in `DotPilot/DotPilot.csproj` as a manually maintained two-segment prefix, with CI appending the final segment from the build number (for example `0.0.<build-number>`)
156
161
- the release workflow must not take ownership of the first two version segments; those remain manually edited in source, while CI supplies only the last numeric segment and matching release tag/application version values
157
162
- for CI and release automation in this solution, prefer existing `dotnet` and `MSBuild` capabilities plus small workflow-native steps over Python or adding a separate helper project for simple versioning and release-note tasks
@@ -278,6 +283,8 @@ Local `AGENTS.md` files may tighten these values, but they must not loosen them
278
283
- The task is not done until the full relevant test suite is green, not only the newly added tests.
279
284
- UI tests are mandatory for this repository and must run in normal agent verification; missing local browser-driver setup is a harness bug to fix, not a reason to skip the suite.
280
285
- UI coverage must validate complete end-to-end operator flows and also assert the presence and behavior of each interactive element introduced by a feature.
286
+
- For `Uno` UI-test changes, use the official `Uno` MCP documentation as the source of truth and align browser assertions with the documented WebAssembly automation mapping before changing the harness shape.
287
+
- When debugging local product behavior on this machine, prefer the real desktop `Uno` app head plus local `Uno` app tooling or MCP over ad hoc `browserwasm` runs; keep `browserwasm` for the dedicated `DotPilot.UITests` verification path.
281
288
- GitHub Actions PR validation is mandatory for every PR and must enforce the real repo verification path so test failures are caught in CI, not only locally.
282
289
- GitHub Actions PR validation must run full automated test verification, especially the real UI suite; build-only or smoke-only checks are not an acceptable substitute for pull-request gating.
283
290
- GitHub Actions validation must also produce downloadable app artifacts for macOS, Windows, and Linux so every PR and mainline run has test results plus installable build outputs.
@@ -332,6 +339,7 @@ Ask first:
332
339
- Follow the canonical MCAF tutorial when bootstrapping or upgrading the agent workflow.
333
340
- Commit cohesive code-change batches promptly while debugging, especially before switching focus or starting long verification runs, so the branch state stays inspectable and pushable.
334
341
- After opening or updating a PR, create a fresh working branch before continuing with the next slice of work so follow-up changes do not pile onto the already-reviewed branch.
342
+
- Keep `DotPilot` feeling like a fast desktop control plane: startup, navigation, and visible UI reactions should be prompt, and agents should remove unnecessary waits instead of normalizing slow web-style loading behavior.
335
343
- Keep the root `AGENTS.md` at the repository root.
336
344
- Keep the repo-local agent skill directory limited to current `mcaf-*` skills.
337
345
- Keep the solution file name cased as `DotPilot.slnx`.
@@ -352,6 +360,7 @@ Ask first:
352
360
- Installing stale, non-canonical, or non-`mcaf-*` skills into the repo-local agent skill directory.
353
361
- Moving root governance out of the repository root.
354
362
- Mixing multiple `.NET` test frameworks in the active solution without a documented migration plan.
363
+
- Adding fallback paths or alternate harnesses that only make failures disappear in tests while the primary product path remains broken.
355
364
- Switching desktop Uno pages into stacked or mobile-style responsive layouts during resize work unless the user explicitly asks for a different composition; desktop pages must stay desktop-first and protect geometry through sizing constraints instead.
356
365
- Adding extra UI-test orchestration complexity when the actual goal is simply to run the tests and get an honest pass or fail result.
357
366
- Planning `MLXSharp` into the first product wave before it is ready for real use.
0 commit comments