Sync docs folder renames, release.yaml, .versionmark.yaml, package.json, dotnet-tools.json, and .reviewmark.yaml from TemplateDotNetTool

.cspell.json

@@ -28,6 +28,14 @@
     "Pylint",
     "Qube",
     "ReqStream",
+    "reviewmark",
+    "ReviewMark",
+    "code_quality",
+    "code_review_plan",
+    "code_review_report",
+    "requirements_doc",
+    "requirements_report",
+    "trace_matrix",
     "Sarif",
     "SarifMark",
     "SBOM",
@@ -91,6 +99,7 @@
     "trx",
     "vbproj",
     "vcxproj",
+    "versionmark",
     "weasyprint",
     "workflow",
     "workflows",
@@ -99,6 +108,7 @@
   "ignorePaths": [
     "node_modules",
     ".git",
+    ".agent-logs",
     "bin",
     "obj",
     "*.nupkg",

.gitattributes

@@ -0,0 +1,7 @@
+# Set default behavior: normalize line endings to LF on checkout for all text files.
+# This ensures consistent SHA256 fingerprints for reviewmark across all platforms.
+* text=auto eol=lf
+
+# Windows batch files require CRLF line endings to function correctly.
+*.bat text eol=crlf
+*.cmd text eol=crlf

.github/pull_request_template.md

@@ -40,9 +40,7 @@ Before submitting this pull request, ensure you have completed the following:
 
 Please run the following checks before submitting:
 
-- [ ] **Spell checker passes**: `cspell "**/*.{md,cs}"`
-- [ ] **Markdown linter passes**: `markdownlint "**/*.md"`
-- [ ] **YAML linter passes**: `yamllint .`
+- [ ] **All linters pass**: `./lint.sh` (Unix/macOS) or `cmd /c lint.bat` / `./lint.bat` (Windows)
 
 ### Testing
 
@@ -57,6 +55,7 @@ Please run the following checks before submitting:
 - [ ] Added code examples for new features (if applicable)
 - [ ] Updated requirements.yaml (if applicable)
 - [ ] Updated XML documentation comments for changed APIs
+- [ ] Updated ARCHITECTURE.md (if applicable)
 
 ## Additional Notes
 

.github/standards/csharp-language.md

@@ -0,0 +1,86 @@
+# C# Language Coding Standards
+
+This document defines DEMA Consulting standards for C# software development
+within Continuous Compliance environments.
+
+## Literate Programming Style (MANDATORY)
+
+Write all C# code in literate style because regulatory environments require
+code that can be independently verified against requirements by reviewers.
+
+- **Intent Comments**: Start every code paragraph with a comment explaining
+  intent (not mechanics). Enables verification that code matches requirements.
+- **Logical Separation**: Use blank lines to separate logical code paragraphs.
+  Makes algorithm structure visible to reviewers.
+- **Purpose Over Process**: Comments describe why, code shows how. Separates
+  business logic from implementation details.
+- **Standalone Clarity**: Reading comments alone should explain the algorithm
+  approach. Supports independent code review.
+
+### Example
+
+```csharp
+// Validate input parameters to prevent downstream errors
+if (string.IsNullOrEmpty(input))
+{
+    throw new ArgumentException("Input cannot be null or empty", nameof(input));
+}
+
+// Transform input data using the configured processing pipeline
+var processedData = ProcessingPipeline.Transform(input);
+
+// Apply business rules and validation logic
+var validatedResults = BusinessRuleEngine.ValidateAndProcess(processedData);
+
+// Return formatted results matching the expected output contract
+return OutputFormatter.Format(validatedResults);
+```
+
+## XML Documentation (MANDATORY)
+
+Document ALL members (public, internal, private) with XML comments because
+compliance documentation is auto-generated from source code comments and review
+agents need to validate implementation against documented intent.
+
+## Dependency Management
+
+Structure code for testability because all functionality must be validated
+through automated tests linked to requirements.
+
+### Rules
+
+- **Inject Dependencies**: Use constructor injection for all external dependencies.
+  Enables mocking for unit tests.
+- **Avoid Static Dependencies**: Use dependency injection instead of static
+  calls. Makes code testable in isolation.
+- **Single Responsibility**: Each class should have one reason to change.
+  Simplifies testing and requirements traceability.
+- **Pure Functions**: Minimize side effects and hidden state. Makes behavior
+  predictable and testable.
+
+## Error Handling
+
+Implement comprehensive error handling because failures must be logged for
+audit trails and compliance reporting.
+
+- **Validate Inputs**: Check all parameters and throw appropriate exceptions
+  with clear messages
+- **Use Typed Exceptions**: Throw specific exception types
+  (`ArgumentException`, `InvalidOperationException`) for different error
+  conditions
+- **Include Context**: Exception messages should include enough information
+  for troubleshooting
+- **Log Appropriately**: Use structured logging for audit trails in regulated
+  environments
+
+## Quality Checks
+
+Before submitting C# code, verify:
+
+- [ ] Code follows Literate Programming Style rules (intent comments, logical separation)
+- [ ] XML documentation on ALL members with required tags
+- [ ] Dependencies injected via constructor (no static dependencies)
+- [ ] Single responsibility principle followed (one reason to change)
+- [ ] Input validation with typed exceptions and clear messages
+- [ ] Zero compiler warnings with `TreatWarningsAsErrors=true`
+- [ ] Compatible with ReqStream requirements traceability

.github/standards/csharp-testing.md

@@ -0,0 +1,119 @@
+# C# Testing Standards (MSTest)
+
+This document defines DEMA Consulting standards for C# test development using
+MSTest within Continuous Compliance environments.
+
+# AAA Pattern Implementation (MANDATORY)
+
+Structure all tests using Arrange-Act-Assert pattern because regulatory reviews
+require clear test logic that can be independently verified against
+requirements.
+
+```csharp
+[TestMethod]
+public void ServiceName_MethodName_Scenario_ExpectedBehavior()
+{
+    // Arrange - (description)
+    // TODO: Set up test data, mocks, and system under test.
+
+    // Act - (description)
+    // TODO: Execute the action being tested
+
+    // Assert - (description)
+    // TODO: Verify expected outcomes and interactions
+}
+```
+
+# Test Naming Standards
+
+Use descriptive test names because test names appear in requirements traceability matrices and compliance reports.
+
+- **Pattern**: `ClassName_MethodUnderTest_Scenario_ExpectedBehavior`
+- **Descriptive Scenarios**: Clearly describe the input condition being tested
+- **Expected Behavior**: State the expected outcome or exception
+
+## Examples
+
+- `UserValidator_ValidateEmail_ValidFormat_ReturnsTrue`
+- `UserValidator_ValidateEmail_InvalidFormat_ThrowsArgumentException`
+- `PaymentProcessor_ProcessPayment_InsufficientFunds_ReturnsFailureResult`
+
+# Requirements Coverage
+
+Link tests to requirements because every requirement must have passing test evidence for compliance validation.
+
+- **ReqStream Integration**: Tests must be linkable in requirements YAML files
+- **Platform Filters**: Use source filters for platform-specific requirements (`windows@TestName`)
+- **TRX Format**: Generate test results in TRX format for ReqStream compatibility
+- **Coverage Completeness**: Test both success paths and error conditions
+
+# Mock Dependencies
+
+Mock external dependencies using NSubstitute (preferred) because tests must run in isolation to generate
+reliable evidence.
+
+- **Isolate System Under Test**: Mock all external dependencies (databases, web services, file systems)
+- **Verify Interactions**: Assert that expected method calls occurred with correct parameters
+- **Predictable Behavior**: Set up mocks to return known values for consistent test results
+
+# MSTest V4 Antipatterns
+
+Avoid these common MSTest V4 patterns because they produce poor error messages or cause tests to be silently ignored.
+
+# Avoid Assertions in Catch Blocks (MSTEST0058)
+
+Instead of wrapping code in try/catch and asserting in the catch block, use `Assert.ThrowsExactly<T>()`:
+
+```csharp
+var ex = Assert.ThrowsExactly<ArgumentNullException>(() => SomeWork());
+Assert.Contains("Some message", ex.Message);
+```
+
+# Avoid Assert.IsTrue/IsFalse for Equality Checks
+
+Use `Assert.AreEqual`/`Assert.AreNotEqual` instead, as they provide better failure messages:
+
+```csharp
+// ❌ Bad: Assert.IsTrue(result == expected);
+// ✅ Good: Assert.AreEqual(expected, result);
+```
+
+# Avoid Non-Public Test Classes and Methods
+
+Test classes and `[TestMethod]` methods must be `public` or they will be silently ignored:
+
+```csharp
+// ❌ Bad: internal class MyTests
+// ✅ Good: public class MyTests
+```
+
+# Avoid Assert.IsTrue for Collection Count
+
+Use `Assert.HasCount` for count assertions:
+
+```csharp
+// ❌ Bad: Assert.IsTrue(collection.Count == 3);
+// ✅ Good: Assert.HasCount(3, collection);
+```
+
+# Avoid Assert.IsTrue for String Prefix Checks
+
+Use `Assert.StartsWith` instead, as it produces clearer failure messages:
+
+```csharp
+// ❌ Bad: Assert.IsTrue(value.StartsWith("prefix"));
+// ✅ Good: Assert.StartsWith("prefix", value);
+```
+
+# Quality Checks
+
+Before submitting C# tests, verify:
+
+- [ ] All tests follow AAA pattern with clear section comments
+- [ ] Test names follow `ClassName_MethodUnderTest_Scenario_ExpectedBehavior`
+- [ ] Each test verifies single, specific behavior (no shared state)
+- [ ] Both success and failure scenarios covered including edge cases
+- [ ] External dependencies mocked with NSubstitute or equivalent
+- [ ] Tests linked to requirements with source filters where needed
+- [ ] Test results generate TRX format for ReqStream compatibility
+- [ ] MSTest V4 antipatterns avoided (proper assertions, public visibility, etc.)