build: wikitool new project - Seite und Tracker-Projekt unter einem Namen (#126)

Files changed:
- CHANGES.md
- VERSION
- tools/CONTRACT.md
- tools/chemenu/commands/new_page.py
- tools/chemenu/errors.py
- tools/chemenu/review.py
- tools/chemenu/tasks/__init__.py
- tools/chemenu/tests/test_new_page.py

CHANGES.md

@@ -59,7 +59,7 @@ concern - readable here, never shipped as something to parse.
 
 ---
 
-## 7.0.0-beta.3 - 2026-09-19 - wikitool review: the weekly GTD review as a read-time join
+## 7.0.0-beta.4 - 2026-09-20 - wikitool new project: Seite und Tracker-Projekt unter einem Namen
 
 **Author:** Torben Nehmer
 
@@ -71,6 +71,7 @@ concern - readable here, never shipped as something to parse.
 - Typ `project` und Collection `kb/gtd/`: das Vorhaben als eigene Seitenart
 - Task-tracker provider layer, with a Super Productivity adapter
 - wikitool review: the weekly GTD review as a read-time join
+- wikitool new project: Seite und Tracker-Projekt unter einem Namen
 <!-- /wikitool:bumps -->
 
 ### Typ `project` und Collection `kb/gtd/`: das Vorhaben als eigene Seitenart
@@ -162,6 +163,37 @@ ist ein Konfigurationsfehler, kein Erreichbarkeitsproblem, und braucht deshalb k
 `kb_project_count`/`complete`); ein Test haelt beide Formen gegeneinander, wie es
 `test_mcp_server.py` fuer den MCP-Lesepfad gegen die CLI tut.
 
+### wikitool new project: Seite und Tracker-Projekt unter einem Namen
+
+Gitea #119 (Paket #126): `wikitool new project --name X --set responsibility=Y` legt jetzt, wenn
+`.wikitool-tasks.json` einen Tracker konfiguriert, zusaetzlich ein gleichnamiges Tracker-Projekt
+an - ein Geburtsort, ein Name (D8/D31). Tracker vor Seite: erst steht die Tracker-Seite fest,
+erst danach wird die `kb/`-Seite geschrieben, damit ein Fehlschlag zwischen beiden immer im
+selben, bereits bekannten Zustand landet - "Tracker-Projekt ohne Seite", das `review`s Pruefung 3
+ohnehin meldet - nie im unbekannten "Seite ohne Tracker-Projekt". Ist kein Tracker konfiguriert,
+bleibt es bei der reinen Seitenanlage, jetzt aber ausdruecklich als solche vermerkt statt
+stillschweigend.
+
+`chemenu.tasks.build_reader`/`build_writer` (neu in `chemenu/tasks/__init__.py`) sind die eine
+Dispatch-Tabelle von `TasksConfig.provider` auf einen konkreten Adapter, jetzt von `review.py`
+*und* `new_page.py` geteilt statt zweimal derselben `if cfg.provider == "superproductivity"`.
+
+Fuer einen Provider ohne Schreibpfad (Super Productivity, #124: keine `POST /projects`) wirft
+`create_project` `chemenu.errors.HumanInterventionRequired` - das Kommando zeigt die Anweisung
+und beendet sich mit Exit 42, ohne irgendetwas anzulegen. Die offene Frage aus #126s eigenem
+Issue-Text war, wie ein zustandsloser CLI-Prozess bei einem erneuten Aufruf eine echte
+Namenskollision von "der Mensch hat gerade getan, worum genau dieses Kommando gebeten hat"
+unterscheidet - beides sieht am Lesepfad identisch aus (Tracker hat den Namen, `kb/` noch keine
+Seite). Entschieden (mit dem Betreiber, nicht allein): ein explizites `--resume`, das ein Treffer
+im Tracker als bestaetigte Fortsetzung liest statt als Kollision - ohne `--resume` bleibt jeder
+Treffer eine Ablehnung samt Fundort, auch bei einem Wiederholungsaufruf. `--resume` ohne einen
+tatsaechlich fehlenden Tracker-Eintrag wirft dieselbe `HumanInterventionRequired`-Meldung erneut,
+keine stille Weiterarbeit auf Zuruf. `--resume` bei jedem anderen Typ wird abgelehnt.
+
+Ein erzwungener Fehlschlag der eigentlichen Seiten-Schreibaktion (Schritt 3) nach bereits
+bestaetigtem Tracker-Projekt ist eigens getestet: die Meldung nennt, dass die Tracker-Seite schon
+steht und nur die `kb/`-Seite fehlt, nie umgekehrt.
+
 ---
 
 ## 6.2.0 - 2026-09-19 - Entity-Subtyp project nach codebase umbenannt