Reine Lesevorgänge (wiki-query ohne abgelegte Seite) schreiben keinen Eintrag mehr in kb/log.md. kb/log.md bleibt das Protokoll dessen, was das Wiki gelernt oder verändert hat. Dazu ein Nebenbefund aus derselben Analyse: sync/publish erzeugen Katalog und kb/provenance.md nicht mehr neu, wenn lokal nur Log-Einträge offen waren.
Wann geholt wird. Es gibt kein git pull. reconcile() (tools/chemenu/commands/git_publish.py) holt per fetch und führt per merge --ff-only oder rebase zusammen, nie mit Merge-Commit. Aufrufer:
wikitool sync - zu Beginn jeder Skill-Session (instructions/session-setup.md, von allen Wiki-Skills verlinkt, auch wiki-query).
publish - vor dem Stagen (nur mit Push) und einmal nach abgelehntem Push.
Der MCP-Leseserver holt außerhalb von wikitool per fetch + reset --hard (instructions/mcp-read-server.md).
Wie zusammengeführt wurde. Generierte Dateien zählen nie als Überschneidung. Wo sie Git im Weg stehen, legt _around_generated sie beiseite. Der lokale Log-Zusatz (_log_suffix, nur angehängte Bytes) wird nach dem Fast-Forward/Rebase ans Ende gehängt. Katalog und Provenance wurden in 10.1.0 dabei immer neu erzeugt. Ist das Log nicht nur angehängt, sondern geändert, ergibt das conflict.
Was das für Query-Einträge hieß - der Grund für die Entscheidung:
wiki-query Schritt 8 loggte, publizierte aber nicht. Der Eintrag blieb uncommittet liegen und fuhr im nächsten fremden Publish mit, auch bei publish --path (generated_outside). Die Commit-Nachricht nannte ihn nicht.
War remote ein Ingest angekommen, lief jeder sync mit offenem Query-Eintrag durch _around_generated und erzeugte den Katalog neu. index_build.py schreibt date.today() hinein, also war danach auch kb/index.md geändert, obwohl lokal nur gelesen wurde.
Die Reihenfolge im Log ist die Ankunftsfolge, nicht die Zeit. Lokale Einträge landen hinter eingetroffenen, die Daten können rückwärts laufen.
Das Log war unvollständig: MCP-Abfragen loggten nicht, ein reiner Leser publiziert nie, ein Klon ohne Push-Recht kommt nicht am Publish-Remote-Gate vorbei.
Kein Werkzeug las Query-Einträge. log status zählt nur ingest seit dem letzten lint. Ein Eintrag trägt keinen Autor; git blame zeigt den Publizierenden, nicht den Fragenden.
Ein Lesevorgang ist keine Operation am Wiki. docs/explanation/knowledge-and-commitment.md warnt davor, das Log mit Einträgen zu füllen, die nicht festhalten, was das Wiki gelernt hat.
Entscheidung
Option a (Betreiber, 2026-10-16): Reine Lesevorgänge werden nicht mehr geloggt.
Verworfen:
b1 lokale Datei außerhalb des Repos: kein Leser, nicht geteilt, eine zweite Telemetrie.
b2 eine Datei pro Klon im Repo: löst die Reihenfolge, aber nicht den geänderten Arbeitsbaum und den fehlenden Push. Viel neue Mechanik (Klon-Kennung, neuer generierter Pfad, Dist-Vorlage, Ownership) für einen ungeklärten Nutzen.
c nur Doku angleichen: lässt Punkte 1-4 bestehen.
Das Bedarfssignal (eine Frage, die das Wiki nicht beantworten kann) läuft über den Weg, den knowledge-and-commitment.md für Aufgaben vorsieht. Die Antwort sagt wie bisher, dass das Wiki keine belastbare Quelle hat, und bietet einen Ingest an. Will der Nutzer die Lücke festhalten, legt der Agent auf seinen Wunsch tools/wikitool task new --inbox --title "..." an. Ohne konfigurierten Tracker bleibt es beim Angebot im Chat.
--op query bleibt gültig. Bestehende Logs enthalten solche Einträge, und eine instanzeigene Instruktion darf das Op noch schreiben. Einen Flag-Wert zu entfernen, wäre laut version-parts.md (Katalog: „flag removed or renamed") ein Bruch der Kompatibilität. Das Op wird nur nicht mehr vom Stack geschrieben, und die Hilfe sagt das.
Umgesetzte Änderungen
instructions/wiki-query/SKILL.md - Schritt 8 entfällt; die Hard rule kennt nur noch Schritt 7 als Ausnahme; log append steht nicht mehr unter den benutzten Befehlen; Schritt 7 verweist für das Loggen einer abgelegten Seite auf wiki-manage / publish-cycle.md (create); der Decision point „Nothing found?" nennt task new --inbox auf Wunsch des Nutzers.
instructions/publish-cycle.md Schritt 3: Die --op-Aufzählung nennt query nicht mehr.
tools/chemenu/commands/log_append.py - VALID_OPS unverändert; Usage, Notes und --op-Hilfe führen query als Altwert. tools/CONTRACT.md und docs/reference/commands/catalog-and-log.md neu erzeugt.
git_publish.py_around_generated - Katalog und Provenance werden nur neu erzeugt, wenn außer kb/log.md eine generierte Datei beiseitegelegt wurde, eine Konfliktauflösung eine andere generierte Datei als das Log betraf, oder regenerate gesetzt ist. War nur das Log im Weg, hängt der neue Helfer append_log_suffix nur den Log-Zusatz wieder an. _rebase_resolving_generated meldet „aufgelöst" nur noch für Nicht-Log-Konflikte. Docstrings, der Kommentarblock „Reconciling around generated files", ReconcileOutcome und die sync-Notes sind nachgezogen (docs/reference/commands/git.md neu erzeugt).
Doku-Durchzug - instructions/session-setup.md (Absatz zu sync: ein offener Log-Eintrag allein lässt den Katalog unangetastet), docs/explanation/architecture.md („Generated audit log, in the order entries arrived", nach Befund 3), CHANGES.md. Veröffentlichte Skill-Kopien per instructions sync neu erzeugt.
Nachzug im Abschluss (beta.2) - drei Aussagen, die der Durchzug vor dem ersten Publish übersehen hatte: die publish-Notes („catalog … regenerated" jetzt mit „unless the log alone stood in the way"), das atomic-Feld von sync („rewrites the catalog, unless kb/log.md was the only one") und der Einleitungssatz der Log-Vorlage („chronological" → „in the order the entries arrived", wie in architecture.md). tools/CONTRACT.md und docs/reference/commands/git.md neu erzeugt. Geprüft und ohne Änderung belassen: docs/explanation/knowledge-and-commitment.md, instructions/gates.md (Rebase-Review-Absatz), docs/how-to/browse-with-obsidian.md, instructions/wiki-status/SKILL.md.
Akzeptanzkriterien
instructions/wiki-query/SKILL.md enthält keinen Aufruf von log append. Weder die Hard rule noch die Befehlsliste nennen ihn.
tools/wikitool log append --op query --title x läuft weiter mit Exit 0 und hängt den Eintrag an (test_log_append.py unverändert grün).
wikitool log append -h und docs/reference/commands/catalog-and-log.md führen query als Altwert. docs verify ist grün.
Ein neu exportiertes kb/log.md (dist export) nennt query nicht unter „Operation types" (Vorlage dist_templates/log.md geändert; CI replayt setup-instance gegen einen frischen Export).
Neuer Test in tools/chemenu/tests/test_git_publish.py: lokal nur ein angehängter Log-Eintrag, remote ein Ingest angekommen (test_an_open_log_entry_alone_does_not_regenerate_the_catalog_on_a_fast_forward).
Nach reconcile in dieser Lage: git status --porcelain nennt genau kb/log.md; kb/index.md und kb/provenance.md sind byte-gleich mit origin/main; das Log enthält die eingetroffenen Einträge gefolgt vom lokalen; BACKUP_REF ist gelöscht.
Dasselbe für den Rebase-Fall (..._on_a_rebase): lokal ein Commit ohne generierte Datei plus offener Log-Eintrag.
Kein lokaler Log-Eintrag geht verloren. Die bestehenden Fall-1/2/3-Tests und test_a_hand_edited_log_*, test_a_plain_fast_forward_regenerates_nothing laufen unverändert grün; test_case_1_on_sync_leaves_the_regenerated_catalog_uncommitted erzeugt weiter neu. Ein dritter neuer Test (..._plus_an_uncommitted_page_still_regenerates) hält genau das fest.
pytest, docs verify und instructions verify sind grün.
CI ist grün auf den publizierten Commits: 05c6697 (Läufe 762, 763) und 55ddf65 (Läufe 764, 765).
Versionsteil
--patch (Kandidat 10.1.1, Bumps beta.1 und beta.2). Drop-in-Test:
Vorwärts: Kopieren reicht. Kein Befehl und kein Flag-Wert entfällt, kein Dateiformat ändert sich, kb/ bleibt unberührt.
Rückwärts: Die alte Version loggt Queries wieder; nichts, was die neue geschrieben hat, wäre ihr unlesbar.
Neue Fähigkeit: keine. Es entfällt ein Verhalten, und Änderung 5 ist eine Korrektur.
Nicht im Umfang
Bestehende query-Einträge in Instanz-Logs werden nicht entfernt (Prüfprotokoll, Invariante 1).
Ein Lese-Log für den MCP-Server.
Eine zeitlich geordnete Zusammenführung des Logs. Die Ankunftsfolge bleibt; log status zählt reihenfolgebasiert, und das ist für die Lint-Taktung ausreichend.
## Ziel
Reine Lesevorgänge (`wiki-query` ohne abgelegte Seite) schreiben keinen Eintrag mehr in `kb/log.md`. `kb/log.md` bleibt das Protokoll dessen, was das Wiki gelernt oder verändert hat. Dazu ein Nebenbefund aus derselben Analyse: `sync`/`publish` erzeugen Katalog und `kb/provenance.md` nicht mehr neu, wenn lokal nur Log-Einträge offen waren.
## Ergebnis
**Erledigt** in zwei Commits des Kandidaten 10.1.1:
- **10.1.1-beta.1, Commit `05c6697`:** die Änderung selbst. Verifiziert durch CI-Lauf 762 (https://gitea.nehmer.net/torben/chemenu/actions/runs/762) und Release-Lauf 763 (https://gitea.nehmer.net/torben/chemenu/actions/runs/763), beide grün. Lokal vorher: `pytest` 3152 grün (4 übersprungen), `docs verify` und `instructions verify` grün. Die beiden neuen Reconcile-Tests schlugen auf dem alten `git_publish.py` fehl und laufen mit der Änderung grün.
- **10.1.1-beta.2, Commit `55ddf65`:** Nachzug aus dem Abschluss (Punkt 7 unten). Verifiziert durch CI-Lauf 764 (https://gitea.nehmer.net/torben/chemenu/actions/runs/764) und Release-Lauf 765 (https://gitea.nehmer.net/torben/chemenu/actions/runs/765), beide grün; lokal `pytest` 3152 grün, beide Verifies grün.
Keine Abweichung vom Entwurf.
## Befund (Stand 10.1.0)
**Wann geholt wird.** Es gibt kein `git pull`. `reconcile()` (`tools/chemenu/commands/git_publish.py`) holt per `fetch` und führt per `merge --ff-only` oder `rebase` zusammen, nie mit Merge-Commit. Aufrufer:
- `wikitool sync` - zu Beginn jeder Skill-Session (`instructions/session-setup.md`, von allen Wiki-Skills verlinkt, auch `wiki-query`).
- `publish` - vor dem Stagen (nur mit Push) und einmal nach abgelehntem Push.
- Der MCP-Leseserver holt außerhalb von `wikitool` per `fetch` + `reset --hard` (`instructions/mcp-read-server.md`).
**Wie zusammengeführt wurde.** Generierte Dateien zählen nie als Überschneidung. Wo sie Git im Weg stehen, legt `_around_generated` sie beiseite. Der lokale Log-Zusatz (`_log_suffix`, nur angehängte Bytes) wird nach dem Fast-Forward/Rebase **ans Ende** gehängt. Katalog und Provenance wurden in 10.1.0 dabei immer neu erzeugt. Ist das Log nicht nur angehängt, sondern geändert, ergibt das `conflict`.
**Was das für Query-Einträge hieß** - der Grund für die Entscheidung:
1. `wiki-query` Schritt 8 loggte, publizierte aber nicht. Der Eintrag blieb uncommittet liegen und fuhr im nächsten fremden Publish mit, auch bei `publish --path` (`generated_outside`). Die Commit-Nachricht nannte ihn nicht.
2. War remote ein Ingest angekommen, lief jeder `sync` mit offenem Query-Eintrag durch `_around_generated` und erzeugte den Katalog neu. `index_build.py` schreibt `date.today()` hinein, also war danach auch `kb/index.md` geändert, obwohl lokal nur gelesen wurde.
3. Die Reihenfolge im Log ist die Ankunftsfolge, nicht die Zeit. Lokale Einträge landen hinter eingetroffenen, die Daten können rückwärts laufen.
4. Das Log war unvollständig: MCP-Abfragen loggten nicht, ein reiner Leser publiziert nie, ein Klon ohne Push-Recht kommt nicht am Publish-Remote-Gate vorbei.
5. Kein Werkzeug las Query-Einträge. `log status` zählt nur `ingest` seit dem letzten `lint`. Ein Eintrag trägt keinen Autor; `git blame` zeigt den Publizierenden, nicht den Fragenden.
6. Ein Lesevorgang ist keine Operation am Wiki. `docs/explanation/knowledge-and-commitment.md` warnt davor, das Log mit Einträgen zu füllen, die nicht festhalten, was das Wiki gelernt hat.
## Entscheidung
**Option a** (Betreiber, 2026-10-16): Reine Lesevorgänge werden nicht mehr geloggt.
Verworfen:
- **b1** lokale Datei außerhalb des Repos: kein Leser, nicht geteilt, eine zweite Telemetrie.
- **b2** eine Datei pro Klon im Repo: löst die Reihenfolge, aber nicht den geänderten Arbeitsbaum und den fehlenden Push. Viel neue Mechanik (Klon-Kennung, neuer generierter Pfad, Dist-Vorlage, Ownership) für einen ungeklärten Nutzen.
- **c** nur Doku angleichen: lässt Punkte 1-4 bestehen.
Das Bedarfssignal (eine Frage, die das Wiki nicht beantworten kann) läuft über den Weg, den `knowledge-and-commitment.md` für Aufgaben vorsieht. Die Antwort sagt wie bisher, dass das Wiki keine belastbare Quelle hat, und bietet einen Ingest an. Will der Nutzer die Lücke festhalten, legt der Agent auf seinen Wunsch `tools/wikitool task new --inbox --title "..."` an. Ohne konfigurierten Tracker bleibt es beim Angebot im Chat.
**`--op query` bleibt gültig.** Bestehende Logs enthalten solche Einträge, und eine instanzeigene Instruktion darf das Op noch schreiben. Einen Flag-Wert zu entfernen, wäre laut `version-parts.md` (Katalog: „flag removed or renamed") ein Bruch der Kompatibilität. Das Op wird nur nicht mehr vom Stack geschrieben, und die Hilfe sagt das.
## Umgesetzte Änderungen
1. **`instructions/wiki-query/SKILL.md`** - Schritt 8 entfällt; die Hard rule kennt nur noch Schritt 7 als Ausnahme; `log append` steht nicht mehr unter den benutzten Befehlen; Schritt 7 verweist für das Loggen einer abgelegten Seite auf `wiki-manage` / `publish-cycle.md` (`create`); der Decision point „Nothing found?" nennt `task new --inbox` auf Wunsch des Nutzers.
2. **`instructions/publish-cycle.md`** Schritt 3: Die `--op`-Aufzählung nennt `query` nicht mehr.
3. **`tools/chemenu/commands/log_append.py`** - `VALID_OPS` unverändert; Usage, Notes und `--op`-Hilfe führen `query` als Altwert. `tools/CONTRACT.md` und `docs/reference/commands/catalog-and-log.md` neu erzeugt.
4. **`tools/chemenu/dist_templates/log.md`** - „Operation types" nennt `ingest`, `lint`, `create`, `update`, `delete`, `rename`, `move`. Bestehende `kb/log.md` bleiben unberührt (auch die dieses Repos, Invariante 1).
5. **`git_publish.py` `_around_generated`** - Katalog und Provenance werden nur neu erzeugt, wenn außer `kb/log.md` eine generierte Datei beiseitegelegt wurde, eine Konfliktauflösung eine andere generierte Datei als das Log betraf, oder `regenerate` gesetzt ist. War nur das Log im Weg, hängt der neue Helfer `append_log_suffix` nur den Log-Zusatz wieder an. `_rebase_resolving_generated` meldet „aufgelöst" nur noch für Nicht-Log-Konflikte. Docstrings, der Kommentarblock „Reconciling around generated files", `ReconcileOutcome` und die `sync`-Notes sind nachgezogen (`docs/reference/commands/git.md` neu erzeugt).
6. **Doku-Durchzug** - `instructions/session-setup.md` (Absatz zu `sync`: ein offener Log-Eintrag allein lässt den Katalog unangetastet), `docs/explanation/architecture.md` („Generated audit log, in the order entries arrived", nach Befund 3), `CHANGES.md`. Veröffentlichte Skill-Kopien per `instructions sync` neu erzeugt.
7. **Nachzug im Abschluss (beta.2)** - drei Aussagen, die der Durchzug vor dem ersten Publish übersehen hatte: die `publish`-Notes („catalog … regenerated" jetzt mit „unless the log alone stood in the way"), das `atomic`-Feld von `sync` („rewrites the catalog, unless `kb/log.md` was the only one") und der Einleitungssatz der Log-Vorlage („chronological" → „in the order the entries arrived", wie in `architecture.md`). `tools/CONTRACT.md` und `docs/reference/commands/git.md` neu erzeugt. Geprüft und ohne Änderung belassen: `docs/explanation/knowledge-and-commitment.md`, `instructions/gates.md` (Rebase-Review-Absatz), `docs/how-to/browse-with-obsidian.md`, `instructions/wiki-status/SKILL.md`.
## Akzeptanzkriterien
- [x] `instructions/wiki-query/SKILL.md` enthält keinen Aufruf von `log append`. Weder die Hard rule noch die Befehlsliste nennen ihn.
- [x] `tools/wikitool log append --op query --title x` läuft weiter mit Exit 0 und hängt den Eintrag an (`test_log_append.py` unverändert grün).
- [x] `wikitool log append -h` und `docs/reference/commands/catalog-and-log.md` führen `query` als Altwert. `docs verify` ist grün.
- [x] Ein neu exportiertes `kb/log.md` (`dist export`) nennt `query` nicht unter „Operation types" (Vorlage `dist_templates/log.md` geändert; CI replayt `setup-instance` gegen einen frischen Export).
- [x] Neuer Test in `tools/chemenu/tests/test_git_publish.py`: lokal nur ein angehängter Log-Eintrag, remote ein Ingest angekommen (`test_an_open_log_entry_alone_does_not_regenerate_the_catalog_on_a_fast_forward`).
- [x] Nach `reconcile` in dieser Lage: `git status --porcelain` nennt genau `kb/log.md`; `kb/index.md` und `kb/provenance.md` sind byte-gleich mit `origin/main`; das Log enthält die eingetroffenen Einträge gefolgt vom lokalen; `BACKUP_REF` ist gelöscht.
- [x] Dasselbe für den Rebase-Fall (`..._on_a_rebase`): lokal ein Commit ohne generierte Datei plus offener Log-Eintrag.
- [x] Kein lokaler Log-Eintrag geht verloren. Die bestehenden Fall-1/2/3-Tests und `test_a_hand_edited_log_*`, `test_a_plain_fast_forward_regenerates_nothing` laufen unverändert grün; `test_case_1_on_sync_leaves_the_regenerated_catalog_uncommitted` erzeugt weiter neu. Ein dritter neuer Test (`..._plus_an_uncommitted_page_still_regenerates`) hält genau das fest.
- [x] `pytest`, `docs verify` und `instructions verify` sind grün.
- [x] CI ist grün auf den publizierten Commits: `05c6697` (Läufe 762, 763) und `55ddf65` (Läufe 764, 765).
## Versionsteil
**`--patch`** (Kandidat 10.1.1, Bumps beta.1 und beta.2). Drop-in-Test:
- Vorwärts: Kopieren reicht. Kein Befehl und kein Flag-Wert entfällt, kein Dateiformat ändert sich, `kb/` bleibt unberührt.
- Rückwärts: Die alte Version loggt Queries wieder; nichts, was die neue geschrieben hat, wäre ihr unlesbar.
Neue Fähigkeit: keine. Es entfällt ein Verhalten, und Änderung 5 ist eine Korrektur.
## Nicht im Umfang
- Bestehende `query`-Einträge in Instanz-Logs werden nicht entfernt (Prüfprotokoll, Invariante 1).
- Ein Lese-Log für den MCP-Server.
- Eine zeitlich geordnete Zusammenführung des Logs. Die Ankunftsfolge bleibt; `log status` zählt reihenfolgebasiert, und das ist für die Lint-Taktung ausreichend.
Ausgearbeitet aus dem Stub. Der ursprüngliche Stub, wörtlich:
Titel: Bewertung: Macht es Sinn, alle Lesevorgänge in LOG.md zu speichern?
gedanken:
jeder query erzeugt einen change
der geht ggf. mit in den nächsten publish
Sollten wir gleich Publishen
Eigenes File vielleicht
oder gar nicht?
welchen Nutzen gib uns das Read-log und wie stellen wir bei verteilter Nutzung die Korrektheit sicher?
Changelog:
Body neu geschrieben: Befund zu sync/publish/reconcile gegen den Baum von 10.1.0.
Betreiberentscheidung: Option a, keine Query-Einträge mehr. Verworfen wurden b1, b2 und c, mit Begründung im Body.
Nebenbefund aufgenommen: _around_generated erzeugt den Katalog auch dann neu, wenn nur kb/log.md beiseitegelegt war.
Titel angepasst. Labels: area/kb, kind/build, prio/planned, size/M; status/incoming entfernt.
**Ausgearbeitet aus dem Stub.** Der ursprüngliche Stub, wörtlich:
> **Titel:** Bewertung: Macht es Sinn, alle Lesevorgänge in LOG.md zu speichern?
>
> gedanken:
> jeder query erzeugt einen change
> der geht ggf. mit in den nächsten publish
> Sollten wir gleich Publishen
> Eigenes File vielleicht
> oder gar nicht?
> welchen Nutzen gib uns das Read-log und wie stellen wir bei verteilter Nutzung die Korrektheit sicher?
**Changelog:**
- Body neu geschrieben: Befund zu `sync`/`publish`/`reconcile` gegen den Baum von 10.1.0.
- Betreiberentscheidung: Option a, keine Query-Einträge mehr. Verworfen wurden b1, b2 und c, mit Begründung im Body.
- Nebenbefund aufgenommen: `_around_generated` erzeugt den Katalog auch dann neu, wenn nur `kb/log.md` beiseitegelegt war.
- Titel angepasst. Labels: `area/kb`, `kind/build`, `prio/planned`, `size/M`; `status/incoming` entfernt.
torben
changed title from Bewertung: Macht es Sinn, alle Lesevorgänge in LOG.md zu speichern? to Query-Log: reine Lesevorgänge nicht mehr in kb/log.md; Reconcile erzeugt den Katalog bei reinem Log-Zusatz nicht neu2026-10-16 17:35:23 +00:00
Changelog: Gebaut und publiziert als 10.1.1-beta.1 (Commit 05c6697). Neu im Body: Abschnitt „Stand" und „Umgesetzte Änderungen" (statt „Änderungen"). Alle Akzeptanzkriterien abgehakt; CI-Läufe 762 (CI) und 763 (Release) sind grün. Dazu ein dritter Test, der festhält, dass ein zusätzlich lokal geänderter Katalog weiter neu erzeugt wird. Keine Abweichung vom Entwurf.
**Changelog:** Gebaut und publiziert als 10.1.1-beta.1 (Commit `05c6697`). Neu im Body: Abschnitt „Stand" und „Umgesetzte Änderungen" (statt „Änderungen"). Alle Akzeptanzkriterien abgehakt; CI-Läufe 762 (CI) und 763 (Release) sind grün. Dazu ein dritter Test, der festhält, dass ein zusätzlich lokal geänderter Katalog weiter neu erzeugt wird. Keine Abweichung vom Entwurf.
Changelog: Abschluss. „Stand“ wird zu „Ergebnis“ mit beiden Commits und ihren CI-Läufen. Neu ist Punkt 7: Der Durchzug hatte drei veraltete Aussagen übersehen (publish-Notes, atomic-Feld von sync, Einleitung der Log-Vorlage). Sie sind als 10.1.1-beta.2 nachgezogen (Commit 55ddf65, Läufe 764 und 765 grün). Geprüft und unverändert gelassen sind vier weitere Dokumente, sie stehen in Punkt 7. Geschlossen.
**Changelog:** Abschluss. „Stand“ wird zu „Ergebnis“ mit beiden Commits und ihren CI-Läufen. Neu ist Punkt 7: Der Durchzug hatte drei veraltete Aussagen übersehen (`publish`-Notes, `atomic`-Feld von `sync`, Einleitung der Log-Vorlage). Sie sind als 10.1.1-beta.2 nachgezogen (Commit `55ddf65`, Läufe 764 und 765 grün). Geprüft und unverändert gelassen sind vier weitere Dokumente, sie stehen in Punkt 7. Geschlossen.
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.
Ziel
Reine Lesevorgänge (
wiki-queryohne abgelegte Seite) schreiben keinen Eintrag mehr inkb/log.md.kb/log.mdbleibt das Protokoll dessen, was das Wiki gelernt oder verändert hat. Dazu ein Nebenbefund aus derselben Analyse:sync/publisherzeugen Katalog undkb/provenance.mdnicht mehr neu, wenn lokal nur Log-Einträge offen waren.Ergebnis
Erledigt in zwei Commits des Kandidaten 10.1.1:
05c6697: die Änderung selbst. Verifiziert durch CI-Lauf 762 (https://gitea.nehmer.net/torben/chemenu/actions/runs/762) und Release-Lauf 763 (https://gitea.nehmer.net/torben/chemenu/actions/runs/763), beide grün. Lokal vorher:pytest3152 grün (4 übersprungen),docs verifyundinstructions verifygrün. Die beiden neuen Reconcile-Tests schlugen auf dem altengit_publish.pyfehl und laufen mit der Änderung grün.55ddf65: Nachzug aus dem Abschluss (Punkt 7 unten). Verifiziert durch CI-Lauf 764 (https://gitea.nehmer.net/torben/chemenu/actions/runs/764) und Release-Lauf 765 (https://gitea.nehmer.net/torben/chemenu/actions/runs/765), beide grün; lokalpytest3152 grün, beide Verifies grün.Keine Abweichung vom Entwurf.
Befund (Stand 10.1.0)
Wann geholt wird. Es gibt kein
git pull.reconcile()(tools/chemenu/commands/git_publish.py) holt perfetchund führt permerge --ff-onlyoderrebasezusammen, nie mit Merge-Commit. Aufrufer:wikitool sync- zu Beginn jeder Skill-Session (instructions/session-setup.md, von allen Wiki-Skills verlinkt, auchwiki-query).publish- vor dem Stagen (nur mit Push) und einmal nach abgelehntem Push.wikitoolperfetch+reset --hard(instructions/mcp-read-server.md).Wie zusammengeführt wurde. Generierte Dateien zählen nie als Überschneidung. Wo sie Git im Weg stehen, legt
_around_generatedsie beiseite. Der lokale Log-Zusatz (_log_suffix, nur angehängte Bytes) wird nach dem Fast-Forward/Rebase ans Ende gehängt. Katalog und Provenance wurden in 10.1.0 dabei immer neu erzeugt. Ist das Log nicht nur angehängt, sondern geändert, ergibt dasconflict.Was das für Query-Einträge hieß - der Grund für die Entscheidung:
wiki-querySchritt 8 loggte, publizierte aber nicht. Der Eintrag blieb uncommittet liegen und fuhr im nächsten fremden Publish mit, auch beipublish --path(generated_outside). Die Commit-Nachricht nannte ihn nicht.syncmit offenem Query-Eintrag durch_around_generatedund erzeugte den Katalog neu.index_build.pyschreibtdate.today()hinein, also war danach auchkb/index.mdgeändert, obwohl lokal nur gelesen wurde.log statuszählt nuringestseit dem letztenlint. Ein Eintrag trägt keinen Autor;git blamezeigt den Publizierenden, nicht den Fragenden.docs/explanation/knowledge-and-commitment.mdwarnt davor, das Log mit Einträgen zu füllen, die nicht festhalten, was das Wiki gelernt hat.Entscheidung
Option a (Betreiber, 2026-10-16): Reine Lesevorgänge werden nicht mehr geloggt.
Verworfen:
Das Bedarfssignal (eine Frage, die das Wiki nicht beantworten kann) läuft über den Weg, den
knowledge-and-commitment.mdfür Aufgaben vorsieht. Die Antwort sagt wie bisher, dass das Wiki keine belastbare Quelle hat, und bietet einen Ingest an. Will der Nutzer die Lücke festhalten, legt der Agent auf seinen Wunschtools/wikitool task new --inbox --title "..."an. Ohne konfigurierten Tracker bleibt es beim Angebot im Chat.--op querybleibt gültig. Bestehende Logs enthalten solche Einträge, und eine instanzeigene Instruktion darf das Op noch schreiben. Einen Flag-Wert zu entfernen, wäre lautversion-parts.md(Katalog: „flag removed or renamed") ein Bruch der Kompatibilität. Das Op wird nur nicht mehr vom Stack geschrieben, und die Hilfe sagt das.Umgesetzte Änderungen
instructions/wiki-query/SKILL.md- Schritt 8 entfällt; die Hard rule kennt nur noch Schritt 7 als Ausnahme;log appendsteht nicht mehr unter den benutzten Befehlen; Schritt 7 verweist für das Loggen einer abgelegten Seite aufwiki-manage/publish-cycle.md(create); der Decision point „Nothing found?" nennttask new --inboxauf Wunsch des Nutzers.instructions/publish-cycle.mdSchritt 3: Die--op-Aufzählung nenntquerynicht mehr.tools/chemenu/commands/log_append.py-VALID_OPSunverändert; Usage, Notes und--op-Hilfe führenqueryals Altwert.tools/CONTRACT.mdunddocs/reference/commands/catalog-and-log.mdneu erzeugt.tools/chemenu/dist_templates/log.md- „Operation types" nenntingest,lint,create,update,delete,rename,move. Bestehendekb/log.mdbleiben unberührt (auch die dieses Repos, Invariante 1).git_publish.py_around_generated- Katalog und Provenance werden nur neu erzeugt, wenn außerkb/log.mdeine generierte Datei beiseitegelegt wurde, eine Konfliktauflösung eine andere generierte Datei als das Log betraf, oderregenerategesetzt ist. War nur das Log im Weg, hängt der neue Helferappend_log_suffixnur den Log-Zusatz wieder an._rebase_resolving_generatedmeldet „aufgelöst" nur noch für Nicht-Log-Konflikte. Docstrings, der Kommentarblock „Reconciling around generated files",ReconcileOutcomeund diesync-Notes sind nachgezogen (docs/reference/commands/git.mdneu erzeugt).instructions/session-setup.md(Absatz zusync: ein offener Log-Eintrag allein lässt den Katalog unangetastet),docs/explanation/architecture.md(„Generated audit log, in the order entries arrived", nach Befund 3),CHANGES.md. Veröffentlichte Skill-Kopien perinstructions syncneu erzeugt.publish-Notes („catalog … regenerated" jetzt mit „unless the log alone stood in the way"), dasatomic-Feld vonsync(„rewrites the catalog, unlesskb/log.mdwas the only one") und der Einleitungssatz der Log-Vorlage („chronological" → „in the order the entries arrived", wie inarchitecture.md).tools/CONTRACT.mdunddocs/reference/commands/git.mdneu erzeugt. Geprüft und ohne Änderung belassen:docs/explanation/knowledge-and-commitment.md,instructions/gates.md(Rebase-Review-Absatz),docs/how-to/browse-with-obsidian.md,instructions/wiki-status/SKILL.md.Akzeptanzkriterien
instructions/wiki-query/SKILL.mdenthält keinen Aufruf vonlog append. Weder die Hard rule noch die Befehlsliste nennen ihn.tools/wikitool log append --op query --title xläuft weiter mit Exit 0 und hängt den Eintrag an (test_log_append.pyunverändert grün).wikitool log append -hunddocs/reference/commands/catalog-and-log.mdführenqueryals Altwert.docs verifyist grün.kb/log.md(dist export) nenntquerynicht unter „Operation types" (Vorlagedist_templates/log.mdgeändert; CI replaytsetup-instancegegen einen frischen Export).tools/chemenu/tests/test_git_publish.py: lokal nur ein angehängter Log-Eintrag, remote ein Ingest angekommen (test_an_open_log_entry_alone_does_not_regenerate_the_catalog_on_a_fast_forward).reconcilein dieser Lage:git status --porcelainnennt genaukb/log.md;kb/index.mdundkb/provenance.mdsind byte-gleich mitorigin/main; das Log enthält die eingetroffenen Einträge gefolgt vom lokalen;BACKUP_REFist gelöscht...._on_a_rebase): lokal ein Commit ohne generierte Datei plus offener Log-Eintrag.test_a_hand_edited_log_*,test_a_plain_fast_forward_regenerates_nothinglaufen unverändert grün;test_case_1_on_sync_leaves_the_regenerated_catalog_uncommittederzeugt weiter neu. Ein dritter neuer Test (..._plus_an_uncommitted_page_still_regenerates) hält genau das fest.pytest,docs verifyundinstructions verifysind grün.05c6697(Läufe 762, 763) und55ddf65(Läufe 764, 765).Versionsteil
--patch(Kandidat 10.1.1, Bumps beta.1 und beta.2). Drop-in-Test:kb/bleibt unberührt.Neue Fähigkeit: keine. Es entfällt ein Verhalten, und Änderung 5 ist eine Korrektur.
Nicht im Umfang
query-Einträge in Instanz-Logs werden nicht entfernt (Prüfprotokoll, Invariante 1).log statuszählt reihenfolgebasiert, und das ist für die Lint-Taktung ausreichend.Ausgearbeitet aus dem Stub. Der ursprüngliche Stub, wörtlich:
Changelog:
sync/publish/reconcilegegen den Baum von 10.1.0._around_generatederzeugt den Katalog auch dann neu, wenn nurkb/log.mdbeiseitegelegt war.area/kb,kind/build,prio/planned,size/M;status/incomingentfernt.Bewertung: Macht es Sinn, alle Lesevorgänge in LOG.md zu speichern?to Query-Log: reine Lesevorgänge nicht mehr in kb/log.md; Reconcile erzeugt den Katalog bei reinem Log-Zusatz nicht neuChangelog: Gebaut und publiziert als 10.1.1-beta.1 (Commit
05c6697). Neu im Body: Abschnitt „Stand" und „Umgesetzte Änderungen" (statt „Änderungen"). Alle Akzeptanzkriterien abgehakt; CI-Läufe 762 (CI) und 763 (Release) sind grün. Dazu ein dritter Test, der festhält, dass ein zusätzlich lokal geänderter Katalog weiter neu erzeugt wird. Keine Abweichung vom Entwurf.Changelog: Abschluss. „Stand“ wird zu „Ergebnis“ mit beiden Commits und ihren CI-Läufen. Neu ist Punkt 7: Der Durchzug hatte drei veraltete Aussagen übersehen (
publish-Notes,atomic-Feld vonsync, Einleitung der Log-Vorlage). Sie sind als 10.1.1-beta.2 nachgezogen (Commit55ddf65, Läufe 764 und 765 grün). Geprüft und unverändert gelassen sind vier weitere Dokumente, sie stehen in Punkt 7. Geschlossen.