stack: Provider-Schicht für Aufgaben-Tracker mit Super-Productivity-Adapter (#124)

Files changed:
- .gitignore
- CHANGES.md
- VERSION
- tools/CONTRACT.md
- tools/chemenu/commands/docs_verify.py
- tools/chemenu/commands/doctor.py
- tools/chemenu/config.py
- tools/chemenu/errors.py
- tools/chemenu/tasks/__init__.py
- tools/chemenu/tasks/config.py
- tools/chemenu/tasks/protocol.py
- tools/chemenu/tasks/superproductivity.py
- tools/chemenu/tests/test_doctor.py
- tools/chemenu/tests/test_superproductivity.py
- tools/chemenu/tests/test_tasks_config.py
- tools/chemenu/tests/test_tasks_protocol.py

CHANGES.md

@@ -59,7 +59,7 @@ concern - readable here, never shipped as something to parse.
 
 ---
 
-## 7.0.0-beta.1 - 2026-09-19 - Typ `project` und Collection `kb/gtd/`: das Vorhaben als eigene Seitenart
+## 7.0.0-beta.2 - 2026-09-19 - Task-tracker provider layer, with a Super Productivity adapter
 
 **Author:** Torben Nehmer
 
@@ -69,6 +69,7 @@ concern - readable here, never shipped as something to parse.
 
 <!-- wikitool:bumps -->
 - Typ `project` und Collection `kb/gtd/`: das Vorhaben als eigene Seitenart
+- Task-tracker provider layer, with a Super Productivity adapter
 <!-- /wikitool:bumps -->
 
 ### Typ `project` und Collection `kb/gtd/`: das Vorhaben als eigene Seitenart
@@ -94,6 +95,40 @@ verantwortlich macht. `kb/entities/COLLECTION.md` traegt jetzt einen `gtd:`-Bloc
 `see-also`), ohne den keine Kante von einer Entity auf ein Vorhaben autorisierbar waere - das ist
 der Block, auf den #118 wartet.
 
+### Task-tracker provider layer, with a Super Productivity adapter
+
+Gitea #119 (Paket #124): die Schicht, ueber die `wikitool` an einen Aufgaben-Tracker kommt -
+ohne dass eine Instruction je erfaehrt, welcher es ist (D25). `chemenu.tasks.protocol` deklariert
+`TaskReader`/`TaskWriter` als getrennte Protocols, `chemenu.tasks.superproductivity` implementiert
+beide gegen Super Productivity, `.wikitool-tasks.json` (`chemenu.tasks.config`) traegt Provider,
+Verbindungsangaben und die drei Schwellwerte des Wochenrueckblicks (#125). `wikitool doctor`
+berichtet den konfigurierten Provider, seinen Lesepfad-Status und ob seine lokale REST-API
+antwortet - read-only, FAILt nur auf eine kaputte Konfiguration, nie auf einen nicht laufenden
+Tracker. Kein Kommando entsteht hier (#124s eigene Abgrenzung) - das ist #125/#126.
+
+Zwei Zwischenbefunde aus der Umsetzung, gegen den tatsaechlichen Quellcode von
+`super-productivity/super-productivity` (`master`, 2026-09-19) verifiziert:
+
+- **Der Lesepfad liest keine `db.json`** - die gibt es auf dem Desktop nicht, der Live-Zustand
+  liegt in IndexedDB. Gelesen wird die neueste Datei unter dessen periodischen
+  Dateisystem-Backups (`electron/backup.ts`, `<userData>/backups/<timestamp>.json`), deren
+  Inhalt exakt die verifizierte Form hat.
+- **Die lokale REST-API kann keine Projekte anlegen** - `GET /projects` existiert,
+  `POST /projects` nicht (`electron/local-rest-api-handler.service.ts`). Damit entfaellt fuer
+  diesen Provider der in #119 D31 vorgesehene automatische Schreibpfad; `create_project` prueft
+  weiterhin die Namenskollision (D8), verlangt dann aber menschliches Eingreifen statt es zu
+  simulieren: `SuperProductivityWriter.create_project` wirft ein neues
+  `chemenu.errors.HumanInterventionRequired` mit Anweisungen fuer den Menschen und einem
+  `verify()`, das den Lesepfad danach erneut befragt statt der Bestaetigung einfach zu glauben.
+  Dieselbe Klasse haengt sich an den bestehenden `EXIT_NEEDS_CLEARANCE`-Code (42) - keine neue
+  benannte Gate, aber dieselbe Haltung: dem Menschen die Ausgabe zeigen und anhalten, statt eine
+  Umgehung zu erfinden. Die CLI-seitige Uebersetzung (`needs_clearance`) folgt mit dem Kommando
+  in #126; #124 liefert nur die Bibliotheksseite. #119s Umsetzungstabelle und #124s eigener
+  Akzeptanzkriterien-Absatz sind entsprechend nachgezogen.
+
+Ausserdem verifiziert, ohne Designfolgen: Super Productivitys Someday/Maybe-Aequivalent ist der
+bestehende `backlogTaskIds`-Puffer je Projekt, keine eigene Tag-Konvention.
+
 ---
 
 ## 6.2.0 - 2026-09-19 - Entity-Subtyp project nach codebase umbenannt