OTS Verification

.github/agents/developer.agent.md

@@ -21,7 +21,7 @@ Perform software development tasks by determining and applying appropriate stand
 5. **Formatting**: Run `pwsh ./fix.ps1` to silently apply all
    available auto-fixers (dotnet format, markdown, YAML) before committing
 6. **Build and test** (code changes only): Run `pwsh ./build.ps1` and confirm it
-   passes — report FAILED if the build or any tests fail
+   passes - report FAILED if the build or any tests fail
 7. **Generate completion report** per the AGENTS.md reporting requirements - save to
    `.agent-logs/{agent-name}-{subject}-{unique-id}.md` and return the summary to the caller
 

.github/standards/coding-principles.md

@@ -20,9 +20,10 @@ All code MUST follow literate programming principles:
   matches design intent without reading the full codebase
 - **Logical Separation**: Complex functions use block comments to separate and
   describe logical steps within the implementation
-- **Full Symbol Documentation**: ALL symbols (public, protected, and private)
-  have comprehensive documentation because reviewers and auditors must verify
-  every implementation detail, not just the public interface
+- **Full Symbol Documentation**: ALL symbols have comprehensive documentation
+  because reviewers and auditors must verify every implementation detail, not
+  just the public interface - access-level specifics (public, protected,
+  private, internal, etc.) vary by language; see the language-specific standard
 - **Clarity Over Cleverness**: Code should be immediately understandable by team members
 
 ## API Documentation

.github/standards/csharp-language.md

@@ -49,7 +49,7 @@ public double ProcessReading(double reading, CalibrationProfile calibration)
 Key qualities demonstrated above:
 
 - **`<summary>`** is a brief one-liner explaining *what* the method does
-- **`<remarks>`** sits directly after summary and carries the extended intent —
+- **`<remarks>`** sits directly after summary and carries the extended intent -
   *why* it exists, design decisions, thread-safety, and side-effect disclosures
 - **`<param>` tags** state constraints (finite, non-null) so callers know what
   is valid without reading the body

.github/standards/csharp-testing.md

@@ -18,17 +18,20 @@ Every xUnit v3 test project requires the following package references for
 
 | Package | Purpose |
 | ------- | ------- |
-| `xunit.v3` | xUnit v3 framework (monolithic — includes assertions and fixtures) |
+| `xunit.v3` | xUnit v3 framework (monolithic - includes assertions and fixtures) |
 | `Microsoft.NET.Test.Sdk` | Required by the VSTest/`dotnet test` host for test discovery |
 | `xunit.runner.visualstudio` | VSTest adapter that bridges xUnit v3 to `dotnet test` |
-| `NSubstitute` | Mocking library |
 
 Omitting `Microsoft.NET.Test.Sdk` or `xunit.runner.visualstudio` causes tests
 to be silently undiscoverable by `dotnet test`.
 
+If tests require mocking of dependencies, add `NSubstitute` as a package
+reference - it is recommended when mocking is needed but is not required for
+every test project.
+
 # Test Style
 
-Test names appear in requirements traceability matrices — use the hierarchical
+Test names appear in requirements traceability matrices - use the hierarchical
 naming pattern, and follow AAA with labeled comments:
 
 - **System tests**: `{SystemName}_{Functionality}_{Scenario}_{ExpectedBehavior}`
@@ -55,11 +58,11 @@ public void UserValidator_ValidateEmail_InvalidFormat_ThrowsArgumentException()
 These are non-obvious v3 behaviors that differ from v2 or common assumptions:
 
 - **`IAsyncLifetime`**: Both `InitializeAsync` and `DisposeAsync` return `ValueTask`
-  in v3, not `Task` — using `Task` compiles but does not satisfy the v3 interface
+  in v3, not `Task` - using `Task` compiles but does not satisfy the v3 interface
 - **`Assert.Multiple`**: Use to collect all assertion failures in a single test
   rather than stopping at the first
 - **`[Collection]` without `[CollectionDefinition]`**: Silently disables parallelism
