Document Lastenheft processing order

Lastenheft_Abarbeitungsreihenfolge.md

@@ -0,0 +1,73 @@
+# Lastenheft-Abarbeitungsreihenfolge / Requirements Processing Order
+
+Stand: 2026-06-19
+
+## Zweck / Purpose
+
+Diese Datei haelt die sinnvolle Abarbeitungsreihenfolge der vorhandenen
+Lastenhefte fest. Sie ist eine Vorbereitung fuer spaetere Spec-Kit-Laeufe und
+startet selbst keinen Lauf. Die Reihenfolge ist so gewaehlt, dass
+Governance-Baselines vor grossen Codeaenderungen geklaert werden, danach die
+Terminal.Gui-Migration gebuendelt laeuft und datenbanknahe Erweiterungen erst
+nach den stabilisierenden Vorarbeiten folgen.
+
+This file records the proposed processing order for the existing requirements
+files. It prepares later Spec Kit runs and does not start a run by itself. The
+order puts governance baselines before large code changes, then groups the
+Terminal.Gui migration work, and schedules database-facing extensions after
+the stabilizing preparation work.
+
+## Aktive Reihenfolge / Active Order
+
+| Rang | Lastenheft | Naechster Status / Next Status | Begruendung / Rationale |
+|---:|---|---|---|
+| 1 | `Lastenheft_Secure-Development-Hardening.md` | Als erstes spezifizieren / specify first | Sicherheits-, Architektur- und Evidenzregeln bilden die Basis fuer alle folgenden Laeufe.<br>Security, architecture, and evidence rules are the baseline for all later runs. |
+| 2 | `Lastenheft_Didactic-Inline-Code-Comment-Hardening.md` | Nach Security-Hardening spezifizieren / specify after security hardening | Didaktische Kommentarregeln sollten vor den groesseren Migrations- und Datenbankaenderungen stabil sein.<br>Didactic comment rules should be stable before larger migration and database changes. |
+| 3 | `Lastenheft_TG_Elmish_Entscheidung.md` | Vor Terminal.Gui-Codeaenderungen entscheiden / decide before Terminal.Gui code changes | Die Elmish-Entscheidung beeinflusst alle Terminal.Gui-v2-Migrationslaeufe und sollte nicht mehrfach getroffen werden.<br>The Elmish decision affects all Terminal.Gui v2 migration runs and should not be made repeatedly. |
+| 4 | `Lastenheft_TG_Migration_InventarViewerApp.md` | Erste operative TUI-Migration / first operative TUI migration | Der Viewer ist die fachlich komplexeste TUI-Flaeche und liefert Muster fuer MainLoop-, Dialog- und Testanpassungen.<br>The viewer is the most complex TUI surface and creates patterns for MainLoop, dialog, and test changes. |
+| 5 | `Lastenheft_TG_Migration_CtrlWorkerServiceCmdlet.md` | Nach Viewer-Muster migrieren / migrate after viewer pattern | Das Cmdlet hat PowerShell- und Terminal.Gui-Lebenszyklusgrenzen, profitiert aber von den Viewer-Erkenntnissen.<br>The cmdlet has PowerShell and Terminal.Gui lifecycle boundaries, but benefits from the viewer findings. |
+| 6 | `Lastenheft_TG_Migration_CtrlWorkerServiceApp.md` | Letzte operative TUI-Migration / final operative TUI migration | Die Service-App ist kleiner und kann die vorher festgelegten v2- und Elmish-Entscheidungen uebernehmen.<br>The service app is smaller and can reuse the v2 and Elmish decisions from the earlier runs. |
+| 7 | `Lastenheft_A11Y_TUI_API.md` | Nach TUI-Migration spezifizieren / specify after TUI migration | A11Y-Pruefungen fuer TUI und API sind belastbarer, wenn die Ziel-TUI-API bereits stabilisiert ist.<br>A11y checks for TUI and API are more reliable after the target TUI API is stabilized. |
+| 8 | `Lastenheft_Statistik_View_Lesemethoden.md` | Vor Interface-Schnitt spezifizieren / specify before interface cut | Die relationalen View-Lesemethoden erweitern die tatsaechliche Service-Oberflaeche und sollten vor dem Interface feststehen.<br>The relational view read methods extend the actual service surface and should be known before the interface is cut. |
+| 9 | `Lastenheft_IDbService_Interface.md` | Nach gereiftem relationalem Umfang spezifizieren / specify after relational scope matures | Das Interface sollte die bereinigten SQLite/PostgreSQL- und Statistik-Lesepfade abbilden, nicht einen Zwischenstand.<br>The interface should reflect the cleaned SQLite/PostgreSQL and statistics read paths, not an intermediate state. |
+| 10 | `Lastenheft_MongoDB_Paritaet.md` | Nach relationalem Interface pruefen / review after relational interface | MongoDB-Paritaet ist ein eigener Backend-Schnitt und sollte erst nach relationaler API-Klaerung geschnitten werden.<br>MongoDB parity is its own backend boundary and should be scoped after the relational API is clear. |
+
+## Abgeschlossen oder nicht operativ / Completed or Non-Operative
+
+| Lastenheft | Einordnung / Classification | Begruendung / Rationale |
+|---|---|---|
+| `Lastenheft_PostgreSQL_Implementation.001-pgsql-paritaet.md` | Abgeschlossen und branch-suffig archiviert / completed and archived with branch suffix | Der Lauf `001-pgsql-paritaet` ist umgesetzt und in `specs/001-pgsql-paritaet/` dokumentiert.<br>The `001-pgsql-paritaet` run is implemented and documented in `specs/001-pgsql-paritaet/`. |
+| `Lastenheft_SQLite_ViewQuery_Bugfix.md` | Bereits im aktuellen Code geloest / already resolved in current code | Die betroffenen View-Abfragen verwenden im aktuellen `SqliteDbService` die View-Namen mit `ORDER BY Name`.<br>The affected view queries in the current `SqliteDbService` use the view names with `ORDER BY Name`. |
+| `Lastenheft_Constitution_Change.md` | Durch aktuelle Governance ueberholt / superseded by current governance | Die Kernpunkte sind durch Constitution, Agent-Guidance und Spec-Kit-Preset-Governance aktueller abgedeckt.<br>The main points are covered more up to date by the constitution, agent guidance, and Spec Kit preset governance. |
+| `Lastenheft_TerminalGui_Migration.md` | Uebersicht, kein einzelner Lauf / overview, not a single run | Die operative Arbeit ist in Entscheidung und drei konkrete TUI-Migrationslastenhefte aufgeteilt.<br>The operative work is split into the decision file and three concrete TUI migration requirements files. |
+
+## Nutzungsregel / Usage Rule
+
+- Vor einem spaeteren Spec-Kit-Lauf wird das erste aktive, noch nicht
+  abgearbeitete Lastenheft aus der Tabelle verwendet.
+- Ein Lauf soll nur dann mehrere Lastenhefte zusammenfassen, wenn die Kopplung
+  fachlich begruendet und vor dem Start dokumentiert ist.
+- Nach Abschluss eines dedizierten Feature-Branches wird das gelieferte
+  Lastenheft gemaess Repository-Regel mit Branch-Suffix umbenannt:
+  `Lastenheft_<Thema>.<feature-branch>.md`.
+- Wenn sich Status oder Reihenfolge aendern, wird diese Datei vor dem naechsten
+  Spec-Kit-Lauf aktualisiert.
+
+- Before a later Spec Kit run, use the first active requirements file that has
+  not yet been processed.
+- A run should combine multiple requirements files only when the coupling is
+  justified by the domain and documented before the start.
+- After a dedicated feature branch is completed, rename the delivered
+  requirements file according to the repository rule:
+  `Lastenheft_<Topic>.<feature-branch>.md`.
+- If status or order changes, update this file before the next Spec Kit run.
+
+## Pflegepruefung / Maintenance Check
+
+Jedes der aktuell bekannten vierzehn Lastenhefte steht in dieser Datei genau
+einmal in der aktiven Reihenfolge oder in der Status-Tabelle. Neue Lastenhefte
+werden ergaenzt, sobald sie als spaeterer Spec-Kit-Input vorgesehen sind.
+
+Each of the fourteen currently known requirements files appears exactly once in
+the active order or in the status table. Add new requirements files as soon as
+they are intended as input for a later Spec Kit run.

