Kein Fixture neben der Testsuite, kein --with-demo-Export, kein zweites Repo. Ein gemeinsames kb/ trägt Demo und Testbett zugleich; Umfang und Kuratierungsgrad bemessen sich am Bedarf
gezielter Entwicklung, nicht an einer synthetischen Fixture-Größe.
Ergebnis
instructions/dev/corpus-policy.md (neu, 4.2.0) beantwortet beide verbliebenen Fragen:
Kuratierungsgrad - fünf messbare Untergrenzen, jede mit einer bestehenden wikitool-Prüfung (search --field, lint, ein Einzeiler-Skript für Kantendichte/Provenienz),
keine davon durch neuen Tool-Code:
Floor
Stand 2026-09-03
Jeder Seitentyp ≥1 Seite
erfüllt (4/4)
Jeder deklarierte Subtyp ≥1 Seite
erfüllt (14/14)
≥5 Seiten mit ≥3 sources:
erfüllt (12)
Orphans zwischen 1 und 10
erfüllt (3)
Ø ausgehende Wikilinks ≥4
erfüllt (6,2 bei 181 Seiten)
Der Korpus war bereits groß genug - keine Seite musste eigens angelegt werden, um einen Floor zu
erfüllen. Die Typ-/Subtyp-Floors stehen bei 1, nicht 2: ein Typ mit genau einer Seite zeigt
keine Mengenfehler, nur Erreichbarkeit - das genügt als Floor; eine zweite Seite eines
untertesteten Typs (aktuell comparison, 1 Seite) ist im Dokument als weiches Ziel für den
nächsten passenden Ingest vermerkt, nicht als eigene Aufgabe.
Leitplanke für reaktive Fixes - drei Stufen: punktuell immer erlaubt; korpusweit nur
geplant, mit eigenem Issue und work/-Run (trifft eine Session das Mass-Update-Gate während sie
etwas anderes tut, holt sie sich nicht den --confirm-Token, sondern stoppt und legt ein Issue
an); reaktiver Eingriff in Korpusinhalt, um einen Test grün zu machen oder einen Tool-Bug zu
umgehen, nie erlaubt (Invariante 7).
Verhältnis zu test_pipeline_l0.py unverändert wie im ursprünglichen Befund: kleiner,
isolierter Fall in den kb_dir/raw_dir-Fixtures, großer vernetzter Fall in kb/ - keine
Fixture-Extraktion aus dem Korpus.
Akzeptanzkriterien
Richtlinie formuliert: was reaktive Fixes am kb/ dürfen und was nicht
Zielgröße für "kuratiert genug" benannt (fünf Floors, Typabdeckung inkl. comparison
bei ≥1 statt ≥2 - Entscheidung des Betreibers 2026-09-03)
Verhältnis zu test_pipeline_l0.py-Fixtures bleibt wie im ursprünglichen Befund
beschrieben - bestätigt, in corpus-policy.md festgehalten
Verworfen
Fixture-Extraktion, --with-demo, separates Repo - alle drei setzen eine Trennung voraus, die
der Betreiber für seinen eigenen Workflow nicht will (siehe #41, Kontext).
Verwandt
#30 (Upstream-Merge-Leck, teilt dieselbe Ursache) - entsperrt: das Fixture-Fundament, das #30 als Voraussetzung nannte, steht jetzt.
Vorgeschichte
Ursprünglicher Befund 2026-09-01. Entscheidung gegen Fixture/Repo-Trennung 2026-09-02 (Sitzung,
die auch #41/#42 hervorbrachte). #39 (3.0.0, Contract/Convention-Eigentumsgrenze) als Grundlage
gelandet 2026-09-03. corpus-policy.md geschrieben und veröffentlicht 2026-09-03 (4.2.0),
Typ-Floor auf ≥1 statt ≥2 vom Betreiber entschieden. Geschlossen 2026-09-03.
## Entschieden (2026-09-02, verfeinert 2026-09-03)
Kein Fixture neben der Testsuite, kein `--with-demo`-Export, kein zweites Repo. Ein gemeinsames
`kb/` trägt Demo und Testbett zugleich; Umfang und Kuratierungsgrad bemessen sich am Bedarf
gezielter Entwicklung, nicht an einer synthetischen Fixture-Größe.
## Ergebnis
`instructions/dev/corpus-policy.md` (neu, 4.2.0) beantwortet beide verbliebenen Fragen:
**Kuratierungsgrad** - fünf messbare Untergrenzen, jede mit einer bestehenden
`wikitool`-Prüfung (`search --field`, `lint`, ein Einzeiler-Skript für Kantendichte/Provenienz),
keine davon durch neuen Tool-Code:
| Floor | Stand 2026-09-03 |
|---|---|
| Jeder Seitentyp ≥1 Seite | erfüllt (4/4) |
| Jeder deklarierte Subtyp ≥1 Seite | erfüllt (14/14) |
| ≥5 Seiten mit ≥3 `sources:` | erfüllt (12) |
| Orphans zwischen 1 und 10 | erfüllt (3) |
| Ø ausgehende Wikilinks ≥4 | erfüllt (6,2 bei 181 Seiten) |
Der Korpus war bereits groß genug - keine Seite musste eigens angelegt werden, um einen Floor zu
erfüllen. Die Typ-/Subtyp-Floors stehen bei 1, nicht 2: ein Typ mit genau einer Seite zeigt
keine Mengenfehler, nur Erreichbarkeit - das genügt als Floor; eine zweite Seite eines
untertesteten Typs (aktuell `comparison`, 1 Seite) ist im Dokument als weiches Ziel für den
nächsten passenden Ingest vermerkt, nicht als eigene Aufgabe.
**Leitplanke für reaktive Fixes** - drei Stufen: punktuell immer erlaubt; korpusweit nur
geplant, mit eigenem Issue und `work/`-Run (trifft eine Session das Mass-Update-Gate während sie
etwas anderes tut, holt sie sich nicht den `--confirm`-Token, sondern stoppt und legt ein Issue
an); reaktiver Eingriff in Korpusinhalt, um einen Test grün zu machen oder einen Tool-Bug zu
umgehen, nie erlaubt (Invariante 7).
**Verhältnis zu `test_pipeline_l0.py`** unverändert wie im ursprünglichen Befund: kleiner,
isolierter Fall in den `kb_dir`/`raw_dir`-Fixtures, großer vernetzter Fall in `kb/` - keine
Fixture-Extraktion aus dem Korpus.
## Akzeptanzkriterien
- [x] Richtlinie formuliert: was reaktive Fixes am `kb/` dürfen und was nicht
- [x] Zielgröße für "kuratiert genug" benannt (fünf Floors, Typabdeckung inkl. `comparison`
bei ≥1 statt ≥2 - Entscheidung des Betreibers 2026-09-03)
- [x] Verhältnis zu `test_pipeline_l0.py`-Fixtures bleibt wie im ursprünglichen Befund
beschrieben - bestätigt, in `corpus-policy.md` festgehalten
## Verworfen
Fixture-Extraktion, `--with-demo`, separates Repo - alle drei setzen eine Trennung voraus, die
der Betreiber für seinen eigenen Workflow nicht will (siehe #41, Kontext).
## Verwandt
#30 (Upstream-Merge-Leck, teilt dieselbe Ursache) - **entsperrt**: das Fixture-Fundament, das
#30 als Voraussetzung nannte, steht jetzt.
## Vorgeschichte
Ursprünglicher Befund 2026-09-01. Entscheidung gegen Fixture/Repo-Trennung 2026-09-02 (Sitzung,
die auch #41/#42 hervorbrachte). #39 (3.0.0, Contract/Convention-Eigentumsgrenze) als Grundlage
gelandet 2026-09-03. `corpus-policy.md` geschrieben und veröffentlicht 2026-09-03 (4.2.0),
Typ-Floor auf ≥1 statt ≥2 vom Betreiber entschieden. Geschlossen 2026-09-03.
Dieses Issue hat jetzt eine Position in einer Kette: #39 → #28 → #30.
Der Auslöser ist konkret geworden
Die Abgrenzung sagt: „Es wird dringend in dem Moment, in dem der öffentliche Korpus zum ersten Mal als Testfläche benutzt und dabei kaputtgemacht wird." Dieser Auslöser ist durch #30 ersetzt worden, und der neue ist planbar statt reaktiv:
In #30 ist B2 empfohlen — den Demo-Korpus in ein eigenes Repo (chemenu-demo) zu ziehen, sodass main nur noch Maschinerie trägt und Merges in private Instanzen von Bauart inhaltsfrei sind. Das nimmt diesem Repo den Korpus vollständig, nicht nur teilweise. Ohne das Fixture aus diesem Issue steht main dann ohne jede Testfläche da — lint, Backlink-Ranking, xref, Orphan-Erkennung hätten nichts mehr zu prüfen.
#28 ist damit Voraussetzung von #30, nicht dessen Nachbereitung. Genau die Vorarbeit-statt-Aufräumarbeit, die die Abgrenzung sich wünscht.
#39 schneidet kb/CONTRACT.md nach Eigentum: Stack-Regel bleibt in CONTRACT.md, Instanz-Konvention zieht nach kb/CONVENTIONS.md, die vier COLLECTION.md werden instanz-eigene Templates mit profile:- und required_by_stack:-Frontmatter.
Das ändert die Form, gegen die das Fixture autorisiert wird — auf jeder Ebene, die dieses Issue nennt: welche Contract-Dateien ein Korpus mitbringt, welches Frontmatter eine Collection trägt, und woher die Autorenkonventionen kommen, gegen die die „absichtlichen Defekte" überhaupt Defekte sind. Vor #39 geschrieben, wird das Fixture zweimal geschrieben.
Die offenen Fragen, teils beantwortet
Fixture oder--with-demo, oder beides aus einer Quelle? Mit B2 in #30 zerfällt die Frage: das Demo-Repo ist die begehbare Demo, das Fixture ist die Testfläche. Zwei Artefakte mit zwei Zwecken, keine zweite Kopie im Sinn von Invariante 8 — der Bezug zu #27 (Decay eines mitgelieferten Korpus) entfällt für den Fixture-Teil, weil ein Fixture nicht altert, sondern mit der Suite gepflegt wird.
Verhältnis zu test_pipeline_l0.py und den kb_dir/raw_dir-Fixtures — unverändert offen. Bleibt der kleine vs. der große, vernetzte Fall.
Re-Labelling: prio/3 → prio/2
Nach instructions/dev/issue-tracking.md Schritt 3: Der Auslöser aus der Abgrenzung ist gefeuert, nur anders als erwartet — nicht durch einen kaputtgemachten Korpus, sondern durch #30s Entscheidung, ihn zu entfernen. Ein eingeplantes Issue statt eines wartenden. size/M bleibt.
Nach Abschluss geht es weiter bei
#30 — Demo-Korpus ins eigene Repo (B2) und upstream verify. Sobald das Fixture steht, kann main seinen Korpus verlieren, ohne blind zu werden; vorher nicht.
## Stand nach der Sitzung vom 2026-09-02
Dieses Issue hat jetzt eine Position in einer Kette: **#39 → #28 → #30.**
### Der Auslöser ist konkret geworden
Die Abgrenzung sagt: *„Es wird dringend in dem Moment, in dem der öffentliche Korpus zum ersten Mal als Testfläche benutzt und dabei kaputtgemacht wird."* Dieser Auslöser ist durch #30 ersetzt worden, und der neue ist planbar statt reaktiv:
In #30 ist **B2** empfohlen — den Demo-Korpus in ein eigenes Repo (`chemenu-demo`) zu ziehen, sodass `main` nur noch Maschinerie trägt und Merges in private Instanzen von Bauart inhaltsfrei sind. Das nimmt diesem Repo den Korpus **vollständig**, nicht nur teilweise. Ohne das Fixture aus diesem Issue steht `main` dann ohne jede Testfläche da — `lint`, Backlink-Ranking, `xref`, Orphan-Erkennung hätten nichts mehr zu prüfen.
**#28 ist damit Voraussetzung von #30, nicht dessen Nachbereitung.** Genau die Vorarbeit-statt-Aufräumarbeit, die die Abgrenzung sich wünscht.
### Und es ist selbst blockiert — durch #39
#39 schneidet `kb/CONTRACT.md` nach Eigentum: Stack-Regel bleibt in `CONTRACT.md`, Instanz-Konvention zieht nach `kb/CONVENTIONS.md`, die vier `COLLECTION.md` werden instanz-eigene Templates mit `profile:`- und `required_by_stack:`-Frontmatter.
Das ändert die Form, gegen die das Fixture autorisiert wird — auf jeder Ebene, die dieses Issue nennt: welche Contract-Dateien ein Korpus mitbringt, welches Frontmatter eine Collection trägt, und woher die Autorenkonventionen kommen, gegen die die „absichtlichen Defekte" überhaupt Defekte *sind*. **Vor #39 geschrieben, wird das Fixture zweimal geschrieben.**
### Die offenen Fragen, teils beantwortet
- **Fixture *oder* `--with-demo`, oder beides aus einer Quelle?** Mit B2 in #30 zerfällt die Frage: das **Demo-Repo** ist die begehbare Demo, das **Fixture** ist die Testfläche. Zwei Artefakte mit zwei Zwecken, keine zweite Kopie im Sinn von Invariante 8 — der Bezug zu #27 (Decay eines mitgelieferten Korpus) entfällt für den Fixture-Teil, weil ein Fixture nicht altert, sondern mit der Suite gepflegt wird.
- **Verhältnis zu `test_pipeline_l0.py` und den `kb_dir`/`raw_dir`-Fixtures** — unverändert offen. Bleibt der kleine vs. der große, vernetzte Fall.
### Re-Labelling: `prio/3` → `prio/2`
Nach `instructions/dev/issue-tracking.md` Schritt 3: Der Auslöser aus der Abgrenzung ist gefeuert, nur anders als erwartet — nicht durch einen kaputtgemachten Korpus, sondern durch #30s Entscheidung, ihn zu entfernen. Ein eingeplantes Issue statt eines wartenden. `size/M` bleibt.
---
## Nach Abschluss geht es weiter bei
**#30** — Demo-Korpus ins eigene Repo (B2) und `upstream verify`. Sobald das Fixture steht, kann `main` seinen Korpus verlieren, ohne blind zu werden; vorher nicht.
Changelog: Body verschlankt. Entscheidung 2026-09-02: kein Fixture, kein --with-demo, kein zweites Repo - ein gemeinsames kb/ für Produktiv- und Entwicklungsnutzung, Umfang nach Bedarf gezielter Entwicklung. Verbleibend nur noch: Kuratierungsgrad und Leitplanke für reaktive Fixes.
**Changelog:** Body verschlankt. Entscheidung 2026-09-02: kein Fixture, kein `--with-demo`, kein zweites Repo - ein gemeinsames `kb/` für Produktiv- und Entwicklungsnutzung, Umfang nach Bedarf gezielter Entwicklung. Verbleibend nur noch: Kuratierungsgrad und Leitplanke für reaktive Fixes.
Update 2026-09-03:#39 ist gelandet (3.0.0) und hatte selbst vermerkt, dass die hier zu definierende Leitplanke gegen die dort entschiedene Contract-Form autorisiert werden sollte (kb/CONVENTIONS.md, COLLECTION.md-Frontmatter mit profile:/required_by_stack:). Diese Form steht jetzt fest und kann als Grundlage für die Kuratierungs-/Leitplanken-Frage dieses Issues dienen. Erster Schritt in der vereinbarten Reihenfolge, vor #38/#42/#30/#7.
**Update 2026-09-03:** #39 ist gelandet (3.0.0) und hatte selbst vermerkt, dass die hier zu definierende Leitplanke gegen die dort entschiedene Contract-Form autorisiert werden sollte (`kb/CONVENTIONS.md`, `COLLECTION.md`-Frontmatter mit `profile:`/`required_by_stack:`). Diese Form steht jetzt fest und kann als Grundlage für die Kuratierungs-/Leitplanken-Frage dieses Issues dienen. Erster Schritt in der vereinbarten Reihenfolge, vor #38/#42/#30/#7.
Changelog: Umgesetzt in 4.2.0 - instructions/dev/corpus-policy.md (neu), verlinkt aus stack-dev. Fünf Untergrenzen definiert, alle heute erfüllt ohne manufactured content; Typ-Floor auf ≥1 (Betreiberentscheidung, nicht ≥2 wie ursprünglich vorgeschlagen). Leitplanke für reaktive Fixes in drei Stufen. Body auf Endstand, alle AKs erfüllt, Issue geschlossen. #30 entsperrt.
**Changelog:** Umgesetzt in 4.2.0 - `instructions/dev/corpus-policy.md` (neu), verlinkt aus `stack-dev`. Fünf Untergrenzen definiert, alle heute erfüllt ohne manufactured content; Typ-Floor auf ≥1 (Betreiberentscheidung, nicht ≥2 wie ursprünglich vorgeschlagen). Leitplanke für reaktive Fixes in drei Stufen. Body auf Endstand, alle AKs erfüllt, Issue geschlossen. #30 entsperrt.
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.
Entschieden (2026-09-02, verfeinert 2026-09-03)
Kein Fixture neben der Testsuite, kein
--with-demo-Export, kein zweites Repo. Ein gemeinsameskb/trägt Demo und Testbett zugleich; Umfang und Kuratierungsgrad bemessen sich am Bedarfgezielter Entwicklung, nicht an einer synthetischen Fixture-Größe.
Ergebnis
instructions/dev/corpus-policy.md(neu, 4.2.0) beantwortet beide verbliebenen Fragen:Kuratierungsgrad - fünf messbare Untergrenzen, jede mit einer bestehenden
wikitool-Prüfung (search --field,lint, ein Einzeiler-Skript für Kantendichte/Provenienz),keine davon durch neuen Tool-Code:
sources:Der Korpus war bereits groß genug - keine Seite musste eigens angelegt werden, um einen Floor zu
erfüllen. Die Typ-/Subtyp-Floors stehen bei 1, nicht 2: ein Typ mit genau einer Seite zeigt
keine Mengenfehler, nur Erreichbarkeit - das genügt als Floor; eine zweite Seite eines
untertesteten Typs (aktuell
comparison, 1 Seite) ist im Dokument als weiches Ziel für dennächsten passenden Ingest vermerkt, nicht als eigene Aufgabe.
Leitplanke für reaktive Fixes - drei Stufen: punktuell immer erlaubt; korpusweit nur
geplant, mit eigenem Issue und
work/-Run (trifft eine Session das Mass-Update-Gate während sieetwas anderes tut, holt sie sich nicht den
--confirm-Token, sondern stoppt und legt ein Issuean); reaktiver Eingriff in Korpusinhalt, um einen Test grün zu machen oder einen Tool-Bug zu
umgehen, nie erlaubt (Invariante 7).
Verhältnis zu
test_pipeline_l0.pyunverändert wie im ursprünglichen Befund: kleiner,isolierter Fall in den
kb_dir/raw_dir-Fixtures, großer vernetzter Fall inkb/- keineFixture-Extraktion aus dem Korpus.
Akzeptanzkriterien
kb/dürfen und was nichtcomparisonbei ≥1 statt ≥2 - Entscheidung des Betreibers 2026-09-03)
test_pipeline_l0.py-Fixtures bleibt wie im ursprünglichen Befundbeschrieben - bestätigt, in
corpus-policy.mdfestgehaltenVerworfen
Fixture-Extraktion,
--with-demo, separates Repo - alle drei setzen eine Trennung voraus, dieder Betreiber für seinen eigenen Workflow nicht will (siehe #41, Kontext).
Verwandt
#30 (Upstream-Merge-Leck, teilt dieselbe Ursache) - entsperrt: das Fixture-Fundament, das
#30 als Voraussetzung nannte, steht jetzt.
Vorgeschichte
Ursprünglicher Befund 2026-09-01. Entscheidung gegen Fixture/Repo-Trennung 2026-09-02 (Sitzung,
die auch #41/#42 hervorbrachte). #39 (3.0.0, Contract/Convention-Eigentumsgrenze) als Grundlage
gelandet 2026-09-03.
corpus-policy.mdgeschrieben und veröffentlicht 2026-09-03 (4.2.0),Typ-Floor auf ≥1 statt ≥2 vom Betreiber entschieden. Geschlossen 2026-09-03.
Stand nach der Sitzung vom 2026-09-02
Dieses Issue hat jetzt eine Position in einer Kette: #39 → #28 → #30.
Der Auslöser ist konkret geworden
Die Abgrenzung sagt: „Es wird dringend in dem Moment, in dem der öffentliche Korpus zum ersten Mal als Testfläche benutzt und dabei kaputtgemacht wird." Dieser Auslöser ist durch #30 ersetzt worden, und der neue ist planbar statt reaktiv:
In #30 ist B2 empfohlen — den Demo-Korpus in ein eigenes Repo (
chemenu-demo) zu ziehen, sodassmainnur noch Maschinerie trägt und Merges in private Instanzen von Bauart inhaltsfrei sind. Das nimmt diesem Repo den Korpus vollständig, nicht nur teilweise. Ohne das Fixture aus diesem Issue stehtmaindann ohne jede Testfläche da —lint, Backlink-Ranking,xref, Orphan-Erkennung hätten nichts mehr zu prüfen.#28 ist damit Voraussetzung von #30, nicht dessen Nachbereitung. Genau die Vorarbeit-statt-Aufräumarbeit, die die Abgrenzung sich wünscht.
Und es ist selbst blockiert — durch #39
#39 schneidet
kb/CONTRACT.mdnach Eigentum: Stack-Regel bleibt inCONTRACT.md, Instanz-Konvention zieht nachkb/CONVENTIONS.md, die vierCOLLECTION.mdwerden instanz-eigene Templates mitprofile:- undrequired_by_stack:-Frontmatter.Das ändert die Form, gegen die das Fixture autorisiert wird — auf jeder Ebene, die dieses Issue nennt: welche Contract-Dateien ein Korpus mitbringt, welches Frontmatter eine Collection trägt, und woher die Autorenkonventionen kommen, gegen die die „absichtlichen Defekte" überhaupt Defekte sind. Vor #39 geschrieben, wird das Fixture zweimal geschrieben.
Die offenen Fragen, teils beantwortet
--with-demo, oder beides aus einer Quelle? Mit B2 in #30 zerfällt die Frage: das Demo-Repo ist die begehbare Demo, das Fixture ist die Testfläche. Zwei Artefakte mit zwei Zwecken, keine zweite Kopie im Sinn von Invariante 8 — der Bezug zu #27 (Decay eines mitgelieferten Korpus) entfällt für den Fixture-Teil, weil ein Fixture nicht altert, sondern mit der Suite gepflegt wird.test_pipeline_l0.pyund denkb_dir/raw_dir-Fixtures — unverändert offen. Bleibt der kleine vs. der große, vernetzte Fall.Re-Labelling:
prio/3→prio/2Nach
instructions/dev/issue-tracking.mdSchritt 3: Der Auslöser aus der Abgrenzung ist gefeuert, nur anders als erwartet — nicht durch einen kaputtgemachten Korpus, sondern durch #30s Entscheidung, ihn zu entfernen. Ein eingeplantes Issue statt eines wartenden.size/Mbleibt.Nach Abschluss geht es weiter bei
#30 — Demo-Korpus ins eigene Repo (B2) und
upstream verify. Sobald das Fixture steht, kannmainseinen Korpus verlieren, ohne blind zu werden; vorher nicht.Changelog: Body verschlankt. Entscheidung 2026-09-02: kein Fixture, kein
--with-demo, kein zweites Repo - ein gemeinsameskb/für Produktiv- und Entwicklungsnutzung, Umfang nach Bedarf gezielter Entwicklung. Verbleibend nur noch: Kuratierungsgrad und Leitplanke für reaktive Fixes.Update 2026-09-03: #39 ist gelandet (3.0.0) und hatte selbst vermerkt, dass die hier zu definierende Leitplanke gegen die dort entschiedene Contract-Form autorisiert werden sollte (
kb/CONVENTIONS.md,COLLECTION.md-Frontmatter mitprofile:/required_by_stack:). Diese Form steht jetzt fest und kann als Grundlage für die Kuratierungs-/Leitplanken-Frage dieses Issues dienen. Erster Schritt in der vereinbarten Reihenfolge, vor #38/#42/#30/#7.Changelog: Umgesetzt in 4.2.0 -
instructions/dev/corpus-policy.md(neu), verlinkt ausstack-dev. Fünf Untergrenzen definiert, alle heute erfüllt ohne manufactured content; Typ-Floor auf ≥1 (Betreiberentscheidung, nicht ≥2 wie ursprünglich vorgeschlagen). Leitplanke für reaktive Fixes in drei Stufen. Body auf Endstand, alle AKs erfüllt, Issue geschlossen. #30 entsperrt.