Initial commit

docs/developer-push-policy.md

@@ -0,0 +1,337 @@
+# Entwicklerhinweise: Anforderungen bei Push und Pull Request
+
+Dieses Repository verwendet Jenkins-basierte PR- und Branch-Policies.  
+Ziel ist, dass Code bereits **vor dem Merge** bestimmte Qualitätsanforderungen erfüllt.
+
+Diese Datei beschreibt, **was bei einem Push erwartet wird**, **was in Jenkins geprüft wird** und **wie du Fehler lokal vermeiden kannst**.
+
+---
+
+## Überblick
+
+Bei Pushes und Pull Requests werden automatisierte Policies ausgeführt.
+
+Je nach Build-Typ gelten leicht unterschiedliche Vergleichsregeln:
+
+- **bei Pull Requests** wird gegen den Zielbranch verglichen, z. B. `origin/main`
+- **bei normalen Branch-Builds** wird auf eine lokale Vergleichsbasis zurückgefallen, z. B. `HEAD~1`, falls kein Zielbranch-Ref verfügbar ist
+
+Die eigentlichen Qualitätsanforderungen bleiben gleich.
+
+---
+
+## Was beim Push / PR geprüft wird
+
+### 1. `.clang-format` muss vorhanden sein
+Im Repository-Root muss eine Datei `.clang-format` liegen.
+
+Ohne diese Datei schlägt der Policy-Check fehl.
+
+---
+
+### 2. Geänderte C/C++-Dateien müssen korrekt formatiert sein
+Für geänderte C/C++-Dateien wird `clang-format` geprüft.
+
+Betroffen sind insbesondere Dateien mit diesen Endungen:
+
+- `.c`
+- `.cc`
+- `.cpp`
+- `.cxx`
+- `.h`
+- `.hh`
+- `.hpp`
+- `.hxx`
+
+Wenn eine Datei nicht korrekt formatiert ist, schlägt der Build fehl.
+
+#### Lokal prüfen
+```bash
+clang-format --dry-run --Werror <datei>
+```
+
+#### Lokal automatisch formatieren
+```bash
+clang-format -i <datei>
+```
+
+Beispiel:
+```bash
+clang-format -i main.cpp tests/test_main.cpp
+```
+
+---
+
+### 3. Zu geänderten C/C++-Dateien muss ein passender Test existieren
+Wenn du eine C/C++-Datei änderst, muss ein passender Test vorhanden sein.
+
+Es wird nach Tests in diesen Verzeichnissen gesucht:
+
+- `tests/`
+- `test/`
+- `qt6-after/qt6-migrated-benchmark/tests/`
+
+Unterstützte typische Testnamen sind zum Beispiel:
+
+- `test_<name>.cpp`
+- `<name>_test.cpp`
+- `<name>test.cpp`
+- `<name>gtest.cpp`
+
+Zusätzlich erkennt die Policy auch ähnliche Dateinamen heuristisch, solange `test` oder `gtest` im Dateinamen vorkommt.
+
+#### Beispiel
+Wenn du `main.cpp` änderst, ist z. B. passend:
+
+```text
+tests/test_main.cpp
+```
+
+Wenn kein passender Test gefunden wird, schlägt der Build fehl.
+
+---
+
+### 4. Nur gültig SSH-signierte Commits sind erlaubt
+Neue Commits im geprüften Bereich müssen gültig **mit SSH signiert** sein.
+
+Die Jenkins-Policy prüft Commit-Signaturen gegen eine erlaubte Signiererdatei:
+
+```text
+ci/allowed_signers
+```
+
+Wenn ein Commit:
+
+- nicht signiert ist
+- nicht per SSH signiert ist
+- mit einem nicht erlaubten SSH-Schlüssel signiert ist
+
+dann schlägt der Build fehl.
+
+---
+
+## SSH-signierte Commits einrichten
+
+### 1. SSH-Signing-Key erzeugen
+Falls du noch keinen dedizierten Signing-Key hast:
+
+```bash
+ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_signing -C "dein.name@example.com"
+```
+
+---
+
+### 2. Git für SSH-Signing konfigurieren
+
+```bash
+git config --global gpg.format ssh
+git config --global user.signingkey ~/.ssh/id_ed25519_signing.pub
+git config --global commit.gpgsign true
+```
+
+Damit werden neue Commits automatisch mit deinem SSH-Key signiert.
+
+---
+
+### 3. Öffentlichen Schlüssel zur Allowlist hinzufügen
+Dein öffentlicher Schlüssel muss in `ci/allowed_signers` eingetragen sein.
+
+Format:
+
+```text
+<principal> <public-key>
+```
+
+Beispiel:
+
+```text
+max.mustermann@example.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA...
+```
+
+Ohne Eintrag in `ci/allowed_signers` wird dein signierter Commit in Jenkins trotzdem abgelehnt.
+
+---
+
+### 4. Optional: lokale Verifikation aktivieren
+Wenn du lokal dieselbe Vertrauenskette wie Jenkins verwenden willst:
+
+```bash
+mkdir -p ~/.config/git
+cp ci/allowed_signers ~/.config/git/allowed_signers
+git config --global gpg.ssh.allowedSignersFile ~/.config/git/allowed_signers
+```
+
+---
+
+### 5. Signierten Commit erstellen
+```bash
+git add .
+git commit -S -m "Meine Änderung"
+git push
+```
+
+Wenn `commit.gpgsign=true` gesetzt ist, signiert Git Commits in der Regel automatisch.
+
+---
+
+### 6. Signatur lokal prüfen
+```bash
+git log --show-signature -1
+git verify-commit HEAD
+```
+
+---
+
+## Lokaler Minimal-Check vor dem Push
+
+Vor dem Push solltest du mindestens diese Schritte ausführen:
+
+### Format anwenden
+```bash
+clang-format -i main.cpp tests/test_main.cpp
+```
+
+### Policy lokal ausführen
+```bash
+python3 ci/check_pr_policies.py
+```
+
+## Projekt lokal im CI-Container bauen
+
+Zuerst das lokale CI-Image bauen:
+
+```bash
+docker build -t lifemaps/ci-cpp:latest -f Dockerfile.ci .
+```
+
+Danach das Projekt im Container bauen und testen:
+
+```bash
+docker run --rm -it \
+  -v "$PWD:/workspace" \
+  -w /workspace \
+  lifemaps/ci-cpp:latest \
+  bash -lc '
+    cmake -S . -B build -G Ninja -DCMAKE_BUILD_TYPE=Debug &&
+    cmake --build build --parallel &&
+    ctest --test-dir build --output-on-failure
+  '
+```
+
+Damit wird dieselbe Toolchain verwendet wie in der Jenkins-CI.
+
+
+## Policy-Check lokal im CI-Container ausführen
+
+```bash
+docker run --rm -it \
+  -v "$PWD:/workspace" \
+  -w /workspace \
+  lifemaps/ci-cpp:latest \
+  bash -lc 'python3 ci/check_pr_policies.py'
+```
+
+---
+
+## Verhalten in Jenkins
+
+Die Jenkins-Pipeline umfasst typischerweise diese Stages:
+
+1. **Checkout**
+2. **Policy Checks**
+3. **Configure**
+4. **Build**
+5. **Test**
+6. **Cleanup**
+
+Wenn die Policy-Checks fehlschlagen, werden die späteren Build- und Test-Stages nicht mehr ausgeführt.
+
+---
+
+## Typische Fehlerursachen
+
+### Formatfehler
+Beispiel:
+```text
+ERROR: Formatfehler in tests/test_main.cpp
+```
+
+#### Lösung
+```bash
+clang-format -i tests/test_main.cpp
+```
+
+---
+
+### Kein passender Test gefunden
+Beispiel:
+```text
+ERROR: Kein passender Test unter tests/, test/ oder qt6-after/qt6-migrated-benchmark/tests für main.cpp gefunden.
+```
+
+#### Lösung
+- passenden Test anlegen
+- Testdatei passend benennen
+- Test in einem der erlaubten Testverzeichnisse ablegen
+
+---
+
+### Commit nicht gültig SSH-signiert
+Beispiel:
+```text
+ERROR: Commit ist nicht gültig mit erlaubtem SSH-Signierer signiert: <sha>
+```
+
+#### Lösung
+- SSH-Signing lokal korrekt konfigurieren
+- prüfen, ob der richtige Schlüssel verwendet wird
+- prüfen, ob der öffentliche Schlüssel in `ci/allowed_signers` eingetragen ist
+- Commit neu erstellen oder neu signieren
+
+---
+
+### `.clang-format` fehlt
+Beispiel:
+```text
+ERROR: .clang-format fehlt im Repository-Root.
+```
+
+#### Lösung
+- `.clang-format` im Repository-Root anlegen oder wiederherstellen
+
+---
+
+## Empfohlener Workflow
+
+1. Feature-Branch erstellen
+2. Änderungen implementieren
+3. Test ergänzen oder anpassen
+4. Code formatieren
+5. Commit SSH-signiert erstellen
+6. lokal Policy, Build und Tests ausführen
+7. pushen
+8. Pull Request öffnen
+9. Jenkins-Ergebnis prüfen
+10. erst bei grünem Status mergen
+
+---
+
+## Kurz-Checkliste vor jedem Push
+
+- [ ] C/C++-Dateien sind formatiert
+- [ ] passender Test existiert
+- [ ] Commit ist SSH-signiert
+- [ ] öffentlicher Schlüssel steht in `ci/allowed_signers`
+- [ ] `python3 ci/check_pr_policies.py` läuft erfolgreich
+- [ ] Build und Tests laufen lokal
+
+---
+
+## Ziel der Regeln
+
+Die Policies sollen sicherstellen, dass:
+
+- Code konsistent formatiert ist
+- Änderungen nachvollziehbar getestet sind
+- nur autorisierte Signierer Commits einbringen
+- PRs frühzeitig automatisiert validiert werden