README.md

@@ -1137,6 +1137,10 @@ generated agent/command files when presets are project policy; do not commit
 Neue Features in diesem Workspace werden nach dem **Specification-Driven Development (SDD)**-Workflow entwickelt.
 Der Workflow verwendet das `speckit`-CLI-Tool (GitHub Copilot Skill).
 
+Die priorisierte Reihenfolge der vorbereiteten Lastenhefte fuer spaetere
+Spec-Kit-Laeufe steht in
+[`Lastenheft_Abarbeitungsreihenfolge.md`](Lastenheft_Abarbeitungsreihenfolge.md).
+
 Schritte für ein neues Feature:
 
 1. **Spezifikation erstellen** — `speckit specify "Feature-Name"` → `specs/{branch}/spec.md`
@@ -1155,6 +1159,10 @@ Alle Spec-Artefakte werden im Branch-Verzeichnis `specs/{branch}/` gespeichert u
 New features in this workspace are developed following the **Specification-Driven Development (SDD)** workflow.
 The workflow uses the `speckit` CLI tool (GitHub Copilot Skill).
 
+The prioritized order of prepared requirements files for later Spec Kit runs is
+recorded in
+[`Lastenheft_Abarbeitungsreihenfolge.md`](Lastenheft_Abarbeitungsreihenfolge.md).
+
 Steps for a new feature:
 
 1. **Create specification** — `speckit specify "Feature Name"` → `specs/{branch}/spec.md`