-  without providing any shared fixture — always pair them or remove `[Collection]`
+  without providing any shared fixture - always pair them or remove `[Collection]`
 
 # Quality Checks
 
@@ -69,6 +72,6 @@ Before submitting C# tests, verify:
 - [ ] Test names follow hierarchical naming pattern above
 - [ ] Each test verifies single, specific behavior (no shared state between tests)
 - [ ] Both success and failure scenarios covered including edge cases
-- [ ] External dependencies mocked with NSubstitute
+- [ ] External dependencies mocked with NSubstitute (when mocking is needed)
 - [ ] Tests linked to requirements with source filters where needed
 - [ ] Test results generated in TRX format for ReqStream compatibility (`dotnet test --logger trx`)

.github/standards/design-documentation.md

@@ -112,7 +112,7 @@ src/Project2Name/
 
 If the design references external documents (standards, specifications), include
 a `## References` section in `introduction.md`. This is the **only** place in the
-design document collection where a References section should appear — do not add
+design document collection where a References section should appear - do not add
 one to any other design file.
 
 ### Companion Artifact Structure (RECOMMENDED)
@@ -177,7 +177,7 @@ implementation specification for formal code review:
 - **Architectural Clarity**: Clearly define component boundaries and interfaces
 - **Traceability**: Link to requirements where applicable using ReqStream patterns
 - **Verbal Cross-References**: Reference other parts of the design by name (e.g.,
-  "See *Parser Design* for more details") — do not use markdown hyperlinks, which
+  "See *Parser Design* for more details") - do not use markdown hyperlinks, which
   break in compiled PDFs
 
 # Mermaid Diagram Integration

.github/standards/requirements-principles.md

@@ -29,7 +29,7 @@ implementation code.
 - **Valid**: "The parser shall report the line number of the first syntax error."
 - **Not a requirement (design decision)**: "The parser shall use a `TokenStream` class."
 
-A unit may use its own name freely — that is identity, not HOW. What is
+A unit may use its own name freely - that is identity, not HOW. What is
 forbidden is describing *internal construction*: class names, method signatures,
 algorithms, or data structures.
 

.github/standards/software-items.md

@@ -90,6 +90,6 @@ the item is correct, well-designed, and proven to work:
 
 - **Requirements** - WHAT the item must do (drives all other artifacts; applies to all item types)
 - **Design** - HOW the item satisfies its requirements (in-house items only: system, subsystem, unit)
-- **Verification Design** - HOW the requirements will be tested (in-house items only: system, subsystem, unit)
+- **Verification Design** - HOW the requirements will be tested (applies to all item types)
 - **Source code** - The implementation of the design (in-house units only)
 - **Tests** - PROOF the item does WHAT it is required to do (applies to all item types)

.github/standards/technical-documentation.md

@@ -29,18 +29,18 @@ Each document collection under `docs/` follows this layout:
 
 ```text
 docs/{collection}/
-  title.txt           # MANDATORY — YAML document metadata (title, author, etc.)
-  definition.yaml     # MANDATORY — Pandoc build definition (inputs, template, paths)
-  introduction.md     # MANDATORY — document introduction (Purpose, Scope, References)
+  title.txt           # MANDATORY - YAML document metadata (title, author, etc.)
+  definition.yaml     # MANDATORY - Pandoc build definition (inputs, template, paths)
+  introduction.md     # MANDATORY - document introduction (Purpose, Scope, References)
   {section}.md        # optional checked-in content sections (zero or more)
-  generated/          # BUILD OUTPUT — never read, edit, or lint these files
+  generated/          # BUILD OUTPUT - never read, edit, or lint these files
     {report}.md       # generated by CI tools (ReqStream, ReviewMark, SarifMark, etc.)
     {collection}.html # generated by Pandoc
 ```
 
 Without `title.txt` and `definition.yaml` the pipeline cannot generate the document.
 When creating a new document collection, create these three files together and use
