32 Releases 32 Tags

RSS Feed

• v4.1.2 41f5dfe1cd

  Compare

  v4.1.2 Stable

  torben released this 2026-09-03 04:42:13 +00:00 | 78 commits to main since this release

  4.1.2 - 2026-09-03 - Issue-Abschluss ist ein Body-Rewrite, nicht nur ein Kommentar

  Author: Torben Nehmer

  Aufgefallen beim Schließen von #44: der Abschlussbericht stand als Kommentar da, der Body
  darunter weiterhin als offene Arbeit — Abschnitt „Zu entscheiden" über eine längst getroffene
  Entscheidung, ungehakte Checkliste, Präsens über einen Defekt, den es nicht mehr gab.

  Die Regel gab es dafür schon: Schritt 2 von instructions/dev/issue-tracking.md sagt, der Body
  ist die aktuelle Wahrheit und wird umgeschrieben, wenn sich der Stand ändert. Nur ließ die
  Formulierung offen, wann — und Schritt 7 („Close with what actually happened") war vollständig
  erfüllbar, ohne den Body anzufassen. Ein Abschlussbericht im Kommentar fühlt sich beim Schreiben
  vollständig an; dass der Body dabei zurückbleibt, merkt erst der nächste Leser.

  Schritt 2 ist deshalb schärfer geworden: der Body ist das Plan-File dieses Stacks. Dasselbe,
  was das Plan-Dokument eines Harness ist, und genauso gepflegt — fortlaufend, sobald etwas darin
  nicht mehr stimmt, nicht am Ende. Der Maßstab ist der Abbruch, nicht der Meilenstein: eine
  Session kann jederzeit enden, und was der Body in diesem Moment sagt, ist die vollständige
  Übergabe. Eine frische Session muss zu jedem Zeitpunkt allein aus dem Body weiterarbeiten
  können, ohne Kommentare rückwärts zu lesen und ohne einen Menschen, der es neu erklärt. Entschieden
  ersetzt die Frage, erledigt hakt das Kriterium ab, verworfen steht mit Begründung dort, wo das
  Kriterium stand.

  Schritt 7 ist damit kein Sonderakt mehr, sondern die letzte dieser Aktualisierungen: erst Body
  auf den Endstand, dann schließen, dann die Changelog-Zeile aus Schritt 3. Wer Schritt 2 befolgt
  hat, ist fast fertig; wer nicht, zahlt die ganze Schuld im schlechtesten Moment — der
  geschlossene Body ist die Fassung, die danach alle lesen und niemand mehr aufsucht. #44 steht
  als Beispiel drin.

  Schritt 3 zieht die Konsequenz: ein Kommentar pro Session-Umfang, nicht pro Edit. Ein
  fortlaufend gepflegter Body mit einem Changelog-Kommentar je Änderung wäre Lärm; triviale Pflege
  braucht gar keinen. Der stack-dev-Skill sagt es beim Aufgreifen mit, weil dort die Entscheidung
  fällt, ob eine Session den Body überhaupt anfasst.

  Und die ehrliche Antwort auf die Frage nach dem Tooling: es gibt keins, und es soll keins
  geben. wikitool kennt diesen Tracker nicht. Es wird an Instanzen ausgeliefert, die unter
  dieser URL keine Issues haben, während instructions/dev/ von dist export gepruned wird —
  ein Gitea-Client im ausgelieferten Tool wäre eine Dev-Abhängigkeit, die jede Instanz mitträgt,
  um ein Board zu prüfen, das keine von ihnen hat. Der Tracker ist ausschließlich über
  gitea-mcp erreichbar, also in einer Session, durch einen Agenten.

  Kein docs verify fängt also einen geschlossenen Issue, dessen Body offen klingt, einen Body,
  der seinen eigenen Kommentaren widerspricht, oder ein fehlendes Pflichtlabel. Das steht jetzt
  als eigener Abschnitt „What no tool checks" in der Instruktion — nicht als Bedauern, sondern als
  Begründung dafür, warum die Reihenfolge in Schritt 7 ausgeschrieben ist statt aus Schritt 2
  erschlossen zu werden.

  Downloads

  • chemenu-stack-4.1.2.tar.gz
    466 KiB

    2026-09-03 04:42:13 +00:00
  • chemenu-stack-4.1.2.tar.gz.sha256
    93 B

    2026-09-03 04:42:13 +00:00
  • Source Code (ZIP)
  • Source Code (TAR.GZ)