Stilregeln: kein Nachschlagewissen, keine Autoren als Gerüst, Code ohne Testgerüst, englische Bezeichner

Vier Regeln aus der Prüfung des Buchs „Techniken der Spieleentwicklung“:
- keine Einstellungspfade, Standardwerte, Versionsnotizen, Methodentabellen
- Sache erklären statt „X beschreibt“, keine Testberichte im Text
- Codebeispiele nur als Kern im Spielskript, Gerüst bleibt unter arbeit/
- Bezeichner englisch, Kommentare und Ausgaben deutsch
Vorwort ohne Prüfprotokoll.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

prompts/stil_basis.md

@@ -5,13 +5,16 @@ Ein deutschsprachiges Sachbuch, das **Verständnis** vermittelt: Wie ist die Sac
 - Sprache: Deutsch, korrekte Umlaute und ß, gut lesbare Sachbuchprosa. Keine direkte Anrede als Stilmittel; „wir“ sparsam.
 - Satzbau: Sätze meist 14–18 Wörter, selten über 25, nie über 35. Höchstens ein Nebensatz je Satz, keine Semikolon-Ketten. Ein Gedanke je Satz; Bedingung und Folge dürfen zusammenstehen. Aktiv statt Nominalstil.
 - Wortwahl: Verben statt Substantivierungen („prüfen“ statt „eine Prüfung vornehmen“, „wahrnehmen“ statt „die Wahrnehmung erfolgt“). Lange zusammengesetzte Wörter nur, wenn sie der Fachbegriff sind; sonst umschreiben oder bei der ersten Nennung erklären. Keine Füllwörter („grundsätzlich“, „im Wesentlichen“, „durchaus“).
-- Code-Bezeichner im Fließtext nur, wenn der Satz von genau diesem Bezeichner handelt. Erst in Worten erklären, was etwas tut, dann den Namen nennen. Keine Aufzählungen von Methoden- oder Klassennamen im Satz: Solche Listen gehören in eine kleine Tabelle (Name | Zweck) oder in ein Codebeispiel. Faustregel: höchstens ein Bezeichner je Satz, selten zwei.
+- Code-Bezeichner im Fließtext nur, wenn der Satz von genau diesem Bezeichner handelt. Erst in Worten erklären, was etwas tut, dann den Namen nennen. Keine Aufzählungen von Methoden-, Eigenschafts- oder Klassennamen, weder im Satz noch als Tabelle: Solche Listen weglassen. Faustregel: höchstens ein Bezeichner je Satz, selten zwei.
 - **Keine** Übungen, Selbsttests, Lernziele, Merkkästen, Checklisten, „Praxistipps“, Schritt-für-Schritt-Anleitungen als Selbstzweck, Zusammenfassungen am Kapitelende, Literaturlisten.
-- Überwiegend Fließtext. Listen und Tabellen nur, wo sie echte Klarheit bringen – sparsam.
+- Überwiegend Fließtext. Listen und Tabellen nur, wo sie echte Klarheit bringen – sparsam. Eine Tabelle vergleicht Varianten mit ihren Kosten; sie zählt nie Methoden, Eigenschaften, Konstanten oder Einstellungen auf.
+- Kein Nachschlagewissen: keine Einstellungspfade (eine Projekteinstellung wird in Worten genannt, nicht als `pfad/zur/einstellung`), keine Standardwerte, Grenzwerte, Signaturen oder Parameterpositionen, die nur beim Bauen helfen. Keine Versionsnotizen („seit 4.3“, „in Godot 3 hieß“, „bis 4.2“): Das Buch beschreibt den Stand der Referenzversion, als hätte es nie einen anderen gegeben.
+- Keine Autoren als Erzählgerüst: nicht „X beschreibt“, „X hält“, „X rät“, sondern die Sache selbst erklären und begründen. Der Erfinder eines Verfahrens wird höchstens einmal genannt, wenn das Verfahren nach ihm heißt. Keine Jahreszahlen, Daten, Lebensläufe oder Anekdoten ohne Erklärwert. Keine Testberichte im Text („Im Testlauf …“, „Das Skript läuft ohne Fehler“, „Ein Versuch zeigt“): Die Ausgabe spricht für sich.
 - Fachbegriffe bei der ersten Nennung kurz erklären; englische Fachbegriffe nennen, wo sie üblich sind.
-- Keine Quellenangaben im Text, weder in Klammern noch als „laut Dokumentation“: Quellen dienen der Prüfung, nicht dem Leser. Klassen und Befehle in `Code`-Formatierung, Versionsangaben („seit 4.3“) nur, wenn geprüft.
+- Keine Quellenangaben im Text, weder in Klammern noch als „laut Dokumentation“: Quellen dienen der Prüfung, nicht dem Leser. Klassen und Befehle in `Code`-Formatierung.
 - Keine Querverweise: keine Verweisklammern „(→ Abschnitt 8.2)“, keine Rückverweise („wie Abschnitt 3.2 zeigte“). Das Buch wird von vorn nach hinten gelesen; der Leser hat das Frühere gerade gelesen. Ein Thema wird nur in seinem Kapitel erklärt, anderswo höchstens in einem Halbsatz gestreift. Kommt ein Begriff vor seinem Kapitel vor, genügt ein Halbsatz wie „das erklärt Kapitel 8“.
-- Codebeispiele (falls das Thema Software ist): kurz (typisch 5–30 Zeilen), nur wo sie ein Konzept erklären, mit Sprachangabe im Codeblock, im Text erklärt.
+- Codebeispiele (falls das Thema Software ist): kurz (typisch 5–20 Zeilen), nur der Kern einer Idee, so wie er in einem Spielskript stünde (etwa `extends Node2D` mit `_ready()` oder `_process()`), mit Sprachangabe im Codeblock, im Text erklärt. Kein Testgerüst im Buch: kein `extends SceneTree`, kein `_init()`, kein `quit()`, keine Warteschleifen, Frame-Zähler, simulierten Eingaben, Fenstergrößen oder Hilfsfunktionen, die nicht abgedruckt sind. Zum Prüfen darf der Autor den Kern in ein Gerüst unter `arbeit/` stecken; abgedruckt wird nur der Kern.
+- Code-Bezeichner (Variablen, Funktionen, Klassen, Signale, Knotennamen) sind englisch wie die Engine-API. Kommentare im Code und ausgegebene Texte sind deutsch.
 - Hat ein Codebeispiel eine Ausgabe, steht die tatsächliche Ausgabe des eigenen Testlaufs als ```text-Block direkt darunter, gekürzt auf das Wesentliche (höchstens etwa 10 Zeilen).
 - Strukturdiagramme: Baum-, Ablauf- und Zustandsstrukturen, die aus Quellcode oder Doku belegt sind, als Textdiagramm mit Kästen und Pfeilen in einem ```diagramm-Block (Zeichen ┌─┐│└┘├┤┬┴ und ▶ ▼, höchstens 60 Zeichen breit, höchstens eines je Abschnitt). Jedes Element im Diagramm kommt auch im Text vor. Keine Illustrationen, keine Szenen, nichts Erfundenes.