diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md index d4f3589..cda42b4 100644 --- a/.github/copilot-instructions.md +++ b/.github/copilot-instructions.md @@ -86,6 +86,7 @@ Fixed grid: columns `A`–`G` (7 columns), 21 rows, 147 total cells. Cell input ### Documentation & language - All code comments and documentation must be **bilingual: German block first, English block second**, both at CEFR B2 readability. +- Large normative documents such as `Pflichtenheft*.md` and `Lastenheft*.md` may use a synchronized English sidecar with suffix `.EN.md` instead of an oversized inline-bilingual file; the German version remains canonical unless explicitly marked otherwise. - Public APIs require complete XML docs (``, ``, ``, `` where applicable). Do not suppress CS1591 globally — missing XML docs are treated as build errors. - When API signatures or XML comments change, regenerate DocFX output in the same PR. @@ -106,7 +107,28 @@ Fixed grid: columns `A`–`G` (7 columns), 21 rows, 147 total cells. Cell input - 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. - Within the `## Fortschreibungsprotokoll` table, keep entries in strict chronological order: oldest entry at the top, newest and most recently added entry at the bottom; entries with the same date keep their insertion order. +- Keep a final top-level `## Gesamtstatistik` block as the last section of `docs/project-statistics.md`; do not append later top-level sections after it. +- Inside that final `## Gesamtstatistik` block, maintain compact ASCII-only trend diagrams directly below the textual overall summary and refresh them with every statistics update; cover at least the artifact mix, the documented branch/phase curves, the documented acceleration factors from agentic AI plus Spec-Kit/SDD support, and a direct comparison between experienced-developer effort, Thorsten-solo effort, and the visible AI-assisted delivery window. +- Keep each short CEFR-B2 explanatory text directly adjacent to its matching ASCII diagram group. +- When the data benefits from progression across an X-axis, add simple ASCII X/Y charts as a second visualization layer; keep them approximate, readable in plain Markdown, and explained in CEFR-B2 language. +- Keep the statistics section plain-text friendly for Braille displays, screen readers, and text browsers; diagrams and explanations must stay understandable without relying on color or visual layout alone. +- When DocFX content, documentation navigation, or API presentation changes, validate representative `_site/` pages through a text-oriented review path, preferably with a local Playwright accessibility snapshot. +- Treat every successful `docfx` regeneration as requiring the matching text-oriented A11y smoke check in the same work item. - 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 125 lines per workday for this Pascal-derived port. -- 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. + +## Inclusion & Accessibility + +- Follow `Programmierung #include`: learner-facing guides, statistics, and generated HTML/API documentation must stay usable on Braille displays, with screen readers, and in text browsers. +- Prefer semantic headings, lists, tables, and ASCII/text-first diagrams; do not encode essential meaning only through color, layout, or pointer-only affordances. +- Treat WCAG 2.2 conformance level AA as the concrete review baseline for generated HTML documentation, especially for page language, bypass blocks, keyboard focus visibility, non-text contrast, and readable landmark structure. +- If `docfx` output is regenerated, follow it with a text-oriented accessibility review, preferably with Playwright + `@axe-core/playwright` and a `lynx` cross-check. +- Recommended A11y toolchain for DocFX-based repos: Node 24 LTS, `npm`, Playwright, `@axe-core/playwright`, and `lynx`. +- Treat bilingual CEFR-B2 delivery and the documented A11Y proof path as formal completion criteria for learner-facing documentation and active requirement artifacts. + +## Shared Parent Guidance + +- The shared parent file `/Users/thorstenhindermann/RiderProjects/AGENTS.md` intentionally stores only repo-spanning baseline rules. +- Keep repository-specific build, test, workflow, architecture, and feature guidance in this repository's own files; when both layers exist, the repository-local files are the more specific authority. diff --git a/AGENTS.md b/AGENTS.md index 8bd58a0..4b9cdf9 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -34,6 +34,7 @@ Use xUnit (`Microsoft.NET.Test.Sdk`, `xunit`, `coverlet.collector`). Name test f ## Documentation & Language Guidelines - Documentation and didactic comments must be bilingual: German block first, English block second. - Both language blocks should target CEFR B2 readability for trainees. +- Large normative documents such as `Pflichtenheft*.md` and `Lastenheft*.md` may use a synchronized English sidecar with suffix `.EN.md` instead of an oversized inline-bilingual file; the German version remains canonical unless explicitly marked otherwise. - Public APIs must include complete XML documentation (``, ``, ``, `` where applicable). - Do not globally suppress CS1591; missing public XML docs must be fixed. - If API signatures or XML comments change, regenerate DocFX output in the same change. @@ -65,7 +66,28 @@ For contributions: - 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. - Within the `## Fortschreibungsprotokoll` table, keep entries in strict chronological order: oldest entry at the top, newest and most recently added entry at the bottom; entries with the same date keep their insertion order. +- Keep a final top-level `## Gesamtstatistik` block as the last section of `docs/project-statistics.md`; do not append later top-level sections after it. +- Inside that final `## Gesamtstatistik` block, maintain compact ASCII-only trend diagrams directly below the textual overall summary and refresh them with every statistics update; cover at least the artifact mix, the documented branch/phase curves, the documented acceleration factors from agentic AI plus Spec-Kit/SDD support, and a direct comparison between experienced-developer effort, Thorsten-solo effort, and the visible AI-assisted delivery window. +- Keep each short CEFR-B2 explanation directly adjacent to its matching ASCII diagram group. +- When progression across an X-axis improves comprehension, add simple ASCII X/Y charts as a second visualization layer; keep them approximate, readable in plain Markdown, and explained in CEFR-B2 language. +- Keep the statistics section plain-text friendly for Braille displays, screen readers, and text browsers; diagrams and explanations must not rely on color or visual layout alone. +- When DocFX content, documentation navigation, or API presentation changes, validate representative `_site/` pages through a text-oriented review path, preferably with a local Playwright accessibility snapshot. +- Treat every successful `docfx` regeneration as requiring the matching text-oriented A11y smoke check in the same work item. - 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 125 lines per workday for this Pascal-derived port. - 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. + +## Inclusion & Accessibility + +- Follow `Programmierung #include`: learner-facing guides, statistics, and generated HTML/API documentation must stay usable on Braille displays, with screen readers, and in text browsers. +- Prefer semantic headings, lists, tables, and ASCII/text-first diagrams; do not encode essential meaning only through color, layout, or pointer-only affordances. +- Treat WCAG 2.2 conformance level AA as the concrete review baseline for generated HTML documentation, especially for page language, bypass blocks, keyboard focus visibility, non-text contrast, and readable landmark structure. +- If `docfx` output is regenerated, follow it with a text-oriented accessibility review, preferably with Playwright + `@axe-core/playwright` and a `lynx` cross-check. +- Recommended A11y toolchain for DocFX-based repos: Node 24 LTS, `npm`, Playwright, `@axe-core/playwright`, and `lynx`. +- Treat bilingual CEFR-B2 delivery and the documented A11Y proof path as formal completion criteria for learner-facing documentation and active requirement artifacts. + +## Shared Parent Guidance + +- The shared parent file `/Users/thorstenhindermann/RiderProjects/AGENTS.md` intentionally stores only repo-spanning baseline rules. +- Keep repository-specific build, test, workflow, architecture, and feature guidance in this repository's own files; when both layers exist, the repository-local files are the more specific authority. diff --git a/CLAUDE.md b/CLAUDE.md index 6cf642a..e253d9f 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -96,6 +96,7 @@ Governed by `.editorconfig`: - Documentation and didactic comments must be bilingual: German first, English second. - Write both language blocks at CEFR B2 readability so trainees can follow the codebase. +- Large normative documents such as `Pflichtenheft*.md` and `Lastenheft*.md` may use a synchronized English sidecar with suffix `.EN.md` instead of an oversized inline-bilingual file; the German version remains canonical unless explicitly marked otherwise. - Public API changes must include complete XML docs (``, ``, ``, `` where applicable). - Do not suppress CS1591 globally; missing public XML docs are treated as errors. @@ -119,7 +120,28 @@ Governed by `.editorconfig`: - 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. - Within the `## Fortschreibungsprotokoll` table, keep entries in strict chronological order: oldest entry at the top, newest and most recently added entry at the bottom; entries with the same date keep their insertion order. +- Keep a final top-level `## Gesamtstatistik` block as the last section of `docs/project-statistics.md`; no later top-level section should follow it. +- Inside that final `## Gesamtstatistik` block, maintain compact ASCII-only trend diagrams directly below the textual overall summary and refresh them together with every statistics update; cover at least the artifact mix, the documented branch/phase curves, the documented acceleration factors from agentic AI plus Spec-Kit/SDD support, and a direct comparison between experienced-developer effort, Thorsten-solo effort, and the visible AI-assisted delivery window. +- Keep each short CEFR-B2 explanation directly adjacent to its matching ASCII diagram group. +- When the data benefits from progression across an X-axis, add simple ASCII X/Y charts as a second visualization layer; keep them approximate, readable in plain Markdown, and explained in CEFR-B2 language. +- Keep the statistics section plain-text friendly for Braille displays, screen readers, and text browsers; diagrams and explanations must stay understandable without relying on color or visual layout alone. +- When DocFX content, documentation navigation, or API presentation changes, validate representative `_site/` pages through a text-oriented review path, preferably with a local Playwright accessibility snapshot. +- Treat every successful `docfx` regeneration as requiring the matching text-oriented A11y smoke check in the same work item. - 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 125 lines per workday for this Pascal-derived port. - 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. + +## Inclusion & Accessibility + +- Follow `Programmierung #include`: learner-facing guides, statistics, and generated HTML/API documentation must stay usable on Braille displays, with screen readers, and in text browsers. +- Prefer semantic headings, lists, tables, and ASCII/text-first diagrams; do not encode essential meaning only through color, layout, or pointer-only affordances. +- Treat WCAG 2.2 conformance level AA as the concrete review baseline for generated HTML documentation, especially for page language, bypass blocks, keyboard focus visibility, non-text contrast, and readable landmark structure. +- If `docfx` output is regenerated, follow it with a text-oriented accessibility review, preferably with Playwright + `@axe-core/playwright` and a `lynx` cross-check. +- Recommended A11y toolchain for DocFX-based repos: Node 24 LTS, `npm`, Playwright, `@axe-core/playwright`, and `lynx`. +- Treat bilingual CEFR-B2 delivery and the documented A11Y proof path as formal completion criteria for learner-facing documentation and active requirement artifacts. + +## Shared Parent Guidance + +- The shared parent file `/Users/thorstenhindermann/RiderProjects/AGENTS.md` intentionally stores only repo-spanning baseline rules. +- Keep repository-specific build, test, workflow, architecture, and feature guidance in this repository's own files; when both layers exist, the repository-local files are the more specific authority. diff --git a/GEMINI.md b/GEMINI.md index 6389697..7d8a734 100644 --- a/GEMINI.md +++ b/GEMINI.md @@ -64,6 +64,7 @@ dotnet run --no-build --configuration Release --project src/MicroCalc.Tui/MicroC ### Documentation & Language - Provide documentation and didactic comments bilingually: German first, English second. - Keep both language blocks at CEFR B2 readability. +- Large normative documents such as `Pflichtenheft*.md` and `Lastenheft*.md` may use a synchronized English sidecar with suffix `.EN.md` instead of an oversized inline-bilingual file; the German version remains canonical unless explicitly marked otherwise. - Maintain complete XML documentation for affected public APIs (``, ``, ``, `` where applicable). - Do not suppress CS1591 globally. @@ -84,7 +85,28 @@ The original Pascal files (`CALC.PAS`, `CALC.INC`) and the help file (`CALC.HLP` - 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. - Within the `## Fortschreibungsprotokoll` table, keep entries in strict chronological order: oldest entry at the top, newest and most recently added entry at the bottom; entries with the same date keep their insertion order. +- Keep a final top-level `## Gesamtstatistik` block as the last section of `docs/project-statistics.md`; do not append later top-level sections after it. +- Inside that final `## Gesamtstatistik` block, maintain compact ASCII-only trend diagrams directly below the textual overall summary and refresh them with every statistics update; cover at least the artifact mix, the documented branch/phase curves, the documented acceleration factors from agentic AI plus Spec-Kit/SDD support, and a direct comparison between experienced-developer effort, Thorsten-solo effort, and the visible AI-assisted delivery window. +- Keep each short CEFR-B2 explanation directly adjacent to its matching ASCII diagram group. +- When progression across an X-axis improves comprehension, add simple ASCII X/Y charts as a second visualization layer; keep them approximate, readable in plain Markdown, and explained in CEFR-B2 language. +- Keep the statistics section plain-text friendly for Braille displays, screen readers, and text browsers; diagrams and explanations must not rely on color or visual layout alone. +- When DocFX content, documentation navigation, or API presentation changes, validate representative `_site/` pages through a text-oriented review path, preferably with a local Playwright accessibility snapshot. +- Treat every successful `docfx` regeneration as requiring the matching text-oriented A11y smoke check in the same work item. - 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 125 lines per workday for this Pascal-derived port. - 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. + +## Inclusion & Accessibility + +- Follow `Programmierung #include`: learner-facing guides, statistics, and generated HTML/API documentation must stay usable on Braille displays, with screen readers, and in text browsers. +- Prefer semantic headings, lists, tables, and ASCII/text-first diagrams; do not encode essential meaning only through color, layout, or pointer-only affordances. +- Treat WCAG 2.2 conformance level AA as the concrete review baseline for generated HTML documentation, especially for page language, bypass blocks, keyboard focus visibility, non-text contrast, and readable landmark structure. +- If `docfx` output is regenerated, follow it with a text-oriented accessibility review, preferably with Playwright + `@axe-core/playwright` and a `lynx` cross-check. +- Recommended A11y toolchain for DocFX-based repos: Node 24 LTS, `npm`, Playwright, `@axe-core/playwright`, and `lynx`. +- Treat bilingual CEFR-B2 delivery and the documented A11Y proof path as formal completion criteria for learner-facing documentation and active requirement artifacts. + +## Shared Parent Guidance + +- Die gemeinsame Datei `/Users/thorstenhindermann/RiderProjects/AGENTS.md` speichert bewusst nur repo-uebergreifende Basisregeln. +- Repository-spezifische Build-, Test-, Workflow-, Architektur- und Feature-Regeln bleiben in den lokalen Projektdateien; wenn beide Ebenen existieren, ist die repo-lokale Guidance die spezifischere Autoritaet. diff --git a/PLAN_MICROCALC_CSHARP_DOTNET10.md b/PLAN_MICROCALC_CSHARP_DOTNET10.md index d6535e5..79cc855 100644 --- a/PLAN_MICROCALC_CSHARP_DOTNET10.md +++ b/PLAN_MICROCALC_CSHARP_DOTNET10.md @@ -223,6 +223,12 @@ Tests (vor UI-Integration): - Fehlerbehandlung, Logging, Performance-Check. - Release-Readiness. +## Phase 7: Dokumentations- und A11Y-Abschlusspruefung +- Alle lernrelevanten Dokumente muessen fuer Auszubildende in Deutsch und Englisch auf CEFR-B2-Niveau nachvollziehbar vorliegen. +- Fuer grosse normative Dokumente ist aus Uebersichtsgruenden eine synchron gepflegte englische Parallelfassung mit Suffix `.EN.md` zulaessig und empfohlen. +- Erzeugte HTML-/API-Dokumentation muss nach `Programmierung #include` fuer Braille-Zeile, Screenreader und Textbrowser nutzbar sein; WCAG 2.2 AA ist die praktische Baseline. +- Nach jedem `docfx`-Neubau folgt ein textorientierter A11Y-Review, bevorzugt mit Playwright + `@axe-core/playwright` und `lynx`. + ## 10. Git- und GitHub-Plan Repository-Setup: diff --git a/README.md b/README.md index aea6f04..1ee55d0 100644 --- a/README.md +++ b/README.md @@ -219,3 +219,12 @@ Wenn du dieses Repo als Blaupause fuer eine eigene Legacy-Portierung nutzen will --- Dieses Repository soll bewusst nicht nur "Code" liefern, sondern einen nachvollziehbaren End-to-End-Prozess zeigen: von Legacy-Analyse ueber Architektur und Tests bis hin zu PR-getriebener, agentischer Umsetzung. + +## Inklusion und Barrierefreiheit / Inclusion and Accessibility + +- Folge dem Leitsatz `Programmierung #include`: Lernmaterialien, Guides und erzeugte HTML-/API-Dokumentation muessen fuer Braille-Zeile, Screenreader und Textbrowser nutzbar bleiben. +- Follow `Programmierung #include`: learner-facing material, guides, and generated HTML/API documentation must stay usable on Braille displays, with screen readers, and in text browsers. +- Fuer erzeugte HTML-Dokumentation gilt WCAG 2.2 Konformitaetsstufe AA als praktische Basis. +- For generated HTML documentation, WCAG 2.2 conformance level AA is the practical baseline. +- Nach jedem `docfx`-Neubau soll ein textorientierter A11y-Review folgen, bevorzugt mit Playwright + `@axe-core/playwright` und `lynx`. +- After every `docfx` regeneration, a text-oriented accessibility review should follow, preferably with Playwright + `@axe-core/playwright` and `lynx`. diff --git a/docs/PR_TEXT_SHARED_GOVERNANCE_BASELINE.md b/docs/PR_TEXT_SHARED_GOVERNANCE_BASELINE.md new file mode 100644 index 0000000..5e33108 --- /dev/null +++ b/docs/PR_TEXT_SHARED_GOVERNANCE_BASELINE.md @@ -0,0 +1,36 @@ +# PR: Shared Governance Baseline fuer TinyCalc nachgezogen + +## Problem + +`TinyCalc` hatte bereits Teile der gemeinsamen repo-uebergreifenden Governance-, +Doku-, Bilingualitaets-, Statistik- und A11Y-Baseline, aber noch nicht alle +Feinregeln, die inzwischen in der Parent-Baseline, der zugehoerigen +Merknote und in `TuiVision` verankert sind. + +## Loesung + +- lokale Guidance-Dateien (`AGENTS.md`, `CLAUDE.md`, `GEMINI.md`, + `.github/copilot-instructions.md`) auf die fehlenden Shared-Baseline-Punkte + nachgezogen +- `.EN.md`-Option fuer grosse normative Dokumente ergaenzt +- Abschlusskriterium fuer bilinguale CEFR-B2-Doku und dokumentierten + A11Y-Nachweis verankert +- Statistikregeln fuer finalen `## Gesamtstatistik`-Block, ASCII-Diagramme, + CEFR-B2-Erklaertexte und ASCII-X/Y-Darstellungen nachgezogen +- `docs/project-statistics.md` mit Schlusssektion und textorientierter + A11Y-/Inklusions-Methodik aktualisiert + +## Risiken + +- Kein funktionales Produkt- oder Laufzeitrisiko, weil nur Dokumentations- und + Governance-Dateien geaendert wurden +- Statistikzahlen koennen bei spaeteren Repo-Aenderungen erneut refresh-beduerftig + werden, was aber dem normalen Pflegeprozess entspricht + +## Testplan + +- Manuelle Diff-Pruefung der betroffenen Guidance-Dateien +- Manuelle Kontrolle, dass `docs/project-statistics.md` mit `## Gesamtstatistik` + endet +- Keine Code- oder Testausfuehrung, weil keine Produktions- oder Testlogik + geaendert wurde diff --git a/docs/project-statistics.md b/docs/project-statistics.md index 2559d70..a5b7405 100644 --- a/docs/project-statistics.md +++ b/docs/project-statistics.md @@ -1,6 +1,6 @@ # Projektstatistik MicroCalc -Stand: 2026-03-27 +Stand: 2026-03-30 (aktualisiert mit finalem `## Gesamtstatistik`-Block, ASCII-/X/Y-Diagrammen und textorientierter A11Y-Statistikbaseline) ## Zweck und Pflege @@ -19,6 +19,21 @@ fortgeschrieben. - Testcode: `tests/**/*.cs` - Dokumentation: Markdown-Dateien in Repository-Wurzel, `docs/`, `specs/`, `.github/` und `.specify/`. +- Leitsatz fuer diese Datei und die zugehoerigen Lernmaterialien: + `Programmierung #include`. Inhalte muessen fuer Braille-Zeile, + Screenreader und Textbrowser lesbar bleiben; ASCII-Diagramme und ihre + Kurztexte sind deshalb bewusst plain-text-freundlich aufgebaut. +- Fuer erzeugte HTML-Dokumentation gilt WCAG 2.2 Konformitaetsstufe AA als + konkrete Pruefbasis; besonders wichtig sind Seitensprache, + Bypass-Mechanismen, sichtbarer Tastaturfokus, Non-Text-Contrast und + verstaendliche Landmark-Struktur. +- Wenn sich DocFX-Inhalte, Navigationsstruktur oder API-Praesentation aendern, + werden repraesentative `_site/`-Seiten ueber einen textorientierten + Reviewpfad geprueft, bevorzugt mit lokalem Playwright-Accessibility-Snapshot + und `lynx` als zusaetzlichem Textbrowser-Gegencheck. +- Jeder erfolgreiche `docfx`-Neubau gilt in diesem Repository erst dann als + vollstaendig, wenn im selben Arbeitsschritt auch der passende textorientierte + A11Y-Review dokumentiert oder ausgefuehrt wurde. - Die konservative Handarbeits-Basis in dieser Datei zaehlt Produktionscode, Testcode und Dokumentation gemeinsam als manuell zu erstellenden Umfang. - Die konservative Handarbeits-Basis folgt dem Beitrag @@ -244,3 +259,158 @@ fortgeschrieben. | 2026-03-27 | Branch `002-spec-kit-versioning` | Repo-weite Versionslogik fuer nummerierte Spec-Kit-Branches eingefuehrt: `Directory.Build.props` neu angelegt, die gemeinsame Agent-Governance und die Constitution auf `Minor = Spec-Kit-Feature-/Branch-Nummer als kanonische PR-Nummer` erweitert. | | 2026-03-27 | Sortierung des Fortschreibungsprotokolls vereinheitlicht | Die Eintraege im Fortschreibungsprotokoll wurden auf strikt chronologische Reihenfolge gebracht: aeltester Eintrag oben, juengster und zuletzt eingetragener Eintrag unten. Dieselbe Regel wurde in der gemeinsamen Agent-Governance fuer dieses Repository festgeschrieben. | | 2026-03-28 | Lastenheft-Branch-Suffix-Regel in Agent-Guidance verankert | Die gemeinsamen Agent-Dateien (`AGENTS.md`, `CLAUDE.md`, `GEMINI.md`, `.github/copilot-instructions.md`) wurden um die Governance-Regel erweitert, dass ein Lastenheft nach Umsetzung durch einen dedizierten Feature-Branch auf `Lastenheft_..md` umzubenennen ist, damit die Rueckverfolgbarkeit im Repository erhalten bleibt; Aenderungsumfang dieser Runde vor dieser Ledger-Fortschreibung: 0 Produktionscode-Zeilen, 0 Testcode-Zeilen, +4 Dokumentationszeilen netto im Arbeitsbaum, konservative Handarbeits-Untergrenze 0.1 Arbeitstage bzw. 0.4 Stunden auf TVoeD-Basis, Monatsannahme weiterhin 21.5 Arbeitstage pro Monat. | +| 2026-03-30 | Inklusions-Leitsatz und DocFX-A11y-Baseline verankert | `README.md`, `AGENTS.md`, `CLAUDE.md`, `GEMINI.md` und `.github/copilot-instructions.md` wurden auf den Leitsatz `Programmierung #include` nachgezogen: lernrelevante Doku und erzeugte HTML-/API-Dokumentation muessen fuer Braille-Zeile, Screenreader und Textbrowser nutzbar bleiben. Fuer DocFX-basierte HTML-Dokumentation ist WCAG 2.2 AA als praktische Baseline festgehalten; nach jedem DocFX-Neubau soll ein textorientierter A11y-Review mit Playwright/axe und `lynx` folgen. Diese Runde war reine Governance-/Doku-Arbeit mit `0` Produktionscode-Zeilen, `0` Testcode-Zeilen und ca. `+37` Dokumentationszeilen netto. Konservative Manualreferenz: 80 Zeilen/Tag = `0.5` Tage (ca. `4.1` Stunden); Thorsten-Solo-Referenz: 125 Zeilen/Tag = `0.3` Tage (ca. `2.6` Stunden); sichtbares Arbeitsfenster: 1 kurze Agentensitzung am 2026-03-30. | +| 2026-03-30 | Abschlusspruefung fuer Bilingualitaet und A11Y in Planungsdokument verankert | Im zentralen Migrationsplan `PLAN_MICROCALC_CSHARP_DOTNET10.md` wurde ein ausdruecklicher Abschlussblock fuer Dokumentation und Barrierefreiheit ergaenzt: Lernrelevante Dokumente muessen in Deutsch und Englisch auf CEFR-B2-Niveau vorliegen; grosse normative Dokumente duerfen als synchron gepflegte `.EN.md`-Parallelfassung gefuehrt werden; fuer erzeugte HTML-Dokumentation gilt WCAG 2.2 AA als Baseline und nach jedem `docfx`-Neubau ist ein textorientierter A11Y-Review vorgesehen. Diese Runde war reine Dokumentationsarbeit mit `0` Produktionscode-Zeilen, `0` Testcode-Zeilen und ca. `+8` Dokumentationszeilen netto. Konservative Manualreferenz: 80 Zeilen/Tag = `0.1` Tage (ca. `0.8` Stunden); Thorsten-Solo-Referenz: 125 Zeilen/Tag = `0.1` Tage (ca. `0.5` Stunden); sichtbares Arbeitsfenster: 1 kurze Agentensitzung am 2026-03-30. | +| 2026-03-30 | Parent-Guidance bewusst auf repo-uebergreifende Regeln begrenzt | In den lokalen Guidance-Dateien von `TinyCalc` ist jetzt ausdruecklich vermerkt, dass `/Users/thorstenhindermann/RiderProjects/AGENTS.md` nur gemeinsame Basisregeln fuer mehrere Repositories traegt. Repository-spezifische Build-, Test-, Workflow-, Architektur- und Feature-Vorgaben bleiben bewusst in `TinyCalc` selbst und sind dort die spezifischere Autoritaet. Diese Runde war reine Dokumentationsarbeit mit `0` Produktionscode-Zeilen, `0` Testcode-Zeilen und ca. `+10` Dokumentationszeilen netto. Konservative Manualreferenz: 80 Zeilen/Tag = `0.1` Tage (ca. `1.0` Stunden); Thorsten-Solo-Referenz: 125 Zeilen/Tag = `0.1` Tage (ca. `0.6` Stunden); sichtbares Arbeitsfenster: 1 kurze Agentensitzung am 2026-03-30. | +| 2026-03-30 | Fehlende Shared-Baseline-Regeln aus `TuiVision` in `TinyCalc` nachgezogen | Die lokalen Guidance-Dateien (`AGENTS.md`, `CLAUDE.md`, `GEMINI.md`, `.github/copilot-instructions.md`) und diese Statistikdatei wurden nur bei den repo-uebergreifenden Restluecken nachgezogen: `.EN.md`-Option fuer grosse normative Dokumente, formale Abschlusspruefung fuer bilinguale CEFR-B2-Doku plus dokumentierten A11Y-Nachweis, textfirst-/ASCII-Regeln fuer Statistik und Doku, finaler `## Gesamtstatistik`-Block als Schlusssektion, CEFR-B2-Erklaertexte direkt an ASCII-Diagrammen sowie zusaetzliche ASCII-X/Y-Darstellung. MicroCalc-spezifische Architektur-, Feature-, Branch- und Build-Regeln blieben bewusst unveraendert. Diese Runde war reine Dokumentations-/Governance-Arbeit mit `0` Produktionscode-Zeilen, `0` Testcode-Zeilen und `+258 / -2` Dokumentationszeilen netto ueber die betroffenen Guidance- und Statistikdateien. Konservative Manualreferenz: 80 Zeilen/Tag = `3.2` Tage (ca. `25.2` Stunden); Thorsten-Solo-Referenz: 125 Zeilen/Tag = `2.1` Tage (ca. `16.1` Stunden); sichtbares Arbeitsfenster: 1 kurze Agentensitzung am 2026-03-30. | + +## Gesamtstatistik + +Basis dieses Schlussblocks sind die aktuell dokumentierten Snapshot- und +Phasenwerte aus den Abschnitten `## Gesamtstand des Repositories` und +`## Phasen und grundlegende Arbeiten` weiter oben. + +| Kennzahl | Verdichteter Gesamtblick | +|---|---:| +| Artefaktbasis gesamt | `9245` Zeilen | +| Produktions- und Testcode zusammen | `3503` Zeilen (`37.9 %`) | +| Dokumentationsanteil | `5742` Zeilen (`62.1 %`) | +| Spec-Kit-Anteil innerhalb der Doku | `2139` Zeilen (`37.3 %`) | +| Governance-/Agent-Anteil innerhalb der Doku | `533` Zeilen (`9.3 %`) | +| Beobachtbarer Projektzeitraum | `2026-02-07` bis `2026-03-06` | +| Git-Commits pro sichtbarem Aktivtag | `9.7` (`68 / 7`) | +| Dokumentierte Gesamtzeilen pro sichtbarem Aktivtag | `1320.7` (`9245 / 7`) | +| Dokumentierte Gesamtzeilen pro Commit | `136.0` (`9245 / 68`) | +| Konservative Einzelentwickler-Untergrenze | `115.6` Arbeitstage / `901.7` Stunden | +| Thorsten-Solo-Untergrenze | `74.0` Arbeitstage / `577.2` Stunden | +| Kleines 3er-Team mit Koordinationsaufschlag | `46.2` Arbeitstage | +| Repo-weiter Speedup gg. 80-Zeilen-Referenz | `16.5x` | +| Repo-weiter Speedup gg. Thorsten-Referenz | `10.6x` | + +Kurzfazit: +Der aktuell dokumentierte Snapshot ist klar dokumentationslastig: Rund +`62.1 %` der sichtbaren Basis liegen in Markdown-, Governance- und +Planungsartefakten, waehrend Produktions- und Testcode zusammen `37.9 %` +ausmachen. Das passt zum beobachtbaren Verlauf von `TinyCalc`, in dem +Portierung, Governance, Spezifikation und Nachweis sehr frueh stark +mitgewachsen sind. Die Beschleunigungsfaktoren beschreiben dabei keine +Stoppuhr, sondern die sichtbare Lieferdichte gegen konservative manuelle +Referenzen. + +Short summary: +The currently documented snapshot is clearly documentation-heavy. About +`62.1 %` of the visible baseline sits in Markdown, governance, and planning +artifacts, while production and test code together make up `37.9 %`. This +matches the visible `TinyCalc` trajectory, where porting, governance, +specification, and proof artifacts grew strongly from the start. The +acceleration factors therefore describe visible delivery density, not a +stopwatch measurement. + +### ASCII-Diagramme + +```text +Artefaktmix nach aktuell dokumentiertem Snapshot (Zeilen) +Produktion | ############## | 2728 | 29.5 % +Tests | #### | 775 | 8.4 % +Dokumentation | ############################## | 5742 | 62.1 % +``` + +Dieses Diagramm zeigt, wie der aktuell dokumentierte Repository-Snapshot +zwischen Produktionscode, Tests und Dokumentation verteilt ist. Laengere Balken +bedeuten mehr Zeilen innerhalb derselben Vergleichsgruppe. + +This chart shows how the currently documented repository snapshot is split +between production code, tests, and documentation. Longer bars mean more lines +inside the same comparison group. + +```text +Dokumentierte Phasenbasis nach Netto-Volumen (Zeilen) +0 main | ######################## | 7368 +1 init | ########### | 3456 +2 001 | ########## | 2962 +3 harden | ### | 782 +4 002v | # | 42 +``` + +Dieses Diagramm zeigt die grob sichtbare Netto-Basis der dokumentierten +Phasenpakete. So wird schnell lesbar, welche Phase besonders viel sichtbaren +Umfang erzeugt hat. + +This chart shows the rough net size of the documented phase packages. It makes +it easy to see which phase created especially large visible scope. + +```text +Konservative Handarbeits-Referenz je dokumentierter Phase (Arbeitstage) +0 main | ######################## | 92.1 d +1 init | ########### | 43.2 d +2 001 | ########## | 37.0 d +3 harden | ### | 9.8 d +4 002v | # | 0.5 d +``` + +Hier werden dieselben Pakete als konservative manuelle Referenz in +Arbeitstagen gezeigt. Damit wird sichtbar, wie gross derselbe Lieferumfang +ohne agentische Unterstuetzung aus klassischer Sicht waere. + +Here the same packages are shown again as a conservative manual reference in +workdays. This makes visible how large the same delivery would look without +agentic support. + +```text +Dokumentierte Beschleunigungsfaktoren durch agentische KI + Spec-Kit/SDD +Repo 80 | ########### | 16.5x +Repo125 | ####### | 10.6x +0 main | ############### | 23.0x +1 init | ############## | 21.6x +2 001 | ######################## | 37.0x +3 harden | ### | 4.9x +4 002v | # | 0.5x +``` + +Dieses Diagramm zeigt die dokumentierten Beschleunigungsfaktoren. Es misst +nicht echte Uhrzeit, sondern die sichtbare Verdichtung des Lieferumfangs gegen +gewaehlte manuelle Referenzen. + +This chart shows the documented acceleration factors. It does not measure real +clock time. Instead, it compares visible delivery density against the selected +manual references. + +```text +Vergleich dokumentierter Gesamtaufwand / sichtbares KI-Lieferfenster +Erfahren | ############################## | 115.6 d +Thorsten | ################### | 74.0 d +KI sichtbar| ## | 7.0 d +``` + +Dieses Diagramm vergleicht die drei Gesamtperspektiven direkt: konservative +Erfahrungsreferenz, Thorsten-Solo-Referenz und sichtbares KI-Lieferfenster. +Der Abstand zwischen den Balken macht die dokumentierte Verdichtung gut lesbar. + +This chart compares the three overall perspectives directly: conservative +experienced-developer reference, Thorsten solo reference, and the visible +AI-assisted delivery window. The distance between the bars makes the documented +delivery compression easy to read. + +```text +ASCII-X/Y-Verlauf der dokumentierten Phasenbasis (Zeilen) +8000 | * +7000 | * +6000 | +5000 | +4000 | * +3000 | * * +2000 | +1000 | * + 0 +---+---+---+---+---> + 0 1 2 3 4 +``` + +Die X-Achse zeigt die dokumentierten Phasen `0` bis `4`, die Y-Achse das grobe +Netto-Volumen in Zeilen. Das Diagramm ist bewusst einfach gehalten und soll vor +allem den starken Anfangssprung und den spaeteren Abfall des sichtbaren +Phasenvolumens schnell erklaeren. + +The X-axis shows the documented phases `0` to `4`, while the Y-axis shows the +rough net volume in lines. The chart is intentionally simple and is meant to +explain quickly the strong early jump and the later decline in visible phase +volume.