Paket 2 aus #119 (D19/D32). Umgesetzt und publiziert als 3c9d669, Stack 6.2.0.
Warum
entity_type: project bezeichnete in diesem Korpus ausnahmslos Codebasen — andybalholm-edl, BCDModule, goresponsiveness, hacs-e3dc, ha-core, Chemenu selbst. kb/entities/COLLECTION.md sagte es bereits woertlich: „Codebases and initiatives". Die zweite
Haelfte — „initiatives" — zieht mit #119 D18 in einen eigenen Typ aus; uebrig bleibt exakt die
erste.
Solange beides project hiess, standen ein Artefakt („Chemenu") und ein Vorhaben
(„Chemenu 7.0 ausliefern") unter demselben Wort. Der Unterschied ist der ganze Punkt von #119.
Was gebaut wurde
Was
Von
Nach
Enum-Wert in types/entity.schema.yaml
project
codebase
layout:-Eintrag in types/entity.md
project: {dir: projects, title: Projekte}
codebase: {dir: codebases, title: Codebasen}
Verzeichnis
kb/entities/projects/
kb/entities/codebases/
11 Seiten
entity_type: project
entity_type: codebase
Das .template war keine eigene Datei zu pflegen: dist export schluesselt die
instanzeigenen Type-Specs beim Export selbst auf <stem>.md.template um
(dist_cmd._plan_types()), im Arbeitsbaum dieses Repos existiert nur die gelebte Datei. Gleiches
gilt fuer kb/entities/COLLECTION.md.
Der Katalogtitel „Codebasen" ist Anzeigetext und bleibt deutsch; der Enum-Wert und dir:
sind Identifier und sind englisch (types/type-spec.md § „Two languages").
Die Seiten wurden ausschliesslich ueber tools/wikitool bewegt — touch --set entity_type=codebase je Seite, dann ein move --reconcile, das alle elf umzog und das
geleerte kb/entities/projects/ entfernte. Kein Handgriff am Dateisystem; git protokolliert
alle elf als Rename mit 94–99 % Aehnlichkeit, womit auch belegt ist, dass keine Prosa
angefasst wurde.
Nach dem Umzug loest jede Referenz auf die elf Seiten weiterhin auf:lint meldet broken_links: []. Die Titel haben sich nicht geaendert, nur Verzeichnis und Frontmatter.
tools/wikitool lint meldet keinen neuen Befund: broken_links, misplaced_pages, nested_pages und duplicate_titles sind alle leer. Die verbliebenen see-also-Hinweise
sind vorbestehend und betreffen keine der elf Seiten.
kb/entities/COLLECTION.md beschreibt die Schublade als Codebasen; die Zeile nennt keine
Initiativen mehr. Die Bereichsbetonung („Projects — purpose, status, …") heisst jetzt
„Codebases".
tools/wikitool index rebuild erzeugt eine Katalogsektion „Codebasen" mit elf Seiten;
keine Sektion „Projekte" bleibt uebrig.
Der Versionsteil ist gegen instructions/dev/version-parts.md geprueft. Ergebnis: --minor, wie angenommen. Der Drop-in-Test haelt in beiden Richtungen, und die
Begruendung ist praeziser als die Erstannahme: types/entity.md und .schema.yaml sind .template-basierte Dateien, und dist upgrade schreibt eine solche Datei nie —
es legt nur das aktualisierte .template daneben (docs/ownership-and-templates.md
§ „The consequence in practice"). Eine bestehende Instanz behaelt ihren adoptierten project-Wert also unveraendert, ihre Seiten validieren weiter, und die Umbenennung ist
ein angebotener Standard statt einer erzwungenen Migration. Kein Betreiber-Handgriff,
keine Entscheidungsvorlage noetig.
Doc-Pull-Through
Ueber die oben gelisteten Dateien hinaus nachgezogen, weil sie eine Aussage ueber die
Subtyp-Vokabular machten, die mit diesem Paket falsch wurde:
types/entity.guidance.md — nannte den Subtyp beim Namen, und die Zeile „a software project,
an initiative or a piece of work" beschrieb genau die Zweideutigkeit, die D18 aufloest.
instructions/wiki-ingest/SKILL.md — das --set entity_type=<…>-Beispiel.
instructions/kb-profiles.md — der Collection-Profilkatalog fuer entities.
README.md — die Subtyp-Aufzaehlung unter „Entity Types".
kb/concepts/architectures/LLM Wiki Pattern.md und Three-Layer Architecture.md — beide
zaehlen die Entity-Subtypen in Prosa auf und waren damit ab dem Umzug schlicht falsch.
Punktweise Korrektur nach instructions/dev/corpus-policy.md Stufe 1.
tools/chemenu/tests/test_type_resolver.py, test_types_cmd.py — pinnen Enum und layout:
gegen das echte Schema und waren die drei einzigen roten Tests.
Bewusst nicht angefasst:test_git_publish.pys historische Pfadliste (Belegstueck eines
Laufs vom 2026-08-31, nicht Wegweiser) und die Gitea-#57-Regressionstests in test_lint.py, test_kb_scan.py, test_index_build.py, test_page_ops.py — deren Docstrings beschreiben die
damals real vorhandenen kb/entities/projects/<owner>/*.md-Seiten, und ihr Fixture-Wert project bleibt funktional korrekt, weil subtype_dir() fuer einen nicht gelisteten Subtyp auf
die Pluralisierung des eigenen Namens zurueckfaellt.
Korpus
instructions/dev/corpus-policy.md eingehalten: der Lauf setzte Frontmatter und Ablage um und
fasste keine Prosa der elf Seiten an. Die Subtyp-Untergrenze („jeder deklarierte Subtyp hat ≥1
Seite") haelt unveraendert — elf Seiten unter codebase, Null unter einem Wert, den es nicht
mehr gibt.
CHANGES.md, VERSION (6.1.0 → 6.2.0), sowie die generierten kb/index.md und kb/entities/INDEX.md
Abhaengigkeiten
Keine. Der Name project ist jetzt frei fuer den Vorhaben-Typ aus #123.
Paket 2 aus #119 (D19/D32). **Umgesetzt und publiziert** als `3c9d669`, Stack `6.2.0`.
## Warum
`entity_type: project` bezeichnete in diesem Korpus ausnahmslos **Codebasen** —
`andybalholm-edl`, `BCDModule`, `goresponsiveness`, `hacs-e3dc`, `ha-core`, Chemenu selbst.
`kb/entities/COLLECTION.md` sagte es bereits woertlich: *„Codebases and initiatives"*. Die zweite
Haelfte — „initiatives" — zieht mit #119 D18 in einen eigenen Typ aus; uebrig bleibt exakt die
erste.
Solange beides `project` hiess, standen ein **Artefakt** („Chemenu") und ein **Vorhaben**
(„Chemenu 7.0 ausliefern") unter demselben Wort. Der Unterschied ist der ganze Punkt von #119.
## Was gebaut wurde
| Was | Von | Nach |
|---|---|---|
| Enum-Wert in `types/entity.schema.yaml` | `project` | `codebase` |
| `layout:`-Eintrag in `types/entity.md` | `project: {dir: projects, title: Projekte}` | `codebase: {dir: codebases, title: Codebasen}` |
| Verzeichnis | `kb/entities/projects/` | `kb/entities/codebases/` |
| 11 Seiten | `entity_type: project` | `entity_type: codebase` |
Das `.template` war **keine eigene Datei zu pflegen**: `dist export` schluesselt die
instanzeigenen Type-Specs beim Export selbst auf `<stem>.md.template` um
(`dist_cmd._plan_types()`), im Arbeitsbaum dieses Repos existiert nur die gelebte Datei. Gleiches
gilt fuer `kb/entities/COLLECTION.md`.
Der Katalogtitel „Codebasen" ist **Anzeigetext** und bleibt deutsch; der Enum-Wert und `dir:`
sind Identifier und sind englisch (`types/type-spec.md` § „Two languages").
## Akzeptanzkriterien
- [x] `tools/wikitool search --field entity_type=project` liefert **null** Treffer;
`--field entity_type=codebase` liefert **elf**.
- [x] **Die Seiten wurden ausschliesslich ueber `tools/wikitool` bewegt** — `touch --set
entity_type=codebase` je Seite, dann ein `move --reconcile`, das alle elf umzog und das
geleerte `kb/entities/projects/` entfernte. Kein Handgriff am Dateisystem; git protokolliert
alle elf als Rename mit 94–99 % Aehnlichkeit, womit auch belegt ist, dass keine Prosa
angefasst wurde.
- [x] **Nach dem Umzug loest jede Referenz auf die elf Seiten weiterhin auf:** `lint` meldet
`broken_links: []`. Die Titel haben sich nicht geaendert, nur Verzeichnis und Frontmatter.
- [x] `tools/wikitool lint` meldet **keinen** neuen Befund: `broken_links`, `misplaced_pages`,
`nested_pages` und `duplicate_titles` sind alle leer. Die verbliebenen `see-also`-Hinweise
sind vorbestehend und betreffen keine der elf Seiten.
- [x] `kb/entities/COLLECTION.md` beschreibt die Schublade als Codebasen; die Zeile nennt keine
Initiativen mehr. Die Bereichsbetonung („**Projects** — purpose, status, …") heisst jetzt
„**Codebases**".
- [x] `tools/wikitool index rebuild` erzeugt eine Katalogsektion „Codebasen" mit elf Seiten;
keine Sektion „Projekte" bleibt uebrig.
- [x] `tools/wikitool docs verify` und `tools/wikitool instructions verify` gruen, `pytest` gruen
(1314 Tests).
- [x] Der Versionsteil ist gegen `instructions/dev/version-parts.md` geprueft. **Ergebnis:
`--minor`, wie angenommen.** Der Drop-in-Test haelt in beiden Richtungen, und die
Begruendung ist praeziser als die Erstannahme: `types/entity.md` und `.schema.yaml` sind
`.template`-basierte Dateien, und `dist upgrade` schreibt eine solche Datei **nie** —
es legt nur das aktualisierte `.template` daneben (`docs/ownership-and-templates.md`
§ „The consequence in practice"). Eine bestehende Instanz behaelt ihren adoptierten
`project`-Wert also unveraendert, ihre Seiten validieren weiter, und die Umbenennung ist
ein *angebotener* Standard statt einer erzwungenen Migration. Kein Betreiber-Handgriff,
keine Entscheidungsvorlage noetig.
## Doc-Pull-Through
Ueber die oben gelisteten Dateien hinaus nachgezogen, weil sie eine Aussage ueber die
Subtyp-Vokabular machten, die mit diesem Paket falsch wurde:
- `types/entity.guidance.md` — nannte den Subtyp beim Namen, und die Zeile „a software project,
an initiative or a piece of work" beschrieb genau die Zweideutigkeit, die D18 aufloest.
- `instructions/wiki-ingest/SKILL.md` — das `--set entity_type=<…>`-Beispiel.
- `instructions/kb-profiles.md` — der Collection-Profilkatalog fuer `entities`.
- `README.md` — die Subtyp-Aufzaehlung unter „Entity Types".
- `kb/concepts/architectures/LLM Wiki Pattern.md` und `Three-Layer Architecture.md` — beide
zaehlen die Entity-Subtypen in Prosa auf und waren damit ab dem Umzug schlicht falsch.
Punktweise Korrektur nach `instructions/dev/corpus-policy.md` Stufe 1.
- `tools/chemenu/tests/test_type_resolver.py`, `test_types_cmd.py` — pinnen Enum und `layout:`
gegen das echte Schema und waren die drei einzigen roten Tests.
**Bewusst nicht angefasst:** `test_git_publish.py`s historische Pfadliste (Belegstueck eines
Laufs vom 2026-08-31, nicht Wegweiser) und die Gitea-#57-Regressionstests in `test_lint.py`,
`test_kb_scan.py`, `test_index_build.py`, `test_page_ops.py` — deren Docstrings beschreiben die
damals real vorhandenen `kb/entities/projects/<owner>/*.md`-Seiten, und ihr Fixture-Wert
`project` bleibt funktional korrekt, weil `subtype_dir()` fuer einen nicht gelisteten Subtyp auf
die Pluralisierung des eigenen Namens zurueckfaellt.
## Korpus
`instructions/dev/corpus-policy.md` eingehalten: der Lauf setzte Frontmatter und Ablage um und
fasste keine Prosa der elf Seiten an. Die Subtyp-Untergrenze („jeder deklarierte Subtyp hat ≥1
Seite") haelt unveraendert — elf Seiten unter `codebase`, Null unter einem Wert, den es nicht
mehr gibt.
## Beruehrte Dateien
- `types/entity.schema.yaml`, `types/entity.md`, `types/entity.guidance.md`
- `kb/entities/COLLECTION.md`
- 11 Seiten von `kb/entities/projects/` nach `kb/entities/codebases/`
- `instructions/wiki-ingest/SKILL.md`, `instructions/kb-profiles.md`, `README.md`
- `kb/concepts/architectures/LLM Wiki Pattern.md`, `Three-Layer Architecture.md`
- `tools/chemenu/tests/test_type_resolver.py`, `test_types_cmd.py`
- `CHANGES.md`, `VERSION` (6.1.0 → 6.2.0), sowie die generierten `kb/index.md` und
`kb/entities/INDEX.md`
## Abhaengigkeiten
Keine. Der Name `project` ist jetzt frei fuer den Vorhaben-Typ aus #123.
Changelog: Body auf Endzustand umgeschrieben. Umgesetzt und publiziert (3c9d669, Stack 6.2.0): Enum und layout: in types/entity.md/.schema.yaml fuehren codebase, die elf Seiten liegen unter kb/entities/codebases/ und wurden ausschliesslich ueber touch --set plus move --reconcile bewegt (git protokolliert alle elf als Rename, 94–99 %). Alle acht Akzeptanzkriterien erfuellt; search --field entity_type=project liefert „No matches", =codebase elf Treffer, lint meldet leere broken_links/misplaced_pages/nested_pages/duplicate_titles, pytest (1314), docs verify und instructions verify gruen.
Praezisiert gegenueber der Erstannahme: --minor haelt, aber nicht ueber upstream merge — der fuehrt types/ gar nicht als Content-Stage — sondern weil types/entity.md.template-basiert ist und dist upgrade eine solche Datei nie schreibt, sondern nur das .template daneben legt. Eine adoptierte Instanz behaelt ihren project-Wert, die Umbenennung ist ein angebotener Standard. Kein Betreiber-Handgriff, keine Entscheidungsvorlage noetig.
Neu im Body: ein Abschnitt Doc-Pull-Through, der auch die bewusst nicht angefassten Stellen benennt (historische Pfadliste in test_git_publish.py, die Gitea-#57-Regressionstests, deren Fixture-Wert project ueber den Pluralisierungs-Fallback in subtype_dir() funktional korrekt bleibt). Die im urspruenglichen Body erwartete .template-Pflege entfaellt: dist export schluesselt die Type-Specs beim Export selbst um, im Arbeitsbaum existiert nur die gelebte Datei.
**Changelog:** Body auf Endzustand umgeschrieben. Umgesetzt und publiziert (`3c9d669`, Stack `6.2.0`): Enum und `layout:` in `types/entity.md`/`.schema.yaml` fuehren `codebase`, die elf Seiten liegen unter `kb/entities/codebases/` und wurden ausschliesslich ueber `touch --set` plus `move --reconcile` bewegt (git protokolliert alle elf als Rename, 94–99 %). Alle acht Akzeptanzkriterien erfuellt; `search --field entity_type=project` liefert „No matches", `=codebase` elf Treffer, `lint` meldet leere `broken_links`/`misplaced_pages`/`nested_pages`/`duplicate_titles`, `pytest` (1314), `docs verify` und `instructions verify` gruen.
Praezisiert gegenueber der Erstannahme: `--minor` haelt, aber nicht ueber `upstream merge` — der fuehrt `types/` gar nicht als Content-Stage — sondern weil `types/entity.md` `.template`-basiert ist und `dist upgrade` eine solche Datei nie schreibt, sondern nur das `.template` daneben legt. Eine adoptierte Instanz behaelt ihren `project`-Wert, die Umbenennung ist ein angebotener Standard. Kein Betreiber-Handgriff, keine Entscheidungsvorlage noetig.
Neu im Body: ein Abschnitt Doc-Pull-Through, der auch die bewusst **nicht** angefassten Stellen benennt (historische Pfadliste in `test_git_publish.py`, die Gitea-#57-Regressionstests, deren Fixture-Wert `project` ueber den Pluralisierungs-Fallback in `subtype_dir()` funktional korrekt bleibt). Die im urspruenglichen Body erwartete `.template`-Pflege entfaellt: `dist export` schluesselt die Type-Specs beim Export selbst um, im Arbeitsbaum existiert nur die gelebte Datei.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Paket 2 aus #119 (D19/D32). Umgesetzt und publiziert als
3c9d669, Stack6.2.0.Warum
entity_type: projectbezeichnete in diesem Korpus ausnahmslos Codebasen —andybalholm-edl,BCDModule,goresponsiveness,hacs-e3dc,ha-core, Chemenu selbst.kb/entities/COLLECTION.mdsagte es bereits woertlich: „Codebases and initiatives". Die zweiteHaelfte — „initiatives" — zieht mit #119 D18 in einen eigenen Typ aus; uebrig bleibt exakt die
erste.
Solange beides
projecthiess, standen ein Artefakt („Chemenu") und ein Vorhaben(„Chemenu 7.0 ausliefern") unter demselben Wort. Der Unterschied ist der ganze Punkt von #119.
Was gebaut wurde
types/entity.schema.yamlprojectcodebaselayout:-Eintrag intypes/entity.mdproject: {dir: projects, title: Projekte}codebase: {dir: codebases, title: Codebasen}kb/entities/projects/kb/entities/codebases/entity_type: projectentity_type: codebaseDas
.templatewar keine eigene Datei zu pflegen:dist exportschluesselt dieinstanzeigenen Type-Specs beim Export selbst auf
<stem>.md.templateum(
dist_cmd._plan_types()), im Arbeitsbaum dieses Repos existiert nur die gelebte Datei. Gleichesgilt fuer
kb/entities/COLLECTION.md.Der Katalogtitel „Codebasen" ist Anzeigetext und bleibt deutsch; der Enum-Wert und
dir:sind Identifier und sind englisch (
types/type-spec.md§ „Two languages").Akzeptanzkriterien
tools/wikitool search --field entity_type=projectliefert null Treffer;--field entity_type=codebaseliefert elf.tools/wikitoolbewegt —touch --set entity_type=codebaseje Seite, dann einmove --reconcile, das alle elf umzog und dasgeleerte
kb/entities/projects/entfernte. Kein Handgriff am Dateisystem; git protokolliertalle elf als Rename mit 94–99 % Aehnlichkeit, womit auch belegt ist, dass keine Prosa
angefasst wurde.
lintmeldetbroken_links: []. Die Titel haben sich nicht geaendert, nur Verzeichnis und Frontmatter.tools/wikitool lintmeldet keinen neuen Befund:broken_links,misplaced_pages,nested_pagesundduplicate_titlessind alle leer. Die verbliebenensee-also-Hinweisesind vorbestehend und betreffen keine der elf Seiten.
kb/entities/COLLECTION.mdbeschreibt die Schublade als Codebasen; die Zeile nennt keineInitiativen mehr. Die Bereichsbetonung („Projects — purpose, status, …") heisst jetzt
„Codebases".
tools/wikitool index rebuilderzeugt eine Katalogsektion „Codebasen" mit elf Seiten;keine Sektion „Projekte" bleibt uebrig.
tools/wikitool docs verifyundtools/wikitool instructions verifygruen,pytestgruen(1314 Tests).
instructions/dev/version-parts.mdgeprueft. Ergebnis:--minor, wie angenommen. Der Drop-in-Test haelt in beiden Richtungen, und dieBegruendung ist praeziser als die Erstannahme:
types/entity.mdund.schema.yamlsind.template-basierte Dateien, unddist upgradeschreibt eine solche Datei nie —es legt nur das aktualisierte
.templatedaneben (docs/ownership-and-templates.md§ „The consequence in practice"). Eine bestehende Instanz behaelt ihren adoptierten
project-Wert also unveraendert, ihre Seiten validieren weiter, und die Umbenennung istein angebotener Standard statt einer erzwungenen Migration. Kein Betreiber-Handgriff,
keine Entscheidungsvorlage noetig.
Doc-Pull-Through
Ueber die oben gelisteten Dateien hinaus nachgezogen, weil sie eine Aussage ueber die
Subtyp-Vokabular machten, die mit diesem Paket falsch wurde:
types/entity.guidance.md— nannte den Subtyp beim Namen, und die Zeile „a software project,an initiative or a piece of work" beschrieb genau die Zweideutigkeit, die D18 aufloest.
instructions/wiki-ingest/SKILL.md— das--set entity_type=<…>-Beispiel.instructions/kb-profiles.md— der Collection-Profilkatalog fuerentities.README.md— die Subtyp-Aufzaehlung unter „Entity Types".kb/concepts/architectures/LLM Wiki Pattern.mdundThree-Layer Architecture.md— beidezaehlen die Entity-Subtypen in Prosa auf und waren damit ab dem Umzug schlicht falsch.
Punktweise Korrektur nach
instructions/dev/corpus-policy.mdStufe 1.tools/chemenu/tests/test_type_resolver.py,test_types_cmd.py— pinnen Enum undlayout:gegen das echte Schema und waren die drei einzigen roten Tests.
Bewusst nicht angefasst:
test_git_publish.pys historische Pfadliste (Belegstueck einesLaufs vom 2026-08-31, nicht Wegweiser) und die Gitea-#57-Regressionstests in
test_lint.py,test_kb_scan.py,test_index_build.py,test_page_ops.py— deren Docstrings beschreiben diedamals real vorhandenen
kb/entities/projects/<owner>/*.md-Seiten, und ihr Fixture-Wertprojectbleibt funktional korrekt, weilsubtype_dir()fuer einen nicht gelisteten Subtyp aufdie Pluralisierung des eigenen Namens zurueckfaellt.
Korpus
instructions/dev/corpus-policy.mdeingehalten: der Lauf setzte Frontmatter und Ablage um undfasste keine Prosa der elf Seiten an. Die Subtyp-Untergrenze („jeder deklarierte Subtyp hat ≥1
Seite") haelt unveraendert — elf Seiten unter
codebase, Null unter einem Wert, den es nichtmehr gibt.
Beruehrte Dateien
types/entity.schema.yaml,types/entity.md,types/entity.guidance.mdkb/entities/COLLECTION.mdkb/entities/projects/nachkb/entities/codebases/instructions/wiki-ingest/SKILL.md,instructions/kb-profiles.md,README.mdkb/concepts/architectures/LLM Wiki Pattern.md,Three-Layer Architecture.mdtools/chemenu/tests/test_type_resolver.py,test_types_cmd.pyCHANGES.md,VERSION(6.1.0 → 6.2.0), sowie die generiertenkb/index.mdundkb/entities/INDEX.mdAbhaengigkeiten
Keine. Der Name
projectist jetzt frei fuer den Vorhaben-Typ aus #123.Changelog: Body auf Endzustand umgeschrieben. Umgesetzt und publiziert (
3c9d669, Stack6.2.0): Enum undlayout:intypes/entity.md/.schema.yamlfuehrencodebase, die elf Seiten liegen unterkb/entities/codebases/und wurden ausschliesslich uebertouch --setplusmove --reconcilebewegt (git protokolliert alle elf als Rename, 94–99 %). Alle acht Akzeptanzkriterien erfuellt;search --field entity_type=projectliefert „No matches",=codebaseelf Treffer,lintmeldet leerebroken_links/misplaced_pages/nested_pages/duplicate_titles,pytest(1314),docs verifyundinstructions verifygruen.Praezisiert gegenueber der Erstannahme:
--minorhaelt, aber nicht ueberupstream merge— der fuehrttypes/gar nicht als Content-Stage — sondern weiltypes/entity.md.template-basiert ist unddist upgradeeine solche Datei nie schreibt, sondern nur das.templatedaneben legt. Eine adoptierte Instanz behaelt ihrenproject-Wert, die Umbenennung ist ein angebotener Standard. Kein Betreiber-Handgriff, keine Entscheidungsvorlage noetig.Neu im Body: ein Abschnitt Doc-Pull-Through, der auch die bewusst nicht angefassten Stellen benennt (historische Pfadliste in
test_git_publish.py, die Gitea-#57-Regressionstests, deren Fixture-Wertprojectueber den Pluralisierungs-Fallback insubtype_dir()funktional korrekt bleibt). Die im urspruenglichen Body erwartete.template-Pflege entfaellt:dist exportschluesselt die Type-Specs beim Export selbst um, im Arbeitsbaum existiert nur die gelebte Datei.