[Add] CSV requirements input and VCD report output via Sep

[fabiantax]

Why

Right now the generator only eats .xlsx. That's fine when your requirements live in a shared drive — but the moment you want to check them into the same repo as your code, xlsx stops being your friend:

• Binary blob. Git can't diff it, can't meaningfully merge it, and it bloats the repo every time someone opens it in Excel and hits save.
• Impossible reviews. A PR that tweaks a requirement shows up as "Requirements.xlsx changed" — no clue what actually changed.
• Merge conflicts = pain. Two people edit the sheet, one of them loses.

CSV fixes all three. It's plain text, diffs beautifully, and a requirements edit becomes a proper one-line change in a PR.

So this PR teaches the tool to read and write CSV alongside xlsx. No flags, no flags to remember — it just looks at the file extension:

• --requirements-file requirements.csv → reads CSV
• --output-report VCD.csv → writes CSV
• Anything else → stays on the xlsx path, exactly as before

How

• New CsvRequirementsReader + CsvReportGenerator using Sep (MIT, AOT-friendly, explicitly targets net10)
• A tiny RequirementsReaderDispatcher picks the right reader based on the input extension
• ReportGenerator grew a ReportKind.Csv branch that delegates to the CSV writer
• GenerateCommand derives the ReportKind from the output extension
• --requirements-sheet-name is silently ignored when the input is CSV (sheets don't exist in CSV land)
• RFC-4180 quoting handled by Sep — embedded commas, quotes, and newlines round-trip correctly

Why Sep and not CsvHelper

CsvHelper is the obvious default — it's the most-starred CSV library in the .NET world. But looking at its current csproj it still targets net9.0; net8.0; netstandard2.1; netstandard2.0; net48; net47; net462 and has no net10.0 target yet. .NET 10 is an LTS release and this project just migrated to it (PR #9) — a library that hasn't updated for the new LTS within this window is a yellow flag for long-term maintenance, especially in security-sensitive contexts where stale dependencies accumulate CVE exposure.

Sep, by contrast, explicitly targets net10.0; net9.0; net8.0 today, is AOT/trim-compatible, and its maintainer tracks runtime releases aggressively. Same MIT license, comparable community footprint (1.4k stars, actively pushed). Switching back to CsvHelper later is trivial if that trade-off calculus ever flips.

What's in the diff

New files

• VCD-Generator/Services/CsvRequirementsReader.cs
• VCD-Generator/Services/CsvReportGenerator.cs
• VCD-Generator/Services/RequirementsReaderDispatcher.cs
• VCD-Generator.Tests/Services/CsvRequirementsReaderTestFixture.cs (8 tests)
• VCD-Generator.Tests/Services/CsvReportGeneratorTestFixture.cs (3 tests)
• VCD-Generator.Tests/Services/RequirementsReaderDispatcherTestFixture.cs (3 tests)
• VCD-Generator.Tests/Data/requirements.csv (covers trim, empty-id skip, and embedded-newline quoting)

Touched files

• ReportKind.cs — added Csv enum value
• ReportGenerator.cs — new ctor dep + Csv case in the switch
• Program.cs — DI wiring for the three new services
• GenerateCommand.cs — extension-based ReportKind selection
• VCD-Generator.csproj — <PackageReference Include="Sep" Version="0.12.5" />

Test plan

• dotnet build — clean on net10.0
• dotnet test — 29/29 passing (14 new, 15 pre-existing)
• Manual smoke: .xlsx in → .csv out
• Manual smoke: .csv in → .xlsx out
• Reviewer sanity-check: extension-based dispatch vs an explicit --format flag — I went with extensions to avoid adding CLI surface, happy to change if you'd rather be explicit

Open questions for reviewers

1. Library choice. Sep over CsvHelper — reasoning above. Swap if you disagree.
2. ClosedXML stays. No attempt to migrate the xlsx path to OpenXML SDK — out of scope.
3. Sheet name on CSV input. Currently silently ignored. I could make it throw instead if you want strict validation.

[samatstariongroup]

2026 please

[samatstariongroup]

we typically use CsvHelper, my preference is there. please change

[samatstariongroup]

i propose we rename this class to XlsxRequirementsReader

[samatstariongroup]

inject interfaces perhaps?

[samatstariongroup]

i think a bigger refactor is required. This report generator is now only realy doing excel report, so, please rename to excel report, introduce a dedicated html report generator and keep the csv report generator.

Then a "master" report generator that dispatches to the specific generator based on the requested report