Eine Seite wurde am 2026-09-13 per wiki-manage inhaltlich erweitert, modified: blieb im
Frontmatter aber auf 2026-09-12 stehen; der naechste wiki-lint-Pass korrigierte es per wikitool touch --date. Vermutete Ursache: der Edit-Pfad von wiki-manage bumpe modified:
nicht selbst, so wie ein frisches wikitool new es tut.
Befund (geprueft am 2026-09-15 gegen den Baum)
Der Effekt ist real, die vermutete Ursache nicht. Drei Teilbehauptungen, drei Ergebnisse:
Behauptung
Ergebnis
modified: stand nach einem Prosa-Edit still
Nicht nachpruefbar in diesem Repo - die betroffene Seite existiert hier weder im Baum noch in git log; der Vorfall stammt aus einer anderen Instanz. Als Verhalten plausibel und durch den Rest des Befunds erklaert.
wikitool touch bumpt nicht zuverlaessig
Falsch.commands/touch.py bumpt das Datumsfeld per Default, waehlt es aus dem Schema (modified bei entity/concept, date bei source) und laesst date: auf einer Source absichtlich stehen. --no-date schaltet es explizit ab. Kein Werkzeugdefekt.
Der Edit-Pfad muesste modified: selbst bumpen
Die Regel steht bereits.instructions/wiki-manage/SKILL.md § "Updating a page" Schritt 6 und instructions/wiki-ingest/SKILL.md Schritt 7 ("Existing: edit the prose directly, then touch") schreiben beide genau das vor.
Die tatsaechliche Luecke ist damit weder im Werkzeug noch im Instruktionstext, sondern: die vorhandene Regel hat keinen mechanischen Waechter. Seitenkoerper werden vom Editor des
Agenten geschrieben, nicht von wikitool - das Werkzeug sieht den Edit nie. Wer Schritt 6
ueberspringt, merkt nichts davon.
Entscheidung
Kein Waechter wird gebaut; das Issue wird geschlossen. Die Drift ist selbstheilend (der
naechste touch setzt das Datum richtig), sie hat einen vorhandenen Backstop (siehe unten),
und jeder erwogene Waechter kostet mehr, als der falsche Datumswert wert ist.
Verworfene Optionen
Hinweiszeile in publish. Technisch der naheliegendste Ort: commands/git_publish.py
liest den Changeset bereits per Porcelain und numstat und zaehlt in attention_notes()
schon geaenderte kb/-Seiten; die Stack-Machinery-Zeile ist der Praezedenzfall fuer eine
rein hinweisende, nicht gate-artige Publish-Ausgabe. Verworfen an der Definition von
"Inhaltsaenderung": xref add und cite add schreiben beide in den Body (Links- bzw.
Fussnotenregion) und bumpen modified: bewusst nicht, rename schreibt Wikilinks und
Cite-IDs in fremde Bodies, und migrate soll bumpen (corpus_diff.py, STRUCTURAL_FIELDS).
Ein Waechter, der auf dem haeufigsten Pfad falsch Alarm schlaegt, ist schlechter als keiner.
Gate mit Exit 42 auf publish. Deckt sich mit docs/why-gates-are-code.md (eine
Prompt-Regel ist eine, an der ein Agent sich vorbeireden kann - genau dieser Vorfall).
Verworfen als unverhaeltnismaessig: ein fuenftes Gate, das routinemaessige Publishes an
einem Symptom blockiert, das sich beim naechsten touch von selbst erledigt.
cite add bumpt modified: der zitierten Seite mit. Deckt den Ingest-Pfad, auf dem der
Vorfall entstand, aber nicht den reinen Prosa-Edit ohne neue Zitate - und aendert eine heute
bewusst getroffene Semantik fuer einen Teilfall.
Was den Fall heute auffaengt
wiki-lint Schritt 4 ("Stale claims", Urteilsarbeit, mit search --field 'modified<<date>' --sort modified als billigem Kandidatenfilter) - genau der
Weg, auf dem dieser Vorfall gefunden wurde. Langsam, aber vorhanden.
lint selbst kommt als Ort eines mechanischen Checks nicht in Frage: lint_core.py ist per
Docstring eine reine Funktion ueber ein Korpusverzeichnis, ohne Git, und Datei-mtimes helfen
nicht (ein frischer Clone setzt alle gleich).
Ergebnis
Keine Aenderung an tools/, types/ oder instructions/. Kein Version-Bump, kein Publish -
reine Tracker-Arbeit.
## Gemeldeter Verdacht
Eine Seite wurde am 2026-09-13 per `wiki-manage` inhaltlich erweitert, `modified:` blieb im
Frontmatter aber auf 2026-09-12 stehen; der naechste `wiki-lint`-Pass korrigierte es per
`wikitool touch --date`. Vermutete Ursache: der Edit-Pfad von `wiki-manage` bumpe `modified:`
nicht selbst, so wie ein frisches `wikitool new` es tut.
## Befund (geprueft am 2026-09-15 gegen den Baum)
Der Effekt ist real, die vermutete Ursache nicht. Drei Teilbehauptungen, drei Ergebnisse:
| Behauptung | Ergebnis |
|---|---|
| `modified:` stand nach einem Prosa-Edit still | Nicht nachpruefbar in diesem Repo - die betroffene Seite existiert hier weder im Baum noch in `git log`; der Vorfall stammt aus einer anderen Instanz. Als Verhalten plausibel und durch den Rest des Befunds erklaert. |
| `wikitool touch` bumpt nicht zuverlaessig | **Falsch.** `commands/touch.py` bumpt das Datumsfeld per Default, waehlt es aus dem Schema (`modified` bei entity/concept, `date` bei source) und laesst `date:` auf einer Source absichtlich stehen. `--no-date` schaltet es explizit ab. Kein Werkzeugdefekt. |
| Der Edit-Pfad muesste `modified:` selbst bumpen | **Die Regel steht bereits.** `instructions/wiki-manage/SKILL.md` § "Updating a page" Schritt 6 und `instructions/wiki-ingest/SKILL.md` Schritt 7 ("Existing: edit the prose directly, then `touch`") schreiben beide genau das vor. |
Die tatsaechliche Luecke ist damit weder im Werkzeug noch im Instruktionstext, sondern:
**die vorhandene Regel hat keinen mechanischen Waechter.** Seitenkoerper werden vom Editor des
Agenten geschrieben, nicht von `wikitool` - das Werkzeug sieht den Edit nie. Wer Schritt 6
ueberspringt, merkt nichts davon.
## Entscheidung
**Kein Waechter wird gebaut; das Issue wird geschlossen.** Die Drift ist selbstheilend (der
naechste `touch` setzt das Datum richtig), sie hat einen vorhandenen Backstop (siehe unten),
und jeder erwogene Waechter kostet mehr, als der falsche Datumswert wert ist.
### Verworfene Optionen
1. **Hinweiszeile in `publish`.** Technisch der naheliegendste Ort: `commands/git_publish.py`
liest den Changeset bereits per Porcelain und numstat und zaehlt in `attention_notes()`
schon geaenderte `kb/`-Seiten; die Stack-Machinery-Zeile ist der Praezedenzfall fuer eine
rein hinweisende, nicht gate-artige Publish-Ausgabe. Verworfen an der Definition von
"Inhaltsaenderung": `xref add` und `cite add` schreiben beide in den Body (Links- bzw.
Fussnotenregion) und bumpen `modified:` bewusst **nicht**, `rename` schreibt Wikilinks und
Cite-IDs in fremde Bodies, und `migrate` soll bumpen (`corpus_diff.py`, `STRUCTURAL_FIELDS`).
Ein Waechter, der auf dem haeufigsten Pfad falsch Alarm schlaegt, ist schlechter als keiner.
2. **Gate mit Exit 42 auf `publish`.** Deckt sich mit `docs/why-gates-are-code.md` (eine
Prompt-Regel ist eine, an der ein Agent sich vorbeireden kann - genau dieser Vorfall).
Verworfen als unverhaeltnismaessig: ein fuenftes Gate, das routinemaessige Publishes an
einem Symptom blockiert, das sich beim naechsten `touch` von selbst erledigt.
3. **`cite add` bumpt `modified:` der zitierten Seite mit.** Deckt den Ingest-Pfad, auf dem der
Vorfall entstand, aber nicht den reinen Prosa-Edit ohne neue Zitate - und aendert eine heute
bewusst getroffene Semantik fuer einen Teilfall.
### Was den Fall heute auffaengt
`wiki-lint` Schritt 4 ("Stale claims", Urteilsarbeit, mit
`search --field 'modified<<date>' --sort modified` als billigem Kandidatenfilter) - genau der
Weg, auf dem dieser Vorfall gefunden wurde. Langsam, aber vorhanden.
`lint` selbst kommt als Ort eines mechanischen Checks nicht in Frage: `lint_core.py` ist per
Docstring eine reine Funktion ueber ein Korpusverzeichnis, ohne Git, und Datei-mtimes helfen
nicht (ein frischer Clone setzt alle gleich).
## Ergebnis
Keine Aenderung an `tools/`, `types/` oder `instructions/`. Kein Version-Bump, kein Publish -
reine Tracker-Arbeit.
Changelog: Verdacht gegen den Baum geprueft und Body auf den Endstand umgeschrieben. touch und beide Edit-Pfade (wiki-manage Schritt 6, wiki-ingest Schritt 7) verhalten sich
wie dokumentiert - die Luecke ist ein fehlender mechanischer Waechter, nicht ein Defekt.
Betreiberentscheidung: keiner wird gebaut, die drei erwogenen Optionen stehen mit ihrer
Verwerfungsbegruendung im Body. status/unconfirmed entfernt, vier Pflichtlabels gesetzt,
geschlossen.
**Changelog:** Verdacht gegen den Baum geprueft und Body auf den Endstand umgeschrieben.
`touch` und beide Edit-Pfade (`wiki-manage` Schritt 6, `wiki-ingest` Schritt 7) verhalten sich
wie dokumentiert - die Luecke ist ein fehlender mechanischer Waechter, nicht ein Defekt.
Betreiberentscheidung: keiner wird gebaut, die drei erwogenen Optionen stehen mit ihrer
Verwerfungsbegruendung im Body. `status/unconfirmed` entfernt, vier Pflichtlabels gesetzt,
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.
Gemeldeter Verdacht
Eine Seite wurde am 2026-09-13 per
wiki-manageinhaltlich erweitert,modified:blieb imFrontmatter aber auf 2026-09-12 stehen; der naechste
wiki-lint-Pass korrigierte es perwikitool touch --date. Vermutete Ursache: der Edit-Pfad vonwiki-managebumpemodified:nicht selbst, so wie ein frisches
wikitool newes tut.Befund (geprueft am 2026-09-15 gegen den Baum)
Der Effekt ist real, die vermutete Ursache nicht. Drei Teilbehauptungen, drei Ergebnisse:
modified:stand nach einem Prosa-Edit stillgit log; der Vorfall stammt aus einer anderen Instanz. Als Verhalten plausibel und durch den Rest des Befunds erklaert.wikitool touchbumpt nicht zuverlaessigcommands/touch.pybumpt das Datumsfeld per Default, waehlt es aus dem Schema (modifiedbei entity/concept,datebei source) und laesstdate:auf einer Source absichtlich stehen.--no-dateschaltet es explizit ab. Kein Werkzeugdefekt.modified:selbst bumpeninstructions/wiki-manage/SKILL.md§ "Updating a page" Schritt 6 undinstructions/wiki-ingest/SKILL.mdSchritt 7 ("Existing: edit the prose directly, thentouch") schreiben beide genau das vor.Die tatsaechliche Luecke ist damit weder im Werkzeug noch im Instruktionstext, sondern:
die vorhandene Regel hat keinen mechanischen Waechter. Seitenkoerper werden vom Editor des
Agenten geschrieben, nicht von
wikitool- das Werkzeug sieht den Edit nie. Wer Schritt 6ueberspringt, merkt nichts davon.
Entscheidung
Kein Waechter wird gebaut; das Issue wird geschlossen. Die Drift ist selbstheilend (der
naechste
touchsetzt das Datum richtig), sie hat einen vorhandenen Backstop (siehe unten),und jeder erwogene Waechter kostet mehr, als der falsche Datumswert wert ist.
Verworfene Optionen
publish. Technisch der naheliegendste Ort:commands/git_publish.pyliest den Changeset bereits per Porcelain und numstat und zaehlt in
attention_notes()schon geaenderte
kb/-Seiten; die Stack-Machinery-Zeile ist der Praezedenzfall fuer einerein hinweisende, nicht gate-artige Publish-Ausgabe. Verworfen an der Definition von
"Inhaltsaenderung":
xref addundcite addschreiben beide in den Body (Links- bzw.Fussnotenregion) und bumpen
modified:bewusst nicht,renameschreibt Wikilinks undCite-IDs in fremde Bodies, und
migratesoll bumpen (corpus_diff.py,STRUCTURAL_FIELDS).Ein Waechter, der auf dem haeufigsten Pfad falsch Alarm schlaegt, ist schlechter als keiner.
publish. Deckt sich mitdocs/why-gates-are-code.md(einePrompt-Regel ist eine, an der ein Agent sich vorbeireden kann - genau dieser Vorfall).
Verworfen als unverhaeltnismaessig: ein fuenftes Gate, das routinemaessige Publishes an
einem Symptom blockiert, das sich beim naechsten
touchvon selbst erledigt.cite addbumptmodified:der zitierten Seite mit. Deckt den Ingest-Pfad, auf dem derVorfall entstand, aber nicht den reinen Prosa-Edit ohne neue Zitate - und aendert eine heute
bewusst getroffene Semantik fuer einen Teilfall.
Was den Fall heute auffaengt
wiki-lintSchritt 4 ("Stale claims", Urteilsarbeit, mitsearch --field 'modified<<date>' --sort modifiedals billigem Kandidatenfilter) - genau derWeg, auf dem dieser Vorfall gefunden wurde. Langsam, aber vorhanden.
lintselbst kommt als Ort eines mechanischen Checks nicht in Frage:lint_core.pyist perDocstring eine reine Funktion ueber ein Korpusverzeichnis, ohne Git, und Datei-mtimes helfen
nicht (ein frischer Clone setzt alle gleich).
Ergebnis
Keine Aenderung an
tools/,types/oderinstructions/. Kein Version-Bump, kein Publish -reine Tracker-Arbeit.
Changelog: Verdacht gegen den Baum geprueft und Body auf den Endstand umgeschrieben.
touchund beide Edit-Pfade (wiki-manageSchritt 6,wiki-ingestSchritt 7) verhalten sichwie dokumentiert - die Luecke ist ein fehlender mechanischer Waechter, nicht ein Defekt.
Betreiberentscheidung: keiner wird gebaut, die drei erwogenen Optionen stehen mit ihrer
Verwerfungsbegruendung im Body.
status/unconfirmedentfernt, vier Pflichtlabels gesetzt,geschlossen.