docs/entire-headless-in-eu-setup.md

@@ -0,0 +1,336 @@
+# Entire auf Headless-Server mit EU-Kontext einrichten
+
+Diese Anleitung beschreibt die Einrichtung von Entire auf einem Headless-Host mit bestehendem Git-Repository auf einem eigenen Gitea-Server und Nutzung des **EU-Kontexts**.
+
+## Ziel
+
+- Entire ohne GUI/Browser auf dem Server verwenden
+- Login über Device-Code-Flow
+- Tokens ohne OS-Keyring in Datei speichern
+- EU-Jurisdiktion / EU-Cluster verwenden
+- Entire lokal in einem bestehenden Git-Repository aktivieren
+
+---
+
+## Voraussetzungen
+
+- `entire` CLI ist installiert
+- Zugriff per SSH auf den Headless-Server
+- funktionierendes lokales Git-Checkout
+- `origin`-Remote ist gesetzt
+- Browser auf einem **anderen lokalen Rechner** verfügbar
+
+Beispiel prüfen:
+
+```bash
+git remote -v
+```
+
+Beispielausgabe:
+
+```bash
+origin  git@devel:lifemaps/qt-migration-copilot-demo.git (fetch)
+origin  git@devel:lifemaps/qt-migration-copilot-demo.git (push)
+```
+
+---
+
+## 1. Token-Speicherung für Headless-Betrieb aktivieren
+
+Auf Headless-Systemen gibt es oft keinen Linux-Keyring (`org.freedesktop.secrets`).  
+Deshalb sollten Entire-Tokens in einer Datei gespeichert werden.
+
+Empfohlene Umgebungsvariablen:
+
+```bash
+export ENTIRE_TOKEN_STORE=file
+export ENTIRE_TOKEN_STORE_PATH="$HOME/.config/entire/tokens.json"
+export ACCESSIBLE=1
+```
+
+Temporär in der aktuellen Shell:
+
+```bash
+export ENTIRE_TOKEN_STORE=file
+export ENTIRE_TOKEN_STORE_PATH="$HOME/.config/entire/tokens.json"
+export ACCESSIBLE=1
+```
+
+Dauerhaft in `~/.bashrc`:
+
+```bash
+echo 'export ENTIRE_TOKEN_STORE=file' >> ~/.bashrc
+echo 'export ENTIRE_TOKEN_STORE_PATH="$HOME/.config/entire/tokens.json"' >> ~/.bashrc
+echo 'export ACCESSIBLE=1' >> ~/.bashrc
+source ~/.bashrc
+```
+
+---
+
+## 2. Im EU-Kontext anmelden
+
+Für Headless-Systeme den Device-Code-Flow verwenden:
+
+```bash
+entire login --device --server https://eu.auth.entire.io
+```
+
+Das CLI zeigt dann etwa:
+
+- einen **Device Code**
+- eine **Login-URL**
+
+Die URL im Browser **auf dem lokalen Rechner** öffnen und die Anmeldung dort bestätigen.
+
+### Wichtiger Hinweis
+
+Wenn auf dem Server kein Browser verfügbar ist, ist eine Meldung wie diese normal:
+
+```text
+Warning: failed to open browser: xdg-open not found
+```
+
+Das ist **nicht** das eigentliche Problem.
+
+Falls Entire versucht, Tokens im Keyring zu speichern und dabei fehlschlägt, war `ENTIRE_TOKEN_STORE=file` nicht gesetzt.
+
+---
+
+## 3. Login prüfen
+
+Nach erfolgreicher Anmeldung:
+
+```bash
+entire auth status
+```
+
+Beispiel:
+
+```text
+Logged in to https://eu.auth.entire.io
+Context: eu.auth.entire.io
+Token: stored in file /home/<user>/.config/entire/tokens.json
+```
+
+Falls mehrere Kontexte existieren:
+
+```bash
+entire auth contexts
+entire auth use --help
+```
+
+---
+
+## 4. Prüfen, ob wirklich EU verwendet wird
+
+Zusätzlich zum Login-Kontext sollte geprüft werden, auf welchem Cluster die Entire-Repositories liegen.
+
+Projekt-Repositories anzeigen:
+
+```bash
+entire repo list <project-id>
+```
+
+Wenn in der Spalte `CLUSTER` z. B. Folgendes erscheint:
+
+```text
+aws-eu-central-1.entire.io
+```
+
+dann liegen diese Repositories auf einem **EU-Cluster**.
+
+### Empfohlener Doppel-Check
+
+```bash
+entire auth status
+entire repo list <project-id>
+```
+
+EU ist praktisch bestätigt, wenn:
+
+- `Context: eu.auth.entire.io` aktiv ist
+- die Repositories auf `aws-eu-central-1.entire.io` liegen
+
+---
+
+## 5. Entire im lokalen Repository aktivieren
+
+In das lokale Repository wechseln:
+
+```bash
+cd ~/coplint.d/qt-migration-copilot-demo
+```
+
+Dann Entire aktivieren:
+
+```bash
+entire enable
+```
+
+Status prüfen:
+
+```bash
+entire status
+```
+
+Beispiel:
+
+```text
+● Enabled · branch bugfix/ci-pipeline-commissioning
+  Agents · Copilot CLI
+```
+
+---
+
+## 6. Agent-Integration prüfen oder ergänzen
+
+Verfügbare Agenten anzeigen:
+
+```bash
+entire agent list
+```
+
+Hilfe für das Hinzufügen:
+
+```bash
+entire agent add --help
+```
+
+Neuen Agenten hinzufügen:
+
+```bash
+entire agent add <name>
+```
+
+Danach erneut prüfen:
+
+```bash
+entire status
+```
+
+---
+
+## 7. Unterschied zwischen lokalem Git-Repo und Entire-Repo verstehen
+
+Wichtig: Entire verwendet hier **zwei verschiedene Konzepte**.
+
+### Lokales Git-Repository
+Das echte Code-Repository, z. B.:
+
+```bash
+git@devel:lifemaps/qt-migration-copilot-demo.git
+```
+
+### Entire-Repository
+Ein separates Objekt in Entire, verwaltet über:
+
+```bash
+entire repo list <project-id>
+entire repo get <repo> --project <project-id>
+entire repo create <name> --project <project-id>
+```
+
+### Konsequenz
+
+`entire enable` aktiviert das **lokale Git-Repository**,  
+aber es erzeugt **nicht automatisch** ein neues `entire repo`-Objekt.
+
+Darum kann es sein, dass:
+
+- `entire status` = aktiviert
+- aber `entire repo list <project-id>` dein lokales Repo **nicht** zeigt
+
+Das ist normales Verhalten.
+
+---
+
+## 8. Optional: Entire-Repo im Projekt anlegen
+
+Wenn zusätzlich ein eigenes Entire-Repo-Objekt für das lokale Projekt gewünscht ist:
+
+```bash
+entire repo create qt-migration-copilot-demo --project <project-id>
+```
+
+Danach prüfen:
+
+```bash
+entire repo list <project-id>
+```
+
+### Hinweis
+
+Nach bisherigem CLI-Verhalten wird dabei nur ein **Entire-internes Repo-Objekt** erzeugt.  
+Es gibt in der gezeigten Hilfe keinen Hinweis darauf, dass dabei automatisch eine Git-URL aus Gitea importiert oder synchronisiert wird.
+
+---
+
+## 9. Typischer Minimal-Workflow
+
+```bash
+export ENTIRE_TOKEN_STORE=file
+export ENTIRE_TOKEN_STORE_PATH="$HOME/.config/entire/tokens.json"
+export ACCESSIBLE=1
+
+entire login --device --server https://eu.auth.entire.io
+entire auth status
+
+cd ~/coplint.d/qt-migration-copilot-demo
+entire enable
+entire status
+entire agent list
+```
+
+---
+
+## 10. Troubleshooting
+
+### Kein Browser auf dem Server
+Normal auf Headless-Hosts.  
+Device-Code-URL auf lokalem Rechner öffnen.
+
+### Login erfolgreich, aber `Not logged in`
+Ursache meist fehlender Keyring und keine Datei-Speicherung.
+
+Lösung:
+
+```bash
+export ENTIRE_TOKEN_STORE=file
+entire login --device --server https://eu.auth.entire.io
+```
+
+### Entire ist aktiviert, aber nicht in `entire repo list`
+Das ist erwartbar, weil lokales Git-Repo und Entire-Projektrepo getrennte Objekte sind.
+
+### Diagnose
+Bei Problemen:
+
+```bash
+entire doctor
+```
+
+---
+
+## 11. Empfehlung für dieses Setup
+
+Für ein Setup mit **Gitea + Jenkins + Entire** gilt:
+
+- **Gitea** bleibt Source-of-Truth für den Code
+- **Jenkins** bleibt CI/CD-System
+- **Entire** ergänzt Session-, Agent- und Checkpoint-Tracking im lokalen Repository
+- **Entire-Projekte/Repos** sind zusätzliche Verwaltungsobjekte und nicht identisch mit dem Gitea-Remote
+
+---
+
+## 12. Nützliche Befehle
+
+```bash
+entire auth status
+entire auth contexts
+entire project list
+entire repo list <project-id>
+entire enable
+entire status
+entire agent list
+entire doctor
+```

