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
## AI Assistant Guidelines: Zero-Tolerance for Hallucination
18
+
19
+
When working with external libraries, frameworks, or any APIs (including .NET BCL, ASP.NET Core, Entity Framework Core, serialization frameworks, etc.), you MUST adhere to the following strict guidelines:
20
+
21
+
### 1. Never Guess or Assume API Behavior
22
+
23
+
- **DO NOT** make assumptions about API signatures, method names, parameter types, return types, or behavior
24
+
- **DO NOT** rely on memory or general knowledge about libraries
25
+
- **DO NOT** proceed with implementation if you are not 100% certain about API details
26
+
27
+
### 2. Verify Using Context7 MCP
28
+
29
+
When you need information about any external library or framework:
30
+
31
+
1. **Use `mcp__context7__resolve-library-id`** to find the correct library ID
32
+
2. **Use `mcp__context7__get-library-docs`** to retrieve up-to-date, accurate documentation
33
+
3. **Base all implementation decisions on verified documentation**, not assumptions
34
+
35
+
Examples of when to use Context7:
36
+
37
+
- Working with .NET BCL types (System.Text.Json, System.Linq, System.Collections, etc.)
- Any API where you are not 100% certain of the exact behavior
42
+
43
+
### 3. Verification Over Speed
44
+
45
+
- **It is better to take extra time to verify than to introduce bugs based on incorrect assumptions**
46
+
- If documentation is unclear or incomplete, ask the user for clarification
47
+
- If Context7 doesn't have the information, explicitly tell the user you need to verify before proceeding
48
+
49
+
### 4. Explicit Uncertainty Communication
50
+
51
+
When you encounter uncertainty:
52
+
53
+
- **State clearly**: "I need to verify the API behavior using Context7"
54
+
- **Never proceed silently** with guessed implementations
55
+
- **Document verification steps** so the user understands your process
56
+
57
+
### 5. This Project's Code is Authoritative
58
+
59
+
- For Thinktecture.Runtime.Extensions library code itself (not external dependencies), use the codebase as the source of truth
60
+
- Read actual source code using Serena tools to understand internal behavior
61
+
- Only for external dependencies must you use Context7 for verification
62
+
63
+
### Summary
64
+
65
+
**Zero hallucination policy**: If you don't know it with 100% certainty, verify it. Use Context7 MCP for external APIs, use Serena tools for internal codebase exploration, and ask the user when neither provides sufficient clarity.
66
+
17
67
## Architecture Overview
18
68
19
69
This is a .NET library providing **Smart Enums**, **Value Objects**, and **Discriminated Unions** through Roslyn Source Generators. The core architecture consists of:
@@ -78,7 +128,7 @@ The `Thinktecture.Runtime.Extensions.SourceGenerator` project contains multiple
78
128
#### Analyzers
79
129
80
130
1. **`ThinktectureRuntimeExtensionsAnalyzer`**: Main diagnostic analyzer with 40+ diagnostic rules that validates correct usage of library features
81
-
- **Type structure**: Ensures types with `[SmartEnum]`, `[ValueObject]`, `[Union]`, or `[AdHocUnion]` are `partial`, are class/struct, not generic (except regular unions and complex value objects), not nested in generic types
131
+
- **Type structure**: Ensures types with `[SmartEnum]`, `[ValueObject]`, `[Union]`, or `[AdHocUnion]` are `partial`, are class/struct, not generic (except smart enums, keyed value objects, regular unions and complex value objects), not nested in generic types
82
132
- **Constructor rules**: Validates constructors are private, no primary constructors allowed
83
133
- **Member validation**:
84
134
- Fields must be readonly, properties must be readonly (no set) or have private init
@@ -119,6 +169,7 @@ The `Thinktecture.Runtime.Extensions.SourceGenerator` project contains multiple
119
169
**Keyed**: `[SmartEnum<TKey>]` - Type-safe enums with underlying key values
120
170
121
171
- Key can be any non-nullable type (int, string, Guid, etc.)
172
+
- **Can be generic**: Smart enums themselves may now be generic types (for example `SmartEnum_Generic_IntBased<T> where T : IEquatable<T>`). Analyzer rules still apply for containing types (no nesting inside generic types) but the enum type can declare its own generic parameters and constraints.
122
173
- Configurable key member via `KeyMemberName`, `KeyMemberAccessModifier`, `KeyMemberKind`
123
174
- Supports comparison operators if key is comparable
124
175
- Supports `IParsable<T>`, `IComparable<T>`, `IFormattable` (depending on key type)
@@ -142,7 +193,7 @@ The `Thinktecture.Runtime.Extensions.SourceGenerator` project contains multiple
- Can skip key member generation: `SkipKeyMember` (you implement it manually)
145
-
- **Cannot be generic**: Keyed value objects must not have type parameters
196
+
- **Can be generic**: Keyed value objects can have type parameters (e.g., `ValueObject_Generic<T> where T : IEquatable<T>`). Analyzer rules still apply for containing types (no nesting inside generic types) but the value object type can declare its own generic parameters and constraints.
@@ -287,7 +338,7 @@ The source generators follow a consistent pattern:
287
338
5. **Type Information**: Rich type metadata captured in interfaces like `ITypeInformation`, `ITypedMemberState`, `IMemberState`, `IKeyMemberSettings`
288
339
6. **Nullability Awareness**: Full support for nullable reference types and value types
289
340
7. **Containing Types**: Handles nested types properly with `ContainingTypeState`
290
-
8. **Generics Support**: Limited support - regular unions and complex value objects can be generic, but smart enums, keyed value objects, and ad-hoc unions cannot
341
+
8. **Generics Support**: Smart enums, keyed value objects, regular unions, and complex value objects can be generic. Ad-hoc unions cannot be generic.
291
342
292
343
## Project Structure
293
344
@@ -316,7 +367,11 @@ The source generators follow a consistent pattern:
316
367
- Comprehensive tests for generated code, serialization, and framework integration
317
368
- Follow Arrange-Act-Assert pattern for unit tests
318
369
- The tests should have same folder structure as the source code (e.g., with class `Ns1/Ns2/MyClass.cs` -> `Ns1/Ns2/MyCassTests/MyMethod.cs`)
319
-
- Create a separate test class/file for every public member (eg. for class `MyClass` with method `MyMethod` create `MyCassTests/MyMethod.cs`)
370
+
- **Test Organization**:
371
+
- **First, check for existing test classes** that test similar functionality (same class/method or related features)
372
+
- **Add new tests to existing test classes** when the test covers the same or closely related functionality
373
+
- **Only create new test classes/files** when there is no fitting existing test class for the functionality being tested
374
+
- Ideal structure: Separate test class/file for every public member (e.g., for class `MyClass` with method `MyMethod` create `MyCassTests/MyMethod.cs`), but consolidate related test cases in the same file
320
375
- If the tests requires a `CSharpCompilation` use base class `test/Thinktecture.Runtime.Extensions.SourceGenerator.Tests/CompilationTestBase.cs`
321
376
- When testing attributes, use real attributes, like `SmartEnumAttribute`, `ValueObjectAttribute`, `ComplexValueObjectAttribute`, `UnionAttribute`, `ObjectFactoryAttribute`, etc. Don't use fake attributes.
## AI Assistant Guidelines: Zero-Tolerance for Hallucination
18
+
19
+
When working with external libraries, frameworks, or any APIs (including .NET BCL, ASP.NET Core, Entity Framework Core, serialization frameworks, etc.), you MUST adhere to the following strict guidelines:
20
+
21
+
### 1. Never Guess or Assume API Behavior
22
+
23
+
-**DO NOT** make assumptions about API signatures, method names, parameter types, return types, or behavior
24
+
-**DO NOT** rely on memory or general knowledge about libraries
25
+
-**DO NOT** proceed with implementation if you are not 100% certain about API details
26
+
27
+
### 2. Verify Using Context7 MCP
28
+
29
+
When you need information about any external library or framework:
30
+
31
+
1.**Use `mcp__context7__resolve-library-id`** to find the correct library ID
32
+
2.**Use `mcp__context7__get-library-docs`** to retrieve up-to-date, accurate documentation
33
+
3.**Base all implementation decisions on verified documentation**, not assumptions
34
+
35
+
Examples of when to use Context7:
36
+
37
+
- Working with .NET BCL types (System.Text.Json, System.Linq, System.Collections, etc.)
- Any API where you are not 100% certain of the exact behavior
42
+
43
+
### 3. Verification Over Speed
44
+
45
+
-**It is better to take extra time to verify than to introduce bugs based on incorrect assumptions**
46
+
- If documentation is unclear or incomplete, ask the user for clarification
47
+
- If Context7 doesn't have the information, explicitly tell the user you need to verify before proceeding
48
+
49
+
### 4. Explicit Uncertainty Communication
50
+
51
+
When you encounter uncertainty:
52
+
53
+
-**State clearly**: "I need to verify the API behavior using Context7"
54
+
-**Never proceed silently** with guessed implementations
55
+
-**Document verification steps** so the user understands your process
56
+
57
+
### 5. This Project's Code is Authoritative
58
+
59
+
- For Thinktecture.Runtime.Extensions library code itself (not external dependencies), use the codebase as the source of truth
60
+
- Read actual source code using Serena tools to understand internal behavior
61
+
- Only for external dependencies must you use Context7 for verification
62
+
63
+
### Summary
64
+
65
+
**Zero hallucination policy**: If you don't know it with 100% certainty, verify it. Use Context7 MCP for external APIs, use Serena tools for internal codebase exploration, and ask the user when neither provides sufficient clarity.
66
+
17
67
## Architecture Overview
18
68
19
69
This is a .NET library providing **Smart Enums**, **Value Objects**, and **Discriminated Unions** through Roslyn Source Generators. The core architecture consists of:
@@ -78,7 +128,7 @@ The `Thinktecture.Runtime.Extensions.SourceGenerator` project contains multiple
78
128
#### Analyzers
79
129
80
130
1.**`ThinktectureRuntimeExtensionsAnalyzer`**: Main diagnostic analyzer with 40+ diagnostic rules that validates correct usage of library features
81
-
-**Type structure**: Ensures types with `[SmartEnum]`, `[ValueObject]`, `[Union]`, or `[AdHocUnion]` are `partial`, are class/struct, not generic (except regular unions and complex value objects), not nested in generic types
131
+
-**Type structure**: Ensures types with `[SmartEnum]`, `[ValueObject]`, `[Union]`, or `[AdHocUnion]` are `partial`, are class/struct, not generic (except smart enums, keyed value objects, regular unions and complex value objects), not nested in generic types
82
132
-**Constructor rules**: Validates constructors are private, no primary constructors allowed
83
133
-**Member validation**:
84
134
- Fields must be readonly, properties must be readonly (no set) or have private init
@@ -119,6 +169,7 @@ The `Thinktecture.Runtime.Extensions.SourceGenerator` project contains multiple
119
169
**Keyed**: `[SmartEnum<TKey>]` - Type-safe enums with underlying key values
120
170
121
171
- Key can be any non-nullable type (int, string, Guid, etc.)
172
+
-**Can be generic**: Smart enums themselves may now be generic types (for example `SmartEnum_Generic_IntBased<T> where T : IEquatable<T>`). Analyzer rules still apply for containing types (no nesting inside generic types) but the enum type can declare its own generic parameters and constraints.
122
173
- Configurable key member via `KeyMemberName`, `KeyMemberAccessModifier`, `KeyMemberKind`
123
174
- Supports comparison operators if key is comparable
124
175
- Supports `IParsable<T>`, `IComparable<T>`, `IFormattable` (depending on key type)
@@ -142,7 +193,7 @@ The `Thinktecture.Runtime.Extensions.SourceGenerator` project contains multiple
- Can skip key member generation: `SkipKeyMember` (you implement it manually)
145
-
-**Cannot be generic**: Keyed value objects must not have type parameters
196
+
-**Can be generic**: Keyed value objects can have type parameters (e.g., `ValueObject_Generic<T> where T : IEquatable<T>`). Analyzer rules still apply for containing types (no nesting inside generic types) but the value object type can declare its own generic parameters and constraints.
@@ -287,7 +338,7 @@ The source generators follow a consistent pattern:
287
338
5.**Type Information**: Rich type metadata captured in interfaces like `ITypeInformation`, `ITypedMemberState`, `IMemberState`, `IKeyMemberSettings`
288
339
6.**Nullability Awareness**: Full support for nullable reference types and value types
289
340
7.**Containing Types**: Handles nested types properly with `ContainingTypeState`
290
-
8.**Generics Support**: Limited support - regular unions and complex value objects can be generic, but smart enums, keyed value objects, and ad-hoc unions cannot
341
+
8.**Generics Support**: Smart enums, keyed value objects, regular unions, and complex value objects can be generic. Ad-hoc unions cannot be generic.
291
342
292
343
## Project Structure
293
344
@@ -316,7 +367,11 @@ The source generators follow a consistent pattern:
316
367
- Comprehensive tests for generated code, serialization, and framework integration
317
368
- Follow Arrange-Act-Assert pattern for unit tests
318
369
- The tests should have same folder structure as the source code (e.g., with class `Ns1/Ns2/MyClass.cs` -> `Ns1/Ns2/MyCassTests/MyMethod.cs`)
319
-
- Create a separate test class/file for every public member (eg. for class `MyClass` with method `MyMethod` create `MyCassTests/MyMethod.cs`)
370
+
-**Test Organization**:
371
+
-**First, check for existing test classes** that test similar functionality (same class/method or related features)
372
+
-**Add new tests to existing test classes** when the test covers the same or closely related functionality
373
+
-**Only create new test classes/files** when there is no fitting existing test class for the functionality being tested
374
+
- Ideal structure: Separate test class/file for every public member (e.g., for class `MyClass` with method `MyMethod` create `MyCassTests/MyMethod.cs`), but consolidate related test cases in the same file
320
375
- If the tests requires a `CSharpCompilation` use base class `test/Thinktecture.Runtime.Extensions.SourceGenerator.Tests/CompilationTestBase.cs`
321
376
- When testing attributes, use real attributes, like `SmartEnumAttribute`, `ValueObjectAttribute`, `ComplexValueObjectAttribute`, `UnionAttribute`, `ObjectFactoryAttribute`, etc. Don't use fake attributes.
0 commit comments