Add clean code and TDD guidelines

- Introduced new markdown files for Clean Code, SOLID principles, KISS, DRY, and Test-Driven Development (TDD) practices.
- Established rules for code clarity, maintainability, and testing workflows, emphasizing the importance of writing meaningful tests and following design principles.
- Included examples in C# to illustrate good and bad practices, enhancing understanding of the guidelines.
- Aimed to improve code quality and development efficiency across the project.

Author: floriankraemer

.cursor/rules/clean-code-solid.mdc

@@ -0,0 +1,77 @@
+---
+description: Enforce Clean Code, SOLID, KISS, and DRY in all code changes
+alwaysApply: true
+---
+
+# Clean Code, SOLID, KISS, and DRY
+
+Follow Robert C. Martin's *Clean Code* and these design principles on every change.
+Prefer clarity and maintainability over cleverness.
+
+## Clean Code
+
+- Names must reveal intent; avoid abbreviations and noise (`CalculateCognitiveScore`, not `CalcCS`).
+- Functions do one thing, stay short (target ≤ 20 lines), and have few parameters.
+- Prefer early returns over deep nesting.
+- Comments explain *why*, not *what* — the code should read like prose.
+- Fail fast with meaningful exceptions; never swallow errors silently.
+
+```csharp
+// ❌ BAD — unclear name, deep nesting, silent failure
+public int Proc(object x) {
+    if (x != null) {
+        if (x is string s) {
+            try { return int.Parse(s); } catch { return 0; }
+        }
+    }
+    return 0;
+}
+
+// ✅ GOOD — intent-revealing, early return, explicit error
+public int ParseScore(string raw) =>
+    int.TryParse(raw, out var score)
+        ? score
+        : throw new FormatException($"Invalid score: '{raw}'");
+```
+
+## SOLID
+
+- **SRP**: One reason to change per class. Split parsing, reporting, and orchestration.
+- **OCP**: Extend via new types or strategies; avoid editing stable code for every variant.
+- **LSP**: Subtypes must honor base contracts — no surprise exceptions or narrowed behavior.
+- **ISP**: Small, focused interfaces (`ICoverageReader`, not `IAnalysisEverything`).
+- **DIP**: Depend on abstractions; inject via constructors, not `new` inside services.
+
+```csharp
+// ❌ BAD — concrete dependency, mixed responsibilities
+public class ReportService {
+    public void Run(string path) {
+        var data = new CoberturaReader().Read(path);
+        File.WriteAllText("out.json", JsonSerializer.Serialize(data));
+    }
+}
+
+// ✅ GOOD — injected abstraction, single responsibility
+public class ReportService(IReportWriter writer, ICoverageReader reader) {
+    public void Generate(string path) => writer.Write(reader.Read(path));
+}
+```
+
+## KISS
+
+- Choose the simplest design that satisfies the requirement.
+- Do not add abstractions, configuration, or generics without a concrete need.
+- Refactor when duplication or complexity appears — not preemptively.
+
+## DRY
+
+- Extract shared logic when the same rule appears twice; do not copy-paste.
+- DRY applies to behavior, not coincidental similarity — two similar-looking blocks with different reasons to change should stay separate.
+- Prefer existing helpers and project conventions before introducing new utilities.
+
+## Code Smells to Fix
+
+- Long methods or classes → extract focused units.
+- Duplicated logic → shared method or type.
+- Magic numbers/strings → named constants.
+- God classes, feature envy, or shotgun surgery → revisit SRP and DIP.

.cursor/rules/tdd.mdc

@@ -0,0 +1,70 @@
+---
+description: Test-driven development workflow and container-based test execution
+alwaysApply: true
+---
+
+# Test-Driven Development
+
+Follow TDD for new behavior, refactors with behavior changes, and bug fixes.
+See also `container-development.mdc` for build and CI commands.
+
+## Red → Green → Refactor
+
+1. **Red** — Write a failing test that describes the desired behavior.
+2. **Green** — Write the smallest production change that makes the test pass.
+3. **Refactor** — Clean up while keeping tests green.
+
+Do not add production code for untested behavior.
+Do not skip the failing-test step to "save time."
+
+## Bug fixes
+
+Reproduce the bug in a test first (as close to real usage as practical), confirm it fails, then fix.
+
+## Writing tests (NUnit)
+
+- Place tests in `*Tests` projects, mirroring production namespaces.
+- Name tests by behavior: `MethodName_Scenario_ExpectedResult`.
+- Prefer focused tests over large integration suites unless the behavior requires end-to-end coverage.
+- Use fixtures under `fixtures/` for sample inputs; keep golden files in `fixtures/reports/golden/`.
+
+```csharp
+// ❌ BAD — implementation detail, no clear behavior
+[Test]
+public void Test1() { ... }
+
+// ✅ GOOD — behavior-focused
+[Test]
+public void CalculateScores_WhenLinesOfCodeExceedsThreshold_MapsToLowerScore()
+{
+    // arrange → act → assert
+}
+```
+
+## Run tests in the container
+
+Always run tests through `make` from the repo root.
+The Makefile re-executes inside the dev container.
+
+```bash
+make test          # full suite (Release)
+make test-debug    # Debug configuration
+make coverage      # Coverlet report → artifacts/coverage
+```
+
+```bash
+# ❌ BAD — host SDK, may differ from CI/container
+dotnet test CognitiveCodeAnalysis.sln
+
+# ✅ GOOD
+make test
+```
+
+After each TDD cycle, run the relevant tests before moving on.
+Before finishing a feature or fix, run `make test` at minimum; use `make ci` for larger changes.
+
+## When to add tests
+
+- **New behavior** — test first, then implement.
+- **Refactor** — existing tests must stay green; add tests only if coverage is missing.
+- **Trivial changes** — typos, comments, formatting: no new tests required.