Der GitHub-PR-Kanal

Der GitHub-PR-Kanal bringt neu erzeugte Dateien in Ihr eigenes Repository: Bei jeder Neuerzeugung öffnet Sichta einen Pull Request mit den geänderten Dateien. Sie prüfen, mergen, und Ihre normale Deploy-Pipeline übernimmt.

Einrichtung

1. In der App: Ihre Website → Kanal → GitHub Pull Request.
2. Die GitHub-App Sichta Conformance auf dem Repository installieren, das Ihre Website deployt. Sie fragt nach Contents- und Pull-requests-Berechtigungen — nur auf den Repositories, die Sie auswählen.
3. GitHub leitet Sie auf eine URL zurück, die auf installation_id=… endet. Diese Nummer ins Formular eintragen.
4. Repository, Basis-Branch und das Verzeichnis wählen, das Ihrem Web-Root entspricht (oft public/ oder static/, leer für das Repository-Stammverzeichnis). Speichern.

So sieht ein PR aus

Ein Branch pro Neuerzeugung, benannt sichta/conformance-<datum>-<set-nummer>, mit allen Dateien in einem einzigen Commit — eine PR-Historie aus „update llms.txt / update llms-full.txt / update security.txt" ist schwerer zu prüfen als der Diff, den sie darstellt.

Der Diff berührt nur die erzeugten Dateien. Die PR-Beschreibung listet sie mit Größe und nennt, wie viele Einträge noch eine Review-Markierung tragen.

Entsprechen die erzeugten Dateien bereits dem Basis-Branch, wird gar kein PR geöffnet: Ein leerer Pull Request kostet nur Review-Zeit.

Der Kompromiss

Die Dateien bleiben in Ihrem Repo und Ihrem Review-Gate. Dafür heißt ein ungemergter PR: Die Live-Dateien driften, bis jemand mergt — die tägliche Prüfung meldet das, aber mergen kann sie nicht für Sie.

Ein fehlgeschlagener PR lässt nie eine Neuerzeugung scheitern: Das Set existiert weiterhin und bleibt in der App herunterladbar.