Update project based on template modifications

.cspell.yaml

@@ -39,6 +39,9 @@ words:
   - unconfigured
   - unparseable
   - tagobj
+  - hotspots
+  - inclusivity
+  - Postconditions
   - wiql
   - workitems
   - yamlfix

.fileassert.yaml

@@ -36,7 +36,7 @@ tests:
             - field: "Author"
               contains: "DEMA Consulting"
             - field: "Subject"
-              contains: "Build notes"
+              contains: "Build Notes for BuildMark"
           pages:
             min: 1
           text:
@@ -69,7 +69,7 @@ tests:
             - field: "Author"
               contains: "DEMA Consulting"
             - field: "Subject"
-              contains: "Code Quality"
+              contains: "Code Quality Report for BuildMark"
           pages:
             min: 1
           text:
@@ -102,7 +102,7 @@ tests:
             - field: "Author"
               contains: "DEMA Consulting"
             - field: "Subject"
-              contains: "Review Plan"
+              contains: "Code Review Plan for BuildMark"
           pages:
             min: 1
           text:
@@ -135,7 +135,7 @@ tests:
             - field: "Author"
               contains: "DEMA Consulting"
             - field: "Subject"
-              contains: "Review Report"
+              contains: "Code Review Report for BuildMark"
           pages:
             min: 1
           text:
@@ -168,7 +168,7 @@ tests:
             - field: "Author"
               contains: "DEMA Consulting"
             - field: "Subject"
-              contains: "design document"
+              contains: "Software Design Document for BuildMark"
           pages:
             min: 3
           text:
@@ -201,7 +201,7 @@ tests:
             - field: "Author"
               contains: "DEMA Consulting"
             - field: "Subject"
-              contains: "Verification design document"
+              contains: "Verification Design Document for BuildMark"
           pages:
             min: 3
           text:
@@ -234,7 +234,7 @@ tests:
             - field: "Author"
               contains: "DEMA Consulting"
             - field: "Subject"
-              contains: "Build Notes Generation"
+              contains: "User Guide for BuildMark"
           pages:
             min: 3
           text:
@@ -268,7 +268,7 @@ tests:
             - field: "Author"
               contains: "DEMA Consulting"
             - field: "Subject"
-              contains: "Requirements"
+              contains: "Requirements Document for BuildMark"
           pages:
             min: 1
           text:
@@ -302,7 +302,7 @@ tests:
             - field: "Author"
               contains: "DEMA Consulting"
             - field: "Subject"
-              contains: "Traceability"
+              contains: "Trace Matrix for BuildMark"
           pages:
             min: 1
           text:

.github/agents/template-sync.agent.md

@@ -31,8 +31,15 @@ For each group intersecting the requested scope, call a sub-agent with:
 
 - **context**:
   - Group scope and template URL from the `# Reference Template` section in `AGENTS.md`
+  - Applicable standards from the `# Standards Application` matrix in `AGENTS.md`
+    for the file types in the group scope
   - Project-specific names substitute for placeholders at matching path depth
-    (e.g. `SystemName` → `{SystemName}`, `system-name` → `{system-name}`)
+    (e.g. `MySystem` → `{SystemName}`, `my-system` → `{system-name}`)
+  - For files within `{system-name}/` subtrees in `docs/design/`, `docs/verification/`,
+    and `docs/reqstream/`: consult `docs/design/introduction.md` to determine whether
+    each item is a subsystem or unit, then select the appropriate template
+    (`subsystem-name.*` or `unit-name.*`) regardless of the item's folder depth —
+    do not infer item type from path depth alone
   - If a template counterpart cannot be fetched, skip the file and report it
 - **goal**:
   - Based on the given mode:
@@ -42,15 +49,38 @@ For each group intersecting the requested scope, call a sub-agent with:
     - **Scaffold** - fetch `repository-map.md` from the template URL in `AGENTS.md`
       to identify files that should exist but don't; for each, fetch the template,
       populate all sections, write the file; run `pwsh ./fix.ps1`
