torben/chemenu
1
1
Fork 0
Code Issues 26 Pull Requests Actions Packages Releases 32 Activity

tools/CONTRACT.md beschreibt raw accept noch vor #67: Typverzeichnisse statt Datums-Shard, keine Capture-Felder #89

New Issue
Closed
opened 2026-09-11 06:43:23 +00:00 by torben · 1 comment
torben commented 2026-09-11 06:43:23 +00:00
Owner
Copy Link
Copy Source

Gefunden in der Vorbereitungssitzung zu #32 (2026-09-11), beim Lesen der Kommandotabelle für die dort zu ergänzenden Zeilen. Umgesetzt und ausgeliefert in 5.0.0-beta.10, Commit 4781140.

Der Befund

#67 hat raw accept auf einen Datums-Shard umgestellt und zwei Pflichtflags ergänzt. Vier Zeilen in tools/CONTRACT.md beschrieben noch den Zustand davor:

Zeile Sagte Code sagt
Kommandotabelle, raw accept „Promote one or more files from incoming/<type>/ into raw/<type>/", „the type subdirectory comes from where the file sits under incoming/", Bündel als raw/<type>/<stem>/, Stem-Eindeutigkeit „at raw/<type>/ level" raw_cmd._shard_dir() schreibt nach raw/<YYYY>/<MM>/; _validate_under_incoming toleriert ein Unterverzeichnis und ignoriert es; _occupied_stems prüft global über raw/
Kommandotabelle, raw accept nannte --fidelity/--authority überhaupt nicht, weder in der Signatur noch im Text beide ohne --replaces Pflicht, unknown verboten, mit --page direkt auf die Seite geschrieben
Kommandotabelle, raw accept --replaces „same filename, same type directory required" nur der Dateiname wird verglichen; ein Typverzeichnis gibt es nicht mehr. --fidelity/--authority sind hier optional und der einzige sanktionierte Weg, einen gesetzten Wert zu korrigieren
Fehlerkontrakt, beide raw accept-Zeilen „sits directly in incoming/ … nested below its type directory", „files in one call disagree on type", „the target name is already occupied at raw/<type>/ level", „an existing raw_files: entry … under a different type directory" eine Datei direkt in incoming/ ist der Normalfall; es gibt keine Typübereinstimmung zu verletzen; Belegung wird global geprüft; fehlende Pflichtflags und ein bereits gesetztes Capture-Feld waren zwei Fehlerfälle, die gar nicht aufgeführt waren

raw/CONTRACT.md war korrekt und beschrieb Shard, Bündelregel und Capture-Felder vollständig — die Abweichung war auf tools/CONTRACT.md beschränkt. #67s Akzeptanzkriterium „tools/CONTRACT.md nennt den entfallenen Check nicht mehr" war auf check_raw_subdirs gemünzt und war erfüllt; die Kommando- und Fehlerkontrakt-Prosa daneben war dabei nicht mitgelesen worden.

Warum docs verify das nicht sah

check_commands gleicht die Namen der registrierten Kommandos gegen die Tabelle ab, in beiden Richtungen, und der Fehlerkontrakt wird auf Vorhandensein einer Zeile pro Kommando geprüft. Der Zellentext ist Prosa, und es gibt keinen mechanischen Wächter dafür — genau die Hälfte, die AGENTS.md § Changelog der Sitzung zuschreibt. Das ist auch keine Lücke, die sich schließen ließe: ein Validator kann nicht wissen, ob ein beschriebener Mechanismus noch der gebaute ist.

Was gemacht wurde

Beide raw accept-Zeilen der Kommandotabelle und beide Fehlerkontrakt-Zeilen in tools/CONTRACT.md neu geschrieben, Zelle für Zelle gegen tools/chemenu/commands/raw_cmd.py gelesen statt gegen raw/CONTRACT.md. Keine Codeänderung. raw/CONTRACT.md selbst unverändert - war bereits korrekt.

Akzeptanzkriterien

  • Beide raw accept-Zeilen der Kommandotabelle beschreiben den Datums-Shard, das tolerierte-und-ignorierte Unterverzeichnis in incoming/, die globale Stem-Eindeutigkeit und die Bündelbildung am Elternverzeichnis der Bestandsdatei
  • Die Signaturspalte nennt --fidelity/--authority, und der Text sagt, dass sie ohne --replaces Pflicht sind, unknown nie schreiben dürfen und mit --replaces der einzige Weg sind, einen gesetzten Wert zu überschreiben
  • Beide Fehlerkontrakt-Zeilen nennen keine Typverzeichnisse mehr und führen die zwei neuen Fehlerfälle (fehlende Pflichtflags, bereits gesetztes Capture-Feld) auf
  • Jede Aussage in den vier Zellen ist gegen tools/chemenu/commands/raw_cmd.py gegengelesen, nicht gegen raw/CONTRACT.md
  • docs verify und pytest grün; keine Codeänderung in diesem Issue
  • Changelog-Eintrag, PATCH (angewendet als Eskalation des laufenden 5.0.0-Kandidaten - der Kandidat trägt seine Boundary-Crossing-Zeile bereits aus einem früheren Bump, diese Änderung fügt keine neue hinzu, siehe version-parts.md)

