diff --git a/Lastenheft_Abarbeitungsreihenfolge.md b/Lastenheft_Abarbeitungsreihenfolge.md new file mode 100644 index 0000000..4a45d24 --- /dev/null +++ b/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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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`.
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.
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.
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_..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_..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. diff --git a/README.md b/README.md index bddecdd..45ce683 100644 --- a/README.md +++ b/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` diff --git a/docs/README.md b/docs/README.md index afdd028..605f2c4 100644 --- a/docs/README.md +++ b/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. diff --git a/docs/project-statistics.md b/docs/project-statistics.md index d5e306f..6fa3329 100644 --- a/docs/project-statistics.md +++ b/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