Sicherheitshaerte und fachliche Differenzierung

[GodModeAI2025]

Welle 5: Beleglage, Eval-Set, ehrliche Landingpage, Abgrenzung

Branch feat/welle-5, sieben Commits, Version auf 2.4.0.

Was umgesetzt ist

Quellen datiert, unbelegte Zahlen zurückgezogen. Der Skill nannte sich an drei Stellen evidenzbasiert und führte keine einzige Quellen-URL. references/SOURCES.md hält jetzt für jede Aussage fest, worauf sie beruht: sieben Quellen mit URL, Veröffentlichungs- und Abrufdatum, davon fünf Primärquellen von LinkedIn, und je Quelle ein Absatz, was sie ausdrücklich nicht belegt. Elf Zahlen ließen sich nicht belegen und sind ohne Ersatzzahl aus SKILL.md, SCORING.md, TEMPLATES.md, README, Landingpage und Report-Template entfernt, darunter der Plattformdurchschnitt der Engagement-Rate, die Engagement-Werte je Postformat und die Wirkungsfaktoren fürs Kommentieren. Die Tabelle „Zurückgezogen" nennt jede mit Begründung.

Zwei Sachfehler kamen dabei heraus. Das goldene Community-Top-Voice-Badge ist seit dem 08.10.2024 zurückgezogen; das Sub-Kriterium „Collaborative Articles" bewertete also ein Verhalten ohne Wirkung und entfällt, der Punkt liegt bei „Momentum". Den Creator-Mode-Schalter gibt es seit März 2024 nicht mehr; er stand als Punkt 15 in der 18-Punkte-Checkliste, deren Zahl direkt in einen Score übersetzt wird.

Der Nenner der Engagement-Rate ist geklärt. SCORING.md rechnet über Impressions, das Report-Template schätzt aus der Follower-Zahl. SCORING.md sagt jetzt, dass das Raster nur für den impressions-basierten Wert gilt, dass der Schätzwert systematisch höher liegt und nur im Zeitverlauf desselben Profils verglichen wird. Der Report kennzeichnet den Wert entsprechend.

Kategorienamen vereinheitlicht. Dieselben zehn Kategorien liefen unter drei Benennungen: generate_report.js kürzte vier davon ab, und SCORING.md selbst nutzte im Rechenbeispiel und in der Balkendarstellung weitere Kurzformen. Ab jetzt gilt eine Schreibweise, geprüft an vier Stellen.

Eval-Set. tests/ enthält drei frei erfundene Profile, je eine Datei mit erwarteten Bändern und tests/run_eval.py. Der Runner liest das Gewichtsmodell aus SCORING.md, prüft die Gewichtssumme, die wortgleichen Kategorienamen an vier Stellen, Gewicht und Maximalbeitrag im Report-Template, rechnet den Gesamtscore aus den Rohscores nach und prüft die Bänder. Drei Kategorien werden nicht geglaubt, sondern nachgerechnet: Posting-Frequenz aus Posts pro Woche, Netzwerk & Follower aus der Follower-Zahl, Profil-Vollständigkeit aus den 18 Haken. Ändert jemand eine der drei Bewertungstabellen, meldet der Runner, welche Umrechnung nachzuziehen ist.

Landingpage. Die Scoring-Engine war schon in einer früheren Welle auf das Modell von SCORING.md gestellt, der gezeigte Gesamtscore 70,0 rechnet sich sauber aus den Einzelwerten. Offen war der Anschein: der Abschnitt hieß „Live Demo". Er heißt jetzt „Beispiel-Dialog", nennt die Herkunft der Zahlen und verlinkt tests/fixtures/profile_mid.json. Neue Zahlen kommen nicht dazu. Der Runner prüft die zehn Balken samt Balkenbreite, den Ring und die vier Werte im Dialog gegen das Fixture.

Abgrenzung zum Orchestrator. Entscheidung: getrennt lassen. SKILL.md, README und Landingpage nennen beide Rollen, hier die einmalige Ist-Analyse mit den Profil-Artefakten, dort der laufende Betrieb. Der eigentliche Punkt ist die Trigger-Überschneidung, weil beide Descriptions auf „Profil optimieren", „Profil verbessern", „Personal Branding", „Content-Strategie" und „Top Voice" greifen. SKILL.md löst das mit vier Regeln: welche Frage wohin geht, dass bei gemischten Anfragen die Ist-Analyse zuerst läuft und danach übergeben wird, und dass „Top Voice" in beiden Skills zweierlei meint. Die Description trägt denselben Hinweis, damit die Auswahl vor dem Laden greift.

Wie geprüft

Zwei neue CI-Schritte, scripts/check_sources.py und tests/run_eval.py, beide mit Gegenproben belegt statt nur mit einem grünen Lauf.

check_sources.py prüft Stand- und Prüfdatum, URL und Datum je Quellenzeile, dass jede zitierte Quellen-ID existiert, und dass keine der 14 zurückgezogenen Angaben zurück in den Skill wandert. Gegenproben: eine wieder eingefügte 3,4-Prozent-Angabe und eine unbekannte ID Q99 führen beide zu Exitcode 1 mit Datei und Zeilennummer.

