incoming/ existiert in keinem Klon: ein .gitkeep ist unter /incoming/ nicht trackbar
#88
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.