-    - **Recreate** - read the existing file in full, then fetch the template; use
-      full semantic understanding to map old content onto template sections,
-      splitting or consolidating as needed; create extra sections for any content
-      that has no template home; write the rebuilt file; run `pwsh ./fix.ps1`
-  - When writing any section: HTML comments and TODO placeholders in the template
-    are instructions - always resolve them to real content; infer from README,
-    related files, sibling docs, and path; if confident write directly; if
-    ambiguous offer 2–3 concrete options and ask the user; keep asking until they
-    answer - never leave a TODO unless the user explicitly requests it
+    - **Recreate** - fetch the template and use it as the blueprint for a
+      freshly authored document:
+      - Work through the template section by section; for each section, find
+        any `TEMPLATE-DIRECTIVE` blocks (both `<!-- TEMPLATE-DIRECTIVE: ... -->`
+        in markdown and `# <!-- TEMPLATE-DIRECTIVE: ... -->` in YAML) — execute
+        each directive (read specified standards, apply structural guidance,
+        substitute content), then **remove the directive block entirely** from
+        the output; gather the relevant technical details from all available
+        sources — the old file, README, related docs, sibling files, and any
+        other repo context — to populate that section correctly; the old file's
+        structure and headings are irrelevant; only its factual content is mined
+        as a source
+      - **Gap-check**: after all template sections are filled, scan the old
+        file once more for any technical information not yet captured; if
+        found, preserve it by appending new relevant sections at the end
+      - **Before writing**: do a mandatory self-check — for every section that
+        has a `TEMPLATE-DIRECTIVE` block in the template, explicitly state what
+        format the directive requires, then verify the drafted content matches
+        that format exactly (e.g. if the directive says "no sub-headings",
+        confirm there are no `###` headings inside that section; if it says
+        "bold-name paragraph blocks", confirm each entry is `**Name**: prose`
+        with no sub-heading); fix any mismatches before writing the file
+      - Write the rebuilt file; run `pwsh ./fix.ps1`
+  - When writing any section: `TEMPLATE-DIRECTIVE` blocks are directives —
+    execute them (read specified standards, apply structural guidance, substitute
+    content) and **remove the block entirely** from the written file; inline
+    `TODO:` placeholders in YAML string values (e.g. `title:`, `justification:`)
+    are content placeholders — always resolve them to real content; infer from
+    README, related files, sibling docs, and path; if confident write directly;
+    if ambiguous offer 2–3 concrete options and ask the user; keep asking until
+    they answer - never leave a TODO or TEMPLATE-DIRECTIVE in the output unless
+    the user explicitly requests it
 
 Collect sub-agent results and assemble the final report.
 
@@ -69,6 +99,8 @@ Collect sub-agent results and assemble the final report.
 - **Template**: {template path}
 - **Missing sections**: {list or "none"}
 - **Heading depth issues**: {list or "none"}
