torben/chemenu
1
1
Fork 0
Code Issues 26 Pull Requests Actions Packages Releases 32 Activity

raw rename: eine Rohdatei bewegen, ohne dass die Referenz zwischendurch ins Leere zeigt #16

New Issue
Open
opened 2026-08-31 08:49:42 +00:00 by torben · 3 comments
torben commented 2026-08-31 08:49:42 +00:00
Owner
Copy Link
Copy Source

Abgespalten von #14, das mit touch --set/--add/--remove in 1.4.0 geschlossen wurde. Übrig bleibt der Teil, den touch --set nicht abdeckt: wenn nicht der Wert, sondern die Datei sich bewegt.

Was jetzt geht, und wo die Lücke bleibt

Seit 1.4.0 ist der Umzug zweistufig machbar:

git mv "raw/notes/A.md" "raw/notes/A, B.md"
tools/wikitool touch --page "Source - X" --set 'raw_files=raw/notes/A\, B.md'
tools/wikitool sources rebuild-index

Das ist ungleich besser als vorher — vorher gab es keinen Weg außer der Handeditierung. Aber zwischen Schritt 1 und Schritt 2 zeigt raw_files: ins Leere. lint und sources coverage würden den Zustand korrekt als Broken raw_files references melden, wenn in diesem Moment jemand prüft.

Bei mehreren referenzierenden Seiten wächst das Fenster mit jeder. sources trace --raw <pfad> sagt zwar, welche Seiten betroffen sind, aber die Reihenfolge und Vollständigkeit hängen dann daran, dass niemand abbricht — genau die Sorte Handarbeit, gegen die der Rest des Stacks gebaut ist.

Vorschlag

wikitool raw rename <alt> <neu>, das den git mv und jede referenzierende Source-Seite in einem Schritt macht:

$ tools/wikitool raw rename "raw/notes/A.md" "raw/notes/A, B.md"
  git mv raw/notes/A.md -> raw/notes/A, B.md
  Source - X          raw_files aktualisiert
  Source - Y          raw_files aktualisiert
OK 1 Datei bewegt, 2 Seiten nachgezogen

Vorbild ist wikitool rename für Seiten: es bewegt die Datei und zieht jede Referenz nach, und page-lifecycle.md schreibt vor, es zu benutzen statt von Hand zu verschieben. Für raw/ fehlt das Gegenstück.

Offene Fragen für die Umsetzung

  • Rückwärtssuche. Woher kommen die referenzierenden Seiten — reicht ein Scan über raw_files: (tools/chemenu/provenance.py hat die Logik für broken_raw_refs und duplicate_raw_file_owners schon), oder soll sources trace die eine Quelle der Wahrheit sein?
  • Mehrere Owner. lint führt duplicate_raw_file_owners als eigenen Befund. raw rename sollte den Zustand nicht stillschweigend erzeugen und nicht daran scheitern, wenn er schon besteht — vermutlich: alle Owner nachziehen und die Mehrfachbelegung melden.
  • Verzeichniswechsel. raw/CONTRACT.md routet nach articles/, documents/, notes/, assets/. Eine Datei von notes/ nach documents/ zu bewegen ist derselbe Vorgang und sollte mitkommen. Prüfen, dass das Ziel unter raw/ liegt.
  • Nur git mv, oder auch ein einfaches mv? Eine noch nicht committete Rohdatei ist git unbekannt. Vermutlich: git mv versuchen, bei „not under version control" auf mv zurückfallen und das melden.
  • sources rebuild-index automatisch anhängen oder dem Aufrufer überlassen? Die anderen Kommandos überlassen es ihm; Konsistenz spricht dafür, es nicht zu tun, sondern in der Abschlussmeldung daran zu erinnern.
  • Löschen und Anlegen sind ausdrücklich nicht Teil davon. raw/ ist unveränderlich; hier geht es allein darum, dass ein Pfad sich ändert, während der Inhalt derselbe bleibt.

Abgrenzung

Kein allgemeiner raw-Unterbefehlsbaum. Ein Kommando, ein Zweck.

