Sync agent/standards files and lint scripts from TemplateDotNetTool; rename code-review agent to formal-review

.github/agents/quality.agent.md

@@ -26,13 +26,6 @@ This assessment is a quality control system of the project and MUST be performed
 Upon completion create a summary in `.agent-logs/{agent-name}-{subject}-{unique-id}.md`
 of the project consisting of:
 
-The **Result** field MUST reflect the quality validation outcome for orchestrator decision-making:
-
-- **Result: SUCCEEDED** - Only when Overall Grade is PASS (all compliance requirements met)
-- **Result: FAILED** - When Overall Grade is FAIL or NEEDS_WORK (compliance failures present)
-
-This ensures orchestrators properly halt workflows when quality gates fail.
-
 ```markdown
 # Quality Assessment Report
 
@@ -81,6 +74,8 @@ This ensures orchestrators properly halt workflows when quality gates fail.
 - Were tests created/updated for all functional changes? (PASS|FAIL|N/A) - {Evidence}
 - Is test coverage maintained for all requirements? (PASS|FAIL|N/A) - {Evidence}
 - Are testing standards followed (AAA pattern, etc.)? (PASS|FAIL|N/A) - {Evidence}
+- Do tests respect software item hierarchy boundaries (System/Subsystem/Unit scope)? (PASS|FAIL|N/A) - {Evidence}
+- Are cross-hierarchy test dependencies documented in design docs? (PASS|FAIL|N/A) - {Evidence}
 - Does test categorization align with code structure? (PASS|FAIL|N/A) - {Evidence}
 - Do all tests pass without failures? (PASS|FAIL|N/A) - {Evidence}
 
@@ -132,4 +127,11 @@ This ensures orchestrators properly halt workflows when quality gates fail.
 - **Quality Gates**: {Status of automated quality checks with tool outputs}
 ```
 
+The **Result** field MUST reflect the quality validation outcome for orchestrator decision-making:
+
+- **Result: SUCCEEDED** - Only when Overall Grade is PASS (all compliance requirements met)
+- **Result: FAILED** - When Overall Grade is FAIL or NEEDS_WORK (compliance failures present)
+
+This ensures orchestrators properly halt workflows when quality gates fail.
+
 Return this summary to the caller.

.github/standards/coding-principles.md

@@ -0,0 +1,70 @@
+---
+name: Coding Principles
+description: Follow these standards when developing any software code.
+---
+
+# Coding Principles Standards
+
+This document defines universal coding principles and quality standards for software development within
+Continuous Compliance environments.
+
+# Core Principles
+
+## Literate Coding
+
+All code MUST follow literate programming principles:
+
+- **Intent Comments**: Every function/method begins with a comment explaining WHY (not what)
+- **Logical Separation**: Complex functions use comments to separate logical blocks
+- **Public Documentation**: All public interfaces have comprehensive documentation
+- **Clarity Over Cleverness**: Code should be immediately understandable by team members
+
+## Universal Code Architecture Principles
+
+### Design Patterns
+
+- **Single Responsibility**: Functions with focused, testable purposes
+- **Dependency Injection**: External dependencies injected for testing
+- **Pure Functions**: Minimize side effects and hidden state
+- **Clear Interfaces**: Well-defined API contracts
+- **Separation of Concerns**: Business logic separate from infrastructure
+- **Repository Structure Adherence**: Before creating any new files, analyze the repository structure to
+  understand established directory conventions and file placement patterns. Place new files in locations
+  consistent with existing patterns.
+
+### Compliance-Ready Code Structure
+
+- **Documentation Standards**: Language-appropriate documentation required on ALL members
+- **Error Handling**: Comprehensive error cases with appropriate exception handling and logging
+- **Configuration**: Externalize settings for different compliance environments
+- **Resource Management**: Proper resource cleanup using language-appropriate patterns
+
+# Quality Gates
+
+## Code Quality Standards
+
+- [ ] Zero compiler warnings (use language-specific warning-as-error flags)
+- [ ] All code follows literate programming style
+- [ ] Language-appropriate documentation complete on all members
+- [ ] Passes static analysis (language-specific tools)
+
+## Universal Anti-Patterns
+
+- **Skip Literate Coding**: Don't skip literate programming comments - they are required for maintainability
+- **Ignore Compiler Warnings**: Don't ignore compiler warnings - they exist for quality enforcement
+- **Hidden Dependencies**: Don't create untestable code with hidden dependencies
+- **Hidden Functionality**: Don't implement functionality without requirement traceability
+- **Monolithic Functions**: Don't write monolithic functions with multiple responsibilities
+- **Overcomplicated Solutions**: Don't make solutions more complex than necessary - favor simplicity and clarity
+- **Premature Optimization**: Don't optimize for performance before establishing correctness
+- **Copy-Paste Programming**: Don't duplicate logic - extract common functionality into reusable components
+- **Magic Numbers**: Don't use unexplained constants - either name them or add clear comments
+
+# Language-Specific Implementation
+
+For each detected language:
+
+- **Load Standards**: Read the appropriate `{language}-language.md` file from `.github/standards/`
+- **Apply Tooling**: Use language-specific formatting, linting, and build tools
+- **Follow Conventions**: Apply language-specific naming, patterns, and best practices
+- **Generate Documentation**: Use language-appropriate documentation format (XmlDoc, Doxygen, JSDoc, etc.)

