Files
chemenu/kb/concepts/Denylist over Allowlist.md
T
torben 18ae28f918
CI / verify (push) Failing after 32s
Release / release (push) Successful in 38s
Chemenu 2.1.0 - deterministischer Wissenskompiler
Chemenu kompiliert Rohnotizen zu einem verlinkten, quellengebundenen Wiki:
raw/ -> types/ + tools/ -> kb/ -> reports/. Was mechanisch ist, macht
tools/wikitool; was Urteil braucht, macht ein Agent unter Contracts, deren
Grenzen in Code durchgesetzt sind statt im Prompt.

Dieser Commit ist der Startpunkt der oeffentlichen Historie. Die vorherige
Entwicklung fand in einer privaten Instanz statt und ist nicht Teil dieses
Repositorys; ihre Erzaehlung steht vollstaendig in CHANGES.md, das mit 44
Eintraegen von 0.1.0 bis 2.1.0 erhalten geblieben ist.

Der mitgelieferte Korpus ist ein Testbett und eine Demo: 170 Seiten ueber den
Stack selbst - Gates, Lint, Versionierung, Suche, das Wiki-Muster. Er
dokumentiert das Werkzeug mit den eigenen Mitteln des Werkzeugs.

Lizenz: AGPL-3.0 fuer den Stack (tools/, types/), CC-BY-4.0 fuer die Inhalte.
Die Grenze zwischen beiden ist der Dateiplan, den dist export berechnet -
siehe NOTICE.
2026-09-01 16:26:14 +02:00

5.3 KiB

type, concept_type, tags, created, modified, related, sources, confidence, confidence_base, provenance, summary
type concept_type tags created modified related sources confidence confidence_base provenance summary
types/concept.md decision
schema
tooling
cli
design-rule
2026-08-31 2026-08-31
wikitool
Write-Once Frontmatter Fields
AGENTS.md
Green Suite Blind Spot
Source - Conversation - Write-Once Frontmatter Fields and touch --set Session 2026-08-31
Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31
0.70 0.70 sourced Entscheidung, schreibbare Felder als Schema minus kurzer Sperrliste zu bestimmen statt als gepflegte Positivliste, weil die Positivliste eine zweite Kopie des Schemas waere

Denylist over Allowlist

Typ: Decision

Definition

Wenn ein Befehl entscheiden muss, welche Felder er schreiben darf, wird die Menge als Schema minus kurzer Sperrliste bestimmt, nicht als gepflegte Positivliste. Die Sperrliste nennt zu jedem Eintrag den Befehl, dem das Feld stattdessen gehört.

Kontext

touch --set brauchte eine Antwort auf die Frage, welche Frontmatter-Felder es schreiben darf. Torben wurden drei Varianten mit ihren Folgen vorgelegt: Denylist, Allowlist, und eine Denylist, die zusätzlich die Felder sperrt, für die es bereits eigene Optionen gibt (summary, provenance, confidence_base)1 .

Entscheidung

Denylist. Das Argument, das den Ausschlag gab: eine gepflegte Allowlist ist eine zweite Kopie des Schemas, und die Kopie ist die Seite, die driftet - Invariante 8 aus AGENTS.md, angewandt auf eine Konstante im Code1 .

Gesperrt sind in wikitool vier Gruppen, jede mit einer Zuständigkeit als Begründung:

  • type: - ändert Schema und Verzeichnis der Seite; das ist der Seiten-Lebenszyklus, kein Feldschreibvorgang.
  • confidence: - aus confidence_base durch Decay abgeleitet, nicht autorisiert.
  • related:, sources:, entities:, concepts: - gehören xref, das auch die Gegenrichtung und die Body-Bullets pflegt; ein blanker Frontmatter-Schreibvorgang ließe die andere Hälfte stehen.

Die dritte Variante - zusätzlich summary, provenance und confidence_base zu sperren, damit es für eine Sache nur einen Weg gibt - wurde nicht gewählt: die Ersparnis wäre eine Verweigerung, die für den Nutzer überraschend aussieht1 .

Konsequenzen

  • Ein neues Schema-Feld ist sofort schreibbar, ohne Codeänderung. Das ist der Zweck der Entscheidung und zugleich ihr Risiko: ein Feld, das eigentlich einen eigenen Befehl bräuchte, wird schreibbar ausgeliefert, wenn niemand daran denkt, es zu sperren.
  • Die Sperrliste muss ihre Gründe mitführen. Jeder Eintrag nennt den zuständigen Befehl, weil die Ablehnung sonst nur "nein" sagt statt zu routen. Eine gesperrte Zuständigkeit ist ein Routing-Problem; ein unbekanntes Feld dagegen ist ein Tippfehler, und die Meldung listet dort auf, welche Felder die Seite tatsächlich hat.
  • Der Verweis in einer Ablehnung ist eine Behauptung über ein anderes Kommando. Die Sperrliste aus 1.4.0 lehnte die Seiten-Referenz-Felder mit dem Hinweis auf xref add und xref remove ab. Die Sperre war richtig, das Verweisziel nicht: für die entities: und concepts: einer Source-Seite konnte xref add gar nicht schreiben, und was es dort schrieb, bekam xref remove nicht wieder weg. Eine Ablehnung, die weiterroutet, gehört deshalb mit einem Test ausgeliefert, der zeigt, dass das genannte Kommando den Fall abdeckt - andernfalls schickt sie den Aufrufer in eine Sackgasse und sieht dabei aus wie Hilfe. Behoben mit 1.6.0 (Gitea-Issue #18), nicht durch eine Änderung an der Sperrliste2
  • Der Ansatz überträgt sich auf jeden schemagetriebenen Befehl, nicht nur auf touch. Wo eine Positivliste dieselbe Information ein zweites Mal aufschreiben würde, ist die Sperrliste die kleinere Kopie.
  • Er ist kein Sicherheitsmuster. Für eine Vertrauensgrenze gilt fail-closed, also die Allowlist. Diese Entscheidung betrifft eine Zuständigkeitsverteilung innerhalb eines Werkzeugs, das ohnehin alle Felder schreiben kann.

Status

Angenommen (2026-08-31) mit Stack-Version 1.4.0, Commit dbe2f731 .

Verwandte Concepts

Beziehungen

Siehe auch

Fußnoten