diff --git a/.github/workflows/pages.yml b/.github/workflows/pages.yml index 46c6642..5cef290 100644 --- a/.github/workflows/pages.yml +++ b/.github/workflows/pages.yml @@ -18,6 +18,9 @@ jobs: build: name: Build DocFX site runs-on: ubuntu-latest + timeout-minutes: 30 + env: + PLAYWRIGHT_CHROMIUM_CHANNEL: chrome permissions: contents: read @@ -58,9 +61,8 @@ jobs: working-directory: tests/web-a11y run: npm ci - - name: Install Playwright Chromium - working-directory: tests/web-a11y - run: npx playwright install --with-deps chromium + - name: Verify system Chrome + run: google-chrome --version - name: Run DocFX accessibility smoke tests working-directory: tests/web-a11y diff --git a/.specify/feature.json b/.specify/feature.json index 78a36b9..07fed01 100644 --- a/.specify/feature.json +++ b/.specify/feature.json @@ -1,3 +1,3 @@ { - "feature_directory": "specs/013-wave2-visual-component-remediation" + "feature_directory": "specs/014-wave1-functional-hardening" } diff --git a/Directory.Build.props b/Directory.Build.props index 5fd5680..9c1860a 100644 --- a/Directory.Build.props +++ b/Directory.Build.props @@ -5,9 +5,9 @@ enable enable true - 1.13.13.46 - 1.13.13.46 - 1.13.13.46 + 1.14.5.46 + 1.14.5.46 + 1.14.5.46 CS1591 diff --git a/docfx-templates/accessibility-modern/public/accessibility.js b/docfx-templates/accessibility-modern/public/accessibility.js index 126c30e..ec7abf6 100644 --- a/docfx-templates/accessibility-modern/public/accessibility.js +++ b/docfx-templates/accessibility-modern/public/accessibility.js @@ -33,16 +33,36 @@ const normalizeDropdownToggles = () => { } }; +const normalizeScrollableTables = () => { + let tableNumber = 1; + + for (const element of document.querySelectorAll('.table-responsive')) { + element.setAttribute('tabindex', '0'); + element.setAttribute('role', 'region'); + + if (!element.hasAttribute('aria-label')) { + element.setAttribute( + 'aria-label', + `Scrollbare Tabelle ${tableNumber} / Scrollable table ${tableNumber}`); + } + + tableNumber++; + } +}; + document.documentElement.lang ||= 'de'; hideDecorativeIcons(); hideEmptyLandmarks(); normalizeLandingHeadings(); normalizeDropdownToggles(); +normalizeScrollableTables(); +requestAnimationFrame(normalizeScrollableTables); const observer = new MutationObserver(() => { hideDecorativeIcons(); hideEmptyLandmarks(); normalizeDropdownToggles(); + normalizeScrollableTables(); }); observer.observe(document.body, { diff --git a/docs/project-statistics.md b/docs/project-statistics.md index a058c7a..a2abbc3 100644 --- a/docs/project-statistics.md +++ b/docs/project-statistics.md @@ -1,6 +1,6 @@ # Projektstatistik TuiVision -Stand: 2026-05-30 (aktualisiert inklusive Branch `011-port-wave2-examples`, Wave-2-Beispielen, Lastenheft fuer interaktive Wave-2-Demos, DocFX-Generated-Output-Cleanup, zweistufigem Beispielwellen-Liefermuster, Pflichtenheft-Abnahme fuer interaktive Beispielreife, 011-Review-Cleanup vor 012, Spec-Kit-Intake-Aufbereitung fuer 012, GitHub-Pages-Artefaktworkflow fuer DocFX, PR-#26-Review-Cleanup, `/speckit-specify`, `/speckit-clarify`, `/speckit-plan`, `/speckit-checklist`, `/speckit-tasks`, PR-#27-Review-Cleanup, `/speckit-analyze`-Remediation fuer 012, Wave-1-Folge-Lastenhefte, Wave-1-Visual-Component-Remediation-Umbenennung, Wave-3-/Wave-4-Visual-Component-Porting-Intakes, Lastenheft-Specify-Readiness-Harmonisierung, C#-Dev-Kit-Language-Service-Cache-Ignore, Claude-Code-Review-Remediation fuer 012-Tasks, `/speckit-implement` fuer `012-interactive-wave2-demos`, Lastenheft fuer Wave-2-Visual-Component-Remediation, `/speckit-specify`, zwei `/speckit-clarify`-Laeufe, `/speckit-plan`, gezieltem `security-governance`-v0.4.0-Plan-Nachlauf, `/speckit-checklist`, `/speckit-tasks`, `/speckit-analyze`-Remediation und `/speckit-implement` fuer `013-wave2-visual-component-remediation`, PR-#29-Copilot-Review-Cleanup, AI-SBOM-Governance-Preset-Rollout sowie allgemeiner historischer `tv203s`-Quellenreferenzregel) +Stand: 2026-05-31 (aktualisiert inklusive Branch `011-port-wave2-examples`, Wave-2-Beispielen, Lastenheft fuer interaktive Wave-2-Demos, DocFX-Generated-Output-Cleanup, zweistufigem Beispielwellen-Liefermuster, Pflichtenheft-Abnahme fuer interaktive Beispielreife, 011-Review-Cleanup vor 012, Spec-Kit-Intake-Aufbereitung fuer 012, GitHub-Pages-Artefaktworkflow fuer DocFX, PR-#26-Review-Cleanup, `/speckit-specify`, `/speckit-clarify`, `/speckit-plan`, `/speckit-checklist`, `/speckit-tasks`, PR-#27-Review-Cleanup, `/speckit-analyze`-Remediation fuer 012, Wave-1-Folge-Lastenhefte, Wave-1-Visual-Component-Remediation-Umbenennung, Wave-3-/Wave-4-Visual-Component-Porting-Intakes, Lastenheft-Specify-Readiness-Harmonisierung, C#-Dev-Kit-Language-Service-Cache-Ignore, Claude-Code-Review-Remediation fuer 012-Tasks, `/speckit-implement` fuer `012-interactive-wave2-demos`, Lastenheft fuer Wave-2-Visual-Component-Remediation, `/speckit-specify`, zwei `/speckit-clarify`-Laeufe, `/speckit-plan`, gezieltem `security-governance`-v0.4.0-Plan-Nachlauf, `/speckit-checklist`, `/speckit-tasks`, `/speckit-analyze`-Remediation und `/speckit-implement` fuer `013-wave2-visual-component-remediation`, PR-#29-Copilot-Review-Cleanup, `/speckit-specify` fuer `014-wave1-functional-hardening`, PR-#30-DocFX-Playwright-Install-Hardening, PR-#30-DocFX-System-Chrome-Fallback, PR-#30-DocFX-A11Y-Smoke-Remediation, AI-SBOM-Governance-Preset-Rollout sowie allgemeiner historischer `tv203s`-Quellenreferenzregel) ## Zweck und Pflege @@ -577,6 +577,11 @@ fortgeschrieben. | 2026-05-30 | `/speckit-analyze`-Remediation fuer `013-wave2-visual-component-remediation` | Die vier relevanten Analyze-Funde wurden als gezielte Artefaktkorrektur eingepflegt: Der Lastenheft-Rename ist nun der letzte Polish-Task, die US4-Dokumentationsaufgaben verlangen German-first/English-second CEFR-B2-Inhalte, DocFX/web-a11y ist wegen der geplanten Guide-/README-Aenderungen deterministischer als erwarteter Nachweis formuliert, und der Acceptance-Contract vermeidet den platzhalterartigen `examples/`-Befehl. Validierung: 94/94 Tasks bleiben sequenziell, der Contract enthaelt keinen `examples/`-Platzhalter mehr, CEFR-B2 ist in den konkreten US4-Tasks sichtbar, `git diff --check` sauber; keine Build-/Testausfuehrung, weil nur Spec-Kit-Planungsdokumentation und Statistik geaendert wurden. Netto-Aenderungsvolumen vor diesem Ledger-Eintrag: `0` Produktionscode-Zeilen, `0` Testcode-Zeilen, Spec-Kit-Aufgaben-/Contract-Remediation ohne Nettozeilenaenderung plus diese Statistikfortschreibung. Sichtbares Arbeitsfenster: kurze Analyze-Remediation am 2026-05-30, als blended repository speedup und nicht als Stopwatch-Messung zu lesen. | | 2026-05-30 | `/speckit-implement` fuer `013-wave2-visual-component-remediation` | Die sichtbare Wave-2-Komponenten-Remediation wurde umgesetzt: alle elf Wave-2-Beispiele besitzen jetzt eine echte sichtbare Hauptkomponente oder einen stabilen visuellen Runtime-Zustand, eine echte `TStatusLine`, einen tastaturerreichbaren `Help -> Description`-Pfad und primaere App-Loop-Smokes mit konkreter Zustandsassertion, View-Baum-Nachweis sowie Buffer-/Cell-Snapshot. Neu ist der gemeinsame Beispiel-Helfer `examples/Shared/Wave2Runtime.cs`; aktualisiert wurden die elf Beispiel-Apps, Example-Smokes, Guides, README, `Pflichtenheft.md`, Architektur-/Security-Nachweise, Agent-Guidance und `pr-evidence.md`. Zwischenvalidierung vor den finalen Gate-Kommandos: fokussierte Wave-2-Smokes `47/47` gruen und Matrix-Smokes `4/4` gruen. Netto-Aenderungsvolumen vor diesem Ledger-Eintrag: ca. `+980` Produktions-/Beispielcode-Zeilen, `+585` Testzeilen und ca. `+540` Dokumentations-/Evidence-/Governance-Zeilen; `Directory.Build.props` steht nach T094 und der finalen regulaeren Commit-Ausrichtung branchkonform auf `1.13.12.46`. Konservative Manualreferenz fuer rund `2105` fachliche Netto-Zeilen: `26,3` Tage (ca. `205,2` Stunden); Thorsten-Solo-Referenz: `16,8` Tage (ca. `131,4` Stunden); sichtbares Arbeitsfenster: eine Agentensitzung am 2026-05-30, als blended repository speedup und nicht als Stopwatch-Messung zu lesen. | | 2026-05-30 | PR-#29-Copilot-Review-Cleanup fuer `013-wave2-visual-component-remediation` | Die zwei Copilot-Inline-Kommentare zu `scripts/check-homogeneity.sh` wurden geschlossen: Der JSON-Modus schreibt fuer `GIT-SCOPE-001` und `GIT-SCOPE-002` keine separaten `printf`-Objekte mehr; beide Warnungen laufen nur noch ueber `emit_result` und die finale Summary. `Directory.Build.props` steht fuer den dreizehnten 013-Branch-Commit auf `1.13.13.46`. Validierung: `./scripts/check-homogeneity.sh --json --dry-run .` erzeugt auf stdout genau ein JSON-Summary-Objekt; stderr meldet weiterhin die bereits vorhandenen fehlenden `hg_scan`-Helfer, weil `scripts/lib/hg-*.sh` in diesem Repo-Snapshot nicht vorhanden ist. `git diff --check` sauber. Netto-Aenderungsvolumen: kleine Script-Remediation plus Evidence-, Statistik- und Versionsmetadatenpflege; sichtbares Arbeitsfenster: kurze PR-Review-Nacharbeit am 2026-05-30, als blended repository speedup und nicht als Stopwatch-Messung zu lesen. | +| 2026-05-31 | `/speckit-specify` fuer `014-wave1-functional-hardening` | Aus `Lastenheft_Wave1-Functional-Hardening.md` wurde die Feature-Spezifikation fuer den Wave-1-Qualitaetsnachlauf erzeugt. Die Spec begrenzt den Scope auf `Desklogo`, `MsgCls`, `Tutorial` mit `tvguid01` bis `tvguid16` und `Videomode`, verlangt historische Read-only-Quellenreviews, eine Quellen-/C#-/Test-/Abweichungs-Matrix, fachlich relevante Smoke-Nachweise statt reiner Startup-/Textpraesenz, Helper-Klassifikation als `SetupOnly`, `PrimaryProof`, `SupplementalProof` oder `LegacyOrTemporary` und German-first/English-second Evidence. Wave-1-Visual-Component-Remediation, Wave 2 bis 4, breite Framework-Revisionen und interaktive Demo-Politur bleiben ausdruecklich ausser Scope; der Pflichtenheft-Marker auf Wave 3 bleibt offen. `Directory.Build.props` wurde fuer den ersten 014-Branch-Commit auf `1.14.1.46` ausgerichtet. Validierung: Spec-Kit-Branch-Hook fuer `014`, `.specify/feature.json` gueltig, keine offenen Spec-Platzhalter oder Clarification-Marker, Requirements-Checklist `PASS`, `git diff --check` sauber; keine Build-/Testausfuehrung, weil nur Specify-, Statistik- und Versionsmetadaten geaendert wurden. Netto-Aenderungsvolumen vor diesem Ledger-Eintrag: `0` Produktionscode-Zeilen, `0` Testcode-Zeilen, `+328` Spec-Kit-Dokumentationszeilen plus diese Statistikfortschreibung; `Directory.Build.props` ist reine Versionsmetadatenpflege. Konservative Manualreferenz fuer die neue Spezifikation und Checkliste: 80 Zeilen/Tag = `4,1` Tage (ca. `32,0` Stunden); Thorsten-Solo-Referenz: 125 Zeilen/Tag = `2,6` Tage (ca. `20,5` Stunden); sichtbares Arbeitsfenster: eine Agentensitzung am 2026-05-31, als blended repository speedup und nicht als Stopwatch-Messung zu lesen. | +| 2026-05-31 | DocFX-Pages-Workflow gegen Playwright-Install-Haenger gehaertet | Der fehlgeschlagene PR-#30-Check wurde als Infrastrukturhaenger im Schritt `Install Playwright Chromium` eingeordnet: DocFX selbst war gruen, der Chromium-Download erreichte 100 %, danach lief der Job bis zum GitHub-Actions-Abbruch nach rund sechs Stunden. `.github/workflows/pages.yml` begrenzt den Build-Job nun auf 30 Minuten, trennt Playwright-Systemabhaengigkeiten und Browserinstallation, setzt Schritt-Timeouts von 10 beziehungsweise 15 Minuten und cached `~/.cache/ms-playwright` ueber den `package-lock.json`-Hash. `Directory.Build.props` wurde fuer den zweiten 014-Branch-Commit auf `1.14.2.46` ausgerichtet. Validierung: YAML-Syntaxcheck, `git diff --check` sauber; keine Build-/Testausfuehrung, weil nur Workflow-, Statistik- und Versionsmetadaten geaendert wurden. | +| 2026-05-31 | PR-#30-DocFX-Playwright-Headless-Shell-Fix | Der zweite PR-#30-Run bestaetigte, dass der neue Timeout greift, der volle Playwright-Chromium-Install aber nach dem 100-%-Download weiter haengen kann. Der Pages-Workflow installiert fuer die headless DocFX-A11Y-Smokes deshalb nur noch die Chromium Headless Shell mit `npx playwright install chromium --only-shell`; das passt zur vorhandenen `playwright.config.ts`, weil kein Browser-`channel` gesetzt ist und die Tests headless laufen. `Directory.Build.props` wurde fuer den dritten 014-Branch-Commit auf `1.14.3.46` ausgerichtet. Validierung: YAML-Syntaxcheck, Playwright-Dry-Run fuer `chromium --only-shell`, realer `npx playwright install chromium --only-shell`, `npm test` in `tests/web-a11y/` mit 2/2 gruen, `git diff --check`; keine Dotnet-Build-/Testausfuehrung, weil nur Workflow-, Statistik- und Versionsmetadaten geaendert wurden. | +| 2026-05-31 | PR-#30-DocFX-System-Chrome-Fallback | Der GitHub-Run mit `--only-shell` zeigte denselben Haenger nach dem 100-%-Download der kleineren Chromium Headless Shell. Der Pages-Workflow nutzt im CI deshalb den auf GitHub-hosted Ubuntu vorhandenen System-Chrome ueber `PLAYWRIGHT_CHROMIUM_CHANNEL=chrome`, prueft ihn mit `google-chrome --version` und entfernt die Playwright-Browserdownload- und Cache-Schritte aus dem PR-Pfad. Lokal bleibt der Standard ohne gesetzten Channel unveraendert und nutzt weiter den installierten Playwright-Browser. `Directory.Build.props` wurde fuer den vierten 014-Branch-Commit auf `1.14.4.46` ausgerichtet. Validierung: YAML-Syntaxcheck, `npm test` in `tests/web-a11y/` mit 2/2 gruen im lokalen Standardpfad, `PLAYWRIGHT_CHROMIUM_CHANNEL=chrome npm test` mit 2/2 gruen im lokalen System-Chrome-Pfad, `git diff --check`; GitHub-PR-Run ist der massgebliche Nachweis fuer den Ubuntu-System-Chrome-Pfad. | +| 2026-05-31 | PR-#30-DocFX-A11Y-Smoke-Remediation | Der System-Chrome-Run beseitigte den Browserinstall-Haenger, legte aber zwei echte CI-Unterschiede frei: Playwrights Failure-Video benoetigte ohne Browserinstall ein fehlendes FFmpeg-Artefakt, und axe meldete auf der Linux-/Chrome-Viewport-Kombination `scrollable-region-focusable` fuer DocFX-Tabellencontainer. Der A11Y-Smoke schaltet Videoaufzeichnung jetzt aus, erhoeht das Test-Timeout auf 60 Sekunden, und das DocFX-Accessibility-Template macht `.table-responsive`-Container per `tabindex`, `role=region` und zweisprachigem Label tastaturerreichbar. `Directory.Build.props` wurde fuer den fuenften 014-Branch-Commit auf `1.14.5.46` ausgerichtet. Validierung: `docfx docfx.json` mit 0 Warnungen/0 Fehlern, `PLAYWRIGHT_CHROMIUM_CHANNEL=chrome npm test` in `tests/web-a11y/` mit 2/2 gruen, `git diff --check`; GitHub-PR-Run bleibt der massgebliche Linux-Nachweis. | ## Gesamtstatistik diff --git a/specs/014-wave1-functional-hardening/checklists/requirements.md b/specs/014-wave1-functional-hardening/checklists/requirements.md new file mode 100644 index 0000000..b4d1ca7 --- /dev/null +++ b/specs/014-wave1-functional-hardening/checklists/requirements.md @@ -0,0 +1,44 @@ +# Specification Quality Checklist: Wave 1 Functional Hardening + +**Purpose**: Validate specification completeness and quality before proceeding +to planning +**Created**: 2026-05-31 +**Feature**: [spec.md](../spec.md) + +## Content Quality + +- [x] No implementation details beyond project/domain constraints, + historical-source anchors, and constitution-required governance facts +- [x] Focused on user value and business needs +- [x] Written for non-technical stakeholders where the feature scope allows it +- [x] All mandatory sections completed + +## Requirement Completeness + +- [x] No [NEEDS CLARIFICATION] markers remain +- [x] Requirements are testable and unambiguous +- [x] Success criteria are measurable +- [x] Success criteria are technology-agnostic except where repository + governance explicitly requires named evidence surfaces +- [x] All acceptance scenarios are defined +- [x] Edge cases are identified +- [x] Scope is clearly bounded +- [x] Dependencies and assumptions identified + +## Feature Readiness + +- [x] All functional requirements have clear acceptance criteria +- [x] User scenarios cover primary flows +- [x] Feature meets measurable outcomes defined in Success Criteria +- [x] No implementation details leak into specification beyond accepted + repository artefact names, historical source references, helper + classification labels, and governance evidence obligations + +## Notes + +- Validation pass completed on 2026-05-31 after generating + `specs/014-wave1-functional-hardening/spec.md`. +- The specification intentionally names Wave-1 examples, historical source + files, proof classification labels, and governance evidence obligations + because these are binding repository and Lastenheft constraints rather than + optional implementation design. diff --git a/specs/014-wave1-functional-hardening/spec.md b/specs/014-wave1-functional-hardening/spec.md new file mode 100644 index 0000000..2739532 --- /dev/null +++ b/specs/014-wave1-functional-hardening/spec.md @@ -0,0 +1,284 @@ +# Feature Specification: Wave 1 Functional Hardening + +**Feature Branch**: `014-wave1-functional-hardening` +**Created**: 2026-05-31 +**Status**: Draft +**Input**: User description: "Use `Lastenheft_Wave1-Functional-Hardening.md` as the binding input. Create the specification for `014-wave1-functional-hardening`. Harden the delivered Wave-1 examples against their historical sources, document ported, replaced, and intentionally omitted core behavior, strengthen smoke proof where startup, string, or headless-helper paths prove too much, and keep Wave-1 visual remediation and later waves out of scope." + +## User Scenarios & Testing *(mandatory)* + +### User Story 1 - Historical proof matrix for Wave 1 (Priority: P1) + +As a maintainer, I want each Wave-1 example area to have a clear historical +proof matrix, so that later remediation work can rely on documented intent +instead of re-reading the original sources from scratch. + +**Why this priority**: This is the feature's foundation. Without the matrix, +reviewers cannot tell whether current behavior is historically grounded, +modernized on purpose, or accidentally thin. + +**Independent Test**: A reviewer can inspect the feature evidence and find one +complete row or section for `Desklogo`, `MsgCls`, `Videomode`, and each of the +16 `Tutorial` steps. + +**Acceptance Scenarios**: + +1. **Given** a reviewer inspects the Wave-1 hardening evidence, **When** they + choose any Wave-1 example area, **Then** they can identify the historical + source, historical core function, current managed behavior, proof method, + and intentional deviations. +2. **Given** a reviewer inspects `Tutorial`, **When** they check the 16 + historical steps, **Then** each step remains individually traceable instead + of being collapsed into one generic tutorial statement. +3. **Given** a historical helper or asset generator is reviewed, **When** it is + not required for the current managed example, **Then** the evidence explains + whether it is omitted, replaced, or used only as context. + +--- + +### User Story 2 - Hardened functional smoke proof (Priority: P1) + +As a reviewer, I want the Wave-1 smoke proof to verify meaningful example +behavior, so that the examples are not accepted only because they start or +display static text. + +**Why this priority**: The existing Wave-1 delivery is accepted, but this +quality pass must close proof gaps before visible Wave-1 remediation builds on +top of it. + +**Independent Test**: Each Wave-1 example area has at least one smoke scenario +or evidence-backed proof that checks a historical core function rather than +only launch success. + +**Acceptance Scenarios**: + +1. **Given** `Desklogo` is reviewed, **When** its proof is inspected, **Then** + it verifies logo or desktop intent, asset-source rationale, or a documented + fallback rather than only startup. +2. **Given** `MsgCls` is reviewed, **When** its proof is inspected, **Then** it + verifies custom message triggering, routing, and observable result, + including repeated-trigger stability. +3. **Given** `Tutorial` is reviewed, **When** its proof is inspected, **Then** + all 16 step tokens remain individually discoverable and each step has a + step-specific learning or behavior proof. +4. **Given** `Videomode` is reviewed, **When** its proof is inspected, **Then** + it verifies a real capability outcome or an explicit fallback with + post-transition usability. + +--- + +### User Story 3 - Helper and headless path classification (Priority: P2) + +As the later visual-remediation implementer, I want every helper and headless +proof path used by Wave-1 smokes to be classified, so that I know which proof +can stay and which proof must later move behind visible runtime paths. + +**Why this priority**: The feature intentionally does not deliver interactive +visual remediation, but it must prepare that follow-up by making current proof +surfaces explicit. + +**Independent Test**: A reviewer can list all Wave-1 smoke helper and proof +paths and see one classification for each: `SetupOnly`, `PrimaryProof`, +`SupplementalProof`, or `LegacyOrTemporary`. + +**Acceptance Scenarios**: + +1. **Given** a helper prepares controlled state, **When** it is reviewed, + **Then** it is marked `SetupOnly` and not counted as proof of historical + behavior. +2. **Given** a helper currently verifies the main behavior, **When** it is + reviewed, **Then** it is marked `PrimaryProof` only if that is acceptable + for functional hardening, or `LegacyOrTemporary` if later visual remediation + must replace it. +3. **Given** a helper adds extra assertions around a real smoke path, **When** + it is reviewed, **Then** it is marked `SupplementalProof`. + +--- + +### User Story 4 - Learner-facing traceability (Priority: P2) + +As an apprentice or text-first reviewer, I want the Wave-1 guides and evidence +to explain historical intent and modern deviations in German first and English +second, so that I can understand the port without confusing it with the +original C/C++ examples. + +**Why this priority**: This feature changes the trust level of the already +delivered examples. The proof must be readable by learners and accessible +reviewers, not only by maintainers. + +**Independent Test**: A learner can open the relevant guide or evidence and +find German-first/English-second traceability, deviation, and proof notes for +each Wave-1 area. + +**Acceptance Scenarios**: + +1. **Given** a guide discusses a historical deviation, **When** a learner reads + it, **Then** the German explanation appears first and the English + explanation follows at CEFR-B2 readability. +2. **Given** a proof path is helper-based or headless, **When** a learner or + reviewer reads the evidence, **Then** the text explains why that proof is + acceptable for functional hardening or why it is deferred to visual + remediation. +3. **Given** the current project next-step marker still points to Wave 3, + **When** this feature is documented, **Then** the documentation states that + this is a Wave-1 quality follow-up and does not complete or replace Wave 3. + +### Edge Cases + +- A historical source uses platform-specific support files, asset generators, + or build scripts that are not part of the managed example runtime. +- A `Tutorial` step is mostly didactic in the current port and has no direct + one-to-one runtime behavior. +- A current smoke proves useful behavior only through a helper or headless + inspection path. +- `Videomode` cannot perform a real terminal mode change in the current + environment and must present an honest fallback. +- `Desklogo` cannot or should not reproduce the historical asset-generation + path exactly. +- `MsgCls` uses a modern event-routing shape that differs from the historical + source layout. +- A future reviewer tries to treat this feature as the Wave-1 visual + remediation or as permission to start Wave-3 implementation. + +## Requirements *(mandatory)* + +### Functional Requirements + +- **FR-001**: The feature MUST cover only the delivered Wave-1 examples: + `Desklogo`, `MsgCls`, `Tutorial` steps `tvguid01` through `tvguid16`, and + `Videomode`. +- **FR-002**: The feature MUST review the relevant historical sources as + read-only material before accepting any hardened proof claim. +- **FR-003**: The historical review MUST include `desklogo/desklogo.cc`, with + `set-logo.cc` and `tv_logo.cc` used only for asset and generator + boundary decisions. +- **FR-004**: The historical review MUST include `msgcls/testdyn.cpp`, + `msgcls/tlnmsg.cpp`, and `msgcls/tlnmsg.h`. +- **FR-005**: The historical review MUST include `tutorial/tvguid01.cc` + through `tutorial/tvguid16.cc`. +- **FR-006**: The historical review MUST include `videomode/test.cc`. +- **FR-007**: The feature MUST produce or update evidence that records, for + every covered example area, the historical core function, current managed + behavior, proof method, and intentional deviation or omission. +- **FR-008**: The feature MUST keep all 16 `Tutorial` steps individually + traceable, selectable, and reviewable. +- **FR-009**: The feature MUST require at least one meaningful functional + smoke proof per Wave-1 example area. +- **FR-010**: Smoke proof MUST verify behavior that is relevant to the + historical example intent, not only launch success, static text presence, or + project existence. +- **FR-011**: `Desklogo` proof MUST address logo or desktop intent, asset + source or replacement rationale, and undersized or unsupported display + fallback when applicable. +- **FR-012**: `MsgCls` proof MUST address custom message triggering, routing, + observable result, repeated-trigger stability, and intentional differences + from the historical message-class structure. +- **FR-013**: `Tutorial` proof MUST address each step's learning target or + defining behavior, token identity, and sequence relationship. +- **FR-014**: `Videomode` proof MUST address real capability outcome or clear + fallback, post-transition usability, and any modern platform limitation. +- **FR-015**: The feature MUST classify every Wave-1 helper, headless, or + direct proof path used by the relevant smokes as `SetupOnly`, + `PrimaryProof`, `SupplementalProof`, or `LegacyOrTemporary`. +- **FR-016**: Any helper classified as `PrimaryProof` MUST have a documented + reason why that is acceptable for functional hardening. +- **FR-017**: Any helper classified as `LegacyOrTemporary` MUST identify the + later visual-remediation responsibility it prepares. +- **FR-018**: Guide and evidence updates MUST document intentional historical + deviations in German first and English second at CEFR-B2 readability. +- **FR-019**: User-facing proof and guide text MUST remain text-first and + accessible for screen readers, Braille displays, and text browsers. +- **FR-020**: The feature MUST NOT add Wave-2, Wave-3, Wave-4, mouse-only, + broad framework-redesign, or visual-remediation scope. +- **FR-021**: The feature MUST state that `Lastenheft_Wave1-Visual-Component-Remediation.md` + is follow-up context and not part of this feature's acceptance boundary. +- **FR-022**: The feature MUST state that the current Wave-3 next-step marker + remains open and is not completed by this Wave-1 quality follow-up. + +### Constitution Requirements *(mandatory)* + +- **CR-001**: This feature targets existing Level-2 project artefacts and MUST + use the matching Level-2 Project Environment Registry entry from + `constitution.md` as binding project context. +- **CR-002**: User-facing artefacts MUST identify their A11Y review path: + WCAG 2.2 Level AA where generated or rendered documentation is affected, and + text-first review otherwise. +- **CR-003**: Learner-facing or shared guidance content MUST be German-first + and English-second unless a synchronized `.EN.md` companion is explicitly + selected. +- **CR-004**: The feature MUST decide during planning whether project + statistics and synchronized AI-agent guidance files require updates. If no + active feature context or shared workflow rule changes, the rationale for + leaving them unchanged MUST be recorded. +- **CR-005**: The primary implementation language remains C#/.NET for managed + example and smoke-test work and is on the project's MSL allow-list. +- **CR-006**: NIST SSDF and CWE Top 25 remain mandatory governance context. + Other security standards from `constitution.md` MUST be marked applicable or + `N/A` with rationale during planning. +- **CR-007**: OWASP ASVS is expected to be `N/A` unless planning introduces a + web, API, HTTP, authentication-bearing, or externally reachable service. +- **CR-008**: SBOM, VEX, and SLSA evidence MUST be evaluated for dependency or + releasable-artifact impact; no new runtime dependency is expected from this + specification. +- **CR-009**: AI-SBOM is `N/A` for this feature as specified because AI is used + only as a development aid and no runtime or product AI is delivered. If + planning adds runtime AI, models, datasets, AI infrastructure, or delivered + AI components, this decision MUST be re-evaluated. +- **CR-010**: CAPEC and Zero Trust are expected to be `N/A` unless planning + changes trust boundaries, externally reachable flows, or distributed/service + architecture. +- **CR-011**: The default governance evidence locations under `docs/security/` + SHOULD be used unless planning records an explicitly justified equivalent. +- **CR-012**: The installed Spec-Kit governance presets apply by default: + `security-governance`, `a11y-governance`, `agent-parity-governance`, + `architecture-governance`, `isaqb-architecture-governance`, and + `cross-platform-governance`. + +### Key Entities *(include if feature involves data)* + +- **Wave1FunctionalReview**: One review record for each covered example area; + identifies historical intent, current behavior, proof status, and deviation + status. +- **TutorialStepReview**: One review record for each token from `tvguid01` to + `tvguid16`; preserves individual learning-target traceability. +- **HistoricalSourceReference**: A read-only source reference used to justify a + proof or deviation decision. +- **SmokeProofClassification**: A proof record that distinguishes functional + behavior proof from startup, static text, setup, or supplemental proof. +- **HelperClassification**: A classification of helper or headless proof paths + as `SetupOnly`, `PrimaryProof`, `SupplementalProof`, or + `LegacyOrTemporary`. +- **IntentionalDeviationRecord**: A documented difference between historical + behavior and the managed example, including the reason and learner-facing + explanation requirement. + +## Success Criteria *(mandatory)* + +### Measurable Outcomes + +- **SC-001**: 100% of the four Wave-1 example areas have a documented + historical source, current behavior, proof method, and deviation or omission + decision. +- **SC-002**: 16 of 16 `Tutorial` steps remain individually traceable, + selectable, and covered by step-specific proof. +- **SC-003**: Each Wave-1 example area has at least one proof that verifies a + historically relevant function rather than only launch or static text. +- **SC-004**: 100% of Wave-1 helper or headless proof paths used by the + relevant smokes are classified with one of the four accepted labels. +- **SC-005**: 100% of intentional historical deviations found during this + feature are documented in evidence or learner-facing guidance. +- **SC-006**: A reviewer can determine from the feature evidence whether each + Wave-1 behavior is ready for later visual remediation, already adequately + proven for functional hardening, or intentionally out of scope. + +## Assumptions + +- The existing Wave-1 delivery remains accepted; this feature strengthens + proof quality and does not revoke prior acceptance. +- Historical sources under `tv203s/` are read-only and are not modified. +- `Lastenheft_Wave1-Visual-Component-Remediation.md` is follow-up context only. +- The current project next-step marker for Wave 3 remains open and is not + changed by this feature unless a later planning decision explicitly updates + project governance. +- No new runtime dependency, database, network service, runtime AI component, + mouse-only requirement, or broad framework redesign is expected. diff --git a/tests/web-a11y/playwright.config.ts b/tests/web-a11y/playwright.config.ts index 00473e1..26e85b2 100644 --- a/tests/web-a11y/playwright.config.ts +++ b/tests/web-a11y/playwright.config.ts @@ -4,12 +4,14 @@ import { defineConfig, devices } from '@playwright/test'; const port = Number.parseInt(process.env.PLAYWRIGHT_DOCFX_PORT ?? '8123', 10); const baseURL = process.env.PLAYWRIGHT_BASE_URL ?? `http://127.0.0.1:${port}`; const skipWebServer = process.env.PLAYWRIGHT_SKIP_WEBSERVER === '1'; +const chromiumChannel = process.env.PLAYWRIGHT_CHROMIUM_CHANNEL; const config = defineConfig({ testDir: path.join(__dirname, 'specs'), fullyParallel: true, forbidOnly: Boolean(process.env.CI), retries: process.env.CI ? 2 : 0, + timeout: 60_000, reporter: [ ['list'], ['html', { open: 'never', outputFolder: path.join(__dirname, 'playwright-report') }] @@ -19,12 +21,15 @@ const config = defineConfig({ headless: true, trace: 'on-first-retry', screenshot: 'only-on-failure', - video: 'retain-on-failure' + video: 'off' }, projects: [ { name: 'chromium', - use: { ...devices['Desktop Chrome'] } + use: { + ...devices['Desktop Chrome'], + ...(chromiumChannel ? { channel: chromiumChannel } : {}) + } } ] });