run_eval.py läuft grün über alle drei Fixtures (21,6 / 70,0 / 88,4). Vier Gegenproben führen zu Exitcode 1: ein zurückgedrehter Kategoriename im Report-Template, eine verstellte Follower-Zahl im Fixture, ein verschobenes Gewicht in SCORING.md (Summe 102 Prozent) und ein Ergebnislauf außerhalb der Bänder. Drei weitere Gegenproben decken die Landingpage ab: verstellter Balkenwert, verstellter Wert im Beispiel-Dialog, verstellter Gesamtscore im Dialog.

Alle Schritte aus ci.yml sind lokal nachgefahren und grün, einschließlich beider Banner-Fälle und der Paketprüfung. Beide Workflow-Dateien wurden zusätzlich als YAML geparst, weil ci.yml per Textersetzung geändert wurde. Das Paket baut reproduzierbar, zwei Läufe liefern identische Bytes, der Inhaltsvergleich gegen die Positivliste ist ohne Unterschied. Die Vorprüfung des Release-Workflows wurde in beide Richtungen getestet: --expect v2.4.0 endet mit 0, --expect v2.3.0 mit 1. Interne Links und Anker in README, SKILL.md, references/ und index.html sind mit einem Skript geprüft und lösen alle auf.

Was bewusst offen bleibt

Ein echtes Vorher-Nachher. Das braucht zwei datierte Messungen desselben Profils im Abstand von 60 bis 90 Tagen, und schon die erste fehlt. Statt eine Erfolgszahl zu bauen, steht auf der Landingpage und in der README, dass es sie nicht gibt.

Die Gegenrichtung im Repo LinkedIn-Orchestrator. Dessen Tabelle beschreibt diesen Skill in einer Zeile ohne Trigger-Regel, und seine Description greift weiter auf „Profil optimieren". Das ist ein eigener Vorgang in jenem Repo.

Die SSI-Aufteilung „4 × 25 Punkte". LinkedIn benennt die vier Säulen, die Punkteverteilung bestätigt es nicht. Sie bleibt im Skill, aber als Konvention gekennzeichnet.

Die Erfahrungswerte. Zeichenlängen für Headline und About, Posting-Kadenz, Postingzeiten, die Formatreihenfolge und die Punktebänder in SCORING.md bleiben unbelegt. Sie stehen gesammelt in einem eigenen Abschnitt von SOURCES.md, damit niemand sie für Messwerte hält.

Sieben der zehn Kategorien sind nur bandgeprüft, drei werden nachgerechnet. Ein LLM-Scoring ist nicht deterministisch; engere Bänder erzeugen rote Läufe ohne Erkenntnisgewinn.

Q6 (Hootsuite) ist eine fortlaufend aktualisierte Seite. Das Abrufdatum trägt dort mehr Gewicht als sonst, und der Prüfrhythmus in SOURCES.md fängt das ab: nächste Prüfung 04.03.2027.

Zwei bewusste Abweichungen von der Aufgabenformulierung: die Fixtures sind frei erfunden statt anonymisiert, weil anonymisieren die Erhebung realer Profile Dritter voraussetzt, die SECURITY.md einschränkt; und die Erwartungsdateien sind JSON statt YAML, damit der CI-Schritt ohne zusätzliche Abhängigkeit läuft.

🤖 Generated with Claude Code

https://claude.ai/code/session_01BL7UoPomBp2Luhg89R6fYk

Wie dieser Branch entstanden ist

Vier Durchgaenge, jeder mit eigener Abnahme, die selbst gemessen hat statt Berichte zu glauben.

1. Umsetzung der Welle-5-Aufgaben.
2. Die Abnahme fand in allen sieben Repos Befunde und gab keinen einzigen frei. Der wiederkehrende
   Typ: eine Sicherheitsaussage in der Doku, die eine Messung widerlegt, und ein Gate, das
   durchlaesst, sobald jemand das richtige Wort hinschreibt.
3. Nacharbeit, danach eine zweite Abnahme. Sie fand, dass die Nacharbeit an mehreren Stellen neue
   Probleme eingebaut hatte, darunter eine echte Erkennungsregression.
4. Letzte Runde, streng auf Blocker und Regressionen begrenzt, mit der Vorgabe: wo sich eine
   Aenderung nicht sauber reparieren laesst, wird sie zurueckgebaut. Gemessen wurde gegen den Stand
   von main, nicht gegen den eigenen Zwischenstand.

Gepruefte Abnahmekriterien

Vor dem Oeffnen dieses Pull Requests wurde am Branch nachgemessen:

• alle CI-Schritte aus .github/workflows/ci.yml laufen lokal durch
• das Packaging-Skript baut das Release-Artefakt, und der Paketpruefer nimmt es an
• der Arbeitsbaum ist sauber, im Diff stehen keine Zugangsdaten und keine Personendaten

Was offen bleibt, steht in der Beschreibung darueber. Es ist bewusst offen und nicht uebersehen.

---

Gestapelt. Dieser PR sitzt auf main. 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 5 des Haerteplans: Sicherheitshaerte. Jede Aenderung wurde von einem zweiten Durchgang abgenommen, der das Artefakt selbst gebaut, entpackt und den Installationsweg durchgegangen ist.