+- **Content format issues**: {list of sections where intra-section content did not
+  match the template comment's prescribed format, or "none"} *(Recreate only)*
 - **Action**: (Reported | Sections added | Created | Rebuilt | No template found)
 
 ## Summary

.github/standards/coding-principles.md

@@ -3,11 +3,6 @@ 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
@@ -20,10 +15,9 @@ 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 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
+- **Full Symbol Documentation**: ALL symbols have comprehensive documentation —
+  not just the public interface, because reviewers and auditors must verify every
+  implementation detail. Access-level specifics vary by language; see the language-specific standard.
 - **Clarity Over Cleverness**: Code should be immediately understandable by team members
 
 ## API Documentation
@@ -79,13 +73,13 @@ interface correctly without reading the implementation:
 
 ## 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
+- **Skip Literate Coding**: Don't skip literate programming comments
+- **Ignore Compiler Warnings**: Don't ignore compiler warnings
 - **Hidden Dependencies**: Don't create untestable code with hidden dependencies
 - **Hidden Functionality**: Don't implement functionality without requirement
   traceability because untraced functionality cannot be validated during audits
 - **Monolithic Functions**: Don't write monolithic functions with multiple responsibilities
-- **Overcomplicated Solutions**: Don't make solutions more complex than necessary - favor simplicity and clarity
+- **Overcomplicated Solutions**: Don't make solutions more complex than necessary
 - **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

.github/standards/csharp-language.md

@@ -12,9 +12,6 @@ Read these standards first before applying this standard:
 
 # API Documentation and Literate Coding Example
 
-The example below demonstrates good XmlDoc API documentation combined with
-literate coding comments.
-
 ```csharp
 /// <summary>
 ///     Converts a raw sensor reading into a validated measurement ready for downstream consumers.

.github/standards/csharp-testing.md

@@ -66,8 +66,6 @@ These are non-obvious v3 behaviors that differ from v2 or common assumptions:
 
 # Quality Checks
 
-Before submitting C# tests, verify:
-
 - [ ] All tests follow AAA pattern with clear section comments
 - [ ] Test names follow hierarchical naming pattern above
 - [ ] Each test verifies single, specific behavior (no shared state between tests)

.github/standards/design-documentation.md

@@ -28,7 +28,9 @@ docs/design/
     └── {package-name}.md        # heading depth ##
 ```
 
-Subsystems may nest recursively. Each file's heading depth equals its folder depth under `docs/design/`.
+All sections in every file are mandatory; write "N/A - {justification}" rather than removing any.
+Determine subsystem vs. unit classification from `docs/design/introduction.md` — folder depth does not determine classification.
+Do not record version numbers anywhere in design documentation — version information is managed in SBOMs.
 
 # introduction.md (MANDATORY)
 
@@ -43,8 +45,7 @@ Must include:
 
 # System Design (MANDATORY)
 
-Create `{system-name}.md` (`#` heading) and `{system-name}/` folder. All sections mandatory;
-write "N/A - {justification}" rather than removing any section:
+Create `{system-name}.md` (`#` heading) and `{system-name}/` folder:
 
 - **Architecture**: software items, relationships, and collaboration
 - **External Interfaces**: name, direction, format, constraints
@@ -55,37 +56,42 @@ write "N/A - {justification}" rather than removing any section:
 
 # Subsystem Design (MANDATORY)
 
-Place `{subsystem-name}.md` in the **parent** folder; create `{subsystem-name}/` for children.
-All sections mandatory; write "N/A - {justification}" rather than removing any section:
+Place `{subsystem-name}.md` in the **parent** folder; create `{subsystem-name}/` for children:
 
 - **Overview**: responsibility, boundaries, contained units
 - **Interfaces**: what it exposes and consumes
 - **Design**: how internal units collaborate
 
 # Unit Design (MANDATORY)
 
-Place `{unit-name}.md` in the **parent** folder. All sections mandatory;
-write "N/A - {justification}" rather than removing any section:
+Place `{unit-name}.md` in the **parent** folder:
 
 - **Purpose**: single responsibility
 - **Data Model**: fields, properties, types, invariants (IEC 62304 §5.4.2)
 - **Key Methods**: name, purpose, algorithm, preconditions, postconditions, parameter types
 - **Error Handling**: detection and handling; what is propagated vs. handled locally
-- **Interactions**: dependencies on other units/subsystems/OTS; who calls this unit
+- **Dependencies**: other units, subsystems, OTS items, and shared packages used
+- **Callers**: units or subsystems that call or consume this unit
 
 # OTS Integration Design (when OTS items exist)
 
 Create `docs/design/ots.md` (`#` heading) covering the overall OTS integration strategy.
 
-For each OTS item, create `docs/design/ots/{ots-name}.md` (`##` heading) covering:
-why chosen, which features/APIs used, integration patterns, version constraints.
+For each OTS item, create `docs/design/ots/{ots-name}.md` (`##` heading) with sections:
+
+- **Purpose**: why chosen and what it provides to the local system
+- **Features Used**: which specific features, APIs, or capabilities are consumed
+- **Integration Pattern**: how it is consumed; initialization, configuration, disposal requirements
 
 # Shared Package Integration Design (when Shared Packages exist)
 
 Create `docs/design/shared.md` (`#` heading) covering the overall consumption strategy.
 
-For each Shared Package, create `docs/design/shared/{package-name}.md` (`##` heading) covering:
-which advertised features are consumed, integration pattern, configuration/initialization.
+For each Shared Package, create `docs/design/shared/{package-name}.md` (`##` heading) with sections:
+
+- **Advertised Features Consumed**: which features the local system relies on
+- **Integration Pattern**: how the package is referenced, initialized, and consumed
+- **Assumptions**: any assumptions the local system makes about the package's behavior
 
 # Writing Guidelines
 
@@ -102,7 +108,7 @@ which advertised features are consumed, integration pattern, configuration/initi
 - [ ] System design includes all mandatory sections (Architecture, External Interfaces, Dependencies,
   Risk Control Measures, Data Flow, Design Constraints)
 - [ ] Subsystem design includes all mandatory sections (Overview, Interfaces, Design)
-- [ ] Unit design includes all mandatory sections (Purpose, Data Model, Key Methods, Error Handling, Interactions)
+- [ ] Unit design includes all mandatory sections (Purpose, Data Model, Key Methods, Error Handling, Dependencies, Callers)
 - [ ] Non-applicable mandatory sections contain "N/A - {justification}"
 - [ ] `docs/design/ots.md` and `docs/design/ots/{ots-name}.md` exist when OTS items are present
 - [ ] `docs/design/shared.md` and `docs/design/shared/{package-name}.md` exist when Shared Packages are present