Neue Ausgabe eines abgeleiteten Ordner-Bundles: raw accept --replaces-bundle auch für raw derive-Ordner #201

New Issue

2026-10-08T12:02:49Z

torben commented

2026-10-08 12:02:49 +00:00

Folge-Issue zu #199 (Entwurf 11). Entwurfsstand, noch nicht ausgearbeitet: Der Kern ist ein Vorschlag, keine Entscheidung.

Befund

raw derive legt aus einer Datei, einem ZIP oder einer Mail einen Ordner incoming/<stem>/ an (original.<ext> + derived.md, bei Containern die Dateien unter ihren Namen). raw accept nimmt ihn als Ganzes nach raw/<YYYY>/<MM>/<stem>/.
Kommt dasselbe Dokument in einer neuen Fassung (Angebot v2, eine neu gesendete Mail, ein ZIP mit korrigierten Dateien), trifft raw accept auf den belegten Ordnernamen. Heute gibt es dafür nur:
- --replaces-bundle, aber nur für erfasste Bundles (_capture.json, raw capture),
- --replaces, aber nur für eine Datei direkt in incoming/, also nicht für einen Ordner.
Eine neue Ausgabe eines abgeleiteten Ordners geht damit nur über Umbenennen (--name) oder von Hand. Die Ausgabe und der ON FAILURE-Text von raw derive sagen das ehrlich, versprechen --replaces also nicht.

Wahrscheinlicher Kern

--replaces-bundle nimmt auch einen abgeleiteten oder gewöhnlichen Ordner und ersetzt den belegten Ordner unter raw/ als Ganzes, mit der A/M/D-Liste wie bei erfassten Bundles.
Offene Fragen für die Ausarbeitung:
- Woran erkennt raw accept einen abgeleiteten Ordner (Header von derived.md, ein Marker, nur der Name)?
- Wie bleiben die Zeiger raw_files: der Quellenseite gültig, wenn Dateien im Bundle wegfallen oder neu dazukommen?
- Ob eine Neuableitung desselben Originals (bessere Engine-Version, gleiche Bytes) derselbe Fall ist wie eine neue Fassung des Dokuments.

Bezug

#199: raw derive; Entwurf 11 dort
#58 und #67: Bundle-Regel und Datums-Shard
raw/CONTRACT.md § Getting a document in: raw derive (der letzte Satz zum Ersetzen)

> Folge-Issue zu #199 (Entwurf 11). Entwurfsstand, noch nicht ausgearbeitet: Der Kern ist ein Vorschlag, keine Entscheidung. ## Befund - `raw derive` legt aus einer Datei, einem ZIP oder einer Mail einen Ordner `incoming/<stem>/` an (`original.<ext>` + `derived.md`, bei Containern die Dateien unter ihren Namen). `raw accept` nimmt ihn als Ganzes nach `raw/<YYYY>/<MM>/<stem>/`. - Kommt dasselbe Dokument in einer neuen Fassung (Angebot v2, eine neu gesendete Mail, ein ZIP mit korrigierten Dateien), trifft `raw accept` auf den belegten Ordnernamen. Heute gibt es dafür nur: - `--replaces-bundle`, aber nur für erfasste Bundles (`_capture.json`, `raw capture`), - `--replaces`, aber nur für eine Datei direkt in `incoming/`, also nicht für einen Ordner. - Eine neue Ausgabe eines abgeleiteten Ordners geht damit nur über Umbenennen (`--name`) oder von Hand. Die Ausgabe und der ON FAILURE-Text von `raw derive` sagen das ehrlich, versprechen `--replaces` also nicht. ## Wahrscheinlicher Kern - `--replaces-bundle` nimmt auch einen abgeleiteten oder gewöhnlichen Ordner und ersetzt den belegten Ordner unter `raw/` als Ganzes, mit der A/M/D-Liste wie bei erfassten Bundles. - Offene Fragen für die Ausarbeitung: - Woran erkennt `raw accept` einen abgeleiteten Ordner (Header von `derived.md`, ein Marker, nur der Name)? - Wie bleiben die Zeiger `raw_files:` der Quellenseite gültig, wenn Dateien im Bundle wegfallen oder neu dazukommen? - Ob eine Neuableitung desselben Originals (bessere Engine-Version, gleiche Bytes) derselbe Fall ist wie eine neue Fassung des Dokuments. ## Bezug - #199: `raw derive`; Entwurf 11 dort - #58 und #67: Bundle-Regel und Datums-Shard - `raw/CONTRACT.md` § Getting a document in: `raw derive` (der letzte Satz zum Ersetzen)