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
@@ -86,6 +86,8 @@ If no new rule is detected -> do not update the file.
86
86
-`docs/ADR/*` for design/architecture decisions
87
87
-`docs/Architecture/Overview.md` when module boundaries or interactions change
88
88
- Implement code and tests together.
89
+
- When asked to fix review findings, close every confirmed finding in the same pass; do not leave partial fixes.
90
+
- Do not keep or add public sample projects; repository focus is SDK + tests (including AOT tests) only.
89
91
- Run verification in this order:
90
92
- focused tests for changed behavior
91
93
- full solution tests
@@ -108,11 +110,20 @@ If no new rule is detected -> do not update the file.
108
110
109
111
### Testing (ALL TASKS)
110
112
111
-
- Testing framework is TUnit (`tests/CodexSharp.Tests`).
113
+
- Testing framework is TUnit (`tests`).
114
+
- TUnit/MTP does not support `--filter`; for focused runs use `dotnet test ... -- --treenode-filter "<pattern>"`.
115
+
- Always invoke runner options after `--` (for example `dotnet test --solution ManagedCode.CodexSharpSDK.slnx -c Release -- --treenode-filter "<pattern>"`); if a focused filter runs zero tests, treat it as an invalid filter and correct it before reporting results.
116
+
- In this repository, method-level `treenode-filter` patterns resolve at depth 3 (`/*/*/*/<TestMethodName>`). For integration subset runs use `dotnet test --solution ManagedCode.CodexSharpSDK.slnx -c Release -- --treenode-filter "/*/*/*/RunAsync_*_EndToEnd"` (matches current `CodexExecIntegrationTests`).
117
+
- For reliable discovery when selecting focused tests, use the built test app directly: `tests/bin/Release/net10.0/ManagedCode.CodexSharpSDK.Tests --list-tests` (the `dotnet test ... -- --list-tests` wrapper can report zero tests in this setup).
112
118
- Every behavior change must include or update tests.
113
119
- Prefer behavior-level tests over trivial implementation tests.
114
-
- For CLI process interactions, use `FakeCodexProcessRunner` test doubles rather than invoking external binaries.
120
+
- Integration test sandboxes must be created under the repository `tests` tree (for example `tests/.sandbox/*`) for deterministic, inspectable paths; do not use `Path.GetTempPath()` for test sandbox directories.
121
+
- For CLI process interaction tests, use the real installed `codex` CLI (no `FakeCodexProcessRunner` test doubles).
122
+
- Treat `codex` CLI as a test prerequisite: ensure local/CI test setup installs `codex` before running CLI interaction tests; do not replace this with fakes.
123
+
- Real Codex integration tests must work with existing Codex CLI login/session by default; `OPENAI_API_KEY` is optional and must not be a hard requirement.
124
+
- Do not bypass integration tests on Windows with unconditional early returns; keep tests cross-platform for supported Codex CLI environments.
115
125
- Parser changes require tests in `ThreadEventParserTests` for supported and invalid payloads.
126
+
- Parser performance tests must use representative mixed payloads across supported event/item types and assert parsed output shape; avoid single-payload stopwatch loops that do not validate branch coverage.
@@ -126,12 +137,29 @@ If no new rule is detected -> do not update the file.
126
137
127
138
- Follow `.editorconfig` and analyzer rules.
128
139
- Always build with `-warnaserror` so warnings fail the build.
140
+
- Prefer idiomatic, readable C# with clear naming and straightforward control flow so code can be understood quickly during review and maintenance.
141
+
- Use synchronization primitives only when there is a proven shared-state invariant; prefer simpler designs over ad-hoc locking for maintainable production code.
129
142
- No magic literals: extract constants/enums/config values.
130
143
- Protocol and CLI string tokens are mandatory constants: never inline literals in parsing, mapping, or switch branches.
131
144
- In SDK model records, never inline protocol type literals in constructors (`ThreadItem(..., "...")`, `ThreadEvent("...")`); always reference protocol constants.
132
145
- Do not expose a public SDK type named `Thread`; use `CodexThread` to avoid .NET type-name conflicts.
133
-
- Keep public API and naming aligned with package/namespace `ManagedCode.CodexSharp`.
146
+
- Keep public API and naming aligned with package/namespace `ManagedCode.CodexSharpSDK`.
147
+
- Solution/workspace file naming must use `ManagedCode.CodexSharpSDK` prefix for consistency with package identity.
148
+
- Keep package/version metadata centralized in `Directory.Build.props`; avoid duplicating version structure or release metadata blocks in individual `.csproj` files unless a project-specific override is required.
149
+
- Never hardcode guessed Codex/OpenAI model names in tests, docs, or defaults; verify supported models and active default via Codex CLI first.
150
+
- Before setting or changing any `Model` value, read available models and current default from the local `codex` CLI in the same environment/account and only then update code/tests/docs.
151
+
- Model identifiers in code/tests must come from centralized constants or a shared resolver helper; do not inline model string literals repeatedly.
152
+
- Image input API must support passing local image data as file path, `FileInfo`, and `Stream`.
153
+
- Use `Microsoft.Extensions.Logging.ILogger` for SDK logging extension points; do not introduce custom logger interfaces or custom log-level enums.
154
+
- In tests, prefer `Microsoft.Extensions.Logging.Abstractions.NullLogger` instead of custom fake logger implementations when log capture is not required.
- Avoid ambiguous option names like `*Override` for primary settings; prefer explicit names (for example executable path / working directory) and keep compatibility aliases only when necessary.
157
+
- README first examples must be beginner-friendly: avoid advanced/optional knobs (for example `CodexPathOverride`) in the very first snippet.
158
+
- When a README snippet shows model tuning, include `ModelReasoningEffort` together with `Model`.
159
+
- Public examples should build output schemas with typed `StructuredOutputSchema` models and map responses to typed DTOs for readability and maintainability.
160
+
- Do not keep or add `JsonSchema` helper abstractions in SDK API/tests; use typed request/response DTO models instead of schema-builder utilities.
161
+
- Do not handcraft JSON with `JsonValue`/`JsonNode` literals for structured outputs in API/tests/examples; define typed DTO models and map schema/fields from those models.
162
+
- Keep consumer usage examples in `README.md`; do not introduce standalone sample projects.
135
163
136
164
### Critical (NEVER violate)
137
165
@@ -165,9 +193,17 @@ If no new rule is detected -> do not update the file.
0 commit comments