Issue-Texte aus der Zeit vor dem Chemenu-Rename tragen veraltete Pfade und Repo-Namen #29

New Issue

2026-09-01T15:22:23Z

torben commented

2026-09-01 15:22:23 +00:00

Befund

Der Rename in 2.0.0 (Issue #3) hat das Python-Paket von wiki_tools nach chemenu und das Repo von torben/llm-wiki-test1 nach torben/chemenu bewegt. Die Issue-Texte sind nicht mitgezogen worden — sie sind kein Teil des Arbeitsbaums, also hat weder docs verify noch ein Test sie erwischt, und keiner von beiden wird es je tun (wikitool kennt diesen Tracker nicht und soll ihn nicht kennenlernen, siehe instructions/dev/issue-tracking.md § „What no tool checks").

Erledigt in zwei Durchgängen (Triage 2026-09-04, Abschluss-Durchgang am selben Tag). Beide Hälften sind durch: die einmaligen Pfadkorrekturen und — der eigentliche Wert — die Regel, die verhindert, dass es beim nächsten Rename wieder passiert.

Warum das mehr war als Kosmetik

Das Repo wird öffentlich geschaltet. Ein Issue ist für einen Fremden oft der erste zusammenhängende Text über eine Codestelle, den er liest — und ein Pfad, der ins Leere zeigt, kostet ihn genau die Zeit, die das Issue sparen sollte. Bei #10 kam dazu, dass der Text einen privaten Hostnamen als Beleg führte.

Die Regel, umgesetzt in 4.5.1

instructions/dev/issue-tracking.md trägt seit 4.5.1 (Commit 87a47cc) den Abschnitt „Renames and other decay in the tracker", eingefügt nach Schritt 7, vor „What no tool checks", plus einen Trigger in „When to run". Drei Klauseln:

Ein Rename ist nicht fertig, wenn der Baum grün ist — der Durchgang durch die offenen Issues gehört zum Rename, in der Sitzung, die ihn gemacht hat, nicht als Nachtrag, an den sich jemand erinnert.
Wegweiser wird nachgezogen, Beleg bleibt stehen und wird datiert; jede Korrektur wird am Ende des Bodies vermerkt, damit der nächste Durchgang einen geprüften Pfad von einem zufällig richtigen unterscheiden kann.
Renames sind nicht das Einzige, was Issue-Texte altern lässt: eine zitierte kb/-Seite kann verschwunden sein (wikitool search gegen die Titel ist der zweite Durchgang), und ein alter Body kann private Infrastrukturangaben in einen inzwischen öffentlichen Tracker tragen.

Verifiziert vor dem Publish: docs verify, instructions verify, pytest (963 passed) — alle grün.

Der Durchgang, vollständig

Nachbedingung, die für jeden angefassten Body galt: kein wiki_tools- oder llm-wiki-test1-Vorkommen mehr, das als Wegweiser gemeint ist; jeder verbliebene Pfad zeigt auf eine Datei, die im Baum existiert; kein privater Hostname; eine Vermerkzeile am Ende. Historische Zitate bleiben, mit Datum. Alle unten aufgeführten Bodies erfüllen sie.

Korrigiert

#6 — tools/wiki_tools/search/fuse.py → tools/chemenu/search/fuse.py, tools/wiki_tools/tests/test_search.py → tools/chemenu/tests/test_search.py.
#10 — wiki_tools/ → chemenu/, und der ci-binford/binford-build.yaml-Beleg neutral als ci-build/ci-build.yaml formuliert — dieselbe Formulierung, die im Baum längst steht. Zusätzlich der Widerspruch zwischen Kommentar 318 und 342 zugunsten von 318 aufgelöst (die Gegenprobe, die 342 nicht gemacht hat).
#23 — tools/wiki_tools/tests/conftest.py → tools/chemenu/tests/conftest.py, wiki_tools/ → chemenu/. Dazu der _WIKITOOL_ENV-Auszug auf acht Einträge gebracht (CHEMENU_ROOT kam mit 2.3.0 dazu) — der schädlichere Fehler, weil eine kalte Sitzung das Issue daran für erledigt halten konnte.
#4 — tools/wiki_tools/commands/xref.py → tools/chemenu/commands/xref.py; publish-cycle.md, kb/index.md, wiki-ingest/SKILL.md geprüft, existieren unverändert.
#5 — tools/wiki_tools/commands/docs_verify.py → tools/chemenu/commands/docs_verify.py; die zitierten Befehle gegen tools/CONTRACT.md geprüft.
#15 — wiki_tools/search/base.py → tools/chemenu/search/base.py, Datei und SearchBackend-Protokoll dort verifiziert. Die commonplace/kb/…-Pfade sind korrekt und bleiben (beide Dateien existieren). Bei #19 ergänzt, dass es geschlossen ist. Die Sonar-Frist 2026-09-27 ist noch Zukunft und bleibt als Frist stehen — nach dem Datum als abgelaufen umzuformulieren.
#21 — pfadseitig sauber; korrigiert wurden der relative Markdown-Link (löste aus der Issue-Ansicht nicht auf, jetzt src/branch/main/) und die Beschreibung von claude-code-model-selection.md, die noch den Stand vor 4.3.3 wiedergab („stack-dev at Opus high" statt der drei Phasenzeilen).
#16 — geprüft, pfadseitig sauber. provenance.py zur Eindeutigkeit als tools/chemenu/provenance.py ausgeschrieben; der Prioritätshinweis nannte noch das abgeschaffte prio/1 und heißt jetzt prio/blocking.

Entfallen

#7, #19 — geschlossen; ein geschlossener Body ist für niemanden mehr ein Wegweiser.
#26 — beim ersten Durchgang als offen geführt, ist aber seit 2026-09-02 geschlossen und fällt damit nach derselben Regel heraus, die dieses Issue geschrieben hat („Closed issues are out of scope - they guide nobody"). Nicht angefasst.

Was der Durchgang zusätzlich gefunden hat

Zwei Bodies waren nicht nur pfadstale, sondern inhaltlich überholt — die Fehlerklasse, für die dieselbe Sitzung parallel die Lesesicht-Regel in issue-tracking.md geschrieben hat (#47, Vorschlag G): #21 beschrieb eine Instruction so, wie sie vor 4.3.3 aussah, und #16 nannte ein Label-Schema, das es nicht mehr gibt. Beides ist genau der Fall „der Body ist erkennbar veraltet, also wird er richtiggestellt, bevor jemand auf ihm arbeitet" — hier angewandt statt nur aufgeschrieben.

Vorgeschichte

Aufgenommen am 2026-09-01 nach einem Durchgang durch alle damals offenen Issues; prio/waiting, weil der Auslöser (Öffentlichschaltung) noch nicht gefeuert hatte. Am 2026-09-04 in der Triage-Sitzung zur Hälfte abgearbeitet, prio/waiting → prio/planned, weil der Auslöser gefeuert hat. Am selben Tag mit #47 zu einem Block zusammengezogen: der Regelabsatz ging als 4.5.1 (Commit 87a47cc) hinaus, der verbleibende Pfad-Durchgang folgte im Abschluss-Durchgang derselben Sitzungskette und schließt dieses Issue.

## Befund Der Rename in 2.0.0 (Issue #3) hat das Python-Paket von `wiki_tools` nach `chemenu` und das Repo von `torben/llm-wiki-test1` nach `torben/chemenu` bewegt. **Die Issue-Texte sind nicht mitgezogen worden** — sie sind kein Teil des Arbeitsbaums, also hat weder `docs verify` noch ein Test sie erwischt, und keiner von beiden wird es je tun (`wikitool` kennt diesen Tracker nicht und soll ihn nicht kennenlernen, siehe `instructions/dev/issue-tracking.md` § „What no tool checks"). Erledigt in zwei Durchgängen (Triage 2026-09-04, Abschluss-Durchgang am selben Tag). Beide Hälften sind durch: die einmaligen Pfadkorrekturen und — der eigentliche Wert — die Regel, die verhindert, dass es beim nächsten Rename wieder passiert. ## Warum das mehr war als Kosmetik Das Repo wird öffentlich geschaltet. Ein Issue ist für einen Fremden oft der erste zusammenhängende Text über eine Codestelle, den er liest — und ein Pfad, der ins Leere zeigt, kostet ihn genau die Zeit, die das Issue sparen sollte. Bei #10 kam dazu, dass der Text einen privaten Hostnamen als Beleg führte. ## Die Regel, umgesetzt in 4.5.1 `instructions/dev/issue-tracking.md` trägt seit `4.5.1` (Commit `87a47cc`) den Abschnitt **„Renames and other decay in the tracker"**, eingefügt nach Schritt 7, vor „What no tool checks", plus einen Trigger in „When to run". Drei Klauseln: 1. Ein Rename ist nicht fertig, wenn der Baum grün ist — der Durchgang durch die offenen Issues gehört zum Rename, in der Sitzung, die ihn gemacht hat, nicht als Nachtrag, an den sich jemand erinnert. 2. Wegweiser wird nachgezogen, Beleg bleibt stehen und wird datiert; jede Korrektur wird am Ende des Bodies vermerkt, damit der nächste Durchgang einen geprüften Pfad von einem zufällig richtigen unterscheiden kann. 3. Renames sind nicht das Einzige, was Issue-Texte altern lässt: eine zitierte `kb/`-Seite kann verschwunden sein (`wikitool search` gegen die Titel ist der zweite Durchgang), und ein alter Body kann private Infrastrukturangaben in einen inzwischen öffentlichen Tracker tragen. Verifiziert vor dem Publish: `docs verify`, `instructions verify`, `pytest` (963 passed) — alle grün. ## Der Durchgang, vollständig **Nachbedingung, die für jeden angefassten Body galt:** kein `wiki_tools`- oder `llm-wiki-test1`-Vorkommen mehr, das als Wegweiser gemeint ist; jeder verbliebene Pfad zeigt auf eine Datei, die im Baum existiert; kein privater Hostname; eine Vermerkzeile am Ende. Historische Zitate bleiben, mit Datum. Alle unten aufgeführten Bodies erfüllen sie. ### Korrigiert - [x] **#6** — `tools/wiki_tools/search/fuse.py` → `tools/chemenu/search/fuse.py`, `tools/wiki_tools/tests/test_search.py` → `tools/chemenu/tests/test_search.py`. - [x] **#10** — `wiki_tools/` → `chemenu/`, und der `ci-binford`/`binford-build.yaml`-Beleg neutral als `ci-build`/`ci-build.yaml` formuliert — dieselbe Formulierung, die im Baum längst steht. Zusätzlich der Widerspruch zwischen Kommentar 318 und 342 zugunsten von 318 aufgelöst (die Gegenprobe, die 342 nicht gemacht hat). - [x] **#23** — `tools/wiki_tools/tests/conftest.py` → `tools/chemenu/tests/conftest.py`, `wiki_tools/` → `chemenu/`. Dazu der `_WIKITOOL_ENV`-Auszug auf acht Einträge gebracht (`CHEMENU_ROOT` kam mit 2.3.0 dazu) — der schädlichere Fehler, weil eine kalte Sitzung das Issue daran für erledigt halten konnte. - [x] **#4** — `tools/wiki_tools/commands/xref.py` → `tools/chemenu/commands/xref.py`; `publish-cycle.md`, `kb/index.md`, `wiki-ingest/SKILL.md` geprüft, existieren unverändert. - [x] **#5** — `tools/wiki_tools/commands/docs_verify.py` → `tools/chemenu/commands/docs_verify.py`; die zitierten Befehle gegen `tools/CONTRACT.md` geprüft. - [x] **#15** — `wiki_tools/search/base.py` → `tools/chemenu/search/base.py`, Datei und `SearchBackend`-Protokoll dort verifiziert. Die `commonplace/kb/…`-Pfade sind korrekt und bleiben (beide Dateien existieren). Bei #19 ergänzt, dass es geschlossen ist. Die Sonar-Frist 2026-09-27 ist noch Zukunft und bleibt als Frist stehen — nach dem Datum als abgelaufen umzuformulieren. - [x] **#21** — pfadseitig sauber; korrigiert wurden der relative Markdown-Link (löste aus der Issue-Ansicht nicht auf, jetzt `src/branch/main/`) und die Beschreibung von `claude-code-model-selection.md`, die noch den Stand vor `4.3.3` wiedergab („`stack-dev` at Opus high" statt der drei Phasenzeilen). - [x] **#16** — geprüft, pfadseitig **sauber**. `provenance.py` zur Eindeutigkeit als `tools/chemenu/provenance.py` ausgeschrieben; der Prioritätshinweis nannte noch das abgeschaffte `prio/1` und heißt jetzt `prio/blocking`. ### Entfallen - [x] **#7, #19** — geschlossen; ein geschlossener Body ist für niemanden mehr ein Wegweiser. - [x] **#26** — beim ersten Durchgang als offen geführt, ist aber seit 2026-09-02 geschlossen und fällt damit nach derselben Regel heraus, die dieses Issue geschrieben hat („Closed issues are out of scope - they guide nobody"). Nicht angefasst. ## Was der Durchgang zusätzlich gefunden hat Zwei Bodies waren nicht nur pfadstale, sondern **inhaltlich überholt** — die Fehlerklasse, für die dieselbe Sitzung parallel die Lesesicht-Regel in `issue-tracking.md` geschrieben hat (#47, Vorschlag G): #21 beschrieb eine Instruction so, wie sie vor `4.3.3` aussah, und #16 nannte ein Label-Schema, das es nicht mehr gibt. Beides ist genau der Fall „der Body ist erkennbar veraltet, also wird er richtiggestellt, bevor jemand auf ihm arbeitet" — hier angewandt statt nur aufgeschrieben. ## Vorgeschichte Aufgenommen am 2026-09-01 nach einem Durchgang durch alle damals offenen Issues; `prio/waiting`, weil der Auslöser (Öffentlichschaltung) noch nicht gefeuert hatte. Am 2026-09-04 in der Triage-Sitzung zur Hälfte abgearbeitet, `prio/waiting` → `prio/planned`, weil der Auslöser gefeuert hat. Am selben Tag mit #47 zu einem Block zusammengezogen: der Regelabsatz ging als `4.5.1` (Commit `87a47cc`) hinaus, der verbleibende Pfad-Durchgang folgte im Abschluss-Durchgang derselben Sitzungskette und schließt dieses Issue.

torben added the prio/waiting label 2026-09-01 15:22:23 +00:00