Akzeptanzkriterien

  • raw rename bewegt die Datei und zieht jede referenzierende Source-Seite nach; zwischen beidem existiert kein Zustand, in dem eine Referenz ins Leere zeigt.
  • --dry-run zeigt die vollständige Liste der betroffenen Seiten, ohne etwas zu schreiben.
  • Der Testfall ist der reale Vorgang aus 5426a6e: eine Rohdatei mit Komma im Namen, eine referenzierende Source-Seite.
  • Ein zweiter Test deckt zwei referenzierende Seiten ab — das ist der Fall, für den das Kommando eigentlich existiert.
  • Zeilen in tools/CONTRACT.md für Kommando und Fehlerkontrakt; docs verify erzwingt beide Richtungen.
  • instructions/page-lifecycle.md erwähnt den Rohdatei-Fall oder verweist ausdrücklich hierher. Heute grenzt sein Scope-Abschnitt nur gegen Contracts, Instructions und Type-Specs ab und schweigt zu raw/.
  • Changelog-Eintrag, MINOR.

Hinweis zur Priorität

Anders als #14 gibt es hier keinen Datenverlust und keine Sackgasse — der Weg existiert, er ist nur zweistufig und kurz unsauber. Deshalb kein prio/blocking.

Geprüft 2026-09-04 (#29): pfadseitig sauber, kein wiki_tools- oder llm-wiki-test1-Vorkommen. provenance.py ist zur Eindeutigkeit auf tools/chemenu/provenance.py ausgeschrieben (Datei existiert), instructions/page-lifecycle.md und raw/CONTRACT.md existieren unverändert. Der Hinweis zur Priorität nannte noch das abgeschaffte prio/1-Schema und heißt jetzt prio/blocking. Damit ist dieses Issue im Rename-Durchgang abgehakt und braucht keinen dritten.

Abgespalten von #14, das mit `touch --set/--add/--remove` in **1.4.0** geschlossen wurde. Übrig bleibt der Teil, den `touch --set` nicht abdeckt: wenn nicht der *Wert*, sondern die *Datei* sich bewegt. ## Was jetzt geht, und wo die Lücke bleibt Seit 1.4.0 ist der Umzug zweistufig machbar: ```bash git mv "raw/notes/A.md" "raw/notes/A, B.md" tools/wikitool touch --page "Source - X" --set 'raw_files=raw/notes/A\, B.md' tools/wikitool sources rebuild-index ``` Das ist ungleich besser als vorher — vorher gab es keinen Weg außer der Handeditierung. Aber zwischen Schritt 1 und Schritt 2 zeigt `raw_files:` ins Leere. `lint` und `sources coverage` würden den Zustand korrekt als `Broken raw_files references` melden, wenn in diesem Moment jemand prüft. **Bei mehreren referenzierenden Seiten wächst das Fenster mit jeder.** `sources trace --raw <pfad>` sagt zwar, welche Seiten betroffen sind, aber die Reihenfolge und Vollständigkeit hängen dann daran, dass niemand abbricht — genau die Sorte Handarbeit, gegen die der Rest des Stacks gebaut ist. ## Vorschlag `wikitool raw rename <alt> <neu>`, das den `git mv` und jede referenzierende Source-Seite in einem Schritt macht: ``` $ tools/wikitool raw rename "raw/notes/A.md" "raw/notes/A, B.md" git mv raw/notes/A.md -> raw/notes/A, B.md Source - X raw_files aktualisiert Source - Y raw_files aktualisiert OK 1 Datei bewegt, 2 Seiten nachgezogen ``` Vorbild ist `wikitool rename` für Seiten: es bewegt die Datei **und** zieht jede Referenz nach, und `page-lifecycle.md` schreibt vor, es zu benutzen statt von Hand zu verschieben. Für `raw/` fehlt das Gegenstück. ## Offene Fragen für die Umsetzung - **Rückwärtssuche.** Woher kommen die referenzierenden Seiten — reicht ein Scan über `raw_files:` (`tools/chemenu/provenance.py` hat die Logik für `broken_raw_refs` und `duplicate_raw_file_owners` schon), oder soll `sources trace` die eine Quelle der Wahrheit sein? - **Mehrere Owner.** `lint` führt `duplicate_raw_file_owners` als eigenen Befund. `raw rename` sollte den Zustand nicht stillschweigend erzeugen *und* nicht daran scheitern, wenn er schon besteht — vermutlich: alle Owner nachziehen und die Mehrfachbelegung melden. - **Verzeichniswechsel.** `raw/CONTRACT.md` routet nach `articles/`, `documents/`, `notes/`, `assets/`. Eine Datei von `notes/` nach `documents/` zu bewegen ist derselbe Vorgang und sollte mitkommen. Prüfen, dass das Ziel unter `raw/` liegt. - **Nur `git mv`, oder auch ein einfaches `mv`?** Eine noch nicht committete Rohdatei ist git unbekannt. Vermutlich: `git mv` versuchen, bei „not under version control" auf `mv` zurückfallen und das melden. - **`sources rebuild-index` automatisch anhängen oder dem Aufrufer überlassen?** Die anderen Kommandos überlassen es ihm; Konsistenz spricht dafür, es nicht zu tun, sondern in der Abschlussmeldung daran zu erinnern. - **Löschen und Anlegen** sind ausdrücklich *nicht* Teil davon. `raw/` ist unveränderlich; hier geht es allein darum, dass ein Pfad sich ändert, während der Inhalt derselbe bleibt. ## Abgrenzung Kein allgemeiner `raw`-Unterbefehlsbaum. Ein Kommando, ein Zweck. ## Akzeptanzkriterien - [ ] `raw rename` bewegt die Datei und zieht jede referenzierende Source-Seite nach; zwischen beidem existiert kein Zustand, in dem eine Referenz ins Leere zeigt. - [ ] `--dry-run` zeigt die vollständige Liste der betroffenen Seiten, ohne etwas zu schreiben. - [ ] Der Testfall ist der reale Vorgang aus `5426a6e`: eine Rohdatei mit Komma im Namen, eine referenzierende Source-Seite. - [ ] Ein zweiter Test deckt zwei referenzierende Seiten ab — das ist der Fall, für den das Kommando eigentlich existiert. - [ ] Zeilen in `tools/CONTRACT.md` für Kommando **und** Fehlerkontrakt; `docs verify` erzwingt beide Richtungen. - [ ] `instructions/page-lifecycle.md` erwähnt den Rohdatei-Fall oder verweist ausdrücklich hierher. Heute grenzt sein Scope-Abschnitt nur gegen Contracts, Instructions und Type-Specs ab und schweigt zu `raw/`. - [ ] Changelog-Eintrag, **MINOR**. ## Hinweis zur Priorität Anders als #14 gibt es hier keinen Datenverlust und keine Sackgasse — der Weg existiert, er ist nur zweistufig und kurz unsauber. Deshalb kein `prio/blocking`. --- *Geprüft 2026-09-04 (#29): pfadseitig **sauber**, kein `wiki_tools`- oder `llm-wiki-test1`-Vorkommen. `provenance.py` ist zur Eindeutigkeit auf `tools/chemenu/provenance.py` ausgeschrieben (Datei existiert), `instructions/page-lifecycle.md` und `raw/CONTRACT.md` existieren unverändert. Der Hinweis zur Priorität nannte noch das abgeschaffte `prio/1`-Schema und heißt jetzt `prio/blocking`. Damit ist dieses Issue im Rename-Durchgang abgehakt und braucht keinen dritten.*
torben added the prio/plannedsize/S labels 2026-08-31 08:49:48 +00:00
torben commented 2026-09-01 20:01:31 +00:00
Author
Owner
Copy Link
Copy Source

Hat seit 2026-09-01 einen Abnehmer: #32 (Ingest-Queue) braucht ein
wikitool raw accept, das eine Datei aus einer Quarantäne nach raw/ befördert — also
genau die Mechanik, um die es hier geht (eine Rohdatei bewegen, ohne dass die Referenz
zwischendurch ins Leere zeigt), nur mit einer Verzeichnisgrenze davor.

Wer #16 baut, sollte die Mechanik so schneiden, dass accept sie mitbenutzen kann,
statt sie später ein zweites Mal zu schreiben.

Hat seit 2026-09-01 einen Abnehmer: #32 (Ingest-Queue) braucht ein `wikitool raw accept`, das eine Datei aus einer Quarantäne nach `raw/` befördert — also genau die Mechanik, um die es hier geht (eine Rohdatei bewegen, ohne dass die Referenz zwischendurch ins Leere zeigt), nur mit einer Verzeichnisgrenze davor. Wer #16 baut, sollte die Mechanik so schneiden, dass `accept` sie mitbenutzen kann, statt sie später ein zweites Mal zu schreiben.
torben added the area/kbkind/build labels 2026-09-02 21:24:57 +00:00
torben commented 2026-09-04 19:28:42 +00:00
Author
Owner
Copy Link
Copy Source

Aus der Sitzung 2026-09-04 zur Ordnerorganisation: #56 (page move) ist bewusst kein Geschwister von diesem Issue, obwohl die Titel gleich klingen.

Der Grund ist die Identität. In raw/ ist sie der Pfad — deshalb steht sie als String in raw_files:, deshalb braucht es hier die Rückwärtssuche über referenzierende Seiten, den Mehrfach-Owner-Fall und die Vermeidung des Fensters, in dem eine Referenz ins Leere zeigt. In kb/ ist sie der Stem (kb_scan.load_kb_pages schlüsselt darüber), und Wikilinks, [^cite-id] und die Frontmatter-Arrays lösen über den Titel auf. Ein page move bewegt deshalb eine Datei und zieht nichts nach — der gesamte Aufwand dieses Issues entfällt dort.

Gemeinsam bleibt genau ein Kleinstprimitiv, das hier ohnehin schon als offene Frage steht: „git mv versuchen, bei not under version control auf mv zurückfallen und das melden". Wer zuerst gebaut wird, schreibt es; der zweite benutzt es. Keine Blockade in beide Richtungen, keine gemeinsame Umsetzung.

Zweiter Berührungspunkt, der wirklich einer ist: #58 (incoming/ + raw accept) braucht die Mechanik dieses Issues vollständig — Beförderung ist derselbe Vorgang wie Umbenennung, nur mit einem Ziel außerhalb des Eingangs. Und der dort offene Punkt „was passiert mit den 29 flach liegenden Bestandsdateien" ist ohne dieses Kommando nicht beantwortbar. Damit hat #16 jetzt zwei Abnehmer statt nur #32.

Aus der Sitzung 2026-09-04 zur Ordnerorganisation: **#56 (`page move`) ist bewusst kein Geschwister von diesem Issue**, obwohl die Titel gleich klingen. Der Grund ist die Identität. In `raw/` ist sie der Pfad — deshalb steht sie als String in `raw_files:`, deshalb braucht es hier die Rückwärtssuche über referenzierende Seiten, den Mehrfach-Owner-Fall und die Vermeidung des Fensters, in dem eine Referenz ins Leere zeigt. In `kb/` ist sie der Stem (`kb_scan.load_kb_pages` schlüsselt darüber), und Wikilinks, `[^cite-id]` und die Frontmatter-Arrays lösen über den **Titel** auf. Ein `page move` bewegt deshalb eine Datei und zieht *nichts* nach — der gesamte Aufwand dieses Issues entfällt dort. Gemeinsam bleibt genau ein Kleinstprimitiv, das hier ohnehin schon als offene Frage steht: „`git mv` versuchen, bei *not under version control* auf `mv` zurückfallen und das melden". Wer zuerst gebaut wird, schreibt es; der zweite benutzt es. Keine Blockade in beide Richtungen, keine gemeinsame Umsetzung. Zweiter Berührungspunkt, der wirklich einer ist: #58 (`incoming/` + `raw accept`) braucht die Mechanik dieses Issues vollständig — Beförderung ist derselbe Vorgang wie Umbenennung, nur mit einem Ziel außerhalb des Eingangs. Und der dort offene Punkt „was passiert mit den 29 flach liegenden Bestandsdateien" ist ohne dieses Kommando nicht beantwortbar. Damit hat #16 jetzt zwei Abnehmer statt nur #32.
torben commented 2026-09-05 05:46:42 +00:00
Author
Owner
Copy Link
Copy Source

Korrektur zum Kommentar vom 2026-09-04 20:56 — beide Hälften gelten nach der Umsetzung von #58 (4.8.0-beta.3, 36d2128) nicht mehr:

  • „#58 braucht die Mechanik dieses Issues vollständig" — nein. raw accept befördert eine Datei, die noch keine Seite referenziert; Rückwärtssuche, Mehrfach-Owner-Fall und das Referenzfenster entfallen im Normalfall ersatzlos. Der eine Fall, der eine referenzierte Datei bewegt (--page, Wachstum von einer auf mehrere Dateien), benutzt provenance.source_pages_by_raw_file — die Inversion existierte längst und trägt schon duplicate_raw_file_owners.
  • „der Punkt mit den 29 Bestandsdateien ist ohne dieses Kommando nicht beantwortbar" — er stellte sich nicht. #58 entschied, ein Bundle-Verzeichnis erst ab der zweiten Datei anzulegen; damit sind die 29 flach liegenden Dateien eindateiige Quellen in vorschriftsmäßiger Form, keine Altlast. Es wurde nichts umsortiert.

Was bleibt: das Kleinstprimitiv „git mv versuchen, bei not under version control auf mv zurückfallen". Auch das ist nach #58 kleiner als gedacht — raw accept benutzt schlicht Path.rename(), wie page_ops.rename_command/move_command es schon tun, weil die Quelle in incoming/ per Definition nie getrackt ist und publishs git add -A eine inhaltsgleiche Bewegung ohnehin als Rename erkennt. Wer #16 baut, entscheidet also neu, ob git mv überhaupt gebraucht wird, statt es aus diesem Issue zu erben.

Ebenfalls neu: die raw-Kommandogruppe existiert jetzt (tools/chemenu/commands/raw_cmd.py, cli.py), raw rename hängt sich also nur noch ein, statt sie anzulegen.

**Korrektur zum Kommentar vom 2026-09-04 20:56** — beide Hälften gelten nach der Umsetzung von #58 (4.8.0-beta.3, `36d2128`) nicht mehr: - *„#58 braucht die Mechanik dieses Issues vollständig"* — nein. `raw accept` befördert eine Datei, die noch **keine** Seite referenziert; Rückwärtssuche, Mehrfach-Owner-Fall und das Referenzfenster entfallen im Normalfall ersatzlos. Der eine Fall, der eine referenzierte Datei bewegt (`--page`, Wachstum von einer auf mehrere Dateien), benutzt `provenance.source_pages_by_raw_file` — die Inversion existierte längst und trägt schon `duplicate_raw_file_owners`. - *„der Punkt mit den 29 Bestandsdateien ist ohne dieses Kommando nicht beantwortbar"* — er stellte sich nicht. #58 entschied, ein Bundle-Verzeichnis erst ab der zweiten Datei anzulegen; damit sind die 29 flach liegenden Dateien eindateiige Quellen in vorschriftsmäßiger Form, keine Altlast. Es wurde nichts umsortiert. Was **bleibt**: das Kleinstprimitiv „`git mv` versuchen, bei *not under version control* auf `mv` zurückfallen". Auch das ist nach #58 kleiner als gedacht — `raw accept` benutzt schlicht `Path.rename()`, wie `page_ops.rename_command`/`move_command` es schon tun, weil die Quelle in `incoming/` per Definition nie getrackt ist und `publish`s `git add -A` eine inhaltsgleiche Bewegung ohnehin als Rename erkennt. Wer #16 baut, entscheidet also neu, ob `git mv` überhaupt gebraucht wird, statt es aus diesem Issue zu erben. Ebenfalls neu: die `raw`-Kommandogruppe existiert jetzt (`tools/chemenu/commands/raw_cmd.py`, `cli.py`), `raw rename` hängt sich also nur noch ein, statt sie anzulegen.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/corpus
Betrifft Demo-/Testbett-Frage, Inhalt und Umfang von kb/
 area/distribution
Betrifft Auslieferung, Upgrade, Versionierung einer Instanz
 area/kb
Betrifft kb/-Schema, Contract, Confidence, Lint, Wissensbasis
 area/process
Betrifft den Entwicklungsprozess selbst, nicht den Stack als Artefakt
 area/workflow
Betrifft Git, Merge, Branching, Publish, PRs
 kind/build
Spezifiziert, wartet nur noch auf Umsetzungszeit
 kind/decision
Wartet auf eine Betreiberentscheidung
 kind/defect
Befund: Doku und Realitaet, oder zwei Dokus, widersprechen sich
 prio/blocking
Blockiert oder beschaedigt laufende Arbeit - als naechstes
 prio/planned
Traegt bald Zinsen - eingeplant
 prio/waiting
Sinnvoll, wartet auf einen Ausloeser
 size/L
Mehrere Sitzungen oder offene Designfragen vor dem ersten Commit
 size/M
Mehrere Dateien, Contract- oder Instruction-Aenderung, eigener Testaufwand
 size/S
Eine Sitzung, ein Publish, klar umrissener Schnitt
 status/blocked
Wartet auf ein anderes, noch offenes Issue - nicht eigenstaendig bearbeitbar
 status/incoming
Vom Menschen angelegte Anforderung, unvollständig, muss durch den Stack komplettiert werden.
 status/unconfirmed
Gemeldeter Verdacht, noch nicht gegen tatsaechliches Verhalten geprueft - size/prio vorlaeufig
No Label area/kb kind/build prio/planned size/S
Milestone
No items
No Milestone
Assignees
Clear assignees
torben
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: torben/chemenu#16
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?