Skip to content

docs: correct Store build and WACK verification instructions #4

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
ellmos-multi-bot merged 1 commit into from
Oct 21, 2026
Merged

docs: correct Store build and WACK verification instructions #4

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,8 @@

## Unreleased

- Correct the Store build guide: require Python 3.12+, explain the external build-scanner prerequisite and output override, use repository-relative SDK packaging paths, and distinguish static preflight from actual WACK execution and certification. Remove a private workstation command from the public instructions.

- WCAG 2.1 AA & BITV 2.0 Accessibility, Keyboard Navigation, Contrast & Screenreader Hardening (SOFTWARE_UX_AND_ACCESSIBILITY_REVIEW) on 2026-10-11:
- Focus and Contrast Hardening: Audited and adjusted status color contrast ratios in `StatusWindow` (`src/codex_logdatenbank_wartung/tray_status_window.py`) to conform to WCAG 2.1 AA standards (`zombie_label` `#1d6f42` > 5:1 contrast, `result_label` `#2b2b2b` > 12:1 contrast); added high-visibility focus indicator rings (`outline: 2px solid #005a9e;`).
- Explicit Focus Policy: Set `Qt.FocusPolicy.StrongFocus` on all 21 interactive controls across `StatusWindow` ensuring complete tab stop coverage.
Expand Down
45 changes: 29 additions & 16 deletions releases/windowsstore/BUILD.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@

## 1. Voraussetzungen

- **Python 3.11+** mit installierten Dependencies aus `requirements.txt`
- **Python 3.12+** gemäß `pyproject.toml`; Build-Abhängigkeiten aus `.[build]`
- **Windows 10/11 x64**
- **Windows SDK** (Build 17763 oder neuer) für `MakeAppx.exe` und `SignTool.exe`
- **Zertifikat (PFX):** Zum lokalen Testen reicht ein selbstsigniertes Zertifikat; für die Einreichung im Partner Center signiert Microsoft das Paket automatisch.
Expand All @@ -11,15 +11,23 @@

## 2. Schritt 1: Python-Executable (EXE) bauen

Der Build erfolgt reproduzierbar über das Projekt-Skript `build_exe.bat`:
Alle Befehle werden im Repository-Root ausgeführt. `build_exe.bat` ist derzeit
an die Build-Umgebung der Maintainer gebunden: Es verlangt einen externen
`build_exclude_scanner.py`, der nicht mit diesem Repository ausgeliefert wird.
Fehlt dieser Scanner, bricht das Skript ab. Ein frischer Checkout allein reicht
für diesen Buildweg daher noch nicht aus.

In der eingerichteten Build-Umgebung kann das Ausgabeziel explizit gesetzt werden:

```cmd
build_exe.bat
set "CARECENTER_DIST_DIR=%CD%\dist"
call build_exe.bat
```

Dies erzeugt:
- `dist\CareCenterForCodex.exe` (Stand-alone PyInstaller Executable mit Tray-Unterstützung und Assets)
- Verifiziert den Start und die Signatur
Das Skript erzeugt `dist\CareCenterForCodex.exe` mit Tray-Unterstützung und Assets
und schreibt Build-Provenienz. Ohne `CARECENTER_DIST_DIR` verwendet es sein eigenes
voreingestelltes Ausgabeziel. Es führt weder einen Starttest noch eine
Authenticode-Signaturprüfung durch; diese Prüfungen müssen separat erfolgen.

---

Expand All @@ -37,30 +45,35 @@ Erwartetes Ergebnis: **AUDIT PASSED (6/6 Checks OK - Vorbereitung vollständig)*

## 4. Schritt 3: MSIX-Paket erstellen

Das MSIX-Paket wird über das zentrale Pipeline-Werkzeug `_STORE/msstore_build_msix.ps1` oder MakeAppx gebaut:
Das Windows SDK stellt `MakeAppx.exe` bereit. Voraussetzung ist ein vollständig
vorbereitetes Staging-Verzeichnis `store_package\CareCenter for Codex` mit der
geprüften EXE, dem passenden `AppxManifest.xml` und allen referenzierten Assets.
Der EXE-Build kopiert seine Ausgabe nicht automatisch dorthin. Vor dem Packen
Staging und Manifest auf Übereinstimmung mit dem gewünschten Build prüfen.

```powershell
# Variante A: Über zentrales Pipeline-Skript
powershell -ExecutionPolicy Bypass -File "C:\Users\lukas\OneDrive\.TOPICS\.SOFTWARE\_STORE\msstore_build_msix.ps1" `
-ProjectRoot "C:\_Local_DEV\repos\CareCenter-for-Codex" `
-ExePath "C:\_Local_DEV\repos\CareCenter-for-Codex\dist\CareCenterForCodex.exe"

# Variante B: MakeAppx direkt
MakeAppx.exe pack /d "C:\_Local_DEV\repos\CareCenter-for-Codex\store_package\CareCenter for Codex" /p "releases\windowsstore\CareCenterForCodex.msix" /nv
MakeAppx.exe pack /d "store_package\CareCenter for Codex" /p "releases\windowsstore\CareCenterForCodex.msix"
```

---

## 5. Schritt 4: WACK-Preflight & Zertifizierungstest
## 5. Schritt 4: Statischer Preflight und echte WACK-Prüfung

```powershell
python scripts\run_windows_wack.py
python scripts\run_windows_wack.py --preflight-only
```

Erzeugt strukturierte Berichte unter `releases\windowsstore\test_reports\`:
- `wack_preflight_YYYYMMDD.xml`
- `wack_preflight_YYYYMMDD.json`

Dieses Skript prüft statische Store-Materialien. Es startet das Windows App
Certification Kit nicht, auch nicht bei Übergabe von `--msix`. Ein erfolgreicher
Preflight ist daher kein bestandener WACK-Test und keine Store-Zertifizierung.
Das fertige Paket muss separat mit dem installierten Windows App Certification
Kit geprüft werden. Einen dabei erzeugten XML-Bericht kann das Skript mit
`--review-wack-report <Bericht.xml>` auswerten; es führt den Test dabei nicht aus.

---

## 6. Schritt 5: Microsoft Partner Center Einreichung
Expand Down
Loading