v1.3.0 — Checks in einem Kommando, Transport bei seiner Folge, Ausfall getrennt von Abweisung

Three changes: one to the tooling, two to the procedure. The repository's checks
now live in a single file that can be run before opening a pull request. The
transport decision sits where its consequence becomes visible — among the
consequences of the architecture decision. And 3.5 separates an outage from a
rejection, because the two carry different next steps and "try again in ten
minutes" does not terminate on a wrong host header.

The five steps and the four disciplines are unchanged, and step 3 still has six
points: 3.5 grew, no section was added.

Added

• scripts/validate.sh — alle Checks des Repos in einem Kommando. Vier der
  sieben Prüfungen lagen bisher als Python-Heredocs inline in ci.yml und waren
  lokal nur per Copy-paste aus der YAML zu bekommen. Wer SKILL.md editierte,
  erfuhr das Ergebnis frühestens im Pull Request.

  Die CI ruft das Skript jetzt auf, statt die Checks zu wiederholen: Eine zweite
  Kopie würde auseinanderlaufen, und ein lokaler Runner, der von der CI
  abgewichen ist, meldet grün auf einem Baum, den die CI ablehnt — das ist genau
  der Fehlermodus, den eine Vorabprüfung nicht haben darf. Dasselbe Argument, das
  in 1.1.0 den Companion-Ordner zu einem Pointer gemacht hat.

  Drei Unterschiede zum bisherigen Verhalten, alle absichtlich:

  Das Skript läuft nach einem Fehlschlag weiter. Als Kette von
  Workflow-Steps brach die Prüfung beim ersten roten Schritt ab, was bei zwei
  Problemen zwei Pushes kostete; jetzt benennt ein Durchlauf alle. Der
  Exit-Code ist 0 nur, wenn keiner fehlgeschlagen ist.

  Der Frontmatter-Check gibt den verbleibenden Spielraum aus statt nur der
  Länge: 1017/1024 chars (7 left). Die Zahl ist die schärfste Nebenbedingung
  im Repo — ein zusätzlicher Trigger-Begriff in der description reisst das
  Limit in einer einzigen Bearbeitung, und die blosse Länge lässt das nicht
  sehen.

  compileall schreibt seine Bytecode-Caches über PYTHONPYCACHEPREFIX in ein
  temporäres Verzeichnis. In der CI war das egal, lokal legt derselbe Befehl ein
  untracked reference/__pycache__/ an — auf diesem Weg ist in 1.1.0 schon
  einmal eine .pyc in den Commit geraten.

  Zehnfach mutationsgetestet: je eine Mutation pro Check, plus die beiden Fälle,
  in denen Check 3 und Check 7 aus zwei verschiedenen Gründen rot werden können
  (falscher Name / zu lange Description, veralteter Badge / fehlende
  Release-Überschrift). Alle zehn wurden vom jeweils zuständigen Check gefangen,
  bei allen zehn liefen die übrigen sechs zu Ende.

• __pycache__/ und *.pyc in .gitignore — die zweite Hälfte desselben
  Problems. Der Cache-Prefix hält das Skript sauber, der Eintrag hält jeden
  anderen python-Aufruf im Repo sauber.

Changed

