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
8 changes: 8 additions & 0 deletions .github/copilot-instructions.md
Original file line number Diff line number Diff line change
Expand Up @@ -35,6 +35,14 @@ docfx docfx.json
- `main` is protected and must not receive direct feature commits.
- Create a new branch for each feature/fix/change.
- Merge to `main` only through pull requests with test evidence.
- Work branches may use either the existing topic naming or the numbered Spec-Kit form `NNN-short-description`.

`Directory.Build.props` carries the repo-wide `Version`, `AssemblyVersion`, and `FileVersion` values for all projects using `Major.Minor.Patch.Build`:
- `Minor` = current Spec-Kit feature/branch number, interpreted numerically as the canonical PR number for versioning (`002` -> `2`) and used immediately even before a GitHub PR exists
- `Patch` = current commit count in that feature/PR branch (after committing the current change)
- `Build` = manual build counter incremented before every `dotnet build` or `dotnet test`

On numbered Spec-Kit branches, align those three version fields before pushing.

## Architecture

Expand Down
24 changes: 16 additions & 8 deletions .specify/memory/constitution.md
Original file line number Diff line number Diff line change
@@ -1,10 +1,10 @@
<!--
Sync Impact Report
- Version change: 2.2.0 -> 2.3.0
- Version change: 2.3.0 -> 2.4.0
- Bump rationale:
- MINOR: Expanded the statistical documentation policy so manual-effort
estimates now include production code, test code, and documentation
together, and added explicit month and TVoeD calendar assumptions.
- MINOR: Added numbered Spec-Kit branch support plus repo-wide assembly
version governance via `Directory.Build.props`, including the rule that the
feature/branch number becomes the canonical PR number for `Minor`.
- Modified principles:
- None
- Added sections:
Expand Down Expand Up @@ -86,9 +86,11 @@ Rationale: uniform contracts prevent drift between agent, harvester, viewer, and
### VI. Branching and Pull Request Governance (NON-NEGOTIABLE)
The `main` branch is protected and MUST NOT receive direct feature commits. Every
feature, fix, or constitutional amendment MUST be implemented on a newly created branch
and merged through a pull request targeting `main`. Pull requests MUST state purpose,
touched projects, test evidence, and config/API impact; UI-impacting changes in
`InventarViewerApp` MUST include a screenshot or terminal capture.
and merged through a pull request targeting `main`. Branches MAY use either the
existing topic naming or the numbered Spec-Kit form `NNN-short-description`. Pull
requests MUST state purpose, touched projects, test evidence, and config/API impact;
UI-impacting changes in `InventarViewerApp` MUST include a screenshot or terminal
capture.
Rationale: branch protection and documented review gates are mandatory for controlled
integration.

Expand All @@ -105,6 +107,12 @@ cost.
- C# naming conventions (`PascalCase`, `camelCase`, `_camelCase`) and nullable
reference types MUST remain enabled.
- Toolchain baseline MUST be `.NET 10` with `LangVersion` set to `14.0`.
- `Directory.Build.props` MUST keep repo-wide `Version`, `AssemblyVersion`, and
`FileVersion` aligned as `Major.Minor.Patch.Build`. On numbered Spec-Kit
branches, `Minor` = numerically interpreted feature/branch number as
canonical PR number for versioning (`002` -> `2`), `Patch` = commit count in
that feature/PR branch after the current change is committed, and `Build` =
manual build counter incremented before every `dotnet build` or `dotnet test`.
- Runtime model MUST stay cross-platform: Windows Service (`AddWindowsService`),
systemd (`AddSystemd`), and launchd compatibility.
- Worker loop timing MUST remain `30_000ms` in debug and `86_400_000ms` in release,
Expand Down Expand Up @@ -179,4 +187,4 @@ be documented in the implementation plan's complexity tracking section.
Use `docs/project-statistics.md` for the living project-statistics ledger and
manual-effort baseline tracking.

