Behoben in 8.0.0-beta.39, Commit 662a844. Beide Skills zeigen xref add --a "<A>" --b "<B>" --rel "<label>". Verifiziert lokal (instructions verify, docs verify, pytest 2211 passed / 3 skipped, --dry-run des Skill-Aufrufs mit Exit 0) und durch CI auf diesem Commit: Lauf 537 (ci.yml, Jobs verify und pwsh) grün, Lauf 538 (release.yml) grün, ohne Release, wie für einen Kandidaten vorgesehen. Die mechanische Prüfung, die den Fehler früher gefunden hätte, ist #176.
Befund
Zwei ausgelieferte Skills zeigten xref add in einer Syntax, die das Werkzeug seit 4.0.0 nicht mehr kannte:
Das Werkzeug lehnte den Aufruf ab (No such option: --rel-a (Possible options: --a, --help, --rel)). xref add -h (8.0.0-beta.38): Synopsis wikitool xref add --a "<A>" --b "<B>" --rel <label> [--dry-run], "Declares one edge, A <label> B ... B is not touched and does not point back". Jede Sitzung, die einem der beiden Skills folgte, scheiterte an dieser Stelle und musste sich die Syntax aus -h holen. Aufgefallen bei einem Ingest in einer privaten Instanz (v7.0.0).
Ursache
git log -S'--rel-a': Die Optionen verschwanden aus dem Code mit 177c7e9 (4.0.0, Link-Taxonomie: xref add schreibt nur noch eine Kante statt beider Richtungen). Die beiden Skill-Stellen stammten unverändert aus 18ae28f (2.1.0) und wurden damals nicht mitgezogen.
instructions verify prüft Frontmatter, Links und Drift der publizierten Kopien. docs verify gleicht Flags nur für die SYNOPSIS der cli_contract-Records gegen die CLI ab (check_synopsis_flags()). Ob ein in einer Instruktion gezeigter Aufruf ausführbar ist, prüfte und prüft niemand - das ist #176.
Umfang
Ein Ad-hoc-Abgleich aller tools/wikitool <cmd> --flag-Vorkommen in instructions/**/*.md, AGENTS.md, */CONTRACT.md, kb/CONVENTIONS.md und kb/**/COLLECTION.md gegen die Optionen des Typer-Kommandobaums fand nur diese beiden Stellen (je --rel-a und --rel-b); alle anderen Treffer waren Fehlgriffe des Ad-hoc-Regex (Flags aus der Folgezeile bzw. aus einem zitierten String). grep über alle *.md außerhalb der generierten Skill-Kopien fand kein weiteres --rel-a/--rel-b, auch nicht in kb/. kb/CONTRACT.md:262 zeigte die Syntax bereits richtig.
Was gebaut wurde
instructions/wiki-ingest/SKILL.md Schritt 9: Die erste Zeile des Code-Blocks lautet
Der Satz unter dem Block sagt vor dem bestehenden Satz zu link-source: Die erste Zeile erklärt eine Kante, nur auf A; Leserichtung und wann die Gegenkante einen eigenen Aufruf verdient, stehen in kb/CONTRACT.md § Linking.
instructions/wiki-manage/SKILL.md "Creating a page" Schritt 6: dieselbe Zeile; der Satz darunter lautet "One per relationship, on A only; which way it reads, and when the reverse edge earns a call of its own, is kb/CONTRACT.md § Linking. Never hand-edit related:."
tools/wikitool instructions sync hat .claude/skills/ und .agents/skills/ nachgezogen.
CHANGES.md: Bump-Zeile (low impact) und Changeset unter 8.0.0-beta.39.
Entscheidungen
Verweisen statt wiederholen (Invariante 8). Die Regel "Satz [A] <label> [B] vor der Label-Wahl sagen; liest er sich nur rückwärts wahr, gehört die Kante auf die andere Seite" und "eine Gegenkante ist eine eigene Entscheidung, kein Spiegel" leben in kb/CONTRACT.md § Linking. Die Skills zeigen nur den Merkkommentar # [A] <label> [B] am Aufruf und verweisen auf den Abschnitt - als Pfad in Backticks, nicht als Markdown-Link, wie die Skills es durchgehend tun; ein relativer Link bräche in den publizierten Kopien unter .claude/skills/.
Verworfen: --rel-a/--rel-b als Alias wieder einführen - brächte die mit 4.0.0 bewusst abgeschaffte Doppelkante zurück.
Ausgelagert: die mechanische Prüfung dokumentierter tools/wikitool-Aufrufe gegen den Kommandobaum, auf Wunsch des Betreibers als eigenes Issue #176.
Versionsteil
--patch, --impact low. Reiner Textfix in ausgelieferten Skills, keine Schnittstellenänderung: Drop-in in beide Richtungen (version-parts.md Schritt 1 und 3). Auf dem laufenden Kandidaten hat das nur den Bump-Zähler erhöht: 8.0.0-beta.38 → 8.0.0-beta.39.
Abschlussprüfung (stack-close)
Kein Dokument musste nachgezogen werden: kb/CONTRACT.md § Linking und tools/README.md ("An edge is authored in one direction") beschrieben die gerichtete Kante bereits richtig; README.md, INSTALL.md, DEVELOPMENT.md, EVALS.md und docs/ enthalten keine Aussage über xref add-Flags; keine Installationsanleitung, kein Contract und keine Überschrift wurden berührt. Daher kein weiterer Bump und kein weiterer Publish.
Akzeptanzkriterien
grep -rn -e '--rel-a' -e '--rel-b' instructions/ .claude/skills/ .agents/skills/ findet nichts (Exit 1, keine Treffer).
Der xref add-Aufruf in beiden Skills benutzt genau die Optionen --a, --b, --rel, die tools/wikitool xref add -h listet, und trägt den Kommentar # [A] <label> [B]; der Text daneben verweist auf kb/CONTRACT.md § Linking, ohne die Gegenkanten-Regel selbst zu wiederholen.
Der Aufruf aus beiden Skills, mit zwei existierenden Seitentiteln und einem für das Collection-Paar autorisierten Label plus --dry-run ausgeführt, endet mit Exit 0: xref add --a "wikitool" --b "Semantic Lint Automation" --rel "implements" --dry-run → "already declares implements", Exit 0.
instructions verify, docs verify und pytest enden mit Exit 0 (pytest: 2211 passed, 3 skipped); die publizierten Kopien sind byte-gleich mit den Quellen (18 Kopien, laut instructions verify).
VERSION ist per version bump --patch --impact low auf 8.0.0-beta.39 weitergezählt, der Changeset in CHANGES.md beschreibt den Fix, und der CI-Lauf auf 662a844 ist grün (Läufe 537 und 538).
Dateien
instructions/wiki-ingest/SKILL.md (Schritt 9)
instructions/wiki-manage/SKILL.md ("Creating a page", Schritt 6)
VERSION, CHANGES.md (über version bump, Changeset von Hand)
## Ergebnis
Behoben in `8.0.0-beta.39`, Commit `662a844`. Beide Skills zeigen `xref add --a "<A>" --b "<B>" --rel "<label>"`. Verifiziert lokal (`instructions verify`, `docs verify`, `pytest` 2211 passed / 3 skipped, `--dry-run` des Skill-Aufrufs mit Exit 0) und durch CI auf diesem Commit: Lauf [537](https://gitea.nehmer.net/torben/chemenu/actions/runs/537) (`ci.yml`, Jobs `verify` und `pwsh`) grün, Lauf [538](https://gitea.nehmer.net/torben/chemenu/actions/runs/538) (`release.yml`) grün, ohne Release, wie für einen Kandidaten vorgesehen. Die mechanische Prüfung, die den Fehler früher gefunden hätte, ist #176.
## Befund
Zwei ausgelieferte Skills zeigten `xref add` in einer Syntax, die das Werkzeug seit 4.0.0 nicht mehr kannte:
- `instructions/wiki-ingest/SKILL.md:346` (Schritt 9 "Cross-reference")
- `instructions/wiki-manage/SKILL.md:59` (Abschnitt "Creating a page", Schritt 6 "Cross-reference")
jeweils:
tools/wikitool xref add --a "<A>" --b "<B>" --rel-a "<label>" --rel-b "<label>"
Das Werkzeug lehnte den Aufruf ab (`No such option: --rel-a (Possible options: --a, --help, --rel)`). `xref add -h` (8.0.0-beta.38): Synopsis `wikitool xref add --a "<A>" --b "<B>" --rel <label> [--dry-run]`, "Declares **one** edge, `A <label> B` ... B is not touched and does not point back". Jede Sitzung, die einem der beiden Skills folgte, scheiterte an dieser Stelle und musste sich die Syntax aus `-h` holen. Aufgefallen bei einem Ingest in einer privaten Instanz (v7.0.0).
## Ursache
- `git log -S'--rel-a'`: Die Optionen verschwanden aus dem Code mit `177c7e9` (4.0.0, Link-Taxonomie: `xref add` schreibt nur noch eine Kante statt beider Richtungen). Die beiden Skill-Stellen stammten unverändert aus `18ae28f` (2.1.0) und wurden damals nicht mitgezogen.
- `instructions verify` prüft Frontmatter, Links und Drift der publizierten Kopien. `docs verify` gleicht Flags nur für die SYNOPSIS der `cli_contract`-Records gegen die CLI ab (`check_synopsis_flags()`). Ob ein in einer Instruktion gezeigter Aufruf ausführbar ist, prüfte und prüft niemand - das ist #176.
## Umfang
Ein Ad-hoc-Abgleich aller `tools/wikitool <cmd> --flag`-Vorkommen in `instructions/**/*.md`, `AGENTS.md`, `*/CONTRACT.md`, `kb/CONVENTIONS.md` und `kb/**/COLLECTION.md` gegen die Optionen des Typer-Kommandobaums fand **nur diese beiden Stellen** (je `--rel-a` und `--rel-b`); alle anderen Treffer waren Fehlgriffe des Ad-hoc-Regex (Flags aus der Folgezeile bzw. aus einem zitierten String). `grep` über alle `*.md` außerhalb der generierten Skill-Kopien fand kein weiteres `--rel-a`/`--rel-b`, auch nicht in `kb/`. `kb/CONTRACT.md:262` zeigte die Syntax bereits richtig.
## Was gebaut wurde
1. **`instructions/wiki-ingest/SKILL.md` Schritt 9:** Die erste Zeile des Code-Blocks lautet
```
tools/wikitool xref add --a "<A>" --b "<B>" --rel "<label>" # [A] <label> [B]
```
Der Satz unter dem Block sagt vor dem bestehenden Satz zu `link-source`: Die erste Zeile erklärt eine Kante, nur auf A; Leserichtung und wann die Gegenkante einen eigenen Aufruf verdient, stehen in `kb/CONTRACT.md` § Linking.
2. **`instructions/wiki-manage/SKILL.md` "Creating a page" Schritt 6:** dieselbe Zeile; der Satz darunter lautet "One per relationship, on A only; which way it reads, and when the reverse edge earns a call of its own, is `kb/CONTRACT.md` § Linking. Never hand-edit `related:`."
3. `tools/wikitool instructions sync` hat `.claude/skills/` und `.agents/skills/` nachgezogen.
4. `CHANGES.md`: Bump-Zeile (low impact) und Changeset unter `8.0.0-beta.39`.
## Entscheidungen
- **Verweisen statt wiederholen (Invariante 8).** Die Regel "Satz `[A] <label> [B]` vor der Label-Wahl sagen; liest er sich nur rückwärts wahr, gehört die Kante auf die andere Seite" und "eine Gegenkante ist eine eigene Entscheidung, kein Spiegel" leben in `kb/CONTRACT.md` § Linking. Die Skills zeigen nur den Merkkommentar `# [A] <label> [B]` am Aufruf und verweisen auf den Abschnitt - als Pfad in Backticks, nicht als Markdown-Link, wie die Skills es durchgehend tun; ein relativer Link bräche in den publizierten Kopien unter `.claude/skills/`.
- **Verworfen: `--rel-a`/`--rel-b` als Alias wieder einführen** - brächte die mit 4.0.0 bewusst abgeschaffte Doppelkante zurück.
- **Ausgelagert:** die mechanische Prüfung dokumentierter `tools/wikitool`-Aufrufe gegen den Kommandobaum, auf Wunsch des Betreibers als eigenes Issue #176.
## Versionsteil
**`--patch`, `--impact low`.** Reiner Textfix in ausgelieferten Skills, keine Schnittstellenänderung: Drop-in in beide Richtungen (version-parts.md Schritt 1 und 3). Auf dem laufenden Kandidaten hat das nur den Bump-Zähler erhöht: `8.0.0-beta.38` → `8.0.0-beta.39`.
## Abschlussprüfung (stack-close)
Kein Dokument musste nachgezogen werden: `kb/CONTRACT.md` § Linking und `tools/README.md` ("An edge is authored in one direction") beschrieben die gerichtete Kante bereits richtig; `README.md`, `INSTALL.md`, `DEVELOPMENT.md`, `EVALS.md` und `docs/` enthalten keine Aussage über `xref add`-Flags; keine Installationsanleitung, kein Contract und keine Überschrift wurden berührt. Daher kein weiterer Bump und kein weiterer Publish.
## Akzeptanzkriterien
- [x] `grep -rn -e '--rel-a' -e '--rel-b' instructions/ .claude/skills/ .agents/skills/` findet nichts (Exit 1, keine Treffer).
- [x] Der `xref add`-Aufruf in beiden Skills benutzt genau die Optionen `--a`, `--b`, `--rel`, die `tools/wikitool xref add -h` listet, und trägt den Kommentar `# [A] <label> [B]`; der Text daneben verweist auf `kb/CONTRACT.md` § Linking, ohne die Gegenkanten-Regel selbst zu wiederholen.
- [x] Der Aufruf aus beiden Skills, mit zwei existierenden Seitentiteln und einem für das Collection-Paar autorisierten Label plus `--dry-run` ausgeführt, endet mit Exit 0: `xref add --a "wikitool" --b "Semantic Lint Automation" --rel "implements" --dry-run` → "already declares implements", Exit 0.
- [x] `instructions verify`, `docs verify` und `pytest` enden mit Exit 0 (pytest: 2211 passed, 3 skipped); die publizierten Kopien sind byte-gleich mit den Quellen (18 Kopien, laut `instructions verify`).
- [x] `VERSION` ist per `version bump --patch --impact low` auf `8.0.0-beta.39` weitergezählt, der Changeset in `CHANGES.md` beschreibt den Fix, und der CI-Lauf auf `662a844` ist grün (Läufe 537 und 538).
## Dateien
- `instructions/wiki-ingest/SKILL.md` (Schritt 9)
- `instructions/wiki-manage/SKILL.md` ("Creating a page", Schritt 6)
- generiert: `.claude/skills/wiki-ingest/`, `.claude/skills/wiki-manage/`, `.agents/skills/…` (über `instructions sync`)
- `VERSION`, `CHANGES.md` (über `version bump`, Changeset von Hand)
$ tools/wikitool xref add --a "A" --b "B" --rel-a "uses" --rel-b "used-by"
Usage: python -m chemenu.cli xref add [OPTIONS]
Try 'python -m chemenu.cli xref add --help' for help.
No such option: --rel-a (Possible options: --a, --help, --rel)
Laut xref add --help gilt: "Declare that A B. One edge, on A only." Es gibt genau eine
Option --rel; B wird nicht veraendert, seine eingehende Sicht wird aus dem Graphen gerendert.
Eine Sitzung, die dem Skill folgt, scheitert also an genau dieser Stelle und muss sich die
richtige Syntax aus --help holen.
Gemessen: v7.0.0 (Instanz) und aktueller main (beide Dateien, Zeilennummern oben von main;
in v7.0.0 steht die wiki-ingest-Stelle in Zeile 288). Angenommen, nicht geprueft: Die Syntax ist
seit der Umstellung auf gerichtete Kanten (4.0.0, link taxonomy) veraltet.
Ursache
Die Umstellung von xref add auf eine gerichtete Kante hat die Beispielaufrufe in den beiden
Skills nicht mitgezogen. instructions verify prueft Frontmatter, Links und Drift der
publizierten Kopien, aber nicht, ob ein dokumentierter wikitool-Aufruf zu den echten Optionen
passt.
Reproduktion
grep -rn "rel-a" instructions/
Den dort gezeigten Aufruf mit beliebigen Titeln ausfuehren -> No such option: --rel-a.
Loesungsvorschlag
Beide Stellen auf die gerichtete Form umstellen, mit dem Satz aus --help als Merkhilfe:
Optional, als eigenes Issue: instructions verify (oder ein Test) gleicht tools/wikitool ...
-Aufrufe in Code-Bloecken unter instructions/ mit den tatsaechlichen Optionen ab.
Verworfen: --rel-a/--rel-b als Alias wieder einfuehren - das wuerde die bewusst abgeschaffte
Doppelkante zurueckbringen.
Akzeptanzkriterien
Kein --rel-a/--rel-b mehr unter instructions/
Beide Skills zeigen xref add --a --b --rel mit Hinweis auf die Leserichtung
Aufgefallen bei einem Ingest in einer privaten Instanz (v7.0.0): der Aufruf aus Schritt 9
scheiterte mit No such option.
**Ausarbeitung des `status/incoming`-Stubs.** Der ursprüngliche Body, wörtlich:
> ## Befund
>
> Zwei Skills zeigen `xref add` in einer Syntax, die das Werkzeug nicht mehr kennt:
>
> - `instructions/wiki-ingest/SKILL.md:346` (Schritt 9 "Cross-reference")
> - `instructions/wiki-manage/SKILL.md:58`
>
> jeweils:
>
> tools/wikitool xref add --a "<A>" --b "<B>" --rel-a "<label>" --rel-b "<label>"
>
> Das Werkzeug lehnt den Aufruf ab:
>
> $ tools/wikitool xref add --a "A" --b "B" --rel-a "uses" --rel-b "used-by"
> Usage: python -m chemenu.cli xref add [OPTIONS]
> Try 'python -m chemenu.cli xref add --help' for help.
> No such option: --rel-a (Possible options: --a, --help, --rel)
>
> Laut `xref add --help` gilt: "Declare that A <rel> B. One edge, on A only." Es gibt genau eine
> Option `--rel`; B wird nicht veraendert, seine eingehende Sicht wird aus dem Graphen gerendert.
> Eine Sitzung, die dem Skill folgt, scheitert also an genau dieser Stelle und muss sich die
> richtige Syntax aus `--help` holen.
>
> Gemessen: v7.0.0 (Instanz) und aktueller `main` (beide Dateien, Zeilennummern oben von `main`;
> in v7.0.0 steht die wiki-ingest-Stelle in Zeile 288). Angenommen, nicht geprueft: Die Syntax ist
> seit der Umstellung auf gerichtete Kanten (4.0.0, link taxonomy) veraltet.
>
> ## Ursache
>
> Die Umstellung von `xref add` auf eine gerichtete Kante hat die Beispielaufrufe in den beiden
> Skills nicht mitgezogen. `instructions verify` prueft Frontmatter, Links und Drift der
> publizierten Kopien, aber nicht, ob ein dokumentierter `wikitool`-Aufruf zu den echten Optionen
> passt.
>
> ## Reproduktion
>
> 1. `grep -rn "rel-a" instructions/`
> 2. Den dort gezeigten Aufruf mit beliebigen Titeln ausfuehren -> `No such option: --rel-a`.
>
> ## Loesungsvorschlag
>
> Beide Stellen auf die gerichtete Form umstellen, mit dem Satz aus `--help` als Merkhilfe:
>
> tools/wikitool xref add --a "<A>" --b "<B>" --rel "<label>" # liest sich: [A] <label> [B]
>
> Optional, als eigenes Issue: `instructions verify` (oder ein Test) gleicht `tools/wikitool ...`
> -Aufrufe in Code-Bloecken unter `instructions/` mit den tatsaechlichen Optionen ab.
>
> Verworfen: `--rel-a`/`--rel-b` als Alias wieder einfuehren - das wuerde die bewusst abgeschaffte
> Doppelkante zurueckbringen.
>
> ## Akzeptanzkriterien
>
> - [ ] Kein `--rel-a`/`--rel-b` mehr unter `instructions/`
> - [ ] Beide Skills zeigen `xref add --a --b --rel` mit Hinweis auf die Leserichtung
> - [ ] `instructions sync`, `instructions verify`, `docs verify`, `pytest` sauber
>
> ## Herkunft
>
> Aufgefallen bei einem Ingest in einer privaten Instanz (v7.0.0): der Aufruf aus Schritt 9
> scheiterte mit `No such option`.
Changelog: Stub gegen den Baum geprüft und ausgearbeitet. Bestätigt: Optionen verschwanden mit 177c7e9 (4.0.0), Skill-Stellen unverändert seit 2.1.0; ein Ad-hoc-Abgleich aller dokumentierten wikitool-Aufrufe fand keine weiteren veralteten Flags. Zeilennummer wiki-manage korrigiert (58 → 59). Neu entschieden: Skills verweisen für Leserichtung und Gegenkanten auf kb/CONTRACT.md § Linking statt die Regel zu wiederholen. Mechanische Prüfung aus dem Paket genommen (Folge-Issue ist Betreiberentscheidung). Versionsteil --patch --impact low. Akzeptanzkriterien als prüfbare Eigenschaften neu gefasst. Labels: area/workflow → area/kb (Skills zum Betrieb der Wissensbasis, nicht Git/Publish), kind/defect → kind/build, prio/planned ergänzt, status/incoming entfernt.
**Changelog:** Stub gegen den Baum geprüft und ausgearbeitet. Bestätigt: Optionen verschwanden mit `177c7e9` (4.0.0), Skill-Stellen unverändert seit 2.1.0; ein Ad-hoc-Abgleich aller dokumentierten `wikitool`-Aufrufe fand keine weiteren veralteten Flags. Zeilennummer wiki-manage korrigiert (58 → 59). Neu entschieden: Skills verweisen für Leserichtung und Gegenkanten auf `kb/CONTRACT.md` § Linking statt die Regel zu wiederholen. Mechanische Prüfung aus dem Paket genommen (Folge-Issue ist Betreiberentscheidung). Versionsteil `--patch --impact low`. Akzeptanzkriterien als prüfbare Eigenschaften neu gefasst. Labels: `area/workflow` → `area/kb` (Skills zum Betrieb der Wissensbasis, nicht Git/Publish), `kind/defect` → `kind/build`, `prio/planned` ergänzt, `status/incoming` entfernt.
Changelog: Gebaut und publiziert als 8.0.0-beta.39 (662a844). Beide Skills zeigen jetzt xref add --a --b --rel mit dem Kommentar # [A] <label> [B] und verweisen auf kb/CONTRACT.md § Linking. Alle fünf Akzeptanzkriterien sind abgehakt, CI-Läufe 537 und 538 grün. „Was gebaut wird“ ist jetzt „Was gebaut wurde“; das Folge-Issue #176 ist verlinkt.
**Changelog:** Gebaut und publiziert als `8.0.0-beta.39` (`662a844`). Beide Skills zeigen jetzt `xref add --a --b --rel` mit dem Kommentar `# [A] <label> [B]` und verweisen auf `kb/CONTRACT.md` § Linking. Alle fünf Akzeptanzkriterien sind abgehakt, CI-Läufe 537 und 538 grün. „Was gebaut wird“ ist jetzt „Was gebaut wurde“; das Folge-Issue #176 ist verlinkt.
Changelog: Abschluss. Der Body ist im Endzustand: „Stand“ heißt jetzt „Ergebnis“, Befund und Ursache stehen in der Vergangenheit, neu ist der Abschnitt „Abschlussprüfung“. Kein Dokument war veraltet, daher kein weiterer Bump und kein weiterer Publish. Geschlossen.
**Changelog:** Abschluss. Der Body ist im Endzustand: „Stand“ heißt jetzt „Ergebnis“, Befund und Ursache stehen in der Vergangenheit, neu ist der Abschnitt „Abschlussprüfung“. Kein Dokument war veraltet, daher kein weiterer Bump und kein weiterer Publish. Geschlossen.
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.
Ergebnis
Behoben in
8.0.0-beta.39, Commit662a844. Beide Skills zeigenxref add --a "<A>" --b "<B>" --rel "<label>". Verifiziert lokal (instructions verify,docs verify,pytest2211 passed / 3 skipped,--dry-rundes Skill-Aufrufs mit Exit 0) und durch CI auf diesem Commit: Lauf 537 (ci.yml, Jobsverifyundpwsh) grün, Lauf 538 (release.yml) grün, ohne Release, wie für einen Kandidaten vorgesehen. Die mechanische Prüfung, die den Fehler früher gefunden hätte, ist #176.Befund
Zwei ausgelieferte Skills zeigten
xref addin einer Syntax, die das Werkzeug seit 4.0.0 nicht mehr kannte:instructions/wiki-ingest/SKILL.md:346(Schritt 9 "Cross-reference")instructions/wiki-manage/SKILL.md:59(Abschnitt "Creating a page", Schritt 6 "Cross-reference")jeweils:
Das Werkzeug lehnte den Aufruf ab (
No such option: --rel-a (Possible options: --a, --help, --rel)).xref add -h(8.0.0-beta.38): Synopsiswikitool xref add --a "<A>" --b "<B>" --rel <label> [--dry-run], "Declares one edge,A <label> B... B is not touched and does not point back". Jede Sitzung, die einem der beiden Skills folgte, scheiterte an dieser Stelle und musste sich die Syntax aus-hholen. Aufgefallen bei einem Ingest in einer privaten Instanz (v7.0.0).Ursache
git log -S'--rel-a': Die Optionen verschwanden aus dem Code mit177c7e9(4.0.0, Link-Taxonomie:xref addschreibt nur noch eine Kante statt beider Richtungen). Die beiden Skill-Stellen stammten unverändert aus18ae28f(2.1.0) und wurden damals nicht mitgezogen.instructions verifyprüft Frontmatter, Links und Drift der publizierten Kopien.docs verifygleicht Flags nur für die SYNOPSIS dercli_contract-Records gegen die CLI ab (check_synopsis_flags()). Ob ein in einer Instruktion gezeigter Aufruf ausführbar ist, prüfte und prüft niemand - das ist #176.Umfang
Ein Ad-hoc-Abgleich aller
tools/wikitool <cmd> --flag-Vorkommen ininstructions/**/*.md,AGENTS.md,*/CONTRACT.md,kb/CONVENTIONS.mdundkb/**/COLLECTION.mdgegen die Optionen des Typer-Kommandobaums fand nur diese beiden Stellen (je--rel-aund--rel-b); alle anderen Treffer waren Fehlgriffe des Ad-hoc-Regex (Flags aus der Folgezeile bzw. aus einem zitierten String).grepüber alle*.mdaußerhalb der generierten Skill-Kopien fand kein weiteres--rel-a/--rel-b, auch nicht inkb/.kb/CONTRACT.md:262zeigte die Syntax bereits richtig.Was gebaut wurde
instructions/wiki-ingest/SKILL.mdSchritt 9: Die erste Zeile des Code-Blocks lautetlink-source: Die erste Zeile erklärt eine Kante, nur auf A; Leserichtung und wann die Gegenkante einen eigenen Aufruf verdient, stehen inkb/CONTRACT.md§ Linking.instructions/wiki-manage/SKILL.md"Creating a page" Schritt 6: dieselbe Zeile; der Satz darunter lautet "One per relationship, on A only; which way it reads, and when the reverse edge earns a call of its own, iskb/CONTRACT.md§ Linking. Never hand-editrelated:."tools/wikitool instructions synchat.claude/skills/und.agents/skills/nachgezogen.CHANGES.md: Bump-Zeile (low impact) und Changeset unter8.0.0-beta.39.Entscheidungen
[A] <label> [B]vor der Label-Wahl sagen; liest er sich nur rückwärts wahr, gehört die Kante auf die andere Seite" und "eine Gegenkante ist eine eigene Entscheidung, kein Spiegel" leben inkb/CONTRACT.md§ Linking. Die Skills zeigen nur den Merkkommentar# [A] <label> [B]am Aufruf und verweisen auf den Abschnitt - als Pfad in Backticks, nicht als Markdown-Link, wie die Skills es durchgehend tun; ein relativer Link bräche in den publizierten Kopien unter.claude/skills/.--rel-a/--rel-bals Alias wieder einführen - brächte die mit 4.0.0 bewusst abgeschaffte Doppelkante zurück.tools/wikitool-Aufrufe gegen den Kommandobaum, auf Wunsch des Betreibers als eigenes Issue #176.Versionsteil
--patch,--impact low. Reiner Textfix in ausgelieferten Skills, keine Schnittstellenänderung: Drop-in in beide Richtungen (version-parts.md Schritt 1 und 3). Auf dem laufenden Kandidaten hat das nur den Bump-Zähler erhöht:8.0.0-beta.38→8.0.0-beta.39.Abschlussprüfung (stack-close)
Kein Dokument musste nachgezogen werden:
kb/CONTRACT.md§ Linking undtools/README.md("An edge is authored in one direction") beschrieben die gerichtete Kante bereits richtig;README.md,INSTALL.md,DEVELOPMENT.md,EVALS.mdunddocs/enthalten keine Aussage überxref add-Flags; keine Installationsanleitung, kein Contract und keine Überschrift wurden berührt. Daher kein weiterer Bump und kein weiterer Publish.Akzeptanzkriterien
grep -rn -e '--rel-a' -e '--rel-b' instructions/ .claude/skills/ .agents/skills/findet nichts (Exit 1, keine Treffer).xref add-Aufruf in beiden Skills benutzt genau die Optionen--a,--b,--rel, dietools/wikitool xref add -hlistet, und trägt den Kommentar# [A] <label> [B]; der Text daneben verweist aufkb/CONTRACT.md§ Linking, ohne die Gegenkanten-Regel selbst zu wiederholen.--dry-runausgeführt, endet mit Exit 0:xref add --a "wikitool" --b "Semantic Lint Automation" --rel "implements" --dry-run→ "already declares implements", Exit 0.instructions verify,docs verifyundpytestenden mit Exit 0 (pytest: 2211 passed, 3 skipped); die publizierten Kopien sind byte-gleich mit den Quellen (18 Kopien, lautinstructions verify).VERSIONist perversion bump --patch --impact lowauf8.0.0-beta.39weitergezählt, der Changeset inCHANGES.mdbeschreibt den Fix, und der CI-Lauf auf662a844ist grün (Läufe 537 und 538).Dateien
instructions/wiki-ingest/SKILL.md(Schritt 9)instructions/wiki-manage/SKILL.md("Creating a page", Schritt 6).claude/skills/wiki-ingest/,.claude/skills/wiki-manage/,.agents/skills/…(überinstructions sync)VERSION,CHANGES.md(überversion bump, Changeset von Hand)Ausarbeitung des
status/incoming-Stubs. Der ursprüngliche Body, wörtlich:Changelog: Stub gegen den Baum geprüft und ausgearbeitet. Bestätigt: Optionen verschwanden mit
177c7e9(4.0.0), Skill-Stellen unverändert seit 2.1.0; ein Ad-hoc-Abgleich aller dokumentiertenwikitool-Aufrufe fand keine weiteren veralteten Flags. Zeilennummer wiki-manage korrigiert (58 → 59). Neu entschieden: Skills verweisen für Leserichtung und Gegenkanten aufkb/CONTRACT.md§ Linking statt die Regel zu wiederholen. Mechanische Prüfung aus dem Paket genommen (Folge-Issue ist Betreiberentscheidung). Versionsteil--patch --impact low. Akzeptanzkriterien als prüfbare Eigenschaften neu gefasst. Labels:area/workflow→area/kb(Skills zum Betrieb der Wissensbasis, nicht Git/Publish),kind/defect→kind/build,prio/plannedergänzt,status/incomingentfernt.Changelog: Gebaut und publiziert als
8.0.0-beta.39(662a844). Beide Skills zeigen jetztxref add --a --b --relmit dem Kommentar# [A] <label> [B]und verweisen aufkb/CONTRACT.md§ Linking. Alle fünf Akzeptanzkriterien sind abgehakt, CI-Läufe 537 und 538 grün. „Was gebaut wird“ ist jetzt „Was gebaut wurde“; das Folge-Issue #176 ist verlinkt.Changelog: Abschluss. Der Body ist im Endzustand: „Stand“ heißt jetzt „Ergebnis“, Befund und Ursache stehen in der Vergangenheit, neu ist der Abschnitt „Abschlussprüfung“. Kein Dokument war veraltet, daher kein weiterer Bump und kein weiterer Publish. Geschlossen.