• 3.5 trennt Ausfall und Abweisung. Der Abschnitt schlug für die ganze
  Fehlerklasse denselben Satz vor — «Bitte in 10 Minuten erneut versuchen».
  Für den Ausfall ist das richtig; für eine Abweisung ist es ein nächster
  Schritt, der per Konstruktion nicht terminiert. 401, 403 und
  421 Invalid Host header heissen, dass die Quelle antwortet und den Aufruf
  nicht annimmt: Warten behebt davon nichts, und 3.1 retried 4xx aus genau
  diesem Grund nicht — 429 ist die Ausnahme, dort ist Warten tatsächlich der
  richtige Schritt.

  Die Unterscheidung selbst stand schon im Skill, an drei Stellen: 3.1 wirft
  bei 4xx statt zu schlucken, 3.5 verlangt «nie einfach leere Records», und 3.6
  grenzt sich im ersten Satz gegen 3.5 ab. Was fehlte, war die Folge daraus für
  den Text, den der Aufrufer zu lesen bekommt. Es ist derselbe Fehler wie ein
  Leermengen-Hinweis, der zur Wildcard rät, während die Abfrage nie angekommen
  ist — nur eine Klasse weiter oben. Dazu die Forderung, die Klasse
  maschinenlesbar in den Status zu legen: Wer bloss einen Satz bekommt, kann
  «später nochmal» nicht von «so nie» unterscheiden.

  Anlass ist die Gegenprüfung nach der Regel-3-Ergänzung in
  mcp-data-fidelity v1.2.0
  und FID-003 in mcp-audit v1.5.0. Dort ging es darum, dass ein Fehlschlag
  nicht als Leermenge formatiert werden darf; hier bleibt er ein Fehler und
  trägt nur den falschen nächsten Schritt.

• Der Transport steht jetzt in 2.3, bei den Konsequenzen des
  Architektur-Entscheids — nicht mehr nur als Zeile in der Schnellreferenz.
  Der Grund ist die Cache-Semantik: Bei ARCH B und C trifft die Transport-Wahl
  eine zweite Entscheidung mit, ohne dass sie jemand ausspricht. Unter stdio
  läuft ein Prozess pro Client, der Cache lebt eine Sitzung und der Dump wird
  pro Sitzung neu geladen; unter streamable-http bedient ein Prozess viele
  Clients, derselbe Cache lebt so lange wie die Instanz und wird geteilt.
  Dieselbe TTL bedeutet damit zwei verschiedene Dinge. Das README-Template
  nennt die Transporte und diese Folge jetzt in den Consequences.

  Daran hängt eine Reichweiten-Korrektur statt einer neuen Regel: Den
  Zeitstempel des letzten erfolgreichen Abrufs verlangt 3.5 schon, aber nur für
  den Ausfall. Bei geteiltem Cache sagt provenance: cached aus 3.2 unter
  streamable-http etwas anderes als unter stdio — «womöglich Stunden alt und
  für jemand anderen geholt» statt «in dieser Sitzung schon geholt» —, also
  braucht auch die erfolgreiche Antwort den Zeitstempel. Sonst hängt das Alter
  der Daten an der Deployment-Konfiguration statt an der Antwort.

  Erwogen und verworfen wurde ein eigener Abschnitt 3.7. Er wäre zur Hälfte
  eine Wiederholung der bestehenden «immer beide»-Regel gewesen und hätte
  Schritt 3 auf sieben Punkte gebracht, dessen Wert darin liegt, kurz genug zu
  sein, dass ihn niemand überspringt. Das ist Lehre 1 aus dem VARIA-Fundstück,
  angewandt auf den Skill selbst: erst fragen, ob eine bestehende Regel zu eng
  gefasst war, statt sofort eine neue zu schreiben. Eine Zeile in der
  Qualitätschecklist unter «Schritt 2 – Architektur» hält den Punkt prüfbar.

  Offen und bewusst so vermerkt: Für diese Regel gibt es kein Fundstück. Die
  Mechanik ist aus dem bestehenden Text ableitbar, aber kein Server im Portfolio
  ist bisher nachweislich darüber gestolpert. Nach dem Massstab des
  Contributing-Abschnitts ist das ein Mangel — wer den Fall trifft, trägt ihn
  bitte nach.

• ENV_VAR_TRANSPORT und __main__.py sind aus der Schnellreferenz raus.
  Beides ist Implementierungsdetail des Einstiegspunkts und gehört damit in
  mcp-transport-hardening, das genau diese Rolle hat. Die Schnellreferenz
  behält die Entscheidung («immer beide») und verweist für die Folgen auf 2.3,
  für die Umsetzung auf den Schwester-Skill.