Reproduktionslauf: kb/ einmal aus raw/ neu kompilieren, Differenz berichten, Ergebnis verwerfen - Paket D #69

New Issue

2026-09-08T17:33:14Z

torben commented

2026-09-08 17:33:14 +00:00

Aus der Architekturdiskussion vom 2026-09-08. Paket D von vier: A ist #66, B ist #67, C ist #68.

Ausgangsfrage des Betreibers: die Testdaten sind durch viel Experimentieren nicht mehr ganz konsistent — sollte man sie einmal neu aufbauen?

Zwei Dinge, die auseinanderzuhalten sind

Neu erfinden ist ausgeschlossen. AGENTS.md Invariante 3 und corpus-policy.md Tier 3 verbieten es, und die Messung vom 2026-09-03 (#28) hält ausdrücklich fest, dass alle Floors „without any manufactured content" gehalten haben. Ein fabrizierter Korpus wäre der erste unbelegte Inhalt im Wiki.

Neu kompilieren ist etwas anderes: raw/ behalten, kb/ verwerfen, aus den 29 Rohdateien neu ingesten. Das ist die einzige Probe aufs Exempel für das Kernversprechen dieses Stacks — „never re-derive, always compile".

Entscheidung: reproduzieren, nicht ersetzen

Als Ersatz ist es ein schlechtes Geschäft. Kuratierte Prosa, von Hand gesetzte confidence_base-Werte und gewachsene related:-Kanten (6,2 pro Seite, gemessen #28) gegen frisch generierten Inhalt unbekannter Güte — und wegen Invariante 3 kann das Ergebnis die Quellen ohnehin nicht übertreffen.

Vor allem: die vermutete Inkonsistenz sitzt nicht in raw/. Die 29 Rohdateien sind unverändert und vollständig beansprucht (sources coverage meldet nichts). Inkonsistent ist die Klassifikation in kb/ — und die reparieren #66 und #67 gezielt.

Als Experiment ist es dagegen wertvoll, und zwar unabhängig davon, wie es ausgeht:

Fällt die Differenz gut aus, ist das eine belastbare Aussage über die Reproduzierbarkeit der Pipeline — die zentrale Behauptung des Stacks, bisher nie gemessen.
Fällt sie schlecht aus, ist das der wertvollste Bugreport, den dieses Projekt erzeugen kann.

Also: einmal durchlaufen, vergleichen, berichten, Ergebnis wegwerfen. Der lebende Korpus wird nicht auf die Antwort gewettet.

Umzusetzen

work/-Lauf nach work/CONTRACT.md, mit eigenem Run-Key. Das Ergebnis entsteht innerhalb des Laufs, nie in kb/.
Aus raw/ neu ingesten, mit den Skills und Contracts im Zustand zum Zeitpunkt des Laufs — nicht mit rekonstruierten Regeln von damals. Die Frage ist „was produziert der Stack heute aus diesem Material", nicht „wie kam der Bestand zustande".
Vergleichen. corpus_diff ist auf zwei Revisionen desselben Baums gebaut; für zwei Bäume braucht es eine Auswertung von Hand oder ein Wegwerfskript im Lauf. Zu berichten sind mindestens:
- Seitenzahl je Collection und je Subtype gegen den Bestand
- Wie viele Bestandsseiten überhaupt eine Entsprechung bekommen, und wie viele nicht
- related:-Dichte, sources:-Fan-in, Orphan-Zahl — die Floors aus corpus-policy.md
- Wie oft eine Aussage im Neulauf ohne Entsprechung im Bestand steht, und umgekehrt
Bericht als Kommentar an diesem Issue, mit Zahlen statt Eindruck. Was daraus an konkreten Mängeln folgt, wird als eigene Issues abgespalten — dieses hier schließt mit dem Befund, nicht mit Reparaturen.
Ergebnis verwerfen, work/-Lauf schließen.

Was dieser Lauf ausdrücklich nicht ist

Kein Ersatz des Korpus. Keine Seite aus dem Lauf wandert nach kb/.
Kein Anlass, raw/ anzufassen. Der Rohbestand ist die unveränderliche Wahrheit und Eingabe des Experiments, nicht sein Gegenstand.
Kein Fixture-Ersatz. corpus-policy.md § Relationship to the test fixtures bleibt, wie sie ist: der kleine, isolierte Fall gehört in conftest.py, der große, verbundene in kb/.

Reihenfolge

Unabhängig von A, B und C, aber sinnvoll erst danach: nach #66 und #67 sind Klassifikation und Capture-Felder in dem Zustand, in dem sie bleiben sollen, und der Lauf misst dann den Zielzustand statt eines Zwischenstands. Vorher gemessen wäre die Hälfte der Differenz genau das, was A und B ohnehin reparieren.

prio/waiting: sinnvoll, wartet auf den Auslöser — nämlich den Abschluss von #66 und #67.

Akzeptanzkriterien

work/-Lauf angelegt und nach work/CONTRACT.md geschlossen; nichts davon in kb/ gelandet.
Alle 29 Raw-Dateien sind im Lauf verarbeitet, oder die Auslassungen sind mit Begründung benannt.
Bericht als Kommentar mit den vier Kennzahlengruppen aus Punkt 3.
Die Aussage „ist die Pipeline reproduzierbar?" ist mit Zahlen beantwortet — auch wenn die Antwort nein lautet.
Gefundene Mängel sind als eigene Issues abgespalten und hier verlinkt.
raw/ unverändert; git status beweist es.
Kein Versions-Bump — dieser Lauf ändert den Stack nicht.

Aus der Architekturdiskussion vom 2026-09-08. **Paket D** von vier: A ist #66, B ist #67, C ist #68. Ausgangsfrage des Betreibers: die Testdaten sind durch viel Experimentieren nicht mehr ganz konsistent — sollte man sie einmal neu aufbauen? ## Zwei Dinge, die auseinanderzuhalten sind **Neu erfinden ist ausgeschlossen.** AGENTS.md Invariante 3 und [corpus-policy.md](../instructions/dev/corpus-policy.md) Tier 3 verbieten es, und die Messung vom 2026-09-03 (#28) hält ausdrücklich fest, dass alle Floors „without any manufactured content" gehalten haben. Ein fabrizierter Korpus wäre der erste unbelegte Inhalt im Wiki. **Neu kompilieren** ist etwas anderes: `raw/` behalten, `kb/` verwerfen, aus den 29 Rohdateien neu ingesten. Das ist die einzige Probe aufs Exempel für das Kernversprechen dieses Stacks — *„never re-derive, always compile"*. ## Entscheidung: reproduzieren, nicht ersetzen Als **Ersatz** ist es ein schlechtes Geschäft. Kuratierte Prosa, von Hand gesetzte `confidence_base`-Werte und gewachsene `related:`-Kanten (6,2 pro Seite, gemessen #28) gegen frisch generierten Inhalt unbekannter Güte — und wegen Invariante 3 kann das Ergebnis die Quellen ohnehin nicht übertreffen. Vor allem: **die vermutete Inkonsistenz sitzt nicht in `raw/`.** Die 29 Rohdateien sind unverändert und vollständig beansprucht (`sources coverage` meldet nichts). Inkonsistent ist die *Klassifikation* in `kb/` — und die reparieren #66 und #67 gezielt. Als **Experiment** ist es dagegen wertvoll, und zwar unabhängig davon, wie es ausgeht: - Fällt die Differenz gut aus, ist das eine belastbare Aussage über die Reproduzierbarkeit der Pipeline — die zentrale Behauptung des Stacks, bisher nie gemessen. - Fällt sie schlecht aus, ist das der wertvollste Bugreport, den dieses Projekt erzeugen kann. Also: **einmal durchlaufen, vergleichen, berichten, Ergebnis wegwerfen.** Der lebende Korpus wird nicht auf die Antwort gewettet. ## Umzusetzen 1. **`work/`-Lauf** nach [work/CONTRACT.md](../work/CONTRACT.md), mit eigenem Run-Key. Das Ergebnis entsteht **innerhalb** des Laufs, nie in `kb/`. 2. **Aus `raw/` neu ingesten**, mit den Skills und Contracts im Zustand *zum Zeitpunkt des Laufs* — nicht mit rekonstruierten Regeln von damals. Die Frage ist „was produziert der Stack heute aus diesem Material", nicht „wie kam der Bestand zustande". 3. **Vergleichen.** `corpus_diff` ist auf zwei Revisionen desselben Baums gebaut; für zwei Bäume braucht es eine Auswertung von Hand oder ein Wegwerfskript im Lauf. Zu berichten sind mindestens: - Seitenzahl je Collection und je Subtype gegen den Bestand - Wie viele Bestandsseiten überhaupt eine Entsprechung bekommen, und wie viele nicht - `related:`-Dichte, `sources:`-Fan-in, Orphan-Zahl — die Floors aus `corpus-policy.md` - Wie oft eine Aussage im Neulauf ohne Entsprechung im Bestand steht, und umgekehrt 4. **Bericht** als Kommentar an diesem Issue, mit Zahlen statt Eindruck. Was daraus an konkreten Mängeln folgt, wird als eigene Issues abgespalten — dieses hier schließt mit dem Befund, nicht mit Reparaturen. 5. **Ergebnis verwerfen**, `work/`-Lauf schließen. ## Was dieser Lauf ausdrücklich nicht ist - Kein Ersatz des Korpus. Keine Seite aus dem Lauf wandert nach `kb/`. - Kein Anlass, `raw/` anzufassen. Der Rohbestand ist die unveränderliche Wahrheit und Eingabe des Experiments, nicht sein Gegenstand. - Kein Fixture-Ersatz. `corpus-policy.md` § Relationship to the test fixtures bleibt, wie sie ist: der kleine, isolierte Fall gehört in `conftest.py`, der große, verbundene in `kb/`. ## Reihenfolge Unabhängig von A, B und C, aber **sinnvoll erst danach**: nach #66 und #67 sind Klassifikation und Capture-Felder in dem Zustand, in dem sie bleiben sollen, und der Lauf misst dann den Zielzustand statt eines Zwischenstands. Vorher gemessen wäre die Hälfte der Differenz genau das, was A und B ohnehin reparieren. `prio/waiting`: sinnvoll, wartet auf den Auslöser — nämlich den Abschluss von #66 und #67. ## Akzeptanzkriterien - [ ] `work/`-Lauf angelegt und nach `work/CONTRACT.md` geschlossen; nichts davon in `kb/` gelandet. - [ ] Alle 29 Raw-Dateien sind im Lauf verarbeitet, oder die Auslassungen sind mit Begründung benannt. - [ ] Bericht als Kommentar mit den vier Kennzahlengruppen aus Punkt 3. - [ ] Die Aussage „ist die Pipeline reproduzierbar?" ist mit Zahlen beantwortet — auch wenn die Antwort nein lautet. - [ ] Gefundene Mängel sind als eigene Issues abgespalten und hier verlinkt. - [ ] `raw/` unverändert; `git status` beweist es. - [ ] Kein Versions-Bump — dieser Lauf ändert den Stack nicht.