Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions docs/design/definition.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,7 @@ resource-path:
- docs/template
input-files:
- docs/design/title.txt
- docs/design/introduction.md
- docs/design/file-assert-rule.md
- docs/design/file-assert-file.md
- docs/design/file-assert-test.md
Expand Down
100 changes: 100 additions & 0 deletions docs/design/introduction.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,100 @@
# Introduction

This document provides the detailed design for the FileAssert tool, a .NET command-line application
for asserting file properties using YAML-defined test suites.

## Purpose

The purpose of this document is to describe the internal design of each software unit that comprises
FileAssert. It captures data models, algorithms, key methods, and inter-unit interactions at a level
of detail sufficient for formal code review, compliance verification, and future maintenance. The
document does not restate requirements; it explains how they are realized.

## Scope

This document covers the detailed design of the following software units:

- **Program** — entry point and execution orchestrator (`Program.cs`)
- **Context** — command-line argument parser and I/O owner (`Context.cs`)
- **FileAssertConfig** — top-level configuration loader and test runner (`FileAssertConfig.cs`)
- **FileAssertData** — YAML data transfer objects for configuration deserialization (`FileAssertData.cs`)
- **FileAssertTest** — named test with file assertions and tag filtering (`FileAssertTest.cs`)
- **FileAssertFile** — glob pattern matcher with count constraints and content rules (`FileAssertFile.cs`)
- **FileAssertRule** — abstract content validation rule hierarchy (`FileAssertRule.cs`)
- **PathHelpers** — safe path-combination utility (`PathHelpers.cs`)
- **Validation** — self-validation test runner (`Validation.cs`)

The following topics are out of scope:

- External library internals (YamlDotNet, Microsoft.Extensions.FileSystemGlobbing,
DemaConsulting.TestResults)
- Build pipeline configuration
- Deployment and packaging

## Software Structure

The following tree shows how the FileAssert software items are organized across the system,
subsystem, and unit levels:

```text
FileAssert (System)
├── Program (Unit)
├── Cli (Subsystem)
│ └── Context (Unit)
├── Configuration (Subsystem)
│ ├── FileAssertConfig (Unit)
│ └── FileAssertData (Unit)
├── Modeling (Subsystem)
│ ├── FileAssertTest (Unit)
│ ├── FileAssertFile (Unit)
│ └── FileAssertRule (Unit)
├── Utilities (Subsystem)
│ └── PathHelpers (Unit)
└── SelfTest (Subsystem)
└── Validation (Unit)
```

Each unit is described in detail in its own chapter within this document.
Copy link

Copilot AI Mar 30, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

“Each unit is described in detail in its own chapter within this document” doesn’t match the current document composition: docs/design/definition.yaml only includes chapters for rule/file/test/config (not Program/Context/FileAssertData/PathHelpers/Validation). Please either change this to future tense (e.g., “will be described…”) or add stubs/chapters and include them in definition.yaml.

Suggested change
Each unit is described in detail in its own chapter within this document.
Each unit will be described in detail in its own chapter within this document.

Copilot uses AI. Check for mistakes.

## Folder Layout

The source code folder structure mirrors the top-level subsystem breakdown above, giving
reviewers an explicit navigation aid from design to code:

Comment on lines +61 to +63
Copy link

Copilot AI Mar 30, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The “Folder Layout” section reads as if it reflects the current repo layout (“mirrors … above”), but the current implementation under src/DemaConsulting.FileAssert/ is still flat (e.g., Context.cs, FileAssertConfig.cs, etc. are not under subsystem subfolders). To avoid misleading readers, reword this section to explicitly say this is the planned/target layout (and optionally note the current flat layout).

Copilot uses AI. Check for mistakes.
```text
src/DemaConsulting.FileAssert/
├── Program.cs — entry point and execution orchestrator
├── Cli/
│ └── Context.cs — command-line argument parser and I/O owner
├── Configuration/
│ ├── FileAssertConfig.cs — top-level configuration loader and test runner
│ └── FileAssertData.cs — YAML data transfer objects
├── Modeling/
│ ├── FileAssertTest.cs — named test with file assertions and tag filtering
│ ├── FileAssertFile.cs — glob pattern matcher with count constraints and rules
│ └── FileAssertRule.cs — abstract content validation rule hierarchy
├── Utilities/
│ └── PathHelpers.cs — safe path-combination utility
└── SelfTest/
└── Validation.cs — self-validation test runner
```

The test project mirrors the same layout under `test/DemaConsulting.FileAssert.Tests/`.
Copy link

Copilot AI Mar 30, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This statement is currently inaccurate: test/DemaConsulting.FileAssert.Tests/ is also flat today (no Cli/, Configuration/, etc. subfolders). Either qualify it as a planned future structure or adjust it to describe the current state.

Suggested change
The test project mirrors the same layout under `test/DemaConsulting.FileAssert.Tests/`.
The test project currently uses a flat folder structure under `test/DemaConsulting.FileAssert.Tests/`, with tests organized logically by subsystem but not yet split into `Cli/`, `Configuration/`, `Modeling/`, `Utilities/`, or `SelfTest` subfolders.

Copilot uses AI. Check for mistakes.

## Document Conventions

Throughout this document:

- Class names, method names, property names, and file names appear in `monospace` font.
- The word **shall** denotes a design constraint that the implementation must satisfy.
- Section headings within each unit chapter follow a consistent structure: overview, data model,
methods/algorithms, and interactions with other units.
Comment on lines +90 to +91
Copy link

Copilot AI Mar 30, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The “Document Conventions” bullet about unit chapter headings (“overview, data model, methods/algorithms, …”) doesn’t match the existing unit chapters in this doc set, which currently use sections like “Overview”, “Class Structure”, “YAML Configuration”, and “Design Decisions”. Update this convention to reflect the current structure, or adjust the existing chapters to follow the stated structure so the document is internally consistent.

Suggested change
- Section headings within each unit chapter follow a consistent structure: overview, data model,
methods/algorithms, and interactions with other units.
- Section headings within each unit chapter typically follow a consistent structure using sections
such as **Overview**, **Class Structure**, **YAML Configuration**, and **Design Decisions**.

Copilot uses AI. Check for mistakes.
- Text tables are used in preference to diagrams, which may not render in all PDF viewers.

## References

- [FileAssert User Guide][guide]
- [FileAssert Repository][repo]

[guide]: ../../README.md
[repo]: https://github.com/demaconsulting/FileAssert
Loading