**Version**: 2.3.0 | **Ratified**: 2026-03-08 | **Last Amended**: 2026-03-22
**Version**: 2.4.0 | **Ratified**: 2026-03-08 | **Last Amended**: 2026-03-27
12 changes: 11 additions & 1 deletion AGENTS.md
Original file line number Diff line number Diff line change
Expand Up @@ -39,6 +39,16 @@ Tests use MSTest (`[TestClass]`, `[TestMethod]`). Prefer descriptive test names
Recent history follows imperative subjects (for example: `Add ...`, `Update ...`, `Refine ...`). Continue with short, present-tense commit titles and narrow scope per commit.

`main` is protected: create a new branch for every feature/fix and merge changes through a pull request targeting `main`.
Branches may use either the existing topic form or the numbered Spec-Kit form `NNN-short-description` when the Spec-Kit workflow creates the branch.

## Build Versioning

- Repo-wide assembly version fields live in `Directory.Build.props` and MUST keep `Version`, `AssemblyVersion`, and `FileVersion` aligned for all projects.
- The scheme is `Major.Minor.Patch.Build`.
- `Minor` = current Spec-Kit feature/branch number, interpreted numerically as the canonical PR number for versioning (`002` -> `2`) and used immediately even before a GitHub PR exists.
- `Patch` = current commit count in that feature/PR branch after committing the current change.
- `Build` = manual build counter incremented by the bot before every `dotnet build` or `dotnet test`.
- Before any commit or push on a numbered Spec-Kit branch, the repo-wide version fields in `Directory.Build.props` MUST be aligned to this scheme.

PRs should include: purpose, touched projects, test evidence (commands run), and any config/API impact. For UI-related changes in `InventarViewerApp`, include screenshots or terminal captures.

Expand All @@ -49,7 +59,7 @@ PRs should include: purpose, touched projects, test evidence (commands run), and
- Maintain `docs/project-statistics.md` as the living statistics ledger for the repository.
- Update the file after each completed Spec-Kit implementation phase, after each agent-driven repository change, or when a refresh is explicitly requested.
- Each update must record branch or phase, observable work window, production/test/documentation line counts, main work packages, the conservative manual baseline of 80 manually created lines per workday across code, tests, and documentation, and the repo-specific Thorsten-Solo comparison baseline of 100 lines per workday for this native .NET codebase.
- When effort is converted into months, use explicit assumptions such as 21.5 workdays per month and, if applicable, 30 vacation days per year under a TVoeD-style calendar.
- When effort is converted into months, use explicit assumptions such as 21.5 workdays per month and, if applicable, 30 vacation days per year through calendar year 2026 and 31 vacation days per year from calendar year 2027 onward under a TVoeD-style 5-day-week calendar.
- When reporting acceleration, compare both manual references against visible Git active days and label the result as a blended repository speedup rather than a stopwatch measurement.
- When hour values are shown, convert the day-based estimates with the TVoeD working-day baseline of `7.8 hours` (`7h 48m`) per day.

Expand Down
12 changes: 11 additions & 1 deletion CLAUDE.md
Original file line number Diff line number Diff line change
Expand Up @@ -48,6 +48,16 @@ docfx docfx.json
- `main` is protected and must not receive direct feature commits.
- Create a new branch for each feature/fix/change.
- Merge to `main` only through a pull request with test evidence.
- Work branches may use either the existing topic naming or the numbered Spec-Kit form `NNN-short-description`.

## Repo Version Scheme

`Directory.Build.props` carries the repo-wide `Version`, `AssemblyVersion`, and `FileVersion` values for all projects using `Major.Minor.Patch.Build`:
- `Minor` = current Spec-Kit feature/branch number, interpreted numerically as the canonical PR number for versioning (`002` -> `2`) and used immediately even before a GitHub PR exists
- `Patch` = current commit count in that feature/PR branch (after committing the current change)
- `Build` = manual build counter incremented before every `dotnet build` or `dotnet test`

