CI sichtbar machen und Aussagen richtigstellen

[GodModeAI2025]

CI und Richtigstellungen (Welle 3)

Was die CI prueft

Der Workflow .github/workflows/ci.yml laeuft auf ubuntu-latest, bei push und pull_request auf main sowie per workflow_dispatch. Er zieht nur actions/checkout@v4 und actions/setup-python@v5. Node kommt aus der Vorinstallation des Runners, dafuer wird keine weitere Action gebraucht.

Sechs Schritte, jeder mit einem realistischen Bruch dahinter:

1. Pillow installieren, festgelegt auf >= 10.1. Die Grenze ist nicht beliebig: ImageFont.load_default() kennt den size-Parameter erst ab 10.1.0. Darunter faellt create_banner.py auf einen Bitmap-Font in fester Groesse zurueck, und seit Welle 2 zaehlt genau dieser Fall selbst als Safe-Zone-Verletzung, weil die gemessenen Textbreiten dann aus einer anderen Schriftgroesse stammen. Mit einer aelteren Pillow-Version wuerde also schon der saubere Lauf mit Exitcode 1 enden. Das Repo hat keine requirements.txt, deshalb steht die Untergrenze im Workflow.
2. Python-Syntax ueber scripts/ (compileall).
3. Node-Syntax ueber scripts/generate_report.js. Der praktisch haeufigste Bruch steht in SKILL.md selbst beschrieben: typografische Anfuehrungszeichen in JavaScript-Strings beim Anpassen der Kundendaten.
4. create_banner.py --strict mit kurzen Texten muss mit 0 enden.
5. create_banner.py --strict mit einem zu langen Titel muss ungleich 0 enden, und die Fehlermeldung muss "Safe-Zone-Verletzung" enthalten. Der zweite Teil ist wichtig, weil ein beliebiger Traceback ebenfalls Exitcode 1 liefert und sonst als bestandener Test durchginge. Die Schritte 4 und 5 zusammen sichern die Welle-2-Reparatur ab.
6. scripts/check_versions.py vergleicht sechs Versionsfundstellen: README-Ueberschrift, README-Abschnitt Version, SKILL.md-Ueberschrift, oberster Changelog-Eintrag, Hero-Badge der Landingpage, DOCX-Kopfzeile im Report-Template. Das Skript endet auch dann mit 1, wenn eine Fundstelle gar nicht mehr gefunden wird, damit eine geloeschte Versionszeile nicht stillschweigend durchgeht.

Alle sechs Schritte wurden lokal Zeile fuer Zeile so ausgefuehrt, wie sie im Workflow stehen, unter bash -eo pipefail. Alle gruen, der Arbeitsbaum bleibt danach sauber.

Was die CI nicht prueft

• Die Report-Erzeugung. node --check parst die Datei, fuehrt sie aber nicht aus. Das npm-Paket docx ist nicht installiert, und der Ausgabepfad steht fest auf die claude.ai-Sandbox.
• Ob die zehn Kategorien auf der Landingpage weiterhin zu SCORING.md passen. Sie wurden in diesem PR von Hand angeglichen, gegen erneutes Auseinanderlaufen gibt es noch keinen Check. Das waere der naechste sinnvolle Schritt.
• Die Scoring-Arithmetik. Dafuer gibt es im Repo keinen Code, nur Dokumentation.
• Das Rendering von index.html.

Unterschiede zwischen lokalem Lauf und Runner

Der lokale Lauf war eine Nachstellung, keine echte GitHub-Action. Was abweicht:

• Lokal Python 3.9.6, auf dem Runner 3.11 aus setup-python. Keines der Skripte nutzt Syntax ab 3.10.
• python war lokal ein Wrapper auf python3, RUNNER_TEMP ein Scratchpad-Verzeichnis. Der Befehlstext ist identisch, die Umgebung nicht.
• Der Pillow-Schritt war lokal ein No-Op (11.3.0 bereits installiert). Auf dem Runner installiert er wirklich.
• Auf dem Mac gibt es kein /usr/share/fonts, beide Banner-Laeufe liefen deshalb ueber den PIL-Default-Pfad. Auf ubuntu-latest sind DejaVu-Fonts vermutlich vorhanden, dann laeuft der TrueType-Zweig mit breiterer Schrift. Deshalb wurden die Texte des sauberen Laufs vorher mit einem echten TrueType-Font gemessen: bei 52px liegt die laengste Titelzeile ("CI Smoke Test") bei 358px Breite gegen ein Budget von 670px, Untertitel, Rolle und Tags bleiben mit noch groesserem Abstand darunter. Auch mit einer deutlich breiteren Schrift bleibt der Lauf damit unter der Safe-Zone-Grenze.

Zaehne-Test

Drei kuenstliche Brueche, jeweils in einer Kopie des Repos, nie im Repo selbst. Alle drei wurden rot.

Der zentrale: in der Kopie wurde sys.exit(1) aus create_banner.py entfernt, also die Welle-2-Reparatur zurueckgenommen. Der Schritt gab aus: "FEHLER: --strict hat die Safe-Zone-Verletzung nicht gemeldet", Exitcode 1. Aufschlussreich daran ist, dass das Skript die Verletzung weiterhin ausdruckte. Ein Check, der nur die Ausgabe liest, waere gruen geblieben.

