Kuratierter Demo-Korpus als Fixture, statt Demo und Testbett im selben kb/ zu vermischen #28
Reference in New Issue
Block a user
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?
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.