incoming/.gitkeep als Datei- statt Verzeichnismuster trackbar (schliesst #88)

Files changed:
- .gitignore
- CHANGES.md
- README.md
- VERSION
- incoming/.gitkeep
- instructions/bootstrap.md
- raw/CONTRACT.md
- tools/CONTRACT.md
- tools/chemenu/commands/docs_verify.py

CHANGES.md

@@ -35,7 +35,7 @@ dev-checkout concern - readable here, never shipped as something to parse.
 
 ---
 
-## 5.0.0-beta.14 - 2026-09-11 - tools/CONTRACT.md als Nachschlage-Dokument strukturiert: ###-Gruppen in beiden Tabellen, spiegelnde Reihenfolge, Lead-in-Regel
+## 5.0.0-beta.15 - 2026-09-11 - incoming/.gitkeep als Datei- statt Verzeichnismuster trackbar (schliesst #88)
 
 **Author:** Torben Nehmer
 
@@ -67,6 +67,7 @@ dev-checkout concern - readable here, never shipped as something to parse.
 - AGENTS.md-Changelog-Absatz korrigiert: Contract-Prosa ist Sitzungsarbeit, doc-pull-through-Instruction ergaenzt
 - docs verify prueft die Kommando- und Fehlerkontrakttabelle in tools/CONTRACT.md getrennt, 10 fehlende Fehlerkontrakt-Zeilen nachgetragen (schliesst #91)
 - tools/CONTRACT.md als Nachschlage-Dokument strukturiert: ###-Gruppen in beiden Tabellen, spiegelnde Reihenfolge, Lead-in-Regel
+- incoming/.gitkeep als Datei- statt Verzeichnismuster trackbar (schliesst #88)
 <!-- /wikitool:bumps -->
 
 
@@ -1308,6 +1309,41 @@ Verifiziert: `tools/wikitool docs verify`, `tools/wikitool instructions verify`,
 `pytest`-Suite (1195 passed). Typischer Zugriff: Median 229 statt 17.500 Tokens.
 Schließt #92.
 
+**`incoming/.gitkeep` ist jetzt trackbar - Datei- statt Verzeichnismuster in `.gitignore` (#88).**
+`/incoming/` schloss bisher das Verzeichnis selbst aus, und Regel 2 im `.gitignore`-Kopf sagt
+genau, warum das eine Falle ist: git kann keine Datei wieder einschließen, deren Elternverzeichnis
+ausgeschlossen ist, also blieb ein `!incoming/.gitkeep` wirkungslos. Ein frischer Klon hatte den
+Eingang deshalb nie - `instructions/bootstrap.md` Schritt 2 (`mkdir -p incoming`) fing das für
+einen Menschen ab, der die Instruction liest, aber nicht für einen Checkout, den eine Maschine
+anlegt: der Korpus-Checkout des MCP-Read-Servers entsteht aus Klon plus `fetch && reset --hard`
+und läuft durch keinen Bootstrap, also fehlte der Eingang dort still, bis das erste Kommando ihn
+brauchte.
+
+Umgestellt auf `/incoming/*` plus `!/incoming/.gitkeep` - jetzt ignoriert das Muster den Inhalt,
+nicht das Verzeichnis, und die Negation greift tatsächlich. Gegengeprüft in beide Richtungen:
+`git check-ignore --no-index incoming/.gitkeep` meldet die Datei als nicht ignoriert,
+`incoming/probe.pdf` weiterhin als ignoriert - die Kanarie aus
+`docs_verify.REQUIRED_IGNORE_CANARIES` hält also unverändert. `incoming/.gitkeep` steht jetzt
+zusätzlich in `REQUIRED_TRACKED_PATHS`, damit eine künftige Rückkehr zur Verzeichnisform
+`docs verify` laut fehlschlagen lässt statt still zu wirken. Ein voller `dist export` +
+`git init` + `git add -A`-Replay bestätigt, dass `incoming/.gitkeep` im allerersten Commit einer
+frischen Instanz landet, während `incoming/probe.pdf` dort weiterhin ignoriert bleibt.
+
+`instructions/bootstrap.md` Schritt 2 entfällt ersatzlos - ein frischer Klon braucht ihn nicht
+mehr -, die übrigen Schritte rücken nach. `mcp-upload/` bleibt bewusst bei der Verzeichnisform
+ohne `.gitkeep`: die Schreibprimitive des `submit`-Tools legt das Verzeichnis selbst an, sobald
+sie gebraucht wird, und ein Checkout, der das Tool nie aktiviert, braucht das Verzeichnis auch
+nie - anders als bei `incoming/` gibt es dort keinen Frisch-Klon-Fall abzudecken. Der
+`.gitignore`-Kommentar zu `mcp-upload/` benennt diesen Kontrast jetzt ausdrücklich, statt sich
+nur noch mit dem alten (identischen) Verhalten von `incoming/` zu vergleichen.
+
+Geändert: `.gitignore` (beide Kommentarblöcke, neues Muster), `incoming/.gitkeep` (neu),
+`tools/chemenu/commands/docs_verify.py` (`REQUIRED_TRACKED_PATHS`), `instructions/bootstrap.md`
+(Schritt 2 entfernt, Rest umnummeriert), `raw/CONTRACT.md`, `tools/CONTRACT.md` (`dist export`-
+Zeile), `README.md` (Architekturdiagramm-Kommentar). Verifiziert: `tools/wikitool docs verify`,
+`tools/wikitool instructions verify`, volle `pytest`-Suite (1195 passed), manueller
+`dist export`-Replay. Schließt #88.
+
 ---
 
 ## 4.7.4 - 2026-09-04 - bootstrap.md nennt den session-id-WARN nach frischem Bootstrap explizit als erwartet