Align the three version fields in `Directory.Build.props` whenever a commit is created or the branch is updated on a numbered Spec-Kit branch, before pushing.

## Architecture Overview

Expand Down Expand Up @@ -128,6 +138,6 @@ InventarViewerApp (TUI) → queries InventarWorkerService API → persists in
- Maintain `docs/project-statistics.md` as the living statistics ledger for the repository.
- Update the file after each completed Spec-Kit implementation phase, after each agent-driven repository change, or when a refresh is explicitly requested.
- Each update must capture branch or phase, observable work window, production/test/documentation line counts, main work packages, the conservative manual baseline of 80 manually created lines per workday across code, tests, and documentation, and the repo-specific Thorsten-Solo comparison baseline of 100 lines per workday for this native .NET codebase.
- When effort is converted into months, use explicit assumptions such as 21.5 workdays per month and, if applicable, 30 vacation days per year under a TVoeD-style calendar.
- When effort is converted into months, use explicit assumptions such as 21.5 workdays per month and, if applicable, 30 vacation days per year through calendar year 2026 and 31 vacation days per year from calendar year 2027 onward under a TVoeD-style 5-day-week calendar.
- When reporting acceleration, compare both manual references against visible Git active days and label the result as a blended repository speedup rather than a stopwatch measurement.
- When hour values are shown, convert the day-based estimates with the TVoeD working-day baseline of `7.8 hours` (`7h 48m`) per day.
3 changes: 3 additions & 0 deletions Directory.Build.props
Original file line number Diff line number Diff line change
@@ -1,5 +1,8 @@
<Project>
<PropertyGroup>
<LangVersion>14.0</LangVersion>
<Version>1.2.1.0</Version>
<AssemblyVersion>1.2.1.0</AssemblyVersion>
<FileVersion>1.2.1.0</FileVersion>
</PropertyGroup>
</Project>
4 changes: 3 additions & 1 deletion GEMINI.md
Original file line number Diff line number Diff line change
Expand Up @@ -33,6 +33,8 @@ Das Projekt nutzt die Standard .NET-CLI.
- Der Branch `main` ist geschützt und darf nicht direkt für Feature-Commits genutzt werden.
- Für jedes Feature/Fix muss ein neuer Branch erstellt werden.
- Änderungen gelangen ausschließlich per Pull Request nach `main` (inkl. Testnachweis).
- Arbeits-Branches duerfen entweder die bestehende Themenbenennung oder die nummerierte Spec-Kit-Form `NNN-short-description` verwenden.
- `Directory.Build.props` fuehrt die repo-weiten Felder `Version`, `AssemblyVersion` und `FileVersion` als `Major.Minor.Patch.Build`; auf nummerierten Spec-Kit-Branches ist `Minor` die numerisch interpretierte Feature-/Branch-Nummer (`002` -> `2`), `Patch` die Commit-Anzahl im Feature-/PR-Branch nach dem aktuellen Commit und `Build` ein nur vor `dotnet build` oder `dotnet test` erhoehter Zaehler.

