AGENTS.md

Any code you commit SHOULD compile, and new and existing tests related to the change SHOULD pass.

You MUST make your best effort to ensure your changes satisfy those criteria before committing. If for any reason you were unable to build or test the changes, you MUST report that. You MUST NOT claim success unless all builds and tests pass as described above.

Do not complete without checking the relevant code builds and relevant tests still pass after the last edits you make. Do not simply assume that your changes fix test failures you see, actually build and run those tests again to confirm. When building and running tests, use /p:TreatsWarningsAsErrors=true. Also, do not assume that tests pass just because you did not see any failures in your last test run; verify that all relevant tests were actually run. When running tests, you can ignore the warning about "Blame" data collector errors.

In addition to building and testing your changes, you MUST run the following scripts:

• dotnet run ./eng/update-all.cs

You MUST follow all code-formatting and naming conventions defined in .editorconfig.

In addition to the rules enforced by .editorconfig, you SHOULD:

• Prefer file-scoped namespace declarations and single-line using directives.
• Ensure that the final return statement of a method is on its own line.
• Use pattern matching and switch expressions wherever possible.
• Use nameof instead of string literals when referring to member names.
• Always use is null or is not null instead of == null or != null.
• Trust the C# null annotations and don't add null checks when the type system says a value cannot be null.
• Prefer ?. if applicable (e.g. scope?.Dispose()).
• Use ObjectDisposedException.ThrowIf where applicable.
• When adding new unit tests, strongly prefer to add them to existing test code files rather than creating new code files.
• When running tests, if possible use filters and check test run counts, or look at test logs, to ensure they actually ran.
• Do not finish work with any tests commented out or disabled that were not previously commented out or disabled.
• Do not update global.json file
• When writing tests, do not emit "Act", "Arrange" or "Assert" comments.
• There should be no trailing whitespace in any lines.
• Add a blank line before XML documentation comments (///) when they follow other code (methods, properties, fields, etc.).
• Do not use static lambdas unless necessary to avoid a closure allocation.

Do not consider solution files (sln, slnx) in the slnx folders. These files are automatically generated and only for developers working on the project.

Do not manually update files under the ref/ folder. Their content is generated when building the solution, and any resulting changes must be committed to git.