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

Ausgelieferte Instructions zitieren Gitea-Issue-Nummern, die es in keiner verteilten Instanz gibt #77

New Issue
Closed
opened 2026-09-09 09:02:33 +00:00 by torben · 3 comments
torben commented 2026-09-09 09:02:33 +00:00
Owner
Copy Link
Copy Source

Erledigt mit a51d7a3 (4.8.0-beta.12, MINOR).

Was das Problem war

tools/wikitool dist export lieferte Dateien aus, die im Fliesstext auf Issue-Nummern dieses
Trackers verwiesen - "flat since Gitea #67", "new source refuses without it (Gitea #66)". In
einer verteilten Instanz zeigte das auf nichts: der Leser konnte den Verweis weder aufloesen
noch als unaufloesbar erkennen, und eine Regel sah damit so aus, als stuetze sie sich auf einen
Beleg, den niemand beibringen kann. Das Board liegt im Ursprungs-Repo, und
instructions/dev/issue-tracking.md - die einzige Datei, die das ueberhaupt sagt - wird von
dist export mit dem Rest von instructions/dev/ weggeschnitten.

Gegenprobe zum Eigenanspruch aus instructions/CONTRACT.md § "Writing an instruction":
"self-contained enough for an agent with no prior context". Eine Issue-Nummer ist genau der
Verweis, den ein Agent ohne Vorkontext nicht aufloesen kann.

Umfang, gemessen statt geschaetzt. Export in ein leeres Verzeichnis, grep -rn '#[0-9]':
43 Treffer in 16 Dateien ausserhalb tools/**/*.py - raw/CONTRACT.md allein acht. Die
urspruengliche Befund-Tabelle dieses Issues fuehrte zehn Stellen in fuenf Dateien; der Rest kam
erst beim Messen gegen den echten Export zutage. Dazu ~90 Treffer in .py, die nach
Entscheidung 1 nicht in den Umfang fielen.

Entschieden und umgesetzt

1. Umfang: nur Doku-Prosa, tools/**/*.py blieb unberuehrt.
Adressat eines Code-Kommentars ist, wer die Zeile editiert - und das passiert ausschliesslich im
Ursprungs-Repo, weil dist export instructions/dev/ samt stack-dev-Skill wegschneidet. Die
Frontload-Regel, aus der der Befund stammt, bindet Instructions, nicht Quelltext; eine
ausgelieferte tools/-Kopie ist Laufzeit-Maschinerie, keine Lektuere. Akzeptanzkriterium 4
wurde entsprechend auf Doku-Pfade eingegrenzt statt woertlich ueber den ganzen Export gelesen.

2. Beleg-Form: Nummer raus, Datierung in Worte - statt der im urspruenglichen Body
vorgeschlagenen Historien-Markierung.
Aus "flat since Gitea #67" wurde "flat since the addressing scheme dropped type directories",
aus "Pre-#67 files are not moved" wurde "Files promoted under the old type directories are
not moved". Der Satz traegt sich damit selbst: keine repoweite Notation, die definiert und an
genau einer Stelle gehalten werden muesste (Invariante 8), und kein README.md-Leser muss
AGENTS.md geladen haben, um sie aufzuloesen. Rueckverfolgbar bleibt es hier ueber git blame
-> Commit-Message; die tragen die Nummern ohnehin.

