Prüfung von Hand auf Windows nach 10.0.0: Neuinstallation aus dem Release mit allen Pflicht-Harnesses, Wiederherstellung aus dem Backup, Browser-Komponente #222

New Issue

2026-10-13T19:52:48Z

torben commented

2026-10-13 19:52:48 +00:00

Sammelt die Prüfungen von Hand, die nach Release 10.0.0 nur noch auf dem Windows-Arbeitsrechner offen waren (Betreiberentscheidung 2026-10-13). Die Herkunfts-Issues sind geschlossen; ihre Bodies bleiben die Referenz für Hintergrund und Entscheidungen, ihre letzten Kriterien stehen hier. Dazu kommt die Klärung von #165 (Abschnitt F), die nur mit Copilot CLI geht, und das gibt es beim Betreiber nur unter Windows.

Auslöser (prio/waiting): ein Termin des Betreibers am Windows-Arbeitsrechner. Was hier abweicht, wird ein eigenes Issue (oder ein Patch), nicht ein Wiederöffnen der Herkunfts-Issues.

Was schon belegt ist (2026-10-13, nicht wiederholen)

Windows, Update der Arbeitsinstanz 8.x/9.x → 10.0.0 mit Copilot CLI: Migration 9.0.0 und 10.0.0, config migrate (Token in %APPDATA%\chemenu\<id>\secrets.json), Backup ins OneDrive (#186), Eingangskanal aus OneDrive (#213, geschlossen), Export mit after_publish, von M365 Copilot gelesen (#214).
Linux, Update einer privaten Instanz und eines zweiten, älteren Checkouts (config migrate je Checkout).
Linux, neues Setup aus dem Asset preflight.sh von v10.0.0: lädt, prüft sha256, entpackt in den eigenen Ordner, löscht sich, erfasst op. Secret-Datei (0600, Rechteprüfung) und op://-Verweise lösen auf. Browser-Komponente vollständig (#212 Kriterien 1–3).
Linux, VS Code Copilot Chat (/wiki-query): Der Trace enthält nur wikitool-Ereignisse, kein prompt.submitted – wie dokumentiert (VS Code Chat hat keine Hooks; Claude-Hooks nur mit chat.useClaudeHooks). Für #165 ohne Aussage.

Vorbereitung

Leerer Ordner mit höchstens 95 Zeichen, z. B. C:\Chemenu-T1 (ein .git eines leeren Instanz-Repos darf drin liegen). Für jeden Lauf ein eigener Ordner.
Das Release v10.0.0 (oder neuer) mit den Assets preflight.ps1, preflight.sh, setup-instance.md, preflight.md.
Installationssatz aus INSTALL.md, dem jeweiligen Agenten gegeben.

Prüfungen

A. Neuinstallation aus dem Release, je Pflicht-Harness (aus #140 Nachlauf, #151, #197)

Drei Läufe: Copilot CLI (pwsh, Asset preflight.ps1), Claude Code (Git Bash, Asset preflight.sh), Copilot in VS Code (pwsh).

Das Release trägt die Assets preflight.ps1, preflight.sh, setup-instance.md, preflight.md (einmal prüfen).
Je Lauf: Das Asset lädt den Tarball selbst (ohne --archive), meldet sha256 OK, installiert in seinen eigenen Ordner und löscht sich danach (#151 letztes Kriterium: pwsh und Git Bash).
Je Lauf: kein could not move tools. Tritt es doch auf, nennt die Zeile Eintrag und Systemmeldung, der Ordner ist auf den Stand vorher zurückgerollt, „nothing was installed“ – Ausgabe festhalten (#197; der Fehler ist sporadisch, ein grüner Lauf belegt die Behebung nicht allein, die Tests mit dem Haken sind der eigentliche Nachweis).
Je Lauf: Der Agent hält bei jedem Exit 42 an, installiert nichts selbst und weicht nicht aus (kein WSL, kein Hand-Patch, kein Push an publish vorbei) (#140 D6).
Je Lauf: tools/wikitool doctor gibt Ausgabe aus, ohne den Windows-Dialog „App auswählen“ (#167; tritt er auf, Befehl notieren und in #167 eintragen).
Je Lauf: doctor zeigt „Fußnoten“ korrekt – im Harness und direkt in pwsh bzw. Git Bash (#140/#152).
Unter Copilot (CLI und VS Code): doctor meldet nach Schritt 10 von setup-instance.md keine session-id-WARN (#140/#153).
Tritt ein Fehler auf, entsteht ein Bündel über tools/bugreport (nur eines, vgl. #220).

B. Einmalig während eines der Läufe (aus #140 Nachlauf)

Registry-PATH: Mitten in der Preflight-Schleife ein Tool so installieren, dass ein neuer PATH-Eintrag entsteht (z. B. rg per winget statt choco). Der erneute Preflight in derselben Harness-Sitzung findet es.
Store-Alias: Mit aktivem Alias python3 unter …\WindowsApps\ führt der Preflight ihn nicht aus und zeichnet die echte Python auf.
ASR: python.exe im venv läuft unter der Defender-Regel, -m pip installiert.

C. Wiederherstellung aus dem Backup (aus #186)

Ziel aus der Arbeitsinstanz: C:\OneDrive - <Firma>\Chemenu, Bare-Repo …\git, Maschinendaten …\<MASCHINE>\.

git clone "<ziel>\git" C:\Chemenu-R, dann git fsck --full ohne Fehler.
Inhalt von <ziel>\<MASCHINE>\ ohne .chemenu-backup.json in die neue Instanz kopieren.
Bootstrap (instructions/bootstrap.md): Preflight, instructions sync; Secret neu hinterlegen.
tools/wikitool doctor läuft ohne FAIL durch. (sync-folder OK, solange C:\Chemenu-R außerhalb des OneDrive liegt.)

D. Browser-Komponente unter Windows (aus #212)

pwsh -NoProfile -ExecutionPolicy Bypass -File tools/preflight.ps1 --with browser installiert; doctor meldet browser: available; ein zweiter Lauf ohne die Option lässt sie stehen.
render: sites/quotes-js.json = {"host": "quotes.toscrape.com", "path": "/js/", "summary": "Test: quotes drawn by JavaScript.", "render": true} → raw fetch https://quotes.toscrape.com/js/ liefert die Zitate im .html und rendered: true.
raw login: sites/quotes-login.json = {"host": "quotes.toscrape.com", "summary": "Test: login sandbox.", "session": {"login": "https://quotes.toscrape.com/login", "signed_in": {"tag": "a", "attr": "href", "value": "/logout"}}}, config set fetch.routes '{"quotes.toscrape.com": "session"}'. Vor dem Login endet raw fetch mit Exit 42; raw login quotes.toscrape.com öffnet das Fenster (beliebige Daten); danach steht session_quotes_toscrape_com in %APPDATA%\chemenu\<id>\secrets.json, und raw fetch liefert die Seite mit session: quotes.toscrape.com.
Geht das unter Windows nicht: raw login verweigert mit Exit 1 und klarer Meldung (Rückfall aus #169). In beiden Fällen sagt INSTALL.md danach, was gilt (heute: „Native Windows is not yet verified for it.“ – reine Prosa, kein Bump).

E. Optional: MCP-Server mit Eingangskanal `mcp`

Nicht als Update prüfbar (lief bisher nirgends). In einer der neuen Instanzen nach docs/how-to/set-up-the-mcp-server.md:

Mit einem Kanal handler: "mcp" in intake startet der Server und bietet submit an; eine Einreichung liegt in quarantine/ mit channel: mcp; ohne mcp-Kanal gibt es kein submit. (Unter Windows ist der MCP-Server zurückgestellt, #160 – dann unter Linux.)

F. #165: Führt Copilot CLI die Claude-Hooks mit aus?

Copilot CLI liest laut Doku auch .claude/settings.json; dann landet je Prompt neben dem eigenen prompt.submitted (source: copilot-cli) ein zweites mit source: claude-code in derselben Sitzung. Prüfbar nur mit Copilot CLI (VS Code Chat hat keine Hooks, siehe oben); das Verhalten hängt am CLI, nicht an der Plattform, Windows genügt.

Zuerst die vorhandenen Daten: Die Arbeitsinstanz hat Telemetrie an und Copilot-CLI-Sitzungen vom 2026-10-13. Hook-Ereignisse liegen unter Copilots eigener Sitzungs-ID, nicht unter einer gesetzten WIKITOOL_SESSION_ID. Im Instanz-Root, pwsh:

Select-String -Path reports\telemetry\*\trace.jsonl -Pattern '"prompt.submitted"' |
  ForEach-Object { $j = $_.Line | ConvertFrom-Json; "{0}`t{1}`t{2}" -f $j.ts, $j.session_id, $j.source } |
  Sort-Object

Reichen die Daten nicht (keine copilot-cli-Zeilen): copilot im Instanz-Root starten, ohne WIKITOOL_SESSION_ID, einen Prompt ohne Werkzeuge schicken („Antworte nur mit OK.“), /exit, dann denselben Befehl.

Ergebnis eingetragen und in #165 übernommen:
- Zu einer Sitzungs-ID nur copilot-cli → #165 widerlegt, schließen.
- Zur selben Sitzungs-ID je Prompt copilot-cli und claude-code, fast zeitgleich → #165 bestätigt, status/unconfirmed weg, /stack-dev #165 (vor #82).
- claude-code nur unter eigenen Sitzungs-IDs → echte Claude-Code-Sitzungen, ohne Aussage.

Abschluss

Jede Abweichung ist behoben und getestet oder als eigenes Issue erfasst. Ergebnisse werden hier im Body eingetragen; geschlossen wird mit /stack-close.

Herkunft

#140 (Dach Installation/Windows, Nachlauf), #151 (Preflight, Asset-Weg aus echtem Release), #197 (Asset-Preflight: Verschieben), #186 (Backup: Wiederherstellung), #212 (Browser-Komponente: Windows) – geschlossen am 2026-10-13 mit Verweis hierher.
Weiter offen und eigenständig: #167 (Dialog „App auswählen“ unter Copilot CLI), #165 (doppelte Trace-Ereignisse unter Copilot CLI; die Klärung läuft in Abschnitt F, das Ergebnis geht nach #165).

Sammelt die Prüfungen von Hand, die nach Release 10.0.0 nur noch auf dem Windows-Arbeitsrechner offen waren (Betreiberentscheidung 2026-10-13). Die Herkunfts-Issues sind geschlossen; ihre Bodies bleiben die Referenz für Hintergrund und Entscheidungen, ihre letzten Kriterien stehen hier. Dazu kommt die Klärung von #165 (Abschnitt F), die nur mit Copilot CLI geht, und das gibt es beim Betreiber nur unter Windows. **Auslöser (`prio/waiting`):** ein Termin des Betreibers am Windows-Arbeitsrechner. Was hier abweicht, wird ein eigenes Issue (oder ein Patch), nicht ein Wiederöffnen der Herkunfts-Issues. ## Was schon belegt ist (2026-10-13, nicht wiederholen) - **Windows, Update der Arbeitsinstanz** 8.x/9.x → 10.0.0 mit Copilot CLI: Migration 9.0.0 und 10.0.0, `config migrate` (Token in `%APPDATA%\chemenu\<id>\secrets.json`), Backup ins OneDrive (#186), Eingangskanal aus OneDrive (#213, geschlossen), Export mit `after_publish`, von M365 Copilot gelesen (#214). - **Linux, Update** einer privaten Instanz und eines zweiten, älteren Checkouts (`config migrate` je Checkout). - **Linux, neues Setup** aus dem Asset `preflight.sh` von v10.0.0: lädt, prüft sha256, entpackt in den eigenen Ordner, löscht sich, erfasst `op`. Secret-Datei (`0600`, Rechteprüfung) und `op://`-Verweise lösen auf. Browser-Komponente vollständig (#212 Kriterien 1–3). - **Linux, VS Code Copilot Chat** (`/wiki-query`): Der Trace enthält nur `wikitool`-Ereignisse, kein `prompt.submitted` – wie dokumentiert (VS Code Chat hat keine Hooks; Claude-Hooks nur mit `chat.useClaudeHooks`). Für #165 ohne Aussage. ## Vorbereitung - Leerer Ordner mit höchstens 95 Zeichen, z. B. `C:\Chemenu-T1` (ein `.git` eines leeren Instanz-Repos darf drin liegen). Für jeden Lauf ein eigener Ordner. - Das Release v10.0.0 (oder neuer) mit den Assets `preflight.ps1`, `preflight.sh`, `setup-instance.md`, `preflight.md`. - Installationssatz aus `INSTALL.md`, dem jeweiligen Agenten gegeben. ## Prüfungen ### A. Neuinstallation aus dem Release, je Pflicht-Harness (aus #140 Nachlauf, #151, #197) Drei Läufe: **Copilot CLI** (pwsh, Asset `preflight.ps1`), **Claude Code** (Git Bash, Asset `preflight.sh`), **Copilot in VS Code** (pwsh). - [ ] Das Release trägt die Assets `preflight.ps1`, `preflight.sh`, `setup-instance.md`, `preflight.md` (einmal prüfen). - [ ] Je Lauf: Das Asset lädt den Tarball selbst (**ohne** `--archive`), meldet `sha256 OK`, installiert in seinen eigenen Ordner und löscht sich danach (#151 letztes Kriterium: pwsh **und** Git Bash). - [ ] Je Lauf: kein `could not move tools`. Tritt es doch auf, nennt die Zeile Eintrag und Systemmeldung, der Ordner ist auf den Stand vorher zurückgerollt, „nothing was installed“ – Ausgabe festhalten (#197; der Fehler ist sporadisch, ein grüner Lauf belegt die Behebung nicht allein, die Tests mit dem Haken sind der eigentliche Nachweis). - [ ] Je Lauf: Der Agent hält bei jedem Exit 42 an, installiert nichts selbst und weicht nicht aus (kein WSL, kein Hand-Patch, kein Push an `publish` vorbei) (#140 D6). - [ ] Je Lauf: `tools/wikitool doctor` gibt Ausgabe aus, ohne den Windows-Dialog „App auswählen“ (#167; tritt er auf, Befehl notieren und in #167 eintragen). - [ ] Je Lauf: `doctor` zeigt „Fußnoten“ korrekt – im Harness und direkt in pwsh bzw. Git Bash (#140/#152). - [ ] Unter Copilot (CLI und VS Code): `doctor` meldet nach Schritt 10 von `setup-instance.md` keine `session-id`-WARN (#140/#153). - [ ] Tritt ein Fehler auf, entsteht ein Bündel über `tools/bugreport` (nur eines, vgl. #220). ### B. Einmalig während eines der Läufe (aus #140 Nachlauf) - [ ] **Registry-PATH:** Mitten in der Preflight-Schleife ein Tool so installieren, dass ein **neuer** PATH-Eintrag entsteht (z. B. `rg` per winget statt choco). Der erneute Preflight in derselben Harness-Sitzung findet es. - [ ] **Store-Alias:** Mit aktivem Alias `python3` unter `…\WindowsApps\` führt der Preflight ihn nicht aus und zeichnet die echte Python auf. - [ ] **ASR:** `python.exe` im venv läuft unter der Defender-Regel, `-m pip` installiert. ### C. Wiederherstellung aus dem Backup (aus #186) Ziel aus der Arbeitsinstanz: `C:\OneDrive - <Firma>\Chemenu`, Bare-Repo `…\git`, Maschinendaten `…\<MASCHINE>\`. - [ ] `git clone "<ziel>\git" C:\Chemenu-R`, dann `git fsck --full` ohne Fehler. - [ ] Inhalt von `<ziel>\<MASCHINE>\` **ohne** `.chemenu-backup.json` in die neue Instanz kopieren. - [ ] Bootstrap (`instructions/bootstrap.md`): Preflight, `instructions sync`; Secret neu hinterlegen. - [ ] `tools/wikitool doctor` läuft ohne `FAIL` durch. (`sync-folder` OK, solange `C:\Chemenu-R` außerhalb des OneDrive liegt.) ### D. Browser-Komponente unter Windows (aus #212) - [ ] `pwsh -NoProfile -ExecutionPolicy Bypass -File tools/preflight.ps1 --with browser` installiert; `doctor` meldet `browser: available`; ein zweiter Lauf ohne die Option lässt sie stehen. - [ ] `render`: `sites/quotes-js.json` = `{"host": "quotes.toscrape.com", "path": "/js/", "summary": "Test: quotes drawn by JavaScript.", "render": true}` → `raw fetch https://quotes.toscrape.com/js/` liefert die Zitate im `.html` und `rendered: true`. - [ ] `raw login`: `sites/quotes-login.json` = `{"host": "quotes.toscrape.com", "summary": "Test: login sandbox.", "session": {"login": "https://quotes.toscrape.com/login", "signed_in": {"tag": "a", "attr": "href", "value": "/logout"}}}`, `config set fetch.routes '{"quotes.toscrape.com": "session"}'`. Vor dem Login endet `raw fetch` mit Exit 42; `raw login quotes.toscrape.com` öffnet das Fenster (beliebige Daten); danach steht `session_quotes_toscrape_com` in `%APPDATA%\chemenu\<id>\secrets.json`, und `raw fetch` liefert die Seite mit `session: quotes.toscrape.com`. - [ ] Geht das unter Windows nicht: `raw login` verweigert mit Exit 1 und klarer Meldung (Rückfall aus #169). In beiden Fällen sagt `INSTALL.md` danach, was gilt (heute: „Native Windows is not yet verified for it.“ – reine Prosa, kein Bump). ### E. Optional: MCP-Server mit Eingangskanal `mcp` Nicht als Update prüfbar (lief bisher nirgends). In einer der neuen Instanzen nach `docs/how-to/set-up-the-mcp-server.md`: - [ ] Mit einem Kanal `handler: "mcp"` in `intake` startet der Server und bietet `submit` an; eine Einreichung liegt in `quarantine/` mit `channel: mcp`; ohne `mcp`-Kanal gibt es kein `submit`. (Unter Windows ist der MCP-Server zurückgestellt, #160 – dann unter Linux.) ### F. #165: Führt Copilot CLI die Claude-Hooks mit aus? Copilot CLI liest laut Doku auch `.claude/settings.json`; dann landet je Prompt neben dem eigenen `prompt.submitted` (`source: copilot-cli`) ein zweites mit `source: claude-code` in **derselben** Sitzung. Prüfbar nur mit Copilot CLI (VS Code Chat hat keine Hooks, siehe oben); das Verhalten hängt am CLI, nicht an der Plattform, Windows genügt. **Zuerst die vorhandenen Daten:** Die Arbeitsinstanz hat Telemetrie an und Copilot-CLI-Sitzungen vom 2026-10-13. Hook-Ereignisse liegen unter Copilots eigener Sitzungs-ID, nicht unter einer gesetzten `WIKITOOL_SESSION_ID`. Im Instanz-Root, pwsh: ```powershell Select-String -Path reports\telemetry\*\trace.jsonl -Pattern '"prompt.submitted"' | ForEach-Object { $j = $_.Line | ConvertFrom-Json; "{0}`t{1}`t{2}" -f $j.ts, $j.session_id, $j.source } | Sort-Object ``` Reichen die Daten nicht (keine `copilot-cli`-Zeilen): `copilot` im Instanz-Root starten, **ohne** `WIKITOOL_SESSION_ID`, einen Prompt ohne Werkzeuge schicken („Antworte nur mit OK.“), `/exit`, dann denselben Befehl. - [ ] Ergebnis eingetragen und in #165 übernommen: - Zu einer Sitzungs-ID nur `copilot-cli` → #165 widerlegt, schließen. - Zur **selben** Sitzungs-ID je Prompt `copilot-cli` **und** `claude-code`, fast zeitgleich → #165 bestätigt, `status/unconfirmed` weg, `/stack-dev #165` (vor #82). - `claude-code` nur unter eigenen Sitzungs-IDs → echte Claude-Code-Sitzungen, ohne Aussage. ## Abschluss Jede Abweichung ist behoben und getestet oder als eigenes Issue erfasst. Ergebnisse werden hier im Body eingetragen; geschlossen wird mit `/stack-close`. ## Herkunft - #140 (Dach Installation/Windows, Nachlauf), #151 (Preflight, Asset-Weg aus echtem Release), #197 (Asset-Preflight: Verschieben), #186 (Backup: Wiederherstellung), #212 (Browser-Komponente: Windows) – geschlossen am 2026-10-13 mit Verweis hierher. - Weiter offen und eigenständig: #167 (Dialog „App auswählen“ unter Copilot CLI), #165 (doppelte Trace-Ereignisse unter Copilot CLI; die Klärung läuft in Abschnitt F, das Ergebnis geht nach #165).