Verifiziert

  • tools/wikitool docs verify — OK, 51 Kommandos dokumentiert, 11 Ignore-Kanarien klar.
  • tools/wikitool instructions verify — OK, 20 Instructions und 7 Skills gültig, 14 publizierte Kopien identisch.
  • pytest -q in tools/: 1118 passed, keine neuen Tests nötig (reine Doku-Korrektur).
  • Commit 4781140, gepusht nach origin/main.

Schließt #89.

Gefunden in der Vorbereitungssitzung zu #32 (2026-09-11), beim Lesen der Kommandotabelle für die dort zu ergänzenden Zeilen. **Umgesetzt und ausgeliefert** in `5.0.0-beta.10`, Commit `4781140`. ## Der Befund #67 hat `raw accept` auf einen Datums-Shard umgestellt und zwei Pflichtflags ergänzt. Vier Zeilen in `tools/CONTRACT.md` beschrieben noch den Zustand davor: | Zeile | Sagte | Code sagt | |---|---|---| | Kommandotabelle, `raw accept` | „Promote one or more files from `incoming/<type>/` into `raw/<type>/`", „the type subdirectory comes from where the file sits under `incoming/`", Bündel als `raw/<type>/<stem>/`, Stem-Eindeutigkeit „at `raw/<type>/` level" | `raw_cmd._shard_dir()` schreibt nach `raw/<YYYY>/<MM>/`; `_validate_under_incoming` toleriert ein Unterverzeichnis und **ignoriert** es; `_occupied_stems` prüft global über `raw/` | | Kommandotabelle, `raw accept` | nannte `--fidelity`/`--authority` überhaupt nicht, weder in der Signatur noch im Text | beide ohne `--replaces` **Pflicht**, `unknown` verboten, mit `--page` direkt auf die Seite geschrieben | | Kommandotabelle, `raw accept --replaces` | „same filename, same type directory required" | nur der Dateiname wird verglichen; ein Typverzeichnis gibt es nicht mehr. `--fidelity`/`--authority` sind hier optional und der einzige sanktionierte Weg, einen gesetzten Wert zu korrigieren | | Fehlerkontrakt, beide `raw accept`-Zeilen | „sits directly in `incoming/` … nested below its type directory", „files in one call disagree on type", „the target name is already occupied at `raw/<type>/` level", „an existing `raw_files:` entry … under a different type directory" | eine Datei direkt in `incoming/` ist der **Normalfall**; es gibt keine Typübereinstimmung zu verletzen; Belegung wird global geprüft; fehlende Pflichtflags und ein bereits gesetztes Capture-Feld waren zwei Fehlerfälle, die gar nicht aufgeführt waren | `raw/CONTRACT.md` war korrekt und beschrieb Shard, Bündelregel und Capture-Felder vollständig — die Abweichung war auf `tools/CONTRACT.md` beschränkt. #67s Akzeptanzkriterium „`tools/CONTRACT.md` nennt den entfallenen Check nicht mehr" war auf `check_raw_subdirs` gemünzt und war erfüllt; die Kommando- und Fehlerkontrakt-Prosa daneben war dabei nicht mitgelesen worden. ## Warum `docs verify` das nicht sah `check_commands` gleicht die **Namen** der registrierten Kommandos gegen die Tabelle ab, in beiden Richtungen, und der Fehlerkontrakt wird auf Vorhandensein einer Zeile pro Kommando geprüft. Der Zellentext ist Prosa, und es gibt keinen mechanischen Wächter dafür — genau die Hälfte, die AGENTS.md § Changelog der Sitzung zuschreibt. Das ist auch keine Lücke, die sich schließen ließe: ein Validator kann nicht wissen, ob ein beschriebener Mechanismus noch der gebaute ist. ## Was gemacht wurde Beide `raw accept`-Zeilen der Kommandotabelle und beide Fehlerkontrakt-Zeilen in `tools/CONTRACT.md` neu geschrieben, Zelle für Zelle gegen `tools/chemenu/commands/raw_cmd.py` gelesen statt gegen `raw/CONTRACT.md`. Keine Codeänderung. `raw/CONTRACT.md` selbst unverändert - war bereits korrekt. ## Akzeptanzkriterien - [x] Beide `raw accept`-Zeilen der Kommandotabelle beschreiben den Datums-Shard, das tolerierte-und-ignorierte Unterverzeichnis in `incoming/`, die globale Stem-Eindeutigkeit und die Bündelbildung am Elternverzeichnis der Bestandsdatei - [x] Die Signaturspalte nennt `--fidelity`/`--authority`, und der Text sagt, dass sie ohne `--replaces` Pflicht sind, `unknown` nie schreiben dürfen und mit `--replaces` der einzige Weg sind, einen gesetzten Wert zu überschreiben - [x] Beide Fehlerkontrakt-Zeilen nennen keine Typverzeichnisse mehr und führen die zwei neuen Fehlerfälle (fehlende Pflichtflags, bereits gesetztes Capture-Feld) auf - [x] Jede Aussage in den vier Zellen ist gegen `tools/chemenu/commands/raw_cmd.py` gegengelesen, nicht gegen `raw/CONTRACT.md` - [x] `docs verify` und `pytest` grün; keine Codeänderung in diesem Issue - [x] Changelog-Eintrag, **PATCH** (angewendet als Eskalation des laufenden `5.0.0`-Kandidaten - der Kandidat trägt seine Boundary-Crossing-Zeile bereits aus einem früheren Bump, diese Änderung fügt keine neue hinzu, siehe `version-parts.md`) ## Verifiziert - `tools/wikitool docs verify` — OK, 51 Kommandos dokumentiert, 11 Ignore-Kanarien klar. - `tools/wikitool instructions verify` — OK, 20 Instructions und 7 Skills gültig, 14 publizierte Kopien identisch. - `pytest -q` in `tools/`: **1118 passed**, keine neuen Tests nötig (reine Doku-Korrektur). - Commit `4781140`, gepusht nach `origin/main`. Schließt #89.
torben added the prio/plannedsize/Sarea/kbkind/defect labels 2026-09-11 06:43:23 +00:00
torben commented 2026-09-11 06:48:38 +00:00
Author
Owner
Copy Link
Copy Source