-the existing collections under `docs/` as templates — they share a consistent
+the existing collections under `docs/` as templates - they share a consistent
 structure across all collections.
 
 **`title.txt`** - YAML front matter with document metadata. Use the existing
@@ -111,7 +111,7 @@ References in design/technical documents must point to **external specifications
 Do **not** use markdown hyperlinks to reference other sections or documents. Markdown anchor links
 (`[text](#heading)`) and relative file links work in a browser but break when compiled to a PDF.
 
-Instead use **verbal references** — plain prose that identifies the target by name:
+Instead use **verbal references** - plain prose that identifies the target by name:
 
 > See *XYZ Design* for more details.
 >
@@ -140,7 +140,7 @@ for consistency and professional presentation:
 
 # Auto-Generated Content (CRITICAL)
 
-**NEVER read, lint, or modify files inside any `generated/` folder** — they are
+**NEVER read, lint, or modify files inside any `generated/` folder** - they are
 build outputs that are overwritten on every CI run:
 
 - **Location**: All generated files live in `generated/` subfolders within their

.github/standards/verification-documentation.md

@@ -13,7 +13,7 @@ Read these standards first before applying this standard:
 
 # Core Principles
 
-Verification design is the bridge between requirements and tests — it documents HOW
+Verification design is the bridge between requirements and tests - it documents HOW
 requirements will be verified, enabling reviewers to confirm test completeness without
 reading implementation code.
 
@@ -24,38 +24,43 @@ Organize under `docs/verification/` mirroring the software item hierarchy:
 ```text
 docs/verification/
 ├── introduction.md              # Verification overview
-└── {system-name}/               # System-level verification folder (one per system)
-    ├── {system-name}.md         # System-level verification design
-    ├── {subsystem-name}/        # Subsystem (kebab-case); may nest recursively
-    │   ├── {subsystem-name}.md  # Subsystem verification design
-    │   ├── {child-subsystem}/   # Child subsystem (same structure as parent)
-    │   └── {unit-name}.md       # Unit-level verification design documents
-    └── {unit-name}.md           # Top-level unit verification documents (if not in subsystem)
+├── {system-name}/               # System-level verification folder (one per system)
+│   ├── {system-name}.md         # System-level verification design
+│   ├── {subsystem-name}/        # Subsystem (kebab-case); may nest recursively
+│   │   ├── {subsystem-name}.md  # Subsystem verification design
+│   │   ├── {child-subsystem}/   # Child subsystem (same structure as parent)
+│   │   └── {unit-name}.md       # Unit-level verification design documents
+│   └── {unit-name}.md           # Top-level unit verification documents (if not in subsystem)
+└── ots/                         # OTS items (one verification file per OTS item)
+    └── {ots-name}.md            # Verification evidence for each OTS item
 ```
 
 ## introduction.md (MANDATORY)
 
-Follow the standard `introduction.md` format from `technical-documentation.md`. The Scope
-section MUST state that verification documentation covers the same software items as the
-design documentation — it MUST NOT include test infrastructure or third-party OTS items.
+Follow the standard `introduction.md` format from `technical-documentation.md`. Scope
+covers all software items including OTS items (via self-validation if appropriate).
 
 Include a Companion Artifact Structure note so agents and reviewers can navigate from any
 artifact to all related files:
 
 ```text
-Each software item in the structure above has corresponding artifacts in
-parallel directory trees:
-
+In-house items have parallel artifacts in:
 - Requirements: `docs/reqstream/{system}/.../{item}.yaml` (kebab-case)
-- Design docs: `docs/design/{system}/.../{item}.md` (kebab-case)
-- Verification design: `docs/verification/{system}/.../{item}.md` (kebab-case)
-- Source code: `src/{System}/.../{Item}.{ext}` (cased per language - see `software-items.md`)
-- Tests: `test/{System}.Tests/.../{Item}Tests.{ext}` (cased per language - see `software-items.md`)
-- Review-sets: defined in `.reviewmark.yaml`
+- Design: `docs/design/{system}/.../{item}.md` (kebab-case)
+- Verification: `docs/verification/{system}/.../{item}.md` (kebab-case)
+- Source: `src/{System}/.../{Item}.{ext}` (cased per language)
+- Tests: `test/{System}.Tests/.../{Item}Tests.{ext}` (cased per language)
+
+OTS items have parallel artifacts in:
+- Requirements: `docs/reqstream/ots/{ots-name}.yaml` (kebab-case)
+- Verification: `docs/verification/ots/{ots-name}.md` (kebab-case)
+- Tests: `test/{OtsName}.Tests/...` (cased per language, if required)
+
+Review-sets: defined in `.reviewmark.yaml`
 ```
 
 If the verification design references external documents (standards, specifications), include