## 🏗 Architektur & Konventionen
- **Plattform-Support**: Implementiert als Windows Service, systemd (Linux) und launchd (macOS).
Expand Down Expand Up @@ -77,6 +79,6 @@ Das Projekt nutzt die Standard .NET-CLI.
- `docs/project-statistics.md` ist das fortlaufende Statistik-Register des Repositories.
- Die Datei muss nach jeder abgeschlossenen Spec-Kit-Implementierungsphase, nach jeder agentischen Änderung am Repository und auf explizite Anforderung aktualisiert werden.
- Jeder Eintrag muss Branch oder Phase, beobachtbares Arbeitsfenster, Produktions-, Test- und Doku-Zeilen, die wesentlichen Arbeitspakete, die konservative Handarbeits-Basis von 80 manuell erstellten Zeilen pro Arbeitstag ueber Code, Tests und Dokumentation hinweg sowie die repo-spezifische Thorsten-Solo-Vergleichsbasis von 100 Zeilen pro Arbeitstag fuer diese native .NET-Loesung enthalten.
- Wenn daraus Monatswerte abgeleitet werden, sind die Annahmen explizit zu nennen, zum Beispiel 21,5 Arbeitstage pro Monat und optional 30 Urlaubstage pro Jahr in einer TVoeD-aehnlichen Kalenderannahme.
- Wenn daraus Monatswerte abgeleitet werden, sind die Annahmen explizit zu nennen, zum Beispiel 21,5 Arbeitstage pro Monat sowie 30 Urlaubstage pro Jahr bis einschliesslich 2026 und 31 Urlaubstage pro Jahr ab 2027 in einer TVoeD-aehnlichen Kalenderannahme bei 5-Tage-Woche.
- Beschleunigungsangaben muessen beide Referenzen gegen sichtbare Git-Aktivtage stellen und ausdruecklich als repo-weiten Verdichtungsfaktor statt als Stoppuhrmessung kennzeichnen.
- Wenn Stundenwerte ausgewiesen werden, sind die Tageswerte mit der TVoeD-Arbeitszeit von `7,8 Stunden` bzw. `7 Stunden 48 Minuten` pro Arbeitstag umzurechnen.
40 changes: 36 additions & 4 deletions docs/project-statistics.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# Projektstatistik InventarWorkerService

Stand: 2026-03-25
Stand: 2026-03-27

## Zweck und Pflege

Expand Down Expand Up @@ -28,9 +28,10 @@ und auf explizite Anforderung fortgeschrieben.
Entwickler.
- Umrechnung in Zeitraeume:
durchschnittlich 21.5 Arbeitstage pro Monat (Mittel aus 21-22 Arbeitstagen);
unter TVoeD-Annahme mit 30 Urlaubstagen pro Jahr ergeben sich
`21.5 * 12 - 30 = 228` produktive Arbeitstage pro Jahr bzw.
durchschnittlich 19.0 produktive Tage pro Kalendermonat.
unter TVoeD-Annahme mit 30 Urlaubstagen pro Jahr bis einschliesslich 2026 und
31 Urlaubstagen pro Jahr ab 2027 (jeweils 5-Tage-Woche) ergeben sich
`21.5 * 12 - 30 = 228` produktive Arbeitstage pro Jahr fuer Zeitraeume bis
2026 bzw. `21.5 * 12 - 31 = 227` produktive Arbeitstage pro Jahr ab 2027.
- TVoeD-Stundenbasis in dieser Datei:
`7.8 Stunden` bzw. `7 Stunden 48 Minuten` pro Arbeitstag fuer zusaetzliche
Stundenumrechnungen.
Expand Down Expand Up @@ -95,6 +96,7 @@ und auf explizite Anforderung fortgeschrieben.

| Branch/Ref | Letzte sichtbare Aktivitaet | Einordnung |
|---|---|---|
| `002-spec-kit-versioning` | 2026-03-27 | Arbeitsbranch fuer repo-weite Versionslogik auf Basis nummerierter Spec-Kit-Branches |
| `main` | 2026-03-08 | Integrationsbranch |
| `INV-7` | sichtbar lokal | lokaler Arbeitsbranch |
| `chore/constitution-2.1-compliance` | sichtbar lokal | lokaler Governance-Branch |
Expand Down Expand Up @@ -200,6 +202,34 @@ und auf explizite Anforderung fortgeschrieben.
- 32.2 Arbeitstage fuer ein 3er-Team (+20 % Koordination), entsprechend ca.
1.7 TVoeD-Kalendermonaten

### 5. Branch `002-spec-kit-versioning`

