Paket 4 aus #119 (D3, D8, D10/D26). Das tragende Bauteil der ganzen Sache: lint fuer
Verpflichtungen statt fuer Wissensstruktur.
Erledigt (80b57e0, Stack 7.0.0-beta.3): wikitool review existiert, mit den fuenf
Pruefungen, dem beidseitigen Namensabgleich und der Teilbericht-Regel aus den Akzeptanzkriterien.
Was es tut
Zieht beim Aufruf die Tracker-Seite ueber die Provider-Schicht (#124) und die kb/-Seite ueber
den vorhandenen Suchweg, joint beide ueber den case-normalisierten Namen und gibt einen
Bericht aus. Es speichert nichts (D3) — das ist das reports/-Muster und folgt dem
Kernprinzip never re-derive, always compile.
Die fuenf Pruefungen
#
Pruefung
Bedingung
1
Stehengeblieben
Tracker-Projekt hat null offene Posten und die kb/-Seite steht auf state: active
2
Waiting-For ueberfaellig
follow_up_at liegt mehr als n Tage zurueck
3
Tracker-Projekt ohne kb/-Seite
kein Titeltreffer und das Projekt ist aelter als n Wochen
4
kb/-Seite ohne offene Schleife
state: active, aber kein Tracker-Projekt oder keine offenen Posten
5
Someday verstaubt
Someday-Posten seit mehr als n Monaten unveraendert
Die drei Schwellwerte kommen aus .wikitool-tasks.json (#124), nicht aus dem Schema.
Pruefung 3 und 4 sind die zwei Richtungen desselben Abgleichs und muessen beide laufen: ein
Rename auf einer Seite bricht den Join lautlos, und erst der beidseitige unmatched-Bericht
macht daraus ein sichtbares Ereignis statt eines stillen Datenverlusts (D8).
Befund aus der Umsetzung: Pruefung 1 und Pruefung 4 sind nicht disjunkt — ein Tracker-Projekt
mit null offenen Posten und einer aktiven kb/-Seite erfuellt beide Bedingungen woertlich
gelesen, und beide melden dann nebeneinander. Das ist keine Dopplung, sondern zwei verschiedene
Aussagen (stalled vs. no-open-loop) ueber denselben Zustand; die Tabelle oben legt das so an,
also blieb es dabei statt eigenmaechtig zu deduplizieren.
Akzeptanzkriterien
Fixtures, gegen die das entscheidbar ist:
Tracker-Projekt mit null offenen Posten, kb/-Seite state: active → Pruefung 1 meldet.
Dieselbe Lage mit state: dormant → meldet nicht. Mit completed oder abandoned
ebenfalls nicht. Das ist der Anti-Rausch-Kern aus D27 und der Grund, warum es dormant
ueberhaupt gibt.
WAITING-Posten mit follow_up_at aelter als die Schwelle → meldet; juenger → meldet nicht.
Tracker-Projekt juenger als die Wochenschwelle ohne kb/-Seite → meldet nicht;
aelter → meldet. (Die Rauschbremse aus D26.)
kb/-Seite state: active, im Tracker existiert kein Projekt dieses Namens → meldet.
Der Namensabgleich ist case-normalisiert: „Kueche renovieren" und „kueche renovieren"
gelten als dasselbe Projekt und erzeugen keinen unmatched-Befund.
Ein Lauf veraendert keine Datei. Ein Test vergleicht den Baum vor und nach dem Aufruf
und stellt Gleichheit fest — einschliesslich kb/log.md, der Indizes und reports/.
(test_a_run_touches_no_file, plus ein Git-Status-Test fuer denselben Anspruch ueber die
CLI.)
Ein unerreichbarer Provider erzeugt niemals einen Bericht, der vollstaendig aussieht.
Der Aufruf endet mit Exit 1, nennt den Grund, sagt welche Pruefungen deshalb nicht liefen,
und gibt die kb/-seitigen Befunde erkennbar als Teilergebnis aus. Ein stiller
Teilbericht waere die schlechteste Fehlerart, die dieses Werkzeug haben kann: er sieht aus
wie eine ruhige Woche. Jeder Providerzugriff (projects(), open_items() je Projekt, someday_items()) ist einzeln abgesichert, sodass ein einzelner scheiternder Aufruf nur
die davon abhaengigen Pruefungen degradiert statt den ganzen Bericht.
--json liefert dieselben Befunde maschinenlesbar; ein Golden-Test haelt beide Ausgaben
gegeneinander, wie beim MCP-Leseserver (test_cli_json_and_text_agree_on_findings).
Das Kommando ist read-only und deshalb vom Iterationsbudget ausgenommen, wie search.
Ohne konfigurierten Provider laeuft es nicht ins Leere, sondern sagt, dass keiner
konfiguriert ist.
docs verify, instructions verify, pytest gruen (1374 Tests, 20 davon neu fuer dieses
Paket).
tools/CONTRACT.md fuehrt eine Zeile fuer review in beiden Tabellen, mit
Fehlervertrag — docs verify prueft die Praesenz der Zeile, ihr Text ist Sitzungsarbeit.
Abhaengigkeiten
status/blocked auf #123 und #124 — beide erledigt, siehe Kommentar unten von 2026-09-19.
Keine offenen Abhaengigkeiten mehr.
Paket 4 aus #119 (D3, D8, D10/D26). Das tragende Bauteil der ganzen Sache: `lint` fuer
Verpflichtungen statt fuer Wissensstruktur.
**Erledigt** (`80b57e0`, Stack 7.0.0-beta.3): `wikitool review` existiert, mit den fuenf
Pruefungen, dem beidseitigen Namensabgleich und der Teilbericht-Regel aus den Akzeptanzkriterien.
## Was es tut
Zieht beim Aufruf die Tracker-Seite ueber die Provider-Schicht (#124) und die `kb/`-Seite ueber
den vorhandenen Suchweg, joint beide **ueber den case-normalisierten Namen** und gibt einen
Bericht aus. **Es speichert nichts** (D3) — das ist das `reports/`-Muster und folgt dem
Kernprinzip *never re-derive, always compile*.
## Die fuenf Pruefungen
| # | Pruefung | Bedingung |
|---|---|---|
| 1 | Stehengeblieben | Tracker-Projekt hat null offene Posten **und** die `kb/`-Seite steht auf `state: active` |
| 2 | Waiting-For ueberfaellig | `follow_up_at` liegt mehr als *n* Tage zurueck |
| 3 | Tracker-Projekt ohne `kb/`-Seite | kein Titeltreffer **und** das Projekt ist aelter als *n* Wochen |
| 4 | `kb/`-Seite ohne offene Schleife | `state: active`, aber kein Tracker-Projekt oder keine offenen Posten |
| 5 | Someday verstaubt | Someday-Posten seit mehr als *n* Monaten unveraendert |
Die drei Schwellwerte kommen aus `.wikitool-tasks.json` (#124), nicht aus dem Schema.
**Pruefung 3 und 4 sind die zwei Richtungen desselben Abgleichs** und muessen beide laufen: ein
Rename auf einer Seite bricht den Join lautlos, und erst der **beidseitige** unmatched-Bericht
macht daraus ein sichtbares Ereignis statt eines stillen Datenverlusts (D8).
**Befund aus der Umsetzung:** Pruefung 1 und Pruefung 4 sind nicht disjunkt — ein Tracker-Projekt
mit null offenen Posten und einer aktiven `kb/`-Seite erfuellt beide Bedingungen woertlich
gelesen, und beide melden dann nebeneinander. Das ist keine Dopplung, sondern zwei verschiedene
Aussagen (stalled vs. no-open-loop) ueber denselben Zustand; die Tabelle oben legt das so an,
also blieb es dabei statt eigenmaechtig zu deduplizieren.
## Akzeptanzkriterien
Fixtures, gegen die das entscheidbar ist:
- [x] Tracker-Projekt mit null offenen Posten, `kb/`-Seite `state: active` → Pruefung 1 meldet.
- [x] Dieselbe Lage mit `state: dormant` → **meldet nicht.** Mit `completed` oder `abandoned`
ebenfalls nicht. Das ist der Anti-Rausch-Kern aus D27 und der Grund, warum es `dormant`
ueberhaupt gibt.
- [x] `WAITING`-Posten mit `follow_up_at` aelter als die Schwelle → meldet; juenger → meldet nicht.
- [x] Tracker-Projekt juenger als die Wochenschwelle ohne `kb/`-Seite → **meldet nicht**;
aelter → meldet. (Die Rauschbremse aus D26.)
- [x] `kb/`-Seite `state: active`, im Tracker existiert kein Projekt dieses Namens → meldet.
- [x] Der Namensabgleich ist **case-normalisiert**: „Kueche renovieren" und „kueche renovieren"
gelten als dasselbe Projekt und erzeugen keinen unmatched-Befund.
- [x] **Ein Lauf veraendert keine Datei.** Ein Test vergleicht den Baum vor und nach dem Aufruf
und stellt Gleichheit fest — einschliesslich `kb/log.md`, der Indizes und `reports/`.
(`test_a_run_touches_no_file`, plus ein Git-Status-Test fuer denselben Anspruch ueber die
CLI.)
- [x] **Ein unerreichbarer Provider erzeugt niemals einen Bericht, der vollstaendig aussieht.**
Der Aufruf endet mit Exit 1, nennt den Grund, sagt welche Pruefungen deshalb nicht liefen,
und gibt die `kb/`-seitigen Befunde erkennbar als Teilergebnis aus. Ein stiller
Teilbericht waere die schlechteste Fehlerart, die dieses Werkzeug haben kann: er sieht aus
wie eine ruhige Woche. Jeder Providerzugriff (`projects()`, `open_items()` je Projekt,
`someday_items()`) ist einzeln abgesichert, sodass ein einzelner scheiternder Aufruf nur
die davon abhaengigen Pruefungen degradiert statt den ganzen Bericht.
- [x] `--json` liefert dieselben Befunde maschinenlesbar; ein Golden-Test haelt beide Ausgaben
gegeneinander, wie beim MCP-Leseserver (`test_cli_json_and_text_agree_on_findings`).
- [x] Das Kommando ist read-only und deshalb **vom Iterationsbudget ausgenommen**, wie `search`.
- [x] Ohne konfigurierten Provider laeuft es nicht ins Leere, sondern sagt, dass keiner
konfiguriert ist.
- [x] `docs verify`, `instructions verify`, `pytest` gruen (1374 Tests, 20 davon neu fuer dieses
Paket).
- [x] `tools/CONTRACT.md` fuehrt eine Zeile fuer `review` in beiden Tabellen, mit
Fehlervertrag — `docs verify` prueft die Praesenz der Zeile, ihr Text ist Sitzungsarbeit.
## Abhaengigkeiten
~~`status/blocked` auf #123 und #124~~ — beide erledigt, siehe Kommentar unten von 2026-09-19.
Keine offenen Abhaengigkeiten mehr.
status/blocked entfernt — #123 und #124 sind erledigt (ee24b6e, 1875449). #124s Lesepfad liefert genau die Form, gegen die diese Pruefungen entworfen sind (case-normalisierter Namensabgleich, follow_up_at fuer WAITING, Someday-Aenderungsdatum) - keine inhaltliche Aenderung an diesem Issue noetig, nur die Blockade.
`status/blocked` entfernt — #123 und #124 sind erledigt (`ee24b6e`, `1875449`). #124s Lesepfad liefert genau die Form, gegen die diese Pruefungen entworfen sind (case-normalisierter Namensabgleich, `follow_up_at` fuer WAITING, Someday-Aenderungsdatum) - keine inhaltliche Aenderung an diesem Issue noetig, nur die Blockade.
Umgesetzt und gepublished: 80b57e0 (Stack 7.0.0-beta.3, --minor). wikitool review mit den fuenf Pruefungen, dem case-normalisierten Namensabgleich und der Teilbericht-Regel bei einem unerreichbaren Provider. 1374 Tests gruen (20 neu), docs verify/instructions verify gruen. Body oben auf den finalen Stand gebracht, alle Akzeptanzkriterien abgehakt. Ein Befund aus der Umsetzung dort ergaenzt: Pruefung 1 und 4 koennen fuer denselben Zustand beide melden (nicht disjunkt), das ist beabsichtigt, keine Dopplung.
Umgesetzt und gepublished: `80b57e0` (Stack 7.0.0-beta.3, `--minor`). `wikitool review` mit den fuenf Pruefungen, dem case-normalisierten Namensabgleich und der Teilbericht-Regel bei einem unerreichbaren Provider. 1374 Tests gruen (20 neu), `docs verify`/`instructions verify` gruen. Body oben auf den finalen Stand gebracht, alle Akzeptanzkriterien abgehakt. Ein Befund aus der Umsetzung dort ergaenzt: Pruefung 1 und 4 koennen fuer denselben Zustand beide melden (nicht disjunkt), das ist beabsichtigt, keine Dopplung.
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.
Paket 4 aus #119 (D3, D8, D10/D26). Das tragende Bauteil der ganzen Sache:
lintfuerVerpflichtungen statt fuer Wissensstruktur.
Erledigt (
80b57e0, Stack 7.0.0-beta.3):wikitool reviewexistiert, mit den fuenfPruefungen, dem beidseitigen Namensabgleich und der Teilbericht-Regel aus den Akzeptanzkriterien.
Was es tut
Zieht beim Aufruf die Tracker-Seite ueber die Provider-Schicht (#124) und die
kb/-Seite ueberden vorhandenen Suchweg, joint beide ueber den case-normalisierten Namen und gibt einen
Bericht aus. Es speichert nichts (D3) — das ist das
reports/-Muster und folgt demKernprinzip never re-derive, always compile.
Die fuenf Pruefungen
kb/-Seite steht aufstate: activefollow_up_atliegt mehr als n Tage zurueckkb/-Seitekb/-Seite ohne offene Schleifestate: active, aber kein Tracker-Projekt oder keine offenen PostenDie drei Schwellwerte kommen aus
.wikitool-tasks.json(#124), nicht aus dem Schema.Pruefung 3 und 4 sind die zwei Richtungen desselben Abgleichs und muessen beide laufen: ein
Rename auf einer Seite bricht den Join lautlos, und erst der beidseitige unmatched-Bericht
macht daraus ein sichtbares Ereignis statt eines stillen Datenverlusts (D8).
Befund aus der Umsetzung: Pruefung 1 und Pruefung 4 sind nicht disjunkt — ein Tracker-Projekt
mit null offenen Posten und einer aktiven
kb/-Seite erfuellt beide Bedingungen woertlichgelesen, und beide melden dann nebeneinander. Das ist keine Dopplung, sondern zwei verschiedene
Aussagen (stalled vs. no-open-loop) ueber denselben Zustand; die Tabelle oben legt das so an,
also blieb es dabei statt eigenmaechtig zu deduplizieren.
Akzeptanzkriterien
Fixtures, gegen die das entscheidbar ist:
kb/-Seitestate: active→ Pruefung 1 meldet.state: dormant→ meldet nicht. Mitcompletedoderabandonedebenfalls nicht. Das ist der Anti-Rausch-Kern aus D27 und der Grund, warum es
dormantueberhaupt gibt.
WAITING-Posten mitfollow_up_ataelter als die Schwelle → meldet; juenger → meldet nicht.kb/-Seite → meldet nicht;aelter → meldet. (Die Rauschbremse aus D26.)
kb/-Seitestate: active, im Tracker existiert kein Projekt dieses Namens → meldet.gelten als dasselbe Projekt und erzeugen keinen unmatched-Befund.
und stellt Gleichheit fest — einschliesslich
kb/log.md, der Indizes undreports/.(
test_a_run_touches_no_file, plus ein Git-Status-Test fuer denselben Anspruch ueber dieCLI.)
Der Aufruf endet mit Exit 1, nennt den Grund, sagt welche Pruefungen deshalb nicht liefen,
und gibt die
kb/-seitigen Befunde erkennbar als Teilergebnis aus. Ein stillerTeilbericht waere die schlechteste Fehlerart, die dieses Werkzeug haben kann: er sieht aus
wie eine ruhige Woche. Jeder Providerzugriff (
projects(),open_items()je Projekt,someday_items()) ist einzeln abgesichert, sodass ein einzelner scheiternder Aufruf nurdie davon abhaengigen Pruefungen degradiert statt den ganzen Bericht.
--jsonliefert dieselben Befunde maschinenlesbar; ein Golden-Test haelt beide Ausgabengegeneinander, wie beim MCP-Leseserver (
test_cli_json_and_text_agree_on_findings).search.konfiguriert ist.
docs verify,instructions verify,pytestgruen (1374 Tests, 20 davon neu fuer diesesPaket).
tools/CONTRACT.mdfuehrt eine Zeile fuerreviewin beiden Tabellen, mitFehlervertrag —
docs verifyprueft die Praesenz der Zeile, ihr Text ist Sitzungsarbeit.Abhaengigkeiten
status/blockedauf #123 und #124Keine offenen Abhaengigkeiten mehr.
status/blockedentfernt — #123 und #124 sind erledigt (ee24b6e,1875449). #124s Lesepfad liefert genau die Form, gegen die diese Pruefungen entworfen sind (case-normalisierter Namensabgleich,follow_up_atfuer WAITING, Someday-Aenderungsdatum) - keine inhaltliche Aenderung an diesem Issue noetig, nur die Blockade.Umgesetzt und gepublished:
80b57e0(Stack 7.0.0-beta.3,--minor).wikitool reviewmit den fuenf Pruefungen, dem case-normalisierten Namensabgleich und der Teilbericht-Regel bei einem unerreichbaren Provider. 1374 Tests gruen (20 neu),docs verify/instructions verifygruen. Body oben auf den finalen Stand gebracht, alle Akzeptanzkriterien abgehakt. Ein Befund aus der Umsetzung dort ergaenzt: Pruefung 1 und 4 koennen fuer denselben Zustand beide melden (nicht disjunkt), das ist beabsichtigt, keine Dopplung.