Changelog: Body auf den Endzustand umgeschrieben, alle Akzeptanzkriterien abgehakt. Umgesetzt in 5.0.0-beta.10, Commit 4781140 — vier Zellen in tools/CONTRACT.md (beide raw accept-Zeilen der Kommandotabelle, beide Fehlerkontrakt-Zeilen) auf den Stand nach #67 gebracht, keine Codeänderung. docs verify, instructions verify, pytest (1118 passed) grün, gepusht.

**Changelog:** Body auf den Endzustand umgeschrieben, alle Akzeptanzkriterien abgehakt. Umgesetzt in `5.0.0-beta.10`, Commit `4781140` — vier Zellen in `tools/CONTRACT.md` (beide `raw accept`-Zeilen der Kommandotabelle, beide Fehlerkontrakt-Zeilen) auf den Stand nach #67 gebracht, keine Codeänderung. `docs verify`, `instructions verify`, `pytest` (1118 passed) grün, gepusht.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/corpus
Betrifft Demo-/Testbett-Frage, Inhalt und Umfang von kb/
 area/distribution
Betrifft Auslieferung, Upgrade, Versionierung einer Instanz
 area/kb
Betrifft kb/-Schema, Contract, Confidence, Lint, Wissensbasis
 area/process
Betrifft den Entwicklungsprozess selbst, nicht den Stack als Artefakt
 area/workflow
Betrifft Git, Merge, Branching, Publish, PRs
 kind/build
Spezifiziert, wartet nur noch auf Umsetzungszeit
 kind/decision
Wartet auf eine Betreiberentscheidung
 kind/defect
Befund: Doku und Realitaet, oder zwei Dokus, widersprechen sich
 prio/blocking
Blockiert oder beschaedigt laufende Arbeit - als naechstes
 prio/planned
Traegt bald Zinsen - eingeplant
 prio/waiting
Sinnvoll, wartet auf einen Ausloeser
 size/L
Mehrere Sitzungen oder offene Designfragen vor dem ersten Commit
 size/M
Mehrere Dateien, Contract- oder Instruction-Aenderung, eigener Testaufwand
 size/S
Eine Sitzung, ein Publish, klar umrissener Schnitt
 status/blocked
Wartet auf ein anderes, noch offenes Issue - nicht eigenstaendig bearbeitbar
 status/incoming
Vom Menschen angelegte Anforderung, unvollständig, muss durch den Stack komplettiert werden.
 status/unconfirmed
Gemeldeter Verdacht, noch nicht gegen tatsaechliches Verhalten geprueft - size/prio vorlaeufig
No Label area/kb kind/defect prio/planned size/S
Milestone
No items
No Milestone
Assignees
Clear assignees
torben
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: torben/chemenu#89
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?