RoslynMcpServer: Instructions file for Codex

Code style for agents

C# style for this repository is in docs/code-style.md, relative to the repository root.

• Read that file in full once before the first creation or edit of C# code in the current task, including tests.
• Read it in full when reviewing style or discussing changes to these rules.
• Planning, research, and discussion that do not change code do not require reading the file, unless the task is about the style itself.
• If the task moves from discussion to implementation, read the file before the first code change.
• If docs/code-style.md changes on disk during the task, read it again in full before the next code change.
• Apply the rules to new code and to lines this task already changes. That includes the section "Applying the rules to existing code": leave the rest of a file as it is, including member order in types this task does not edit.
• If you launch a subagent that will create, edit, or review the style of C# code, its prompt must require it to read docs/code-style.md in full before the first edit or before style comments, and to apply those rules only to new code and to lines that subagent changes.
• Text that lives in code is English: comments, XML docs, log and diagnostic messages, exception messages, test failure text, and asserted fragments. Localized external output kept as test data stays verbatim; project documentation keeps its current language.
• Exception: code under forks/ is a copy of an upstream project. It follows that project's style and its .editorconfig (for forks/roslyn-buildhost, Roslyn's), not docs/code-style.md, so a change can go upstream as a pull request with a minimal diff. Keep upstream files verbatim except for deliberate changes, and match the surrounding upstream code in naming, layout and comments.

Test selection and final validation

• Use focused tests during implementation for quick feedback. Tests named by a plan or epoch are a minimum, not the complete validation scope.
• After changing production C# code, run all tests in RoslynMcpServer.Tests/SourceStructure. They analyze the entire production source tree, including transitive calls and registered lambdas, so searching for references to changed symbols is not enough to select them.
• Before final acceptance or committing code or test changes, build the solution and run the complete main CI suite (Category!=AnalyzerLifecycle&Category!=RequiresPinnedSdk; on Linux also &Category!=RequiresWindows, as in the workflow) in the RoslynMcpServer.Tests project against the final code, in Release configuration as specified in .github/workflows/test-suite.yml. After a fix, rerun affected tests during development and the complete main suite before acceptance or commit.
• Comments are not production code. A change that only edits comments (// and XML doc comments in C#, comments in project and build files) needs neither the SourceStructure run nor the main suite, and it does not raise the version or need a release. Any change to code, attributes, or project and build settings, even in the same commit, brings back the full rules.
• Run AnalyzerLifecycle additionally when changes can affect analyzer/shadow-copy lifecycle, the workspace load/prepare/publication paths used by that lifecycle, the lifecycle host, or its test/build configuration. Enable ROSLYN_MCP_ANALYZER_LIFECYCLE=1 for that run. Unrelated changes do not require this specialized suite.
• With Roslyn MCP available, prefer run_dotnet_build, run_specific_test, and run_dotnet_test. If a specialized tool cannot express the required integration environment, use an available runner that can. With another harness, use its supported build/test runner for the same checks. A zero-test run is not a pass; report failures, skips, timeouts, and unavailable integration environments instead of claiming full validation.
• In subagent workflows, the coordinator owns final build/test validation. Independent review and specification acceptance do not replace running the tests.
• Preserve exact inventories of known structural-analysis limits. When production changes legitimately add a limit, explain it and update the expected identity and kind; do not merely loosen the count or ignore unexpected limits.