docs/scripts-usage.md

@@ -0,0 +1,280 @@
+# scripts/
+
+Dieses Verzeichnis enthält Hilfsskripte für den Demo- und Benchmark-Workflow rund um:
+
+- **Qt5 → Qt6**
+- **C++11 → C++23**
+- **Copilot CLI**
+- **Entire CLI**
+- **Scaleway BYOK / OpenAI-kompatibler Provider**
+- **lokale Reproduzierbarkeit der Migration**
+
+## Übersicht
+
+### `create-qt5-legacy-benchmark.sh`
+Erzeugt das Legacy-Beispielprojekt unter:
+
+```text
+qt5-before/qt5-legacy-migration-benchmark
+```
+
+Das Projekt ist absichtlich veraltet aufgebaut, um eine realistische Migration zu erzwingen, z. B. mit:
+
+- `QRegExp`
+- `QDesktopWidget`
+- `QTextCodec`
+- alter `SIGNAL/SLOT`-Syntax
+- `Qt5::Core`, `Qt5::Gui`, `Qt5::Widgets`
+- `C++11`
+
+### `run-entire-copilot-migration.sh`
+Standard-Workflow für eine Copilot-CLI-Migration mit Entire:
+
+1. Entire für Copilot CLI aktivieren
+2. Baseline committen
+3. Copilot-Session starten
+4. Ergebnis committen
+5. Checkpoints anzeigen
+6. letzten Stand mit Entire erklären
+
+Dieses Skript ist für den normalen Migrationslauf gedacht.
+
+**Modellwahl:**
+Das Skript akzeptiert optional ein Modell als zweiten Parameter.
+
+Default:
+
+```bash
+./scripts/run-entire-copilot-migration.sh
+```
+
+verwendet intern:
+
+```bash
+copilot --model "qwen3.5-397b-a17b"
+```
+
+Mit explizitem Modell:
+
+```bash
+./scripts/run-entire-copilot-migration.sh qt5-before/qt5-legacy-migration-benchmark gpt-5
+```
+
+### `run-entire-copilot-migration-with-optional-rewind-resume.sh`
+Wie das Standardskript, aber zusätzlich mit optionalem:
+
+- `entire checkpoint rewind`
+- `entire session resume <branch>`
+
+**Modellwahl:**
+Auch dieses Skript akzeptiert optional ein Modell als zweiten Parameter.
+
+Beispiel:
+
+```bash
+./scripts/run-entire-copilot-migration-with-optional-rewind-resume.sh qt5-before/qt5-legacy-migration-benchmark claude-sonnet-4
+```
+
+**Wichtig:**  
+Die Entire-Dokumentation ist bei Copilot CLI in Bezug auf Rewind/Resume nicht ganz konsistent.  
+Die Copilot-CLI-Seite beschreibt Rewind und Resume, während die allgemeine Agent-Übersicht teils eingeschränkte Aussagen macht.
+
+Darum behandelt dieses Skript Rewind/Resume bewusst als **optional** und **fehlertolerant**.
+
+### `use-scaleway-copilot-debug.sh`
+Hilfsskript zum Setzen einer **Scaleway OpenAI-kompatiblen BYOK-Konfiguration** für Copilot CLI.
+
+Typischer Zweck:
+
+- Provider-Umgebungsvariablen setzen
+- Copilot CLI mit Scaleway testen
+- Modellname konfigurieren
+- Token-Limits für nicht im Copilot-Katalog enthaltene Modelle explizit setzen
+- Debugging eines externen Providers vereinfachen
+
+Ein typischer Inhalt wäre z. B.:
+
+- `COPILOT_PROVIDER_TYPE=openai`
+- `COPILOT_PROVIDER_BASE_URL=https://api.scaleway.ai/v1`
+- `COPILOT_PROVIDER_API_KEY=...`
+- `COPILOT_MODEL=qwen3.5-397b-a17b`
+- `COPILOT_PROVIDER_MAX_PROMPT_TOKENS=...`
+- `COPILOT_PROVIDER_MAX_OUTPUT_TOKENS=...`
+
+---
+
+## NOTE: Secret in `.envrc` hinterlegen
+
+Das Secret für den verwendeten LLM-Provider soll **nicht** direkt in die Skripte geschrieben oder committed werden.
+
+Lege den API-Key stattdessen in einer lokalen `.envrc` ab, z. B.:
+
+```bash
+export SCW_SECRET_KEY="YOUR_PROVIDER_SECRET_HERE"
+```
+
+oder allgemeiner:
+
+```bash
+export OPENAI_API_KEY="YOUR_PROVIDER_SECRET_HERE"
+```
+
+Danach die Umgebung neu laden, z. B. mit:
+
+```bash
+direnv allow
+```
+
+oder die Datei manuell sourcen, falls du kein `direnv` verwendest.
+
+**Wichtig:**
+- `.envrc` nicht committen
+- Secrets nicht im Repository speichern
+- Provider-Zugangsdaten nur lokal halten
+
+---
+
+## Empfohlene Reihenfolge
+
+### 1. Legacy-Projekt erzeugen
+
+```bash
+./scripts/create-qt5-legacy-benchmark.sh
+```
+
+### 2. Optional: Copilot mit Scaleway konfigurieren
+
+```bash
+source ./scripts/use-scaleway-copilot-debug.sh
+```
+
+Danach kannst du prüfen, ob die Variablen gesetzt sind:
+
+```bash
+echo "$COPILOT_PROVIDER_BASE_URL"
+echo "$COPILOT_MODEL"
+```
+
+### 3. Migration mit Entire + Copilot starten
+
+Standard mit Default-Modell:
+
+```bash
+./scripts/run-entire-copilot-migration.sh qt5-before/qt5-legacy-migration-benchmark
+```
+
+Standard mit explizitem Modell:
+
+```bash
+./scripts/run-entire-copilot-migration.sh qt5-before/qt5-legacy-migration-benchmark qwen3.5-397b-a17b
+```
+
+Mit optionalem Rewind/Resume:
+
+```bash
+./scripts/run-entire-copilot-migration-with-optional-rewind-resume.sh qt5-before/qt5-legacy-migration-benchmark qwen3.5-397b-a17b
+```
+
+---
+
+## Copilot-Prompt für die Migration
+
+Die Migrationsskripte verwenden sinngemäß einen Prompt in dieser Richtung:
+
+```text
+Migrate the legacy Qt5/C++11 desktop application to Qt6/C++23.
+
+Requirements:
+- Read the legacy source project from qt5-before/qt5-legacy-migration-benchmark
+- Write the migrated project into qt6-after/qt6-migrated-benchmark
+- Do not modify the legacy source tree in place
+- Update CMake from Qt5 to Qt6
+- Keep Core, Gui, and Widgets explicitly linked
+- Replace QRegExp with QRegularExpression
+- Replace QDesktopWidget / QApplication::desktop() usage with QScreen-based Qt6 APIs
+- Remove legacy QTextCodec usage and use modern Qt6-safe text handling
+- Modernize old SIGNAL/SLOT syntax to function-pointer connect syntax
+- Replace legacy null pointer literals with nullptr
+- Preserve the .ui and .qrc integration
+- Preserve application behavior
+- Upgrade the project from C++11 to C++23
+- For every code change inside a method, add at least three tests covering the changed behavior
+- Place all generated tests in qt6-after/qt6-migrated-benchmark/tests
+- Update CMake so the migrated application and all tests build successfully with CTest
+- Keep the test file naming compatible with repository policy checks
+- Briefly explain each migration change
+```
+
+---
+
+## Entire-Hinweise
+
+Entire erfasst bei unterstützten Agenten u. a.:
+
+- Gesprächsverlauf
+- Dateiveränderungen
+- Zeitstempel
+- Checkpoints bei Commits
+- Session-Kontext auf dem Branch `entire/checkpoints/v1`
+
+Typischer Entire-Grundablauf:
+
+```bash
+entire agent add copilot-cli
+copilot --model "qwen3.5-397b-a17b"
+git add .
+git commit -m "..."
+entire checkpoint list
+```
+
+---
+
+## Hinweise zu `use-scaleway-copilot-debug.sh`
+
+Das Skript sollte **gesourct** werden, nicht als eigener Prozess laufen, damit exportierte Variablen in deiner aktuellen Shell erhalten bleiben:
+
+```bash
+source ./scripts/use-scaleway-copilot-debug.sh
+```
+
+oder kurz:
+
+```bash
+. ./scripts/use-scaleway-copilot-debug.sh
+```
+
+Außerdem:
+
+- keine echten Secrets committen
+- API-Keys nicht im Repo speichern
+- sensible Werte aus `.envrc` oder bereits gesetzten Umgebungsvariablen übernehmen
+
+Beispiel:
+
+```bash
+export SCW_SECRET_KEY="..."
+source ./scripts/use-scaleway-copilot-debug.sh
+```
+
+---
+
+## Empfohlene Erweiterungen
+
+Optional kannst du später noch ergänzen:
+
+- `build-qt6-after.sh`
+- `run-ctest-qt6-after.sh`
+- `compare-before-after.sh`
+- `capture-copilot-env.sh`
+
+---
+
+## Kurzfassung
+
+Der `scripts/`-Ordner enthält alles, um:
+
+1. ein Legacy-Qt5-Projekt zu erzeugen,
+2. Copilot CLI optional mit einem externen Modell zu konfigurieren,
+3. Secrets lokal über `.envrc` bereitzustellen,
+4. eine Qt6/C++23-Migration mit Entire zu dokumentieren,
+5. und den Migrationslauf reproduzierbar zu machen.