docs/README.md

@@ -617,6 +617,16 @@ markiert und eine `Commit Message` eingegeben wurden.
 - Empfohlene A11Y-Toolchain fuer DocFX-basierte Doku: Node 24 LTS, `npm`, Playwright, `@axe-core/playwright` und `lynx`.
 - Recommended A11y toolchain for DocFX-based documentation: Node 24 LTS, `npm`, Playwright, `@axe-core/playwright`, and `lynx`.
 
+## Spec-Kit-Lastenhefte / Spec Kit Requirements Files
+
+Die priorisierte Reihenfolge der vorbereiteten Lastenhefte fuer spaetere
+Spec-Kit-Laeufe steht in
+[`Lastenheft_Abarbeitungsreihenfolge.md`](../Lastenheft_Abarbeitungsreihenfolge.md).
+
+The prioritized order of prepared requirements files for later Spec Kit runs is
+recorded in
+[`Lastenheft_Abarbeitungsreihenfolge.md`](../Lastenheft_Abarbeitungsreihenfolge.md).
+
 ## Abschlusspruefung fuer Bilingualitaet und A11Y
 
 - Lernrelevante Dokumente und Guides muessen fuer Auszubildende nachvollziehbar in Deutsch und Englisch auf CEFR-B2-Niveau vorliegen.

docs/project-statistics.md

@@ -1,6 +1,6 @@
 # Projektstatistik InventarWorkerService
 
-Stand: 2026-06-18 (aktualisiert inklusive Spec-Kit-Preset-Governance, Constitution v1.13.0, didaktischer Inline-Code-Kommentar-Haertung und Claude-Code-Review-Bot-Freigabe fuer Release-Please-PRs)
+Stand: 2026-06-19 (aktualisiert inklusive Spec-Kit-Preset-Governance, Constitution v1.13.0, didaktischer Inline-Code-Kommentar-Haertung, Claude-Code-Review-Bot-Freigabe fuer Release-Please-PRs und Lastenheft-Abarbeitungsreihenfolge fuer spaetere Spec-Kit-Laeufe)
 
 ## Zweck und Pflege
 
