stack: wikitool review - der Wochenrueckblick als Join zur Lesezeit (#125)

Files changed:
- CHANGES.md
- VERSION
- tools/CONTRACT.md
- tools/chemenu/cli.py
- tools/chemenu/commands/review_cmd.py
- tools/chemenu/commands/run_budget.py
- tools/chemenu/review.py
- tools/chemenu/tests/test_review.py

CHANGES.md

@@ -59,7 +59,7 @@ concern - readable here, never shipped as something to parse.
 
 ---
 
-## 7.0.0-beta.2 - 2026-09-19 - Task-tracker provider layer, with a Super Productivity adapter
+## 7.0.0-beta.3 - 2026-09-19 - wikitool review: the weekly GTD review as a read-time join
 
 **Author:** Torben Nehmer
 
@@ -70,6 +70,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 review: the weekly GTD review as a read-time join
 <!-- /wikitool:bumps -->
 
 ### Typ `project` und Collection `kb/gtd/`: das Vorhaben als eigene Seitenart
@@ -129,6 +130,38 @@ Zwei Zwischenbefunde aus der Umsetzung, gegen den tatsaechlichen Quellcode von
 Ausserdem verifiziert, ohne Designfolgen: Super Productivitys Someday/Maybe-Aequivalent ist der
 bestehende `backlogTaskIds`-Puffer je Projekt, keine eigene Tag-Konvention.
 
+### wikitool review: the weekly GTD review as a read-time join
+
+Gitea #119 (Paket #125): das tragende Bauteil - `wikitool review` joint die Tracker-Seite
+(`chemenu.tasks`, #124) und die `kb/gtd/`-Projektseiten ueber den case-normalisierten Namen und
+gibt einen Bericht aus. Es speichert nichts, nicht einmal eine `reports/`-Datei (D3) - `search`
+ist das naechste Vorbild dafuer, und `review` ist deshalb genauso vom Iterationsbudget
+ausgenommen.
+
+Fuenf Pruefungen (#119 D10/D26), alle in `chemenu.review.run_review`: **stalled** (Tracker-
+Projekt ohne offene Posten, `kb/`-Seite `state: active` - `dormant`/`completed`/`abandoned`
+melden nie, D27), **waiting_overdue** (`follow_up_at` aelter als `stalled_waiting_days`),
+**unpaged_project** (Tracker-Projekt ohne `kb/`-Seite, aelter als `unpaged_project_weeks`),
+**no_open_loop** (`kb/`-Seite `active`, aber kein Tracker-Projekt dieses Namens oder keine
+offenen Posten - die Gegenrichtung des vorigen Abgleichs, D8s beidseitiger unmatched-Bericht),
+**someday_stale** (Someday-Posten seit `someday_stale_months` unveraendert, ueber Kalendermonate
+gerechnet statt ueber `Tage / 30`). Ein Tracker-Projekt ohne offene Posten mit aktiver `kb/`-Seite
+erfuellt zugleich stalled und no_open_loop - beide melden, das ist keine Dopplung, sondern zwei
+verschiedene Aussagen ueber denselben Zustand.
+
+Jeder Providerzugriff ist einzeln abgesichert: scheitert `projects()`, entfallen die vier darauf
+aufbauenden Pruefungen; scheitert `someday_items()`, entfaellt nur die fuenfte; scheitert
+`open_items()` fuer ein einzelnes Tracker-Projekt, faellt nur dieses eine aus den betroffenen
+Pruefungen heraus, der Rest laeuft weiter. Ein so unvollstaendiger Bericht setzt `complete` auf
+`false`, druckt trotzdem alles, was noch entschieden werden konnte, und die CLI beendet sich mit
+Exit 1 - nie mit einem leisen Teilbericht, der wie eine ruhige Woche aussieht. Fehlt
+`.wikitool-tasks.json` ganz, oder ist es kaputt, scheitert der Aufruf sofort und sagt das - das
+ist ein Konfigurationsfehler, kein Erreichbarkeitsproblem, und braucht deshalb keinen Teilbericht.
+
+`--json` traegt dieselben Befunde maschinenlesbar (`findings`/`checks_run`/`checks_skipped`/
+`kb_project_count`/`complete`); ein Test haelt beide Formen gegeneinander, wie es
+`test_mcp_server.py` fuer den MCP-Lesepfad gegen die CLI tut.
+
 ---
 
 ## 6.2.0 - 2026-09-19 - Entity-Subtyp project nach codebase umbenannt