.github/standards/csharp-language.md

@@ -1,23 +1,22 @@
-# C# Language Coding Standards
+---
+name: C# Language
+description: Follow these standards when developing C# source code.
+globs: ["**/*.cs"]
+---
 
-This document defines DEMA Consulting standards for C# software development
-within Continuous Compliance environments.
+# C# Language Development Standard
 
-## Literate Programming Style (MANDATORY)
+## Required Standards
 
-Write all C# code in literate style because regulatory environments require
-code that can be independently verified against requirements by reviewers.
+Read these standards first before applying this standard:
 
-- **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.
+- **`coding-principles.md`** - Universal coding principles and quality gates
 
-### Example
+# File Patterns
+
+- **Source Files**: `**/*.cs`
+
+# Literate Coding Example
 
 ```csharp
 // Validate input parameters to prevent downstream errors
@@ -36,51 +35,13 @@ var validatedResults = BusinessRuleEngine.ValidateAndProcess(processedData);
 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
+# Code Formatting
 
-## Quality Checks
+- **Format entire solution**: `dotnet format`
+- **Format specific project**: `dotnet format MyProject.csproj`
+- **Format specific file**: `dotnet format --include MyFile.cs`
 
-Before submitting C# code, verify:
+# Quality Checks
 
-- [ ] 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
+- [ ] Zero compiler warnings (`TreatWarningsAsErrors=true`)
+- [ ] XmlDoc documentation complete on all members (public, internal, protected, private)

.github/standards/csharp-testing.md

@@ -1,13 +1,22 @@
+---
+name: C# Testing
+description: Follow these standards when developing C# tests.
+globs: ["**/test/**/*.cs", "**/tests/**/*.cs", "**/*Tests.cs", "**/*Test.cs"]
+---
+
 # C# Testing Standards (MSTest)
 
 This document defines DEMA Consulting standards for C# test development using
 MSTest within Continuous Compliance environments.
 
-# AAA Pattern Implementation (MANDATORY)
+## Required Standards
+
+Read these standards first before applying this standard:
+
+- **`testing-principles.md`** - Universal testing principles and dependency boundaries
+- **`csharp-language.md`** - C# language development standards
 
-Structure all tests using Arrange-Act-Assert pattern because regulatory reviews
-require clear test logic that can be independently verified against
-requirements.
+# C# AAA Pattern Implementation
 
 ```csharp
 [TestMethod]
@@ -26,7 +35,7 @@ public void ServiceName_MethodName_Scenario_ExpectedBehavior()
 Use descriptive test names because test names appear in requirements traceability matrices and compliance reports.
 
 - **System tests**: `{SystemName}_{Functionality}_{Scenario}_{ExpectedBehavior}`
-- **Subsystem tests**: `{SubsystemName}_{Functionality}_{Scenario}_{ExpectedBehavior}`  
+- **Subsystem tests**: `{SubsystemName}_{Functionality}_{Scenario}_{ExpectedBehavior}`
 - **Unit tests**: `{ClassName}_{MethodUnderTest}_{Scenario}_{ExpectedBehavior}`
 - **Descriptive Scenarios**: Clearly describe the input condition being tested
 - **Expected Behavior**: State the expected outcome or exception