Zwei Stellen, an denen der Zeiger der ganze Wert des Satzes war und in Worten nichts uebrig
geblieben waere, stehen jetzt in einem <!-- dist:strip-start/end -->-Block:
instructions/CONTRACT.md (was ein Test der Kontextfenster-Behauptung kosten wuerde, #72) und
EVALS.md (Schliessen der Coverage-Luecken, #51). Bestehende Konvention aus
instructions/CONTRACT.md § instructions/dev/, hier zum zweiten Mal angewandt statt neu
erfunden.

3. Die offene docs verify-Frage: mit Ja beantwortet.
check_no_issue_references liest nicht den Arbeitsbaum, sondern den Text, den
dist_cmd.build_plan() schreiben wuerde - dort leben ROOT_FILES, der
instructions/dev/-Ausschluss und das .template-Rekeying schon, und der Text hat seine
Marker-Bloecke bereits verloren. Ein Strip-Block ist damit automatisch exemptiert, ohne dass der
Check ihn kennen muesste.

Der Einwand aus § "What no tool checks" - wikitool soll den Tracker nicht kennen - traegt
nicht, und der Abschnitt zieht die Grenze jetzt selbst: re.compile(r"#\d+") hat keinen Client,
keine URL und keinen Begriff vom Zustand eines Issues. Der Check sieht eine Eigenschaft des
Dokuments, nicht des Boards. Gemessen null False Positives ueber den gesamten Export, weil
Markdown-Anker aus Wortzeichen bestehen (](#gates) matcht nicht).

Der erste Fund des Checks war prompt der Satz, den diese Sitzung selbst in tools/CONTRACT.md
geschrieben hatte, um die Regel zu erklaeren (ein illustratives "#42").

Akzeptanzkriterien

  • Keine von dist export ausgelieferte .md/.template-Datei enthaelt einen Verweis auf
    eine Gitea-Issue-Nummer.
  • Die Begruendungen, die vorher nur ueber die Nummer erreichbar waren (warum source_type
    keinen Default hat, warum raw accept auf Stem-Eindeutigkeit besteht, warum raw/ flach
    ist), stehen im Text selbst.
  • tools/.coveragerc und .gitignore mitgezogen, obwohl der Check sie nicht erfasst.
  • Frischer dist export + grep -rn '#[0-9]' liefert null Treffer - nicht nur in
    .md/.template, sondern im gesamten Export ausserhalb .py.
  • docs verify meldet den Verstoss, wenn eine Nummer wieder in eine ausgelieferte Datei
    gelangt; sechs Tests decken beide Richtungen ab.
  • docs verify, instructions verify und pytest ohne neue Findings.
  • tools/**/*.py unveraendert (Entscheidung 1).

Verifiziert

Check Ergebnis
tools/wikitool docs verify OK - "no issue references in 63 shipped document(s)"
tools/wikitool instructions verify OK - 21 Instructions, 7 Skills, 14 publizierte Kopien deckungsgleich
pytest (tools/) 1082 passed
dist export + grep -rn '#[0-9]', --exclude='*.py' 0 Treffer
CI-Lauf 210 (verify, Nr. 165) success - alle 9 Schritte, inkl. "Export the distribution" und "The distribution works as a fresh instance" (der setup-instance-Replay, der einzige Check, der lokal nicht lief)
CI-Lauf 211 (release, Nr. 166) success, ohne etwas zu veroeffentlichen - neuester Tag/Release bleibt v4.7.4. Erwartet: 4.8.0-beta.12 ist ein Kandidat, und release.yml handelt nur auf einer suffixfreien VERSION

docs/-Veralterung geprueft und keine gefunden: docs/version-model.md's Aussage "No check
in docs verify or anywhere else confirms that a version part was chosen correctly" bleibt wahr
(der neue Check sagt nichts ueber Versionsteile), und docs/ownership-and-templates.md
beschreibt, wer eine Datei aendern darf und was ein Upgrade ueberschreiben darf - der Check
schreibt nichts und verschiebt keine Ownership. docs/pipeline-rationale.md hat nur die
Klammer verloren, seine Begruendung ist unberuehrt.

Geaendert

tools/chemenu/commands/docs_verify.py (neuer Check plus shipped_prose()),
tools/chemenu/tests/test_docs_verify.py (sechs Tests: sauberer Baum, praeparierte Datei,
Anker-Nicht-Treffer, .py ausserhalb des Scans, Strip-Block unsichtbar, verify bricht ab),
tools/CONTRACT.md (Kommandotabelle + Fehlerkontrakt-Zeile), tools/README.md,
instructions/dev/issue-tracking.md (neuer § Citing an issue in the repo; § What no tool checks
zieht die Grenze zwischen "was dieses Repo ueber den Tracker schreibt" und "dem Tracker selbst").

Die 16 Doku-Dateien: raw/CONTRACT.md, kb/CONTRACT.md, tools/CONTRACT.md,
types/type-spec.md, types/source.schema.yaml, kb/sources/COLLECTION.md,
kb/concepts/COLLECTION.md, instructions/wiki-ingest/SKILL.md,
instructions/evolve-subtypes.md, instructions/bootstrap.md, instructions/kb-profiles.md,
instructions/mcp-read-server.md, instructions/CONTRACT.md, README.md, EVALS.md,
INSTALL.md, docs/pipeline-rationale.md, .gitignore, tools/.coveragerc.

Bewusst nicht gemacht

  • tools/**/*.py (~90 Stellen) - Entscheidung 1.
  • Eine Historien-Notation ("origin-repo issue #67") - der urspruengliche Body liess sie als
    Option zu. Verworfen zugunsten von Entscheidung 2: sie haette eine repoweite Notation
    gebraucht, die genau eine Definitionsstelle haben darf, waehrend README.md und INSTALL.md
    von Lesern gesehen werden, die AGENTS.md nie laden.
  • Eine Ausnahme fuer instanzeigene Dateien. Der Check liest auch kb/CONVENTIONS.md und
    kb/<collection>/COLLECTION.md, weil ein Export sie als .template mitnimmt. Eine Instanz,
    die dort ihre eigene Ticket-Nummer zitiert, bekommt ein Finding. Das ist kein Fehlalarm - ein
    Export dieser Instanz wuerde den Verweis weitergeben - aber es ist neu, und es steht so im
    CHANGES.md-Eintrag.

Herkunft

Analyse aus #65, Sitzung 2026-09-09, aufgefallen bei der Volltext-Sichtung von wiki-ingest.
Per grep auf die uebrigen ausgelieferten Instructions ausgeweitet, in der Umsetzungssitzung
auf den vollstaendigen Export gemessen. Verwandte Vorgeschichte in die Gegenrichtung: #29
(Issue-Texte trugen veraltete Pfade nach dem Chemenu-Rename).

**Erledigt** mit `a51d7a3` (`4.8.0-beta.12`, MINOR). ## Was das Problem war `tools/wikitool dist export` lieferte Dateien aus, die im Fliesstext auf Issue-Nummern dieses Trackers verwiesen - "flat since Gitea #67", "`new source` refuses without it (Gitea #66)". In einer verteilten Instanz zeigte das auf nichts: der Leser konnte den Verweis weder aufloesen noch als unaufloesbar erkennen, und eine Regel sah damit so aus, als stuetze sie sich auf einen Beleg, den niemand beibringen kann. Das Board liegt im Ursprungs-Repo, und `instructions/dev/issue-tracking.md` - die einzige Datei, die das ueberhaupt sagt - wird von `dist export` mit dem Rest von `instructions/dev/` weggeschnitten. Gegenprobe zum Eigenanspruch aus `instructions/CONTRACT.md` § "Writing an instruction": "self-contained enough for an agent with no prior context". Eine Issue-Nummer ist genau der Verweis, den ein Agent ohne Vorkontext nicht aufloesen kann. **Umfang, gemessen statt geschaetzt.** Export in ein leeres Verzeichnis, `grep -rn '#[0-9]'`: **43 Treffer in 16 Dateien** ausserhalb `tools/**/*.py` - `raw/CONTRACT.md` allein acht. Die urspruengliche Befund-Tabelle dieses Issues fuehrte zehn Stellen in fuenf Dateien; der Rest kam erst beim Messen gegen den echten Export zutage. Dazu ~90 Treffer *in* `.py`, die nach Entscheidung 1 nicht in den Umfang fielen. ## Entschieden und umgesetzt **1. Umfang: nur Doku-Prosa, `tools/**/*.py` blieb unberuehrt.** Adressat eines Code-Kommentars ist, wer die Zeile editiert - und das passiert ausschliesslich im Ursprungs-Repo, weil `dist export` `instructions/dev/` samt `stack-dev`-Skill wegschneidet. Die Frontload-Regel, aus der der Befund stammt, bindet Instructions, nicht Quelltext; eine ausgelieferte `tools/`-Kopie ist Laufzeit-Maschinerie, keine Lektuere. Akzeptanzkriterium 4 wurde entsprechend auf Doku-Pfade eingegrenzt statt woertlich ueber den ganzen Export gelesen. **2. Beleg-Form: Nummer raus, Datierung in Worte** - statt der im urspruenglichen Body vorgeschlagenen Historien-Markierung. Aus "flat since Gitea #67" wurde "flat since the addressing scheme dropped type directories", aus "**Pre-#67 files are not moved**" wurde "**Files promoted under the old type directories are not moved**". Der Satz traegt sich damit selbst: keine repoweite Notation, die definiert und an genau einer Stelle gehalten werden muesste (Invariante 8), und kein `README.md`-Leser muss `AGENTS.md` geladen haben, um sie aufzuloesen. Rueckverfolgbar bleibt es hier ueber `git blame` -> Commit-Message; die tragen die Nummern ohnehin. Zwei Stellen, an denen der Zeiger *der ganze Wert* des Satzes war und in Worten nichts uebrig geblieben waere, stehen jetzt in einem `<!-- dist:strip-start/end -->`-Block: `instructions/CONTRACT.md` (was ein Test der Kontextfenster-Behauptung kosten wuerde, #72) und `EVALS.md` (Schliessen der Coverage-Luecken, #51). Bestehende Konvention aus `instructions/CONTRACT.md` § `instructions/dev/`, hier zum zweiten Mal angewandt statt neu erfunden. **3. Die offene `docs verify`-Frage: mit Ja beantwortet.** `check_no_issue_references` liest nicht den Arbeitsbaum, sondern den Text, den `dist_cmd.build_plan()` schreiben wuerde - dort leben `ROOT_FILES`, der `instructions/dev/`-Ausschluss und das `.template`-Rekeying schon, und der Text hat seine Marker-Bloecke bereits verloren. Ein Strip-Block ist damit automatisch exemptiert, ohne dass der Check ihn kennen muesste. Der Einwand aus § "What no tool checks" - `wikitool` soll den Tracker nicht kennen - traegt nicht, und der Abschnitt zieht die Grenze jetzt selbst: `re.compile(r"#\d+")` hat keinen Client, keine URL und keinen Begriff vom Zustand eines Issues. Der Check sieht eine Eigenschaft des *Dokuments*, nicht des Boards. Gemessen null False Positives ueber den gesamten Export, weil Markdown-Anker aus Wortzeichen bestehen (`](#gates)` matcht nicht). Der erste Fund des Checks war prompt der Satz, den diese Sitzung selbst in `tools/CONTRACT.md` geschrieben hatte, um die Regel zu erklaeren (ein illustratives "#42"). ## Akzeptanzkriterien - [x] Keine von `dist export` ausgelieferte `.md`/`.template`-Datei enthaelt einen Verweis auf eine Gitea-Issue-Nummer. - [x] Die Begruendungen, die vorher nur ueber die Nummer erreichbar waren (warum `source_type` keinen Default hat, warum `raw accept` auf Stem-Eindeutigkeit besteht, warum `raw/` flach ist), stehen im Text selbst. - [x] `tools/.coveragerc` und `.gitignore` mitgezogen, obwohl der Check sie nicht erfasst. - [x] Frischer `dist export` + `grep -rn '#[0-9]'` liefert **null Treffer** - nicht nur in `.md`/`.template`, sondern im gesamten Export ausserhalb `.py`. - [x] `docs verify` meldet den Verstoss, wenn eine Nummer wieder in eine ausgelieferte Datei gelangt; sechs Tests decken beide Richtungen ab. - [x] `docs verify`, `instructions verify` und `pytest` ohne neue Findings. - [x] `tools/**/*.py` unveraendert (Entscheidung 1). ## Verifiziert | Check | Ergebnis | |---|---| | `tools/wikitool docs verify` | OK - "no issue references in 63 shipped document(s)" | | `tools/wikitool instructions verify` | OK - 21 Instructions, 7 Skills, 14 publizierte Kopien deckungsgleich | | `pytest` (`tools/`) | 1082 passed | | `dist export` + `grep -rn '#[0-9]'`, `--exclude='*.py'` | 0 Treffer | | CI-Lauf 210 (`verify`, Nr. 165) | **success** - alle 9 Schritte, inkl. "Export the distribution" und "The distribution works as a fresh instance" (der `setup-instance`-Replay, der einzige Check, der lokal nicht lief) | | CI-Lauf 211 (`release`, Nr. 166) | **success**, ohne etwas zu veroeffentlichen - neuester Tag/Release bleibt `v4.7.4`. Erwartet: `4.8.0-beta.12` ist ein Kandidat, und `release.yml` handelt nur auf einer suffixfreien `VERSION` | `docs/`-Veralterung geprueft und **keine** gefunden: `docs/version-model.md`'s Aussage "No check in `docs verify` or anywhere else confirms that a version part was chosen correctly" bleibt wahr (der neue Check sagt nichts ueber Versionsteile), und `docs/ownership-and-templates.md` beschreibt, *wer* eine Datei aendern darf und was ein Upgrade ueberschreiben darf - der Check schreibt nichts und verschiebt keine Ownership. `docs/pipeline-rationale.md` hat nur die Klammer verloren, seine Begruendung ist unberuehrt. ## Geaendert `tools/chemenu/commands/docs_verify.py` (neuer Check plus `shipped_prose()`), `tools/chemenu/tests/test_docs_verify.py` (sechs Tests: sauberer Baum, praeparierte Datei, Anker-Nicht-Treffer, `.py` ausserhalb des Scans, Strip-Block unsichtbar, `verify` bricht ab), `tools/CONTRACT.md` (Kommandotabelle + Fehlerkontrakt-Zeile), `tools/README.md`, `instructions/dev/issue-tracking.md` (neuer § Citing an issue in the repo; § What no tool checks zieht die Grenze zwischen "was dieses Repo ueber den Tracker schreibt" und "dem Tracker selbst"). Die 16 Doku-Dateien: `raw/CONTRACT.md`, `kb/CONTRACT.md`, `tools/CONTRACT.md`, `types/type-spec.md`, `types/source.schema.yaml`, `kb/sources/COLLECTION.md`, `kb/concepts/COLLECTION.md`, `instructions/wiki-ingest/SKILL.md`, `instructions/evolve-subtypes.md`, `instructions/bootstrap.md`, `instructions/kb-profiles.md`, `instructions/mcp-read-server.md`, `instructions/CONTRACT.md`, `README.md`, `EVALS.md`, `INSTALL.md`, `docs/pipeline-rationale.md`, `.gitignore`, `tools/.coveragerc`. ## Bewusst nicht gemacht - **`tools/**/*.py`** (~90 Stellen) - Entscheidung 1. - **Eine Historien-Notation** ("origin-repo issue #67") - der urspruengliche Body liess sie als Option zu. Verworfen zugunsten von Entscheidung 2: sie haette eine repoweite Notation gebraucht, die genau eine Definitionsstelle haben darf, waehrend `README.md` und `INSTALL.md` von Lesern gesehen werden, die `AGENTS.md` nie laden. - **Eine Ausnahme fuer instanzeigene Dateien.** Der Check liest auch `kb/CONVENTIONS.md` und `kb/<collection>/COLLECTION.md`, weil ein Export sie als `.template` mitnimmt. Eine Instanz, die dort ihre eigene Ticket-Nummer zitiert, bekommt ein Finding. Das ist kein Fehlalarm - ein Export dieser Instanz wuerde den Verweis weitergeben - aber es ist neu, und es steht so im `CHANGES.md`-Eintrag. ## Herkunft Analyse aus #65, Sitzung 2026-09-09, aufgefallen bei der Volltext-Sichtung von `wiki-ingest`. Per `grep` auf die uebrigen ausgelieferten Instructions ausgeweitet, in der Umsetzungssitzung auf den vollstaendigen Export gemessen. Verwandte Vorgeschichte in die Gegenrichtung: #29 (Issue-Texte trugen veraltete Pfade nach dem Chemenu-Rename).
torben added the prio/plannedsize/Marea/distributionkind/defect labels 2026-09-09 09:02:33 +00:00
torben commented 2026-09-09 14:32:02 +00:00
Author
Owner
Copy Link
Copy Source

Changelog: Zeilennummern in der Befund-Tabelle nachgezogen. 663b1c0 (#79) hat instructions/wiki-ingest/SKILL.md in den Schritten 1 und 6 gekuerzt, die drei dort gelisteten Stellen sind verrutscht:

Datei alt neu
instructions/wiki-ingest/SKILL.md Z. 46 Z. 43
instructions/wiki-ingest/SKILL.md Z. 93 Z. 91
instructions/wiki-ingest/SKILL.md Z. 102 Z. 100

Der Wortlaut der dritten Stelle hat sich mitgeaendert: "new source refuses without them the same way (Gitea #67) - but here there is no catalog slot to fall back on, for the reason step 1 gives". Am Befund aendert das nichts, die Nummer steht weiter im ausgelieferten Text.

Die uebrigen vier Dateien der Tabelle (kb-profiles.md, mcp-read-server.md, bootstrap.md, evolve-subtypes.md) wurden nicht angefasst, ihre Zeilennummern stehen.

Sonst unveraendert - Wegweiser/Beleg-Unterscheidung, Akzeptanzkriterien und die offene docs verify-Frage gelten wie beschrieben.

**Changelog:** Zeilennummern in der Befund-Tabelle nachgezogen. `663b1c0` (#79) hat `instructions/wiki-ingest/SKILL.md` in den Schritten 1 und 6 gekuerzt, die drei dort gelisteten Stellen sind verrutscht: | Datei | alt | neu | |---|---|---| | `instructions/wiki-ingest/SKILL.md` | Z. 46 | **Z. 43** | | `instructions/wiki-ingest/SKILL.md` | Z. 93 | **Z. 91** | | `instructions/wiki-ingest/SKILL.md` | Z. 102 | **Z. 100** | Der Wortlaut der dritten Stelle hat sich mitgeaendert: "`new source` refuses without them the same way (Gitea #67) - but here there is no catalog slot to fall back on, **for the reason step 1 gives**". Am Befund aendert das nichts, die Nummer steht weiter im ausgelieferten Text. Die uebrigen vier Dateien der Tabelle (`kb-profiles.md`, `mcp-read-server.md`, `bootstrap.md`, `evolve-subtypes.md`) wurden nicht angefasst, ihre Zeilennummern stehen. Sonst unveraendert - Wegweiser/Beleg-Unterscheidung, Akzeptanzkriterien und die offene `docs verify`-Frage gelten wie beschrieben.
torben commented 2026-09-09 15:29:43 +00:00
Author
Owner
Copy Link
Copy Source

Changelog: Body auf den entschiedenen Stand umgeschrieben.

Neu: die drei Entscheidungen der Umsetzungssitzung (Umfang ohne tools/**/*.py, Beleg-Form "Nummer raus, Datierung in Worte" statt Historien-Marker, docs verify-Check mit Ja beantwortet). Der Abschnitt "Offene Frage" faellt damit weg - sie ist beantwortet, nicht mehr offen.

Korrigiert: der Umfang. Die Befund-Tabelle fuehrte 10 Stellen in 5 Dateien; gemessen am tatsaechlichen dist export sind es 43 ausserhalb .py, in 16 Dateien. Die Zeilennummern-Tabelle ist durch eine Datei/Treffer-Tabelle ersetzt - Zeilennummern waren zweimal in zwei Tagen nachzuziehen und sind fuer die Abarbeitung ohnehin kein Fundort, der Grep ist einer.

Gestrichen: der separate Hinweis auf instructions/CONTRACT.md Z. 218 - die Datei steht jetzt regulaer im Umfang. Der Wegweiser/Beleg-Abschnitt bleibt, aber ohne die Auflage "als Historie markiert" (Entscheidung 2 macht sie gegenstandslos).

Akzeptanzkriterien entsprechend neu: Kriterium 4 auf .md/.template eingegrenzt, ein Kriterium fuer den docs verify-Test und eines fuer die Unveraendertheit von tools/**/*.py dazu.

**Changelog:** Body auf den entschiedenen Stand umgeschrieben. Neu: die drei Entscheidungen der Umsetzungssitzung (Umfang ohne `tools/**/*.py`, Beleg-Form "Nummer raus, Datierung in Worte" statt Historien-Marker, `docs verify`-Check mit Ja beantwortet). Der Abschnitt "Offene Frage" faellt damit weg - sie ist beantwortet, nicht mehr offen. Korrigiert: der Umfang. Die Befund-Tabelle fuehrte 10 Stellen in 5 Dateien; gemessen am tatsaechlichen `dist export` sind es **43 ausserhalb `.py`, in 16 Dateien**. Die Zeilennummern-Tabelle ist durch eine Datei/Treffer-Tabelle ersetzt - Zeilennummern waren zweimal in zwei Tagen nachzuziehen und sind fuer die Abarbeitung ohnehin kein Fundort, der Grep ist einer. Gestrichen: der separate Hinweis auf `instructions/CONTRACT.md` Z. 218 - die Datei steht jetzt regulaer im Umfang. Der Wegweiser/Beleg-Abschnitt bleibt, aber ohne die Auflage "als Historie markiert" (Entscheidung 2 macht sie gegenstandslos). Akzeptanzkriterien entsprechend neu: Kriterium 4 auf `.md`/`.template` eingegrenzt, ein Kriterium fuer den `docs verify`-Test und eines fuer die Unveraendertheit von `tools/**/*.py` dazu.
torben commented 2026-09-09 17:27:29 +00:00
Author
Owner
Copy Link
Copy Source

Changelog: Abschluss-Rewrite. Body steht auf dem Endstand, geschlossen mit a51d7a3 (4.8.0-beta.12).

Neu: die drei Entscheidungen als umgesetzt statt als Vorhaben formuliert, ein Abschnitt "Verifiziert" mit den tatsaechlichen Ergebnissen (CI 210 verify und 211 release, beide gruen), die docs/-Veralterungspruefung mit ihrem Negativbefund, und ein Abschnitt "Bewusst nicht gemacht".

Korrigiert gegenueber dem vorherigen Stand: die CI-Zeile nannte die Laeufe nur als laufend. 210 ist durch, inklusive "The distribution works as a fresh instance" - der setup-instance-Replay war der einzige Check, der lokal nicht lief. 211 (release) lief ebenfalls gruen und hat korrekt nichts veroeffentlicht: neuester Tag/Release bleibt v4.7.4, weil 4.8.0-beta.12 ein Kandidat ist.

Alle sieben Akzeptanzkriterien abgehakt. Kriterium 4 uebererfuellt: der Export ist nicht nur in .md/.template frei von Issue-Nummern, sondern im gesamten Baum ausserhalb .py - .gitignore und tools/.coveragerc wurden von Hand mitgezogen, obwohl der Check sie nicht erfasst.

Nachtragen fuer spaeter, ohne eigenes Issue: der Check liest auch die instanzeigenen kb/CONVENTIONS.md und kb/<collection>/COLLECTION.md, weil ein Export sie als .template mitnimmt. Eine Instanz, die dort ihre eigene Ticket-Nummer zitiert, bekommt ein neues Finding. Steht im Body unter "Bewusst nicht gemacht" und im CHANGES.md-Eintrag.

**Changelog:** Abschluss-Rewrite. Body steht auf dem Endstand, geschlossen mit `a51d7a3` (`4.8.0-beta.12`). Neu: die drei Entscheidungen als umgesetzt statt als Vorhaben formuliert, ein Abschnitt "Verifiziert" mit den tatsaechlichen Ergebnissen (CI 210 `verify` und 211 `release`, beide gruen), die `docs/`-Veralterungspruefung mit ihrem Negativbefund, und ein Abschnitt "Bewusst nicht gemacht". Korrigiert gegenueber dem vorherigen Stand: die CI-Zeile nannte die Laeufe nur als laufend. 210 ist durch, inklusive "The distribution works as a fresh instance" - der `setup-instance`-Replay war der einzige Check, der lokal nicht lief. 211 (`release`) lief ebenfalls gruen und hat korrekt **nichts** veroeffentlicht: neuester Tag/Release bleibt `v4.7.4`, weil `4.8.0-beta.12` ein Kandidat ist. Alle sieben Akzeptanzkriterien abgehakt. Kriterium 4 uebererfuellt: der Export ist nicht nur in `.md`/`.template` frei von Issue-Nummern, sondern im gesamten Baum ausserhalb `.py` - `.gitignore` und `tools/.coveragerc` wurden von Hand mitgezogen, obwohl der Check sie nicht erfasst. Nachtragen fuer spaeter, ohne eigenes Issue: der Check liest auch die instanzeigenen `kb/CONVENTIONS.md` und `kb/<collection>/COLLECTION.md`, weil ein Export sie als `.template` mitnimmt. Eine Instanz, die dort ihre eigene Ticket-Nummer zitiert, bekommt ein neues Finding. Steht im Body unter "Bewusst nicht gemacht" und im `CHANGES.md`-Eintrag.
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/distribution kind/defect prio/planned size/M
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#77
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?