Add typed EventViewerX failure descriptor resolver with neutral engine naming

[PrzemyslawKlys]

Summary:

• add EventViewerFailureDescriptorResolver in EventViewerX
• map typed failure enums (EVTX/live/catalog) to stable machine-readable fields: ErrorCode, Category, Entity, Recoverable
• keep API naming engine-neutral (no host/tool-specific terminology)
• harden descriptor model/resolver:
  • immutable descriptor properties
  • explicit Exception enum mappings
  • optional entity override with normalization and default-entity caching

Why:

• keep failure semantics owned by EventViewerX
• provide stable structured failures for wrappers/consumers without message parsing
• avoid coupling EventViewerX public API to IntelligenceX naming
• improve correctness, extensibility, and resolver clarity

Validation:

• dotnet build Sources/EventViewerX/EventViewerX.csproj -c Release
• dotnet test Sources/EventViewerX.Tests/EventViewerX.Tests.csproj -c Release --filter FullyQualifiedName~TestEventViewerFailureDescriptorResolver

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[claude]

Claude finished @PrzemyslawKlys's task —— View job

---

PR Review

Todo List

• Read repository guidelines (CLAUDE.md)
• Analyze the main implementation file
• Analyze the test file
• Provide comprehensive review feedback

---

✅ Overall Assessment

This is a well-designed, defensive failure handling system with excellent attention to detail. The implementation demonstrates strong architectural principles and comprehensive testing.

🎯 Strengths

Code Quality & Design

• Immutable descriptors: Properties are read-only with validation in constructor - excellent defensive programming
• Clear separation of concerns: Descriptor model vs. resolver logic is well-separated
• Engine-neutral naming: Good abstraction that avoids coupling to host/tool-specific terminology
• Consistent fallback strategy: Unknown enum values consistently map to query_failed across all resolvers

Performance Optimizations

• Instance caching: Default entity descriptors reuse cached instances (EventViewerFailureDescriptorResolver:163-165) - smart memory optimization
• String interning pattern: Using pre-allocated static instances for common cases
• Efficient switch expressions: Modern C# pattern matching syntax

Security & Robustness

• Input normalization: All string inputs are trimmed and validated (EventViewerFailureDescriptor.cs:52-68)
• Null safety: Proper null handling with fallbacks throughout
• Explicit enum mapping: No magic numbers or assumptions - every enum case is explicitly handled

🧪 Test Coverage Excellence

The test suite is comprehensive and well-structured:

• All enum types covered: EVTX, Live, Catalog failures all tested
• Edge cases: Unknown enum values (line 999 tests), blank entities, Exception mappings
• Instance caching verification: Tests that default entities reuse instances (TestEventViewerFailureDescriptorResolver.cs:111-116)
• Normalization testing: Verifies blank/whitespace entity handling
• Recoverability logic: Tests both recoverable and non-recoverable scenarios

🔍 Minor Observations

Documentation

• Excellent XML documentation with usage examples (EventViewerFailureDescriptor.cs:99-104)
• Clear recoverability policy guidance (EventViewerFailureDescriptor.cs:75-82)
• Good consumer guidance for retry logic

API Design

• Optional entity parameters with sensible defaults
• Consistent method signatures across all resolver overloads
• Clear const values for fallbacks

🎯 Recommendations

1. Consider adding validation: While current normalization is good, consider if entity values should be validated against a known set
2. Performance monitoring: The caching strategy is excellent - consider metrics to verify cache hit rates in production
3. Logging consideration: For debugging, consider if resolver decisions should be logged (though this may be handled at the caller level)

🚀 Verdict

This implementation demonstrates excellent engineering practices:

• ✅ Code Quality: High-quality, defensive code with proper error handling
• ✅ Performance: Smart caching and efficient patterns
• ✅ Security: Robust input validation and null safety
• ✅ Test Coverage: Comprehensive test suite covering all scenarios
• ✅ Best Practices: Modern C# patterns, immutable design, clear documentation

Ready for merge - this is a solid, production-ready implementation that follows C# best practices and provides a stable API for failure handling.

---