@@ -37,15 +46,6 @@ Use descriptive test names because test names appear in requirements traceabilit
 - `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

.github/standards/design-documentation.md

@@ -1,10 +1,23 @@
+---
+name: Design Documentation
+description: Follow these standards when creating design documentation.
+globs: ["docs/design/**/*.md"]
+---
+
 # Design Documentation Standards
 
 This document defines DEMA Consulting standards for design documentation
 within Continuous Compliance environments, extending the general technical
 documentation standards with specific requirements for software design
 artifacts.
 
+## Required Standards
+
+Read these standards first before applying this standard:
+
+- **`technical-documentation.md`** - General technical documentation standards
+- **`software-items.md`** - Software categorization (System/Subsystem/Unit/OTS)
+
 # Core Principles
 
 Design documentation serves as the bridge between requirements and
@@ -46,7 +59,9 @@ or compliance drivers.
 ### Scope Section
 
 Define what software items are covered and what is explicitly excluded.
-Specify version boundaries and applicability constraints.
+Design documentation must NOT include test projects, test classes, or test
+infrastructure because design documentation documents the architecture of
+shipping product code, not ancillary content used to validate it.
 
 ### Software Structure Section (MANDATORY)
 

.github/standards/reqstream-usage.md

@@ -1,8 +1,20 @@
+---
+name: ReqStream Usage
+description: Follow these standards when managing requirements with ReqStream.
+globs: ["requirements.yaml", "docs/reqstream/**/*.yaml"]
+---
+
 # ReqStream Requirements Management Standards
 
 This document defines DEMA Consulting standards for requirements management
 using ReqStream within Continuous Compliance environments.
 
+## Required Standards
+
+Read these standards first before applying this standard:
+
+- **`software-items.md`** - Software categorization (System/Subsystem/Unit/OTS)
+
 # Core Principles
 
 ReqStream implements Continuous Compliance methodology for automated evidence
@@ -48,12 +60,12 @@ consistency with design documentation and enable automated tooling.
 
 # Requirement Hierarchies and Links
 
-When linking requirements between different software item levels, links MUST
-only flow downward in the hierarchy to maintain clear traceability:
+Requirements link downward only - higher-level requirements reference lower-level
+ones they decompose into:
 
 - **System requirements** → may link to subsystem or unit requirements
 - **Subsystem requirements** → may link to unit requirements within that subsystem
-- **Unit requirements** → should NOT link to higher-level requirements
+- **Unit requirements** → should NOT link upward to parent requirements
 
 This prevents circular dependencies and ensures clear hierarchical relationships
 for compliance auditing.
@@ -80,7 +92,7 @@ sections:
         justification: |
           Business rationale explaining why this requirement exists.
           Include regulatory or standard references where applicable.
-        children:  # Links to child requirements (optional)
+        children:  # Downward links to decomposed requirements (optional)
           - ChildSystem-Feature-Behavior
         tests:     # Links to test methods (required)
           - TestMethodName

.github/standards/reviewmark-usage.md

@@ -1,5 +1,16 @@
+---
+name: ReviewMark Usage
+description: Follow these standards when configuring file reviews with ReviewMark.
+---
+
 # ReviewMark Usage Standard
 
+## Required Standards
+
+Read these standards first before applying this standard:
+
+- **`software-items.md`** - Software categorization (System/Subsystem/Unit/OTS)
+
 ## Purpose
 
 ReviewMark manages file review status enforcement and formal review processes. It tracks which files need

.github/standards/software-items.md

@@ -1,3 +1,8 @@
+---
+name: Software Items
+description: Follow these standards when categorizing software components.
+---
+
 # Software Items Definition Standards
 
 This document defines DEMA Consulting standards for categorizing software
@@ -35,13 +40,16 @@ Choose the appropriate category based on scope and testability:
 ## Software Subsystem
 
 - Major architectural boundary (authentication, data layer, UI, communications)
+- Contains multiple software units working together
+- Typically maps to project folders or namespaces
 - Tested through subsystem integration tests
 
 ## Software Unit
 
 - Smallest independently testable component
-- Tested through unit tests with mocked dependencies
 - Typically a single class or cohesive set of functions
+- Methods within a class are NOT separate units
+- Tested through unit tests with mocked dependencies
 
 ## OTS Software Item