-a `## References` section in `introduction.md` only — do not add one to any other verification file.
+a `## References` section in `introduction.md` only - do not add one to any other verification file.
 
 ## System Verification Design (MANDATORY)
 
@@ -86,15 +91,23 @@ For each unit, create `{unit-name}.md` covering:
 - Which dependencies are mocked and how they are configured
 - Coverage mapping of every unit requirement to at least one named test scenario
 
+## OTS Verification Evidence (when OTS items are used)
+
+For each OTS item, create `docs/verification/ots/{ots-name}.md` covering:
+
+- The OTS item's required functionality (reference `docs/reqstream/ots/{ots-name}.yaml`)
+- Verification of each requirement (using self-validation evidence if appropriate)
+- Coverage mapping of OTS requirements to test scenarios
+
 # Writing Guidelines
 
 - **Test Coverage**: Map every requirement to at least one named test scenario so
   reviewers can verify completeness without reading test code
-- **Scenario Clarity**: Name each scenario clearly — "Valid input returns parsed result" not "Test 1"
+- **Scenario Clarity**: Name each scenario clearly - "Valid input returns parsed result" not "Test 1"
 - **Boundary Conditions**: Call out boundary values, error inputs, and edge cases explicitly
 - **Isolation Strategy**: Describe what is mocked or stubbed and why at each level
 - **Traceability**: Link to requirements where applicable using ReqStream patterns
-- **Verbal Cross-References**: Reference other documents by name — do not use markdown
+- **Verbal Cross-References**: Reference other documents by name - do not use markdown
   hyperlinks, which break in compiled PDFs
 
 Mermaid diagrams may supplement text descriptions where test flow benefits from visual
@@ -111,4 +124,5 @@ Before submitting verification documentation, verify:
 - [ ] Subsystem documentation folders use kebab-case names mirroring the source subsystem structure
 - [ ] All documents follow technical documentation formatting standards
 - [ ] Content is current with requirements and test implementation
+- [ ] Every OTS item has `docs/verification/ots/{ots-name}.md` with requirement coverage
 - [ ] Documents are integrated into ReviewMark review-sets for formal review

.reviewmark.yaml

@@ -57,6 +57,7 @@ reviews:
       - "docs/reqstream/template-dot-net-library/platform-requirements.yaml"
       - "docs/design/introduction.md"
       - "docs/design/template-dot-net-library/**/*.md"
+      - "docs/verification/introduction.md"
 
   - id: TemplateDotNetLibrary-AllRequirements
     title: Review of Template DotNet Library requirements quality and traceability
@@ -74,3 +75,64 @@ reviews:
       - "docs/verification/template-dot-net-library/demo.md"
       - "src/DemaConsulting.TemplateDotNetLibrary/Demo.cs"
       - "test/DemaConsulting.TemplateDotNetLibrary.Tests/DemoTests.cs"
