From f5fa63e963b8e2fb65e35e9307f55a97d5e718d2 Mon Sep 17 00:00:00 2001
From: Thorsten Hindermann <hindermath@googlemail.com>
Date: Fri, 27 Mar 2026 11:20:02 +0100
Subject: [PATCH 1/2] Align repo versioning with Spec-Kit branch numbering

---
 .github/copilot-instructions.md |  8 ++++++++
 .specify/memory/constitution.md | 24 ++++++++++++++++--------
 AGENTS.md                       | 10 ++++++++++
 CLAUDE.md                       | 10 ++++++++++
 Directory.Build.props           |  3 +++
 GEMINI.md                       |  2 ++
 docs/project-statistics.md      | 32 +++++++++++++++++++++++++++++++-
 7 files changed, 80 insertions(+), 9 deletions(-)

diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md
index bcd2c499..3dda7f8d 100644
--- a/.github/copilot-instructions.md
+++ b/.github/copilot-instructions.md
@@ -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
 
diff --git a/.specify/memory/constitution.md b/.specify/memory/constitution.md
index fd00edeb..907c40c5 100644
--- a/.specify/memory/constitution.md
+++ b/.specify/memory/constitution.md
@@ -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:
@@ -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.
 
@@ -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,
@@ -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
diff --git a/AGENTS.md b/AGENTS.md
index c3620c6d..82d684db 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -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.
 
diff --git a/CLAUDE.md b/CLAUDE.md
index 37c97d49..de41170e 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -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
 
diff --git a/Directory.Build.props b/Directory.Build.props
index 3d76fa82..1e89d95d 100644
--- a/Directory.Build.props
+++ b/Directory.Build.props
@@ -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>
diff --git a/GEMINI.md b/GEMINI.md
index c6f1b03b..ace54ccd 100644
--- a/GEMINI.md
+++ b/GEMINI.md
@@ -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).
diff --git a/docs/project-statistics.md b/docs/project-statistics.md
index fdc95c96..940ca232 100644
--- a/docs/project-statistics.md
+++ b/docs/project-statistics.md
@@ -1,6 +1,6 @@
 # Projektstatistik InventarWorkerService
 
-Stand: 2026-03-25
+Stand: 2026-03-27
 
 ## Zweck und Pflege
 
@@ -95,6 +95,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 |
@@ -200,6 +201,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
@@ -224,6 +253,7 @@ und auf explizite Anforderung fortgeschrieben.
 
 | Datum | Ausloeser | Eintrag |
 |---|---|---|
+| 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. |

From 0ca4ecfbe3794f37d6baac509ad554a936444938 Mon Sep 17 00:00:00 2001
From: Thorsten Hindermann <hindermath@googlemail.com>
Date: Fri, 27 Mar 2026 12:06:29 +0100
Subject: [PATCH 2/2] Update TVoeD vacation assumption for 2027

---
 AGENTS.md                  | 2 +-
 CLAUDE.md                  | 2 +-
 GEMINI.md                  | 2 +-
 docs/project-statistics.md | 8 +++++---
 4 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/AGENTS.md b/AGENTS.md
index 82d684db..41fde2be 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -59,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.
 
diff --git a/CLAUDE.md b/CLAUDE.md
index de41170e..6aaa5683 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -138,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.
diff --git a/GEMINI.md b/GEMINI.md
index ace54ccd..c1919b21 100644
--- a/GEMINI.md
+++ b/GEMINI.md
@@ -79,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.
diff --git a/docs/project-statistics.md b/docs/project-statistics.md
index 940ca232..35a667ea 100644
--- a/docs/project-statistics.md
+++ b/docs/project-statistics.md
@@ -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.
@@ -253,6 +254,7 @@ 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. |