Kohärenzregel und Einsteiger als Standard-Zielgruppe
Jeder Satz knüpft an den vorigen an, Grund und Folge ausgeschrieben, Brückensatz je Absatz; Prüfer schließt Gedankensprünge. Recherche setzt Leser ohne Vorkenntnisse als Standard, Anspruch verstehen statt umsetzen. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
@@ -11,7 +11,7 @@ Loop, bis nichts mehr zu korrigieren ist:
|
||||
1. Lies das Kapitel komplett. Extrahiere alle überprüfbaren Behauptungen: Bezeichner und Signaturen, Versionsangaben, Studien (Autoren, Jahr, Design, Stichprobe, Ergebnis, Effektgröße), Zahlen, Zitate, Verhaltensbeschreibungen („was passiert wann“), Zuschreibungen („X hat Y eingeführt“), Textdiagramme (jedes Element und jeder Pfeil gegen Quellcode/Doku) und Ausgabeblöcke (gegen den eigenen Testlauf).
|
||||
2. Verifiziere möglichst ALLE gegen die lokalen Quellen (QUELLEN.md). Priorisiere nach Fehlerwahrscheinlichkeit. Führe Codebeispiele aus bzw. teste beschriebenes Verhalten mit kleinen Skripten, wo STIL.md das vorsieht. Versionsangaben gegen Tags/Changelogs prüfen. Achte besonders auf: falsche Zuschreibungen, verdrehte Effektrichtungen, überzogene Kausalaussagen aus Korrelationsstudien, erfundene Stichprobengrößen, veraltete oder erfundene Bezeichner, Doku-Aussagen, die dem Quellcode widersprechen (dann gilt der Quellcode).
|
||||
3. Korrigiere Fehler direkt in der Datei mit Edit (minimal-invasiv, Stil beibehalten). Unbelegbares vorsichtiger formulieren oder streichen.
|
||||
4. Prüfe Form: Überschriften exakt wie GLIEDERUNG.md; keine Übungen/Merkkästen/Zusammenfassungen/Literaturlisten; Querverweise zeigen auf Kapitel, die das Thema laut Gliederung (und, falls die Datei schon existiert, laut Text) wirklich behandeln; keine größeren Doppelungen mit Themen, die in andere Kapitel gehören (dann kürzen und verweisen); Rechtschreibung, Umlaute, Markdown. Satzbau: Sätze über 30 Wörter in mehrere auflösen, Inhalt unverändert; Zielschnitt unter 20 Wörter je Satz. Sätze mit drei und mehr Code-Bezeichnern entflechten: in Worten erklären, Namenslisten in eine Tabelle oder ein Codebeispiel. Verständlichkeit: Begriffe, die der Abschnitt benutzt, ohne sie bis dahin eingeführt zu haben, kurz erklären oder auf die Einführung verweisen; Interna, die mitten im Einstieg stehen, in `### Unter der Haube` verschieben; Zwischenabschnitte unter 150 Wörtern mit dem Nachbarn zusammenlegen. Umfang: Abschnitte über 120 % ihres Richtwerts aus der Gliederung (`(kurz)` ≈ 800, ohne Angabe ≈ 1.300, `(lang)` ≈ 2.000 Wörter) straffen – zuerst Wiederholungen und Quellenformeln ohne Informationswert, keine Fakten oder Beispiele streichen.
|
||||
4. Prüfe Form: Überschriften exakt wie GLIEDERUNG.md; keine Übungen/Merkkästen/Zusammenfassungen/Literaturlisten; Querverweise zeigen auf Kapitel, die das Thema laut Gliederung (und, falls die Datei schon existiert, laut Text) wirklich behandeln; keine größeren Doppelungen mit Themen, die in andere Kapitel gehören (dann kürzen und verweisen); Rechtschreibung, Umlaute, Markdown. Satzbau: Sätze über 30 Wörter in mehrere auflösen, Inhalt unverändert; Zielschnitt unter 20 Wörter je Satz. Sätze mit drei und mehr Code-Bezeichnern entflechten: in Worten erklären, Namenslisten in eine Tabelle oder ein Codebeispiel. Verständlichkeit: Begriffe, die der Abschnitt benutzt, ohne sie bis dahin eingeführt zu haben, kurz erklären oder auf die Einführung verweisen; Interna, die mitten im Einstieg stehen, in `### Unter der Haube` verschieben; Zwischenabschnitte unter 150 Wörtern mit dem Nachbarn zusammenlegen; Gedankensprünge schließen, wo zwischen zwei Sätzen oder Absätzen die Verbindung fehlt. Umfang: Abschnitte über 120 % ihres Richtwerts aus der Gliederung (`(kurz)` ≈ 800, ohne Angabe ≈ 1.300, `(lang)` ≈ 2.000 Wörter) straffen – zuerst Wiederholungen und Quellenformeln ohne Informationswert, keine Fakten oder Beispiele streichen.
|
||||
5. Wiederhole, bis du keine Fehler mehr findest.
|
||||
|
||||
Ändere nur `buch/{{datei}}`. Arbeitsdateien nur unter `arbeit/pruefung-{{n}}/`. Keine persönlichen Daten an externe Dienste senden.
|
||||
|
||||
@@ -4,7 +4,7 @@ Du arbeitest im Verzeichnis dieses Buchprojekts (aktuelles Arbeitsverzeichnis).
|
||||
|
||||
Deine Aufgaben, in dieser Reihenfolge:
|
||||
|
||||
1. **Deutung.** Kläre, was mit dem Thema gemeint ist. Bei mehrdeutigen Namen wähle die wahrscheinlichste Deutung selbst (keine Rückfragen möglich). Lege den Buchtyp fest: `werkzeug` (Software, Framework, Engine, Sprache – der Leser soll verstehen, wie sie gebaut ist und warum sie sich so verhält; Anwendung ist nicht das Ziel) oder `wissen` (Wissenschaft, Fachgebiet, Phänomen – der Leser soll den Forschungsstand verstehen). Bestimme Zielgruppe und Anspruch; beachte die Hinweise oben.
|
||||
1. **Deutung.** Kläre, was mit dem Thema gemeint ist. Bei mehrdeutigen Namen wähle die wahrscheinlichste Deutung selbst (keine Rückfragen möglich). Lege den Buchtyp fest: `werkzeug` (Software, Framework, Engine, Sprache – der Leser soll verstehen, wie sie gebaut ist und warum sie sich so verhält; Anwendung ist nicht das Ziel) oder `wissen` (Wissenschaft, Fachgebiet, Phänomen – der Leser soll den Forschungsstand verstehen). Zielgruppe und Anspruch: Standard sind Leser ohne Vorkenntnisse im Thema – bei Software Programmiergrundlagen in irgendeiner Sprache, aber keine Erfahrung mit dem Werkzeug; bei Wissensthemen allgemeine Bildung. Anspruch: die Sache lesend verstehen und einordnen, nicht selbst umsetzen. Von diesem Standard nur abweichen, wenn die Hinweise oben es verlangen.
|
||||
|
||||
2. **Quellen beschaffen – lokal, prüfbar.** Lege alles unter `quellen/` ab, damit die späteren Autoren und Prüfer ohne Websuche arbeiten können (das Websuch-Kontingent je Agent ist begrenzt):
|
||||
- Software: Quellcode und offizielle Dokumentation der aktuellen stabilen Version per `git clone --depth 1` (Tag der aktuellen Version ermitteln), ggf. auch der Vorversion für Vergleiche; Klassenreferenzen; wenn eine ausführbare Version frei erhältlich ist (z. B. ein Engine-Binary, ein CLI), herunterladen und einen kurzen Testlauf machen, damit Beispiele später ausgeführt werden können; Upgrade-/Changelog-Dateien.
|
||||
|
||||
@@ -19,6 +19,7 @@ Ein deutschsprachiges Sachbuch, das **Verständnis** vermittelt: Wie ist die Sac
|
||||
- Konkret vor abstrakt: Jeder neue Begriff bekommt zuerst eine Situation oder ein Beispiel aus dem Thema, dann die Erklärung, dann den Namen. Nicht mit der Definition beginnen.
|
||||
- Begriffsbudget: etwa 5 neue Fachbegriffe oder Klassen je Zwischenabschnitt. Braucht der Stoff mehr, einen weiteren Zwischenabschnitt anlegen. Zwischenabschnitte (###) 200–600 Wörter, nicht kleiner.
|
||||
- Interna trennen: Quellcode-Details, Server-Ebene, Speicherlayout, Registrierungsmechanismen, Herleitungen über das Nötige hinaus stehen in einem eigenen Zwischenabschnitt `### Unter der Haube` am Ende des Abschnitts (bei Wissensthemen `### Vertiefung`). Der Abschnitt muss ohne ihn verständlich sein; höchstens einer je Abschnitt. Dieser Teil wird gelesen, nicht übersprungen: Er erklärt den Mechanismus mit derselben Sorgfalt (Beispiel, Erklärung, Name), kein Nachschlagestil, kein Sammelbecken für Dichtes.
|
||||
- Zusammenhang ausschreiben: Jeder Satz knüpft erkennbar an den vorigen an. Den Begriff wiederholen statt „es“, „dies“, „dieser Mechanismus“. Wo ein Grund oder eine Folge vorliegt, steht sie im Text („weil“, „deshalb“, „dadurch“, „damit“). Kein Gedankensprung ohne Übergang; an jeder Absatzgrenze ein Brückensatz, der sagt, was der neue Absatz mit dem vorigen zu tun hat. Leser ohne Vorwissen können Lücken nicht selbst füllen.
|
||||
- Ein Begriff, der in einem früheren Kapitel eingeführt wurde, wird bei Wiederverwendung mit einem halben Satz in Erinnerung gerufen, nicht vorausgesetzt.
|
||||
|
||||
## Aufbau jeder Kapiteldatei (Markdown)
|
||||
|
||||
Reference in New Issue
Block a user