+
+  # OTS Items
+  - id: OTS-BuildMark
+    title: Review of BuildMark OTS verification evidence
+    paths:
+      - "docs/reqstream/ots/buildmark.yaml"
+      - "docs/verification/ots/buildmark.md"
+
+  - id: OTS-FileAssert
+    title: Review of FileAssert OTS verification evidence
+    paths:
+      - "docs/reqstream/ots/fileassert.yaml"
+      - "docs/verification/ots/fileassert.md"
+
+  - id: OTS-Pandoc
+    title: Review of Pandoc OTS verification evidence
+    paths:
+      - "docs/reqstream/ots/pandoc.yaml"
+      - "docs/verification/ots/pandoc.md"
+
+  - id: OTS-ReqStream
+    title: Review of ReqStream OTS verification evidence
+    paths:
+      - "docs/reqstream/ots/reqstream.yaml"
+      - "docs/verification/ots/reqstream.md"
+
+  - id: OTS-ReviewMark
+    title: Review of ReviewMark OTS verification evidence
+    paths:
+      - "docs/reqstream/ots/reviewmark.yaml"
+      - "docs/verification/ots/reviewmark.md"
+
+  - id: OTS-SarifMark
+    title: Review of SarifMark OTS verification evidence
+    paths:
+      - "docs/reqstream/ots/sarifmark.yaml"
+      - "docs/verification/ots/sarifmark.md"
+
+  - id: OTS-SonarMark
+    title: Review of SonarMark OTS verification evidence
+    paths:
+      - "docs/reqstream/ots/sonarmark.yaml"
+      - "docs/verification/ots/sonarmark.md"
+
+  - id: OTS-VersionMark
+    title: Review of VersionMark OTS verification evidence
+    paths:
+      - "docs/reqstream/ots/versionmark.yaml"
+      - "docs/verification/ots/versionmark.md"
+
+  - id: OTS-WeasyPrint
+    title: Review of WeasyPrint OTS verification evidence
+    paths:
+      - "docs/reqstream/ots/weasyprint.yaml"
+      - "docs/verification/ots/weasyprint.md"
+
+  - id: OTS-xUnit
+    title: Review of xUnit OTS verification evidence
+    paths:
+      - "docs/reqstream/ots/xunit.yaml"
+      - "docs/verification/ots/xunit.md"

docs/design/template-dot-net-library/template-dot-net-library.md

@@ -23,7 +23,7 @@ best practices. The system consists of:
 - **ReqStream**: Requirements traceability enforcement
 - **ReviewMark**: File review management
 - **BuildMark/VersionMark**: Build and version documentation
-- **SonarMark/SARIFMark**: Quality analysis integration
+- **SonarMark/SarifMark**: Quality analysis integration
 
 ### Public API
 

docs/reqstream/ots/buildmark.yaml

@@ -18,3 +18,7 @@ sections:
             tags: [ots]
             tests:
               - BuildMark_MarkdownReportGeneration
+              - BuildMark_GitIntegration
+              - BuildMark_IssueTracking
+              - BuildMark_KnownIssuesReporting
+              - BuildMark_RulesRouting

docs/reqstream/ots/fileassert.yaml

@@ -12,11 +12,12 @@ sections:
             title: FileAssert shall validate generated documents against acceptance criteria.
             justification: |
               DemaConsulting.FileAssert validates HTML and PDF documents produced during the
-              build, asserting that each document exists, has a non-trivial size, is structurally
-              valid, and contains expected content. It provides OTS evidence for Pandoc and
-              WeasyPrint and independently confirms file assertion is functioning. Self-validation
-              proves the tool itself is operational before ReqStream consumes the results.
+              build, asserting that each document exists and contains expected content. It
+              provides OTS evidence for Pandoc and WeasyPrint and independently confirms file
+              assertion is functioning. Self-validation proves the tool itself is operational
+              before ReqStream consumes the results.
             tags: [ots]
             tests:
-              - FileAssert_VersionDisplay
-              - FileAssert_HelpDisplay
+              - FileAssert_Results
+              - FileAssert_Exists
+              - FileAssert_Contains

docs/reqstream/ots/pandoc.yaml

@@ -23,4 +23,5 @@ sections:
               - Pandoc_ReviewPlanHtml
               - Pandoc_ReviewReportHtml
               - Pandoc_DesignHtml
+              - Pandoc_VerificationHtml
               - Pandoc_UserGuideHtml