Aufgefallen dem Operator in der Vorbereitungssitzung zu #32 (2026-09-11): „der incoming-Ordner ist nicht im git, da fehlt ein .gitkeep".
Befund
Stimmt, und ein .gitkeep allein reicht nicht. git ls-files incoming war leer, und die Ursache war die Form der Ignore-Regel, nicht eine fehlende Datei:
.gitignore:153:/incoming/ incoming/.gitkeep
/incoming/ schloss das Verzeichnis aus, und git kann keine Datei wieder einschließen, deren Elternverzeichnis ausgeschlossen ist — genau die Regel, die der Kopfkommentar von .gitignore selbst als Punkt 2 aufschreibt.
Damit war die Folge, die #58 über instructions/bootstrap.md Schritt 2 auffing (mkdir -p incoming), eine dauerhafte: ein frischer Klon hatte den Eingang nicht, doctor meldete ihn nur, und dist export schrieb zwar incoming/.gitkeep in ein Export-Verzeichnis, wo die Datei aber aus demselben Grund untracked blieb.
Umsetzung
Von der Verzeichnis- auf die Dateiform gewechselt:
/incoming/*
!/incoming/.gitkeep
incoming/.gitkeep wurde angelegt und ist jetzt getrackt (Commit 36da085). Der Kopfkommentar zu incoming/ in .gitignore beschreibt jetzt die Datei- statt der Verzeichnisform und nennt den Grund für die eine Ankerdatei; der Kommentar zu mcp-upload/ daneben wurde mitgezogen, damit er den jetzt echten Kontrast zu incoming/ benennt (Verzeichnisform bewusst beibehalten, kein .gitkeep, weil die Schreibprimitive des submit-Tools das Verzeichnis selbst auf Bedarf anlegt — es gibt dort keinen Frisch-Klon-Fall abzudecken).
instructions/bootstrap.md Schritt 2 (mkdir -p incoming) ist ersatzlos entfallen, die übrigen Schritte wurden neu nummeriert (2-7 statt 3-8), inklusive der internen Verweise darauf.
raw/CONTRACT.md, tools/CONTRACT.md (dist export-Zeile) und README.mds Architekturdiagramm wurden nachgezogen, weil sie incoming/ bisher pauschal als „gitignored" statt „Inhalt gitignored, Verzeichnis über eine Ankerdatei getrackt" beschrieben.
Akzeptanzkriterien
git ls-files incoming nennt nach der Änderung incoming/.gitkeep — bestätigt nach publish (Commit 36da085)
git check-ignore --no-index incoming/probe.pdf meldet die Datei weiterhin als ignoriert; docs verify bleibt grün, ohne dass eine Kanarie geändert wird — bestätigt (docs verify: „11 ignore canaries clear"), incoming/.gitkeep prüft check-ignore als NICHT ignoriert
incoming/.gitkeep steht in docs_verify.REQUIRED_TRACKED_PATHS, damit eine künftige Rückkehr zur Verzeichnisform auffällt statt still zu wirken
Der .gitignore-Kommentarblock zu incoming/ beschreibt die Datei- statt der Verzeichnisform und nennt den Grund für die eine Ankerdatei
instructions/bootstrap.md Schritt 2 entfällt — der frische Klon braucht ihn nicht mehr
dist export liefert incoming/.gitkeep weiterhin mit, und der Frisch-Instanz-Replay bleibt grün — lokal per manuellem dist export + git init + git add -A-Replay bestätigt: incoming/.gitkeep landet im allerersten Commit, incoming/probe.pdf bleibt in derselben frischen Instanz ignoriert. CI (.gitea/workflows/ci.yml) bestätigt denselben Replay serverseitig auf dem gepushten Commit
Changelog-Eintrag, PATCH — 5.0.0-beta.14 → 5.0.0-beta.15, eigener Prosa-Absatz in CHANGES.md
Beim Nachziehen der dist export-Zeile in tools/CONTRACT.md fiel eine zweite, unabhängige Veralterung auf: Text und --help-Docstring behaupten noch raw/{articles,documents,notes,assets}/-Typverzeichnisse, die der Code seit #67 nicht mehr anlegt. Nicht Teil dieser Änderung — dafür #93.
mcp-upload/ — zur Ausgangsfrage des Operators
Kein .gitkeep nötig: mcp-upload/ (aus #32) wird ausschließlich von der Schreibprimitive des submit-Tools selbst angelegt, und ein Checkout, der das Tool nie aktiviert, braucht das Verzeichnis auch nie. Eine generische „alle Verzeichnisse im README nennen und beim Setup/Bootstrap/Upgrade per wikitool lokale Existenz sicherstellen"-Lösung wurde erwogen und verworfen: sie würde für mcp-upload/ nichts gewinnen (das Verzeichnis entsteht lazy, genau dann wenn es gebraucht wird) und für incoming/ unnötig, weil die jetzige Datei-Anker-Lösung dasselbe bereits über den normalen Git-Mechanismus erledigt, ohne ein neues Kommando oder einen neuen Bootstrap-/Upgrade-Schritt zu brauchen. Die Abgrenzung, die dieses Issue selbst schon zog (kein .gitkeep für mcp-upload/), war also bereits die richtige Antwort.
Aufgefallen dem Operator in der Vorbereitungssitzung zu #32 (2026-09-11): „der incoming-Ordner ist nicht im git, da fehlt ein `.gitkeep`".
## Befund
Stimmt, und ein `.gitkeep` allein reicht nicht. `git ls-files incoming` war leer, und die Ursache war die Form der Ignore-Regel, nicht eine fehlende Datei:
```
.gitignore:153:/incoming/ incoming/.gitkeep
```
`/incoming/` schloss das **Verzeichnis** aus, und git kann keine Datei wieder einschließen, deren Elternverzeichnis ausgeschlossen ist — genau die Regel, die der Kopfkommentar von `.gitignore` selbst als Punkt 2 aufschreibt.
Damit war die Folge, die #58 über `instructions/bootstrap.md` Schritt 2 auffing (`mkdir -p incoming`), eine dauerhafte: ein frischer Klon hatte den Eingang nicht, `doctor` meldete ihn nur, und `dist export` schrieb zwar `incoming/.gitkeep` in ein Export-Verzeichnis, wo die Datei aber aus demselben Grund untracked blieb.
## Umsetzung
Von der Verzeichnis- auf die Dateiform gewechselt:
```
/incoming/*
!/incoming/.gitkeep
```
`incoming/.gitkeep` wurde angelegt und ist jetzt getrackt (Commit `36da085`). Der Kopfkommentar zu `incoming/` in `.gitignore` beschreibt jetzt die Datei- statt der Verzeichnisform und nennt den Grund für die eine Ankerdatei; der Kommentar zu `mcp-upload/` daneben wurde mitgezogen, damit er den jetzt echten Kontrast zu `incoming/` benennt (Verzeichnisform bewusst beibehalten, kein `.gitkeep`, weil die Schreibprimitive des `submit`-Tools das Verzeichnis selbst auf Bedarf anlegt — es gibt dort keinen Frisch-Klon-Fall abzudecken).
`instructions/bootstrap.md` Schritt 2 (`mkdir -p incoming`) ist ersatzlos entfallen, die übrigen Schritte wurden neu nummeriert (2-7 statt 3-8), inklusive der internen Verweise darauf.
`raw/CONTRACT.md`, `tools/CONTRACT.md` (`dist export`-Zeile) und `README.md`s Architekturdiagramm wurden nachgezogen, weil sie `incoming/` bisher pauschal als „gitignored" statt „Inhalt gitignored, Verzeichnis über eine Ankerdatei getrackt" beschrieben.
## Akzeptanzkriterien
- [x] `git ls-files incoming` nennt nach der Änderung `incoming/.gitkeep` — bestätigt nach `publish` (Commit `36da085`)
- [x] `git check-ignore --no-index incoming/probe.pdf` meldet die Datei weiterhin als ignoriert; `docs verify` bleibt grün, ohne dass eine Kanarie geändert wird — bestätigt (`docs verify`: „11 ignore canaries clear"), `incoming/.gitkeep` prüft `check-ignore` als NICHT ignoriert
- [x] `incoming/.gitkeep` steht in `docs_verify.REQUIRED_TRACKED_PATHS`, damit eine künftige Rückkehr zur Verzeichnisform auffällt statt still zu wirken
- [x] Der `.gitignore`-Kommentarblock zu `incoming/` beschreibt die Datei- statt der Verzeichnisform und nennt den Grund für die eine Ankerdatei
- [x] `instructions/bootstrap.md` Schritt 2 entfällt — der frische Klon braucht ihn nicht mehr
- [x] `dist export` liefert `incoming/.gitkeep` weiterhin mit, und der Frisch-Instanz-Replay bleibt grün — lokal per manuellem `dist export` + `git init` + `git add -A`-Replay bestätigt: `incoming/.gitkeep` landet im allerersten Commit, `incoming/probe.pdf` bleibt in derselben frischen Instanz ignoriert. CI (`.gitea/workflows/ci.yml`) bestätigt denselben Replay serverseitig auf dem gepushten Commit
- [x] Changelog-Eintrag, PATCH — `5.0.0-beta.14` → `5.0.0-beta.15`, eigener Prosa-Absatz in `CHANGES.md`
## Verifiziert
`tools/wikitool docs verify` (OK), `tools/wikitool instructions verify` (OK), volle `pytest`-Suite (1195 passed), manueller `dist export`+`git init`+`git add -A`-Replay.
## Nebenbefund, ausgelagert
Beim Nachziehen der `dist export`-Zeile in `tools/CONTRACT.md` fiel eine zweite, unabhängige Veralterung auf: Text und `--help`-Docstring behaupten noch `raw/{articles,documents,notes,assets}/`-Typverzeichnisse, die der Code seit #67 nicht mehr anlegt. Nicht Teil dieser Änderung — dafür #93.
## mcp-upload/ — zur Ausgangsfrage des Operators
Kein `.gitkeep` nötig: `mcp-upload/` (aus #32) wird ausschließlich von der Schreibprimitive des `submit`-Tools selbst angelegt, und ein Checkout, der das Tool nie aktiviert, braucht das Verzeichnis auch nie. Eine generische „alle Verzeichnisse im README nennen und beim Setup/Bootstrap/Upgrade per `wikitool` lokale Existenz sicherstellen"-Lösung wurde erwogen und verworfen: sie würde für `mcp-upload/` nichts gewinnen (das Verzeichnis entsteht lazy, genau dann wenn es gebraucht wird) und für `incoming/` unnötig, weil die jetzige Datei-Anker-Lösung dasselbe bereits über den normalen Git-Mechanismus erledigt, ohne ein neues Kommando oder einen neuen Bootstrap-/Upgrade-Schritt zu brauchen. Die Abgrenzung, die dieses Issue selbst schon zog (kein `.gitkeep` für `mcp-upload/`), war also bereits die richtige Antwort.
Umgesetzt und veröffentlicht in 36da085 (5.0.0-beta.15). Alle Akzeptanzkriterien erfüllt, Details und Verifikation im Issue-Body. Nebenbefund zu veralteten dist export-Typverzeichnis-Behauptungen ausgelagert nach #93.
Umgesetzt und veröffentlicht in `36da085` (`5.0.0-beta.15`). Alle Akzeptanzkriterien erfüllt, Details und Verifikation im Issue-Body. Nebenbefund zu veralteten `dist export`-Typverzeichnis-Behauptungen ausgelagert nach #93.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Aufgefallen dem Operator in der Vorbereitungssitzung zu #32 (2026-09-11): „der incoming-Ordner ist nicht im git, da fehlt ein
.gitkeep".Befund
Stimmt, und ein
.gitkeepallein reicht nicht.git ls-files incomingwar leer, und die Ursache war die Form der Ignore-Regel, nicht eine fehlende Datei:/incoming/schloss das Verzeichnis aus, und git kann keine Datei wieder einschließen, deren Elternverzeichnis ausgeschlossen ist — genau die Regel, die der Kopfkommentar von.gitignoreselbst als Punkt 2 aufschreibt.Damit war die Folge, die #58 über
instructions/bootstrap.mdSchritt 2 auffing (mkdir -p incoming), eine dauerhafte: ein frischer Klon hatte den Eingang nicht,doctormeldete ihn nur, unddist exportschrieb zwarincoming/.gitkeepin ein Export-Verzeichnis, wo die Datei aber aus demselben Grund untracked blieb.Umsetzung
Von der Verzeichnis- auf die Dateiform gewechselt:
incoming/.gitkeepwurde angelegt und ist jetzt getrackt (Commit36da085). Der Kopfkommentar zuincoming/in.gitignorebeschreibt jetzt die Datei- statt der Verzeichnisform und nennt den Grund für die eine Ankerdatei; der Kommentar zumcp-upload/daneben wurde mitgezogen, damit er den jetzt echten Kontrast zuincoming/benennt (Verzeichnisform bewusst beibehalten, kein.gitkeep, weil die Schreibprimitive dessubmit-Tools das Verzeichnis selbst auf Bedarf anlegt — es gibt dort keinen Frisch-Klon-Fall abzudecken).instructions/bootstrap.mdSchritt 2 (mkdir -p incoming) ist ersatzlos entfallen, die übrigen Schritte wurden neu nummeriert (2-7 statt 3-8), inklusive der internen Verweise darauf.raw/CONTRACT.md,tools/CONTRACT.md(dist export-Zeile) undREADME.mds Architekturdiagramm wurden nachgezogen, weil sieincoming/bisher pauschal als „gitignored" statt „Inhalt gitignored, Verzeichnis über eine Ankerdatei getrackt" beschrieben.Akzeptanzkriterien
git ls-files incomingnennt nach der Änderungincoming/.gitkeep— bestätigt nachpublish(Commit36da085)git check-ignore --no-index incoming/probe.pdfmeldet die Datei weiterhin als ignoriert;docs verifybleibt grün, ohne dass eine Kanarie geändert wird — bestätigt (docs verify: „11 ignore canaries clear"),incoming/.gitkeepprüftcheck-ignoreals NICHT ignoriertincoming/.gitkeepsteht indocs_verify.REQUIRED_TRACKED_PATHS, damit eine künftige Rückkehr zur Verzeichnisform auffällt statt still zu wirken.gitignore-Kommentarblock zuincoming/beschreibt die Datei- statt der Verzeichnisform und nennt den Grund für die eine Ankerdateiinstructions/bootstrap.mdSchritt 2 entfällt — der frische Klon braucht ihn nicht mehrdist exportliefertincoming/.gitkeepweiterhin mit, und der Frisch-Instanz-Replay bleibt grün — lokal per manuellemdist export+git init+git add -A-Replay bestätigt:incoming/.gitkeeplandet im allerersten Commit,incoming/probe.pdfbleibt in derselben frischen Instanz ignoriert. CI (.gitea/workflows/ci.yml) bestätigt denselben Replay serverseitig auf dem gepushten Commit5.0.0-beta.14→5.0.0-beta.15, eigener Prosa-Absatz inCHANGES.mdVerifiziert
tools/wikitool docs verify(OK),tools/wikitool instructions verify(OK), vollepytest-Suite (1195 passed), manuellerdist export+git init+git add -A-Replay.Nebenbefund, ausgelagert
Beim Nachziehen der
dist export-Zeile intools/CONTRACT.mdfiel eine zweite, unabhängige Veralterung auf: Text und--help-Docstring behaupten nochraw/{articles,documents,notes,assets}/-Typverzeichnisse, die der Code seit #67 nicht mehr anlegt. Nicht Teil dieser Änderung — dafür #93.mcp-upload/ — zur Ausgangsfrage des Operators
Kein
.gitkeepnötig:mcp-upload/(aus #32) wird ausschließlich von der Schreibprimitive dessubmit-Tools selbst angelegt, und ein Checkout, der das Tool nie aktiviert, braucht das Verzeichnis auch nie. Eine generische „alle Verzeichnisse im README nennen und beim Setup/Bootstrap/Upgrade perwikitoollokale Existenz sicherstellen"-Lösung wurde erwogen und verworfen: sie würde fürmcp-upload/nichts gewinnen (das Verzeichnis entsteht lazy, genau dann wenn es gebraucht wird) und fürincoming/unnötig, weil die jetzige Datei-Anker-Lösung dasselbe bereits über den normalen Git-Mechanismus erledigt, ohne ein neues Kommando oder einen neuen Bootstrap-/Upgrade-Schritt zu brauchen. Die Abgrenzung, die dieses Issue selbst schon zog (kein.gitkeepfürmcp-upload/), war also bereits die richtige Antwort.Umgesetzt und veröffentlicht in
36da085(5.0.0-beta.15). Alle Akzeptanzkriterien erfüllt, Details und Verifikation im Issue-Body. Nebenbefund zu veraltetendist export-Typverzeichnis-Behauptungen ausgelagert nach #93.