docs/use-scaleway-with-copilot-cli.md

@@ -0,0 +1,97 @@
+# Copilot CLI mit Scaleway verwenden
+
+## 1) `.envrc` anlegen
+
+Lege in deinem Projekt eine Datei `.envrc` an:
+
+```bash name=.envrc
+export STRIX_LLM="qwen3.5-397b-a17b"
+export SCW_SECRET_KEY="REPLACE_WITH_YOURS"
+
+export COPILOT_PROVIDER_TYPE="openai"
+export COPILOT_PROVIDER_API_KEY="${SCW_SECRET_KEY}"
+export COPILOT_PROVIDER_BASE_URL="https://api.scaleway.ai/v1"
+export COPILOT_MODEL="${STRIX_LLM}"
+
+export COPILOT_PROVIDER_MAX_PROMPT_TOKENS="32768"
+export COPILOT_PROVIDER_MAX_OUTPUT_TOKENS="8192"
+```
+
+## 2) `direnv` erlauben
+
+Falls `direnv` schon installiert ist:
+
+```bash name=direnv-allow.sh
+direnv allow
+```
+
+Wenn noch nicht in der Shell aktiviert, ergänze deine Shell-Config.
+
+### Bash
+```bash name=bash-direnv-hook.sh
+eval "$(direnv hook bash)"
+```
+
+### Zsh
+```bash name=zsh-direnv-hook.sh
+eval "$(direnv hook zsh)"
+```
+
+Danach Shell neu laden:
+
+```bash name=reload-shell-config.sh
+source ~/.bashrc
+# oder
+source ~/.zshrc
+```
+
+## 3) Startskript anlegen
+
+```bash name=use-scaleway-copilot.sh
+#!/usr/bin/env bash
+set -euo pipefail
+
+if ! command -v copilot >/dev/null 2>&1; then
+  echo "copilot CLI nicht gefunden."
+  exit 1
+fi
+
+: "${COPILOT_PROVIDER_TYPE:?COPILOT_PROVIDER_TYPE fehlt}"
+: "${COPILOT_PROVIDER_API_KEY:?COPILOT_PROVIDER_API_KEY fehlt}"
+: "${COPILOT_PROVIDER_BASE_URL:?COPILOT_PROVIDER_BASE_URL fehlt}"
+: "${COPILOT_MODEL:?COPILOT_MODEL fehlt}"
+
+echo "Starte Copilot CLI mit:"
+echo "  Provider: ${COPILOT_PROVIDER_TYPE}"
+echo "  Base URL: ${COPILOT_PROVIDER_BASE_URL}"
+echo "  Modell:   ${COPILOT_MODEL}"
+
+exec copilot "$@"
+```
+
+Dann ausführbar machen:
+
+```bash name=chmod-script.sh
+chmod +x use-scaleway-copilot.sh
+```
+
+Start:
+
+```bash name=start-script.sh
+./use-scaleway-copilot.sh
+```
+
+Oder mit Argumenten:
+
+```bash name=start-script-with-args.sh
+./use-scaleway-copilot.sh --model="qwen3.5-397b-a17b"
+```
+
+## 4) `.gitignore` ergänzen
+
+Falls noch nicht vorhanden:
+
+```gitignore name=.gitignore
+.env
+.envrc
+```