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
Copy file name to clipboardExpand all lines: AGENTS.md
+10Lines changed: 10 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -21,6 +21,8 @@ This file defines how AI agents work in this solution.
21
21
- Solution root: `.` (`DotPilot.slnx`)
22
22
- Projects or modules with local `AGENTS.md` files:
23
23
-`DotPilot`
24
+
-`DotPilot.Core`
25
+
-`DotPilot.Runtime`
24
26
-`DotPilot.ReleaseTool`
25
27
-`DotPilot.Tests`
26
28
-`DotPilot.UITests`
@@ -136,13 +138,16 @@ For this app:
136
138
- coverage uses the `coverlet.collector` integration on `DotPilot.Tests` with the repo runsettings file to keep generated Uno artifacts out of the coverage path
137
139
- 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
138
140
-`LangVersion` is pinned to `latest` at the root
141
+
- 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
139
142
- the repo-root lowercase `.editorconfig` is the source of truth for formatting, naming, style, and analyzer severity
140
143
- local and CI build commands must pass `-warnaserror`; warnings are not an acceptable "green" build state in this repository
141
144
- 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
142
145
-`Directory.Build.props` owns the shared analyzer and warning policy for future projects
-`global.json` pins the .NET SDK and Uno SDK version used by the app and tests
145
148
-`DotPilot/DotPilot.csproj` keeps `GenerateDocumentationFile=true` with `CS1591` suppressed so `IDE0005` stays enforceable in CI across all target frameworks without inventing command-line-only build flags
149
+
- architecture work must keep a vertical-slice shape: each feature owns its contracts, orchestration, and tests behind clear boundaries instead of growing a shared horizontal service layer
150
+
- 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
146
151
- 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
147
152
- 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
148
153
- the release workflow must run automatically on pushes to `main`, build desktop apps, and publish the GitHub Release without requiring a manual dispatch
@@ -259,16 +264,20 @@ Local `AGENTS.md` files may tighten these values, but they must not loosen them
259
264
- Tests must prove the real user flow or caller-visible system flow, not only internal implementation details.
260
265
- Tests should be as realistic as possible and exercise the system through real flows, contracts, and dependencies.
261
266
- Tests must cover positive flows, negative flows, edge cases, and unexpected paths from multiple relevant angles when the behaviour can fail in different ways.
267
+
- All caller-visible feature flows must have API or integration-style automated coverage through public contracts; structure-only unit tests are not enough for this repository.
262
268
- Prefer integration, API, and UI tests over isolated unit tests when behaviour crosses boundaries.
263
269
- Do not use mocks, fakes, stubs, or service doubles in verification.
264
270
- Exercise internal and external dependencies through real containers, test instances, or sandbox environments that match the real contract.
265
271
- Flaky tests are failures. Fix the cause.
272
+
- Because CI does not guarantee Codex, Claude Code, or GitHub Copilot availability, keep a deterministic test AI client in-repo so core agent flows stay testable without external provider CLIs.
273
+
- Tests that require real Codex, Claude Code, or GitHub Copilot toolchains must run only when the corresponding toolchain and auth are available; their absence is an environment condition, not a reason to block the provider-independent test baseline.
266
274
- Changed production code MUST reach at least 80% line coverage, and at least 70% branch coverage where branch coverage is available.
267
275
- Critical flows and public contracts MUST reach at least 90% line coverage with explicit success and failure assertions.
268
276
- Repository or module coverage must not decrease without an explicit written exception. Coverage after the change must stay at least at the previous baseline or improve.
269
277
- Coverage is for finding gaps, not gaming a number. Coverage numbers do not replace scenario coverage or user-flow verification.
270
278
- The task is not done until the full relevant test suite is green, not only the newly added tests.
271
279
- 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
+
- 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.
272
281
- 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.
273
282
- 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.
274
283
- 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.
@@ -322,6 +331,7 @@ Ask first:
322
331
323
332
- Follow the canonical MCAF tutorial when bootstrapping or upgrading the agent workflow.
324
333
- 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
+
- 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.
325
335
- Keep the root `AGENTS.md` at the repository root.
326
336
- Keep the repo-local agent skill directory limited to current `mcaf-*` skills.
327
337
- Keep the solution file name cased as `DotPilot.slnx`.
Stack: `.NET 10`, class library, feature-aligned contracts and provider-independent runtime foundations
5
+
6
+
## Purpose
7
+
8
+
- This project owns non-UI contracts, typed identifiers, and feature slices that must stay independent from the Uno presentation host.
9
+
- It provides the stable public shapes for runtime, orchestration, providers, and shell configuration so UI and future runtime implementations can evolve without circular coupling.
10
+
11
+
## Entry Points
12
+
13
+
-`DotPilot.Core.csproj`
14
+
-`Features/ApplicationShell/AppConfig.cs`
15
+
-`Features/RuntimeFoundation/*`
16
+
17
+
## Boundaries
18
+
19
+
- Keep this project free of `Uno Platform`, XAML, brushes, and page/view-model concerns.
20
+
- Organize code by vertical feature slice, not by shared horizontal folders such as generic `Services` or `Helpers`.
21
+
- Prefer stable contracts, typed identifiers, and public interfaces here; concrete runtime integrations can live in separate libraries.
22
+
- Keep provider-independent testing seams real and deterministic so CI can validate core flows without external CLIs.
0 commit comments