Dazu: nur die README-Ueberschrift auf v2.3.0 gesetzt, check_versions.py meldete "Versionsangaben laufen auseinander: v2.2.2, v2.3.0" mit Exitcode 1. Und ein offenes Objektliteral ans Ende von generate_report.js gehaengt, node --check meldete "SyntaxError: Unexpected end of input" mit Exitcode 1.

Richtiggestellte Aussagen

• Der Report ist seit v2.2.0 DOCX, nicht PDF. README und Landingpage bewarben an acht Stellen einen PDF-Report, eine Karte im Workflow-Abschnitt widersprach sich sogar innerhalb ihrer selbst (Ueberschrift PDF, Text darunter DOCX). Radar-Charts kommen im Report nicht vor, generate_report.js erzeugt kein einziges Diagramm.
• Die dokumentierte Ausfuehrung nannte Dateien, die es nicht gibt: node report.js statt generate_report.js, und dreimal scripts/office/validate.py, das im Repo nicht existiert. An seine Stelle tritt eine Pruefung, die ohne Zusatzskript auskommt.
• Drei Roadmap-Horizonte standen nebeneinander. Die Implementierung reicht bis Monat 6, README und Landingpage versprachen zwoelf. Beide sagen jetzt Monat 6.
• Der Gesamtscore 73 auf der Landingpage war aus den zehn danebenstehenden Werten nicht ableitbar, und die zehn Kategorien kamen in SCORING.md gar nicht vor. Sie sind durch die zehn echten Kategorien mit ihren Gewichten ersetzt, die Zahlen durch die in SCORING.md durchgerechnete Beispielbewertung, deren gewichtete Summe 70,0 ergibt. Der Ring zeigt 70, der stroke-dashoffset wurde von 150 auf 170 mitgezogen. Neue Zahlen wurden nicht erfunden, die nicht belegbare Kennzahl "15+ Seiten" weicht der tatsaechlich angelegten Kapitelzahl.
• Die README hat jetzt einen Abschnitt Grenzen und einen Abschnitt Roadmap, beide aus dem Bestand belegt, und verlinkt die Gewichtstabelle sowie die Benchmark-Tabelle in references/SCORING.md, die bisher nur dort standen.
• Die Version stand an sechs Stellen in drei Varianten und steht jetzt ueberall auf v2.2.2.

Offen

• Die Nenner-Frage der Engagement-Rate. SCORING.md rechnet gegen Impressions, generate_report.js schaetzt aus der Follower-Zahl. Der geschaetzte Wert liegt systematisch hoeher, die Benchmark-Baender passen also nicht zur berechneten Zahl. Der Widerspruch ist im Abschnitt Grenzen benannt, aufgeloest ist er nicht.
• Der Ausgabepfad des Report-Templates zeigt weiterhin fest auf /mnt/user-data/outputs/.
• requirements.txt und package.json fehlen weiterhin, docx ist nicht gepinnt.
• Die Fehlerbehandlung deckt Rate Limit beziehungsweise LinkedIn-Checkpoint und geaenderte DOM-Struktur noch nicht ab.
• SCORING.md verlangt Radar-Chart und Balkendiagramm, das Template liefert keine Diagramme. Als Grenze dokumentiert, nicht geloest.

index.html blieb unveraendert im Repo-Root, nur inhaltlich korrigiert. Es wurde nichts gepusht.

🤖 Generated with Claude Code

https://claude.ai/code/session_01BL7UoPomBp2Luhg89R6fYk

Wie dieser Branch entstanden ist

Drei Durchgaenge, jeder mit eigener Abnahme:

1. CI anlegen und die im Haerteplan gelisteten Falschaussagen korrigieren.
2. Die Abnahme hat die CI selbst nachgefahren, absichtlich gebrochen, um zu pruefen ob sie Zaehne
   hat, und dabei 8 weitere Aussagen gefunden, die immer noch nicht stimmten. Die wurden im
   zweiten Durchgang korrigiert.
3. Die Nachpruefung des zweiten Durchgangs fand Formulierungen, die beim Korrigieren zu weit
   gingen oder eine neue Ungenauigkeit einfuehrten. Die wurden im dritten Durchgang praezisiert.

Jede Zahl in den geaenderten Texten ist gegen das Repo gemessen, nicht uebernommen.

Zur CI

Die CI prueft nur, was heute wirklich pruefbar ist. Sie wurde absichtlich gebrochen, um zu
belegen, dass ein realistischer Fehler sie rot macht. Was sie nicht abdeckt, steht in der
Beschreibung der einzelnen Schritte.

---

Gestapelt. Dieser PR sitzt auf fix/welle-2. GitHub haengt ihn automatisch auf main um, sobald der darunterliegende PR gemergt ist. Vorher zeigt der Diff nur die Welle-3-Aenderungen, das ist so gewollt.

Teil von Welle 3 des Haerteplans: CI sichtbar und Claims ehrlich. Jede Aenderung wurde von einem zweiten Durchgang abgenommen, der die CI-Schritte selbst nachgefahren und die CI absichtlich gebrochen hat.