-
v2.1.1 Stable
released this
2026-09-01 15:06:29 +00:00 | 107 commits to main since this release2.1.1 - 2026-09-01 - raw_dir-Fixture kappt config.ROOT; letzte private Fixture-Namen ersetzt
Author: Torben Nehmer
Der erste CI-Lauf nach der Korpus-Bereinigung wurde rot, während dieselbe Suite lokal grün
blieb:test_legacy_source_pages_flags_url_and_directoryscheiterte mit
KeyError: 'Source - DirBacked'.Die Ursache ist keine Testschwäche, sondern eine Umgebungsabhängigkeit. Der Test legt eine
Quellenseite mitsource: raw/documentsan und erwartet, dasslegacy_source_pages()sie als
„directory, not a file" meldet. Die Prüfung dort ist(config.ROOT / legacy).is_dir()— sie
löst also gegen das echte Repo-Wurzelverzeichnis auf, während dieraw_dir-Fixture ihren
Baum untertmp_pathbaut. Der Test war nie hermetisch; er bestand, weil dieser Checkout
zufällig einraw/documents/besaß.Die Korpus-Bereinigung hat dieses Verzeichnis geleert. Git verfolgt keine leeren Verzeichnisse,
also verschwand es im CI-Checkout und blieb im lokalen Arbeitsbaum stehen — grün hier, rot
dort, ohne dass sich am Test etwas geändert hätte.Geschlossen in der Fixture, nicht im Test.
raw_dirsetzt jetztconfig.ROOTauf
tmp_path. Das ist dieselbe Bauart und dasselbe Argument wie beihermetic_environment
(Gitea #8): Wenn eine Umgebungsabhängigkeit lokal unsichtbar ist, gehört sie an der Stelle
geschlossen, die alle Tests erreicht, statt bei dem einen, der zufällig darüber stolpert.
Nachgewiesen, indemraw/documents/lokal entfernt und die Suite erneut gefahren wurde — 38
Provenance-Tests grün ohne das Verzeichnis, vorher rot.Fixture-Namen. Die Suite benutzte weiterhin reale Systemnamen der Ursprungsinstanz als
Fixture-Bezeichner (atlantis,abydos,Nathan,hermes,ecodms,Opa Hasso). In einem
öffentlichen Repo beschreiben sie nichts, verraten aber die Namensgebung einer privaten
Umgebung. Ersetzt durchaurora,almanac,Borealis,gateway,docstore.gdeploy
bleibt: die Seite existiert im öffentlichen Korpus.Dateien:
tools/chemenu/tests/conftest.py(raw_dir), sämtliche Testdateien mit
Fixture-Namen.Downloads
-
v2.1.0 Stable
released this
2026-09-01 14:30:30 +00:00 | 108 commits to main since this release2.1.0 - 2026-09-01 - Dual-Lizenz AGPL-3.0/CC-BY-4.0, und ein Leak-Canary fuer dist export
Author: Torben Nehmer
Das Repo hatte keine Lizenz. Für ein Repo, das privat auf der eigenen Gitea liegt, ist das
folgenlos; für eines, das veröffentlicht werden soll, hebt es den Zweck der Veröffentlichung
auf — ohne Lizenz gilt „alle Rechte vorbehalten", und niemand darf eine Instanz aufsetzen.Zwei Hälften, zwei Lizenzen.
LICENSEträgt die AGPL-3.0 und gilt für den Stack
(tools/,types/);LICENSE-CONTENTträgt CC-BY-4.0 und gilt für die Inhalte (kb/,
raw/,instructions/, dieCONTRACT.md-Ebene, die Prosa im Wurzelverzeichnis). Die
Aufteilung folgt dem Vorbild der vendorten Commonplace-Basis, kehrt aber deren Dateinamen um:
Die Copyleft-Hälfte heißtLICENSE, weil das die Lizenz ist, die eine Forge für das Repository
meldet — und wer eine Copyleft-Pflicht übersieht, wird dadurch geschädigt, wer eine zu viel
sieht, nicht.Die Affero-Variante statt der einfachen GPL, weil Issue #19 den Stack als MCP-Frontend
erreichbar machen will. Bei der GPL schuldet nichts, wer nur einen Dienst betreibt statt
Software zu verteilen; genau dieser Weg ist der, den dieses Projekt einschlägt.Die Grenze wird nicht aufgeschrieben. Welche Datei zu welcher Hälfte gehört, ist der
Dateiplan, dendist exportohnehin berechnet.NOTICEverweist darauf, statt eine zweite
Pfadliste anzulegen, die drifted (Invariante 8).NOTICEträgt außerdem die Attribution für
commonplace(zby, CC-BY-4.0 Inhalte + MIT Code), die CC-BY verlangt.dist exportliefert die Lizenzen mit — und weigert sich sonst. Die drei Dateien stehen
jetzt inROOT_FILES, aber nicht nur dort:REQUIRED_ROOT_FILESmacht sie zur Bedingung.
Jeder andereROOT_FILES-Eintrag wirdif source.is_file()kopiert und sonst stillschweigend
übersprungen — richtig fürINSTALL.md, das es lange nicht gab, und falsch für eine Lizenz:
Ein Export, der sie weglässt, übergibt einen AGPL-tools/-Baum ohne Lizenztext, und das ist
eine Verletzung, sobald die empfangende Instanz irgendwo öffentlich landet.Der Leak-Canary.
find_leaks()prüft den fertigen Plan gegen das, was er nie enthalten
darf: eine ausgefüllteUSER.md/SOUL.md/ENVIRONMENT.md, etwas unterinstructions/dev/,
einekb/-Seite oder eineraw/-Quelle. Drei getrennte Allowlists entscheiden bisher, was
build_plankopiert, und jede hält nur, solange sich beim Editieren jemand an die Regel
erinnert hat — nichts prüfte das Ergebnis nach.exportbricht jetzt ab, wenn der Plan etwas
davon trägt, mit dem Hinweis, die Allowlist zu reparieren statt Dateien aus dem Ziel zu löschen.Die Prüfung ist bewusst strukturell und nicht textbasiert. Ein Muster-Scan auf Hostnamen
oder IP-Literale wurde erwogen und verworfen: Der eigene Host steht legitim inINSTALL.mdund
version.py, ein solcher Scan müsste also genau die Zeichenkette ausnehmen, nach der er sucht —
oder bei jedem Export Fehlalarm geben.Beispiele neutralisiert. Hilfetexte, Docstrings und Contract-Beispiele nannten reale
Seiten und Pfade der Ursprungsinstanz (Quellenseiten und Pfade
aus dem privaten Korpus). In einer
Distribution ist das nicht nur unpassend, sondern verrät den Inhalt der Instanz, die sie gebaut
hat. Ersetzt durch Beispiele aus dem verbleibenden öffentlichen Korpus.Dateien:
LICENSE,LICENSE-CONTENT,NOTICE(neu),config.LICENSE_FILES,
dist_cmd.REQUIRED_ROOT_FILES,dist_cmd.find_leaks(), Lizenzabschnitt inREADME.md,
sechs neue Tests intest_dist_cmd.py; Beispiel-Neutralisierung incite_cmd.py,
page_ops.py,work_cmd.py,provenance.py,search/ripgrep.py,work/CONTRACT.md,
instructions/session-setup.mdund zwei Testdateien.Downloads