- Status: in Arbeit auf Feature-Branch `002-spec-kit-versioning`
- Beobachtbarer Zeitraum: 2026-03-27 bis 2026-03-27
- Commit-Bild: aktueller Working-Tree-Aenderungssatz vor dem ersten Branch-Commit
- Grundlegende Arbeiten: nummerierte Spec-Kit-Branches als zulaessige
Arbeitsform ergaenzt, repo-weite Versionslogik in `Directory.Build.props`
eingefuehrt und die gemeinsame Agent-/Constitution-Governance darauf
synchronisiert
- Git-/Arbeitsbaum-Aenderungsvolumen fuer den aktuellen Aenderungssatz:
- Produktionscode: 0 Zeilen
- Testcode: 0 Zeilen
- Dokumentation und Governance: 38 Zeilen netto
- Build-/Versionsmetadaten: 3 Zeilen in `Directory.Build.props`
- Konservative Handarbeits-Basis fuer Code und Dokumentation:
- 41 Zeilen netto gesamt
- 0.5 Arbeitstage fuer einen erfahrenen Entwickler
- 3.9 Stunden auf TVoeD-Basis (`0.5 * 7.8`)
- 0.0 Arbeitsmonate brutto bzw. 0.0 TVoeD-Kalendermonate
- Thorsten-Solo-Referenz:
- 0.4 Arbeitstage
- 3.1 Stunden auf TVoeD-Basis (`0.4 * 7.8`)
- 0.0 Arbeitsmonate brutto bzw. 0.0 TVoeD-Kalendermonate
- Blended Repository Speedup gegen sichtbare 1 Git-Aktivtag fuer diesen
Aenderungssatz:
- 0.5x gegen die konservative 80-Zeilen-Referenz
- 0.4x gegen die Thorsten-Solo-Referenz mit 100 Zeilen pro Arbeitstag

## Einordnung der KI-/Spec-Kit-Wirkung

- Die beobachtbare manuelle Gesamtbasis liegt bereits bei 17522 Zeilen
Expand All @@ -224,6 +254,8 @@ und auf explizite Anforderung fortgeschrieben.

| Datum | Ausloeser | Eintrag |
|---|---|---|
| 2026-03-27 | TVoeD-Urlaubsregel ab 2027 nachgezogen | Die Statistik- und Agentenmethodik wurde auf die neue Stichtagsregel umgestellt: 30 Urlaubstage pro Jahr gelten nur bis einschliesslich 2026, ab dem Kalenderjahr 2027 werden unter TVoeD-Annahme 31 Urlaubstage bei unveraenderter 5-Tage-Woche verwendet. |
| 2026-03-27 | Branch `002-spec-kit-versioning` | Repo-weite Versionslogik fuer nummerierte Spec-Kit-Branches eingefuehrt: `Directory.Build.props` traegt jetzt `Version`, `AssemblyVersion` und `FileVersion`; die gemeinsame Agent-Governance und die Constitution wurden auf `Minor = Spec-Kit-Feature-/Branch-Nummer als kanonische PR-Nummer` synchronisiert. |
| 2026-03-21 | Erstanlage | Basisstatistik fuer `InventarWorkerService` angelegt; Entwicklungsphasen aus der Git-Historie rekonstruiert und Constitution, Templates sowie Agent-Dateien auf Pflegepflicht synchronisiert. |
| 2026-03-22 | Methodik-Update fuer Handarbeits-Schaetzung | Die Statistik rechnet Handarbeit jetzt auf Basis von Produktionscode, Testcode und Dokumentation gemeinsam; zusaetzlich werden Monatswerte auf Basis von 21.5 Arbeitstagen pro Monat sowie TVoeD-Kalenderwerte mit 30 Urlaubstagen pro Jahr ausgewiesen. |
| 2026-03-22 | Governance-Synchronisierung zur Statistiklogik | Constitution sowie die gemeinsamen Agent-Hinweise (`AGENTS.md`, `CLAUDE.md`, `GEMINI.md`, `.github/copilot-instructions.md`) wurden auf die neue Statistiklogik synchronisiert: Handarbeits-Schaetzung umfasst nun Code, Tests und Dokumentation gemeinsam; Monats- und TVoeD-Annahmen muessen explizit genannt werden. |
Expand Down
Loading