Skip to content

Commit 431d230

Browse files
chore: sync template files and restructure design/reqstream/reviewmark to new standards (#16)
* chore: binary-copy updated files from TemplateDotNetTool template Agent-Logs-Url: https://github.com/demaconsulting/FileAssert/sessions/6a3e36d3-6354-4084-ad2d-7ca8bcfb6fd4 Co-authored-by: Malcolmnixon <1863707+Malcolmnixon@users.noreply.github.com> * chore: restructure design/reqstream into system-level folders per updated standards Agent-Logs-Url: https://github.com/demaconsulting/FileAssert/sessions/d2c6e43e-2876-4c66-8359-c3f1cbf56023 Co-authored-by: Malcolmnixon <1863707+Malcolmnixon@users.noreply.github.com> * chore: remove OTS dependency review set from .reviewmark.yaml Agent-Logs-Url: https://github.com/demaconsulting/FileAssert/sessions/883b5ddd-b995-446b-aae0-ab8ae0f95258 Co-authored-by: Malcolmnixon <1863707+Malcolmnixon@users.noreply.github.com> * chore: fix AllRequirements paths, add missing design files, fix template name in AGENTS.md Agent-Logs-Url: https://github.com/demaconsulting/FileAssert/sessions/348a483a-24cd-449f-a6d9-55cbc65d5852 Co-authored-by: Malcolmnixon <1863707+Malcolmnixon@users.noreply.github.com> * fix: replace TemplateDotNetLibrary with TemplateDotNetTool in repo-consistency agent Agent-Logs-Url: https://github.com/demaconsulting/FileAssert/sessions/396c86b4-364a-485d-82ed-56c141bf4fa8 Co-authored-by: Malcolmnixon <1863707+Malcolmnixon@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: Malcolmnixon <1863707+Malcolmnixon@users.noreply.github.com>
1 parent 69c452e commit 431d230

47 files changed

Lines changed: 403 additions & 405 deletions

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

.github/agents/developer.agent.md

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -16,7 +16,8 @@ Perform software development tasks by determining and applying appropriate DEMA
1616
2. **Read relevant standards** from `.github/standards/` as defined in AGENTS.md based on work performed
1717
3. **Apply loaded standards** throughout development process
1818
4. **Execute work** following standards requirements and quality checks
19-
5. **Generate completion report** with results and compliance status
19+
5. **Lint fixes** follow the linting process before performing quality gates
20+
6. **Generate completion report** with results and compliance status
2021

2122
# Reporting
2223

.github/agents/implementation.agent.md

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -28,7 +28,7 @@ counting how many retries have occurred.
2828

2929
Call the built-in explore sub-agent with:
3030

31-
- **context**: the user's request and any current quality findings
31+
- **context**: the user's request + any previous quality findings + retry context
3232
- **goal**: analyze the implementation state and develop a plan to implement the request
3333

3434
Once the explore sub-agent finishes, transition to the DEVELOPMENT state.
@@ -37,7 +37,7 @@ Once the explore sub-agent finishes, transition to the DEVELOPMENT state.
3737

3838
Call the developer sub-agent with:
3939

40-
- **context** the user's request and the current implementation plan
40+
- **context** the user's request + research plan + specific quality issues to address (if retry)
4141
- **goal** implement the user's request and any identified quality fixes
4242

4343
Once the developer sub-agent finishes:
@@ -49,7 +49,7 @@ Once the developer sub-agent finishes:
4949

5050
Call the quality sub-agent with:
5151

52-
- **context** the user's request and the current implementation report
52+
- **context** the user's request + development summary + files changed + previous issues (if any)
5353
- **goal** check the quality of the work performed for any issues
5454

5555
Once the quality sub-agent finishes:
@@ -73,7 +73,7 @@ of the project consisting of:
7373
## State Machine Execution
7474

7575
- **Research Results**: [Summary of explore agent findings]
76-
- **Development Results**: [Summary of developer agent results]
76+
- **Development Results**: [Summary of developer agent results]
7777
- **Quality Results**: [Summary of quality agent results]
7878
- **State Transitions**: [Log of state changes and decisions]
7979

@@ -86,7 +86,7 @@ of the project consisting of:
8686
## Final Status
8787

8888
- **Implementation Success**: [Overall completion status]
89-
- **Quality Compliance**: [Final quality validation status]
89+
- **Quality Compliance**: [Final quality validation status]
9090
- **Issues Resolved**: [Problems encountered and resolution attempts]
9191
```
9292

.github/agents/quality.agent.md

Lines changed: 14 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -26,6 +26,13 @@ This assessment is a quality control system of the project and MUST be performed
2626
Upon completion create a summary in `.agent-logs/{agent-name}-{subject}-{unique-id}.md`
2727
of the project consisting of:
2828

29+
The **Result** field MUST reflect the quality validation outcome for orchestrator decision-making:
30+
31+
- **Result: SUCCEEDED** - Only when Overall Grade is PASS (all compliance requirements met)
32+
- **Result: FAILED** - When Overall Grade is FAIL or NEEDS_WORK (compliance failures present)
33+
34+
This ensures orchestrators properly halt workflows when quality gates fail.
35+
2936
```markdown
3037
# Quality Assessment Report
3138

@@ -98,6 +105,13 @@ of the project consisting of:
98105
- Do README.md files use absolute URLs and include concrete examples? (PASS|FAIL|N/A) - [Evidence]
99106
- Is documentation integrated into ReviewMark review-sets for formal review? (PASS|FAIL|N/A) - [Evidence]
100107

108+
## Software Item Completeness: (PASS|FAIL|N/A)
109+
110+
- Does every identified software unit have its own requirements file? (PASS|FAIL|N/A) - [Evidence]
111+
- Does every identified software unit have its own design document? (PASS|FAIL|N/A) - [Evidence]
112+
- Does every identified subsystem have its own requirements file? (PASS|FAIL|N/A) - [Evidence]
113+
- Does every identified subsystem have its own design document? (PASS|FAIL|N/A) - [Evidence]
114+
101115
## Process Compliance: (PASS|FAIL|N/A)
102116

103117
- Was Continuous Compliance workflow followed? (PASS|FAIL|N/A) - [Evidence]

.github/standards/design-documentation.md

Lines changed: 37 additions & 26 deletions
Original file line numberDiff line numberDiff line change
@@ -23,12 +23,13 @@ design to implementation:
2323

2424
```text
2525
docs/design/
26-
├── introduction.md # Design overview with software structure
27-
├── system.md # System-level design documentation
28-
├── {subsystem-name}/ # Subsystem design documents (kebab-case folder names)
29-
│ ├── {subsystem-name}.md # Subsystem overview and design
30-
│ └── {unit-name}.md # Unit-level design documents
31-
└── {unit-name}.md # Top-level unit design documents (if not in subsystem)
26+
├── introduction.md # Design overview with software structure
27+
└── {system-name}/ # System-level design folder (one per system)
28+
├── {system-name}.md # System-level design documentation
29+
├── {subsystem-name}/ # Subsystem design documents (kebab-case folder names)
30+
│ ├── {subsystem-name}.md # Subsystem overview and design
31+
│ └── {unit-name}.md # Unit-level design documents
32+
└── {unit-name}.md # Top-level unit design documents (if not in subsystem)
3233
```
3334

3435
## introduction.md (MANDATORY)
@@ -56,13 +57,16 @@ to understand these classifications before creating this section.
5657
Example format:
5758

5859
```text
59-
ProjectName (System)
60+
Project1Name (System)
6061
├── ComponentA (Subsystem)
6162
│ ├── ClassX (Unit)
6263
│ └── ClassY (Unit)
6364
├── ComponentB (Subsystem)
6465
│ └── ClassZ (Unit)
6566
└── UtilityClass (Unit)
67+
68+
Project2Name (System)
69+
└── HelperClass (Unit)
6670
```
6771

6872
### Folder Layout Section (MANDATORY)
@@ -73,34 +77,39 @@ mirror the software structure, with file paths and brief descriptions.
7377
Example format:
7478

7579
```text
76-
src/ProjectName/
80+
src/Project1Name/
7781
├── ComponentA/
78-
│ ├── ClassX.cs — brief description
79-
│ └── ClassY.cs — brief description
82+
│ ├── ClassX.cs — Core business logic handler
83+
│ └── ClassY.cs — Data validation service
8084
├── ComponentB/
81-
│ └── ClassZ.cs — brief description
82-
└── UtilityClass.cs — brief description
85+
│ └── ClassZ.cs — Integration interface
86+
└── UtilityClass.cs — Common utility functions
87+
88+
src/Project2Name/
89+
└── HelperClass.cs — Helper functions
8390
```
8491

85-
## system.md (MANDATORY)
92+
## System Design Documentation (MANDATORY)
8693

87-
The `system.md` file contains system-level design documentation including:
94+
For each system identified in the repository:
8895

89-
- System architecture and major components
90-
- External interfaces and dependencies
91-
- Data flow and control flow
92-
- System-wide design constraints and decisions
93-
- Integration patterns and communication protocols
96+
- Create a kebab-case folder matching the system name
97+
- Include `{system-name}.md` with system-level design documentation such as:
98+
- System architecture and major components
99+
- External interfaces and dependencies
100+
- Data flow and control flow
101+
- System-wide design constraints and decisions
102+
- Integration patterns and communication protocols
94103

95104
## Subsystem and Unit Design Documents
96105

97106
For each subsystem identified in the software structure:
98107

99108
- Create a kebab-case folder matching the subsystem name (enables automated tooling)
100109
- Include `{subsystem-name}.md` with subsystem overview and design
101-
- Include unit design documents for complex units within the subsystem
110+
- Include unit design documents for ALL units within the subsystem
102111

103-
For significant units requiring detailed design:
112+
For every unit identified in the software structure:
104113

105114
- Document data models, algorithms, and key methods
106115
- Describe interactions with other units
@@ -124,19 +133,21 @@ implementation specification for formal code review:
124133
- **Implementation Detail**: Provide sufficient detail for code review and implementation
125134
- **Architectural Clarity**: Clearly define component boundaries and interfaces
126135
- **Traceability**: Link to requirements where applicable using ReqStream patterns
127-
- **Concrete Examples**: Use actual class names, method signatures, and data structures
128-
- **Current Information**: Keep synchronized with code changes and refactoring
136+
137+
# Mermaid Diagram Integration
138+
139+
Use Mermaid diagrams to supplement text descriptions (diagrams must not replace text content).
129140

130141
# Quality Checks
131142

132143
Before submitting design documentation, verify:
133144

134145
- [ ] `introduction.md` includes both Software Structure and Folder Layout sections
135146
- [ ] Software structure correctly categorizes items as System/Subsystem/Unit per `software-items.md`
136-
- [ ] Folder layout matches actual source code organization
137-
- [ ] `system.md` provides comprehensive system-level design
147+
- [ ] Folder layout mirrors software structure organization
148+
- [ ] Design documents provide sufficient detail for code review
149+
- [ ] System documentation provides comprehensive system-level design
138150
- [ ] Subsystem documentation folders use kebab-case names while mirroring source subsystem names and structure
139-
- [ ] Design documents contain sufficient implementation detail
140151
- [ ] All documents follow technical documentation formatting standards
141152
- [ ] Content is current with implementation and requirements
142153
- [ ] Documents are integrated into ReviewMark review-sets for formal review

.github/standards/reqstream-usage.md

Lines changed: 14 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -30,15 +30,17 @@ the source code structure because reviewers need clear navigation from
3030
requirements to design to implementation:
3131

3232
```text
33-
requirements.yaml # Root file (includes only)
33+
requirements.yaml # Root file (includes only)
3434
docs/reqstream/
35-
├── system.yaml # System-level requirements
36-
├── platform-requirements.yaml # Platform support requirements
37-
├── {subsystem-name}/ # Subsystem requirements (kebab-case folders)
38-
│ └── {subsystem-name}.yaml # Requirements for this subsystem
39-
├── {unit-name}.yaml # Unit requirements (for top-level units)
40-
└── ots/ # OTS software item requirements
41-
└── {ots-name}.yaml # Requirements for OTS components
35+
├── {system-name}/ # System-level requirements folder (one per system)
36+
│ ├── {system-name}.yaml # System-level requirements
37+
│ ├── platform-requirements.yaml # Platform support requirements
38+
│ ├── {subsystem-name}/ # Subsystem requirements (kebab-case folders)
39+
│ │ ├── {subsystem-name}.yaml # Requirements for this subsystem
40+
│ │ └── {unit-name}.yaml # Requirements for units within this subsystem
41+
│ └── {unit-name}.yaml # Requirements for top-level units (outside subsystems)
42+
└── ots/ # OTS software items folder
43+
└── {ots-name}.yaml # Requirements for OTS components
4244
```
4345

4446
The folder structure MUST mirror the source code organization to maintain
@@ -62,7 +64,7 @@ for compliance auditing.
6264
sections:
6365
- title: Functional Requirements
6466
requirements:
65-
- id: Project-Subsystem-Feature
67+
- id: System-Subsystem-Feature
6668
title: The system shall perform the required function.
6769
justification: |
6870
Business rationale explaining why this requirement exists.
@@ -88,15 +90,15 @@ sections:
8890
sections:
8991
- title: System.Text.Json
9092
requirements:
91-
- id: Project-SystemTextJson-ReadJson
93+
- id: TemplateTool-SystemTextJson-ReadJson
9294
title: System.Text.Json shall be able to read JSON files.
9395
tests:
9496
- JsonReaderTests.TestReadValidJson
9597
```
9698

9799
# Semantic IDs (MANDATORY)
98100

99-
Use meaningful IDs following `Project-Section-ShortDesc` pattern because
101+
Use meaningful IDs following `System-Section-ShortDesc` pattern because
100102
auditors need to understand requirements without cross-referencing:
101103

102104
- **Good**: `TemplateTool-Core-DisplayHelp`
@@ -127,12 +129,6 @@ dotnet reqstream \
127129
--requirements requirements.yaml \
128130
--lint
129131
130-
# Enforce requirements traceability (use in CI/CD)
131-
dotnet reqstream \
132-
--requirements requirements.yaml \
133-
--tests "artifacts/**/*.trx" \
134-
--enforce
135-
136132
# Generate requirements report
137133
dotnet reqstream \
138134
--requirements requirements.yaml \
@@ -154,7 +150,7 @@ dotnet reqstream \
154150

155151
Before submitting requirements, verify:
156152

157-
- [ ] All requirements have semantic IDs (`Project-Section-Feature` pattern)
153+
- [ ] All requirements have semantic IDs (`System-Section-Feature` pattern)
158154
- [ ] Every requirement links to at least one passing test
159155
- [ ] Platform-specific requirements use source filters (`platform@TestName`)
160156
- [ ] Requirements specify observable behavior (WHAT), not implementation (HOW)

0 commit comments

Comments
 (0)