@@ -292,6 +292,7 @@ und auf explizite Anforderung fortgeschrieben.
 | 2026-05-05 | Spec-Kit-Preset-Governance auf Constitution v1.13.0 synchronisiert | Nach der Integration der sechs Spec-Kit-Presets (`a11y-governance`, `agent-parity-governance`, `architecture-governance`, `cross-platform-governance`, `isaqb-architecture-governance`, `security-governance`) wurden `constitution.md`, `.specify/memory/constitution.md`, die Spec-Kit-Plan-/Spec-/Tasks-/Command-Templates sowie die vier Agentenflaechen synchronisiert. Neu erfasst sind iSAQB/arc42-Architekturevidenz unter `docs/architecture/`, A11Y-Evidenz unter `docs/accessibility/`, sprachgetaggte Markdown-Codebloecke, CRA-/MSL-/Secure-Coding-Evidenz und Cross-Platform-/Agent-Parity-Templates. Sichtbares Zusatzvolumen vor dieser Ledger-Zeile: ca. `+1269` Dokumentations-/Template-Zeilen netto, `0` Produktionscode-Zeilen und `0` Testcode-Zeilen. Konservative Manualreferenz: `1269 / 80 = 15.9` Arbeitstage bzw. `123.8` Stunden; Thorsten-Solo-Referenz: `1269 / 100 = 12.7` Arbeitstage bzw. `99.0` Stunden; sichtbares Arbeitsfenster: 1 agentische Governance-Sitzung am 2026-05-05. |
 | 2026-06-05 | Didaktische Inline-Code-Kommentar-Haertung vorbereitet | `Lastenheft_Didactic-Inline-Code-Comment-Hardening.md` wurde als Specify-ready Intake fuer eine moderate Inline-Kommentar-Haertung angelegt. Der Lauf soll Service-, API-, Persistenz-, Cross-Platform-, TUI- und Test-Helfer-Flows pruefen, ohne Runtime-Verhalten, Datenbank-/API-/TUI-Funktionen oder Architektur zu veraendern. `AGENTS.md`, `CLAUDE.md`, `GEMINI.md` und `.github/copilot-instructions.md` halten nun fest, dass neue oder geaenderte nicht-triviale Logik auf didaktischen Kommentarbedarf geprueft wird und Kommentare Warum, Trade-off, Randbedingung, Plattformgrenze oder Proof-Grenze erklaeren muessen. Validierung: Doku-/Guidance-Suchcheck und `git diff --check`; keine Build-/Test-/DocFX-Ausfuehrung, weil nur Lastenheft, Guidance und Statistik geaendert wurden. |
 | 2026-06-18 | Claude-Code-Review fuer Release-Please-PRs freigegeben | Der automatische `Claude Code Review`-Workflow blockierte Release-Please-PRs, weil `github-actions[bot]` als nicht-menschlicher Actor nicht in `allowed_bots` freigegeben war. `.github/workflows/claude-code-review.yml` erlaubt nun gezielt den Bot-Slug `github-actions`, ohne alle Bots per Wildcard zuzulassen. Sichtbares Zusatzvolumen: `0` Produktionscode-Zeilen, `0` Testcode-Zeilen, ca. `+3` Workflow-Konfigurationszeilen und diese Ledger-Fortschreibung. Konservative Manualreferenz: grob `4 / 80 = 0.1` Arbeitstage bzw. `0.4` Stunden; Thorsten-Solo-Referenz: `4 / 100 = 0.0` Arbeitstage bzw. `0.3` Stunden; sichtbares Arbeitsfenster: 1 kurze Agentensitzung am 2026-06-18. |
+| 2026-06-19 | Lastenheft-Abarbeitungsreihenfolge fuer spaetere Spec-Kit-Laeufe dokumentiert | `Lastenheft_Abarbeitungsreihenfolge.md` wurde als dauerhaft einsehbares Root-Artefakt angelegt. Es ordnet die offenen Lastenhefte fuer spaetere Spec-Kit-Laeufe, markiert bereits geloeste oder ueberholte Lastenhefte separat und verlinkt die Reihenfolge aus `README.md` sowie `docs/README.md`. Diese Runde war reine Dokumentationsarbeit ohne Produktions- oder Testcodeaenderung; die Validierung erfolgt ueber Markdown-Suchchecks und `git diff --check`, ein Build-/Test-/DocFX-Lauf ist fuer diese reine Ordnungsdokumentation nicht erforderlich. Sichtbares Zusatzvolumen vor dieser Ledger-Zeile: ca. `+91` Dokumentationszeilen netto. Konservative Manualreferenz: grob `91 / 80 = 1.1` Arbeitstage bzw. `8.9` Stunden; Thorsten-Solo-Referenz: `91 / 100 = 0.9` Arbeitstage bzw. `7.1` Stunden; sichtbares Arbeitsfenster: 1 kurze Agentensitzung am 2026-06-19. |
 
 ## Gesamtstatistik