33 Releases 33 Tags

RSS Feed

• v6.0.0 5d26698cd0

  Compare

  v6.0.0 Stable

  torben released this 2026-09-15 19:38:53 +00:00 | 0 commits to main since this release

  6.0.0 - 2026-09-15 - search: Pfad und Titel vollstaendig, Trunkierung sichtbar

  Author: Torben Nehmer

  Breaking Change:

  • docs verify loest ab dieser Version jeden relativen Markdown-Link in den Referenzdateien auf und meldet ein totes Ziel als Fehler - auch in kb/CONVENTIONS.md und kb//COLLECTION.md, die eine Instanz selbst besitzt und die ein Drop-in-Copy der Maschinerie nicht ersetzt. Eine Instanz, deren eigene Konventions- oder Collection-Datei einen relativen Link mit falscher ../-Tiefe oder auf eine inzwischen geloeschte Datei traegt, sieht docs verify nach dem Update fehlschlagen, wo es vorher durchlief. Reparatur: den in der Meldung genannten Datei:Zeile-Link korrigieren - kein Werkzeuglauf, keine Inhaltsmigration.
  • docs verify prueft die TOC-Region ab dieser Version auch auf types/.md und docs/.md. Eine Instanz, die die Page-Type-Spec-Templates adoptiert hat, traegt types/source.md und types/concept.md ohne Region und sieht docs verify nach dem Update fehlschlagen, wo es vorher durchlief; dasselbe gilt fuer eine selbst angelegte oder lokal geaenderte docs/-Seite ueber 100 Zeilen. Reparatur: tools/wikitool docs toc --apply - ein Werkzeuglauf, keine Inhaltsmigration.

  Migration: none required - Keine kb/-Seite aendert ihre Form. Der Grenzuebertritt ist ein strengerer Check auf instanz-eigener Prosa, keine Schema- oder Frontmatteraenderung.

  High impact

  • SKILL.md: relative Links durch repo-root-relative Pfade ersetzt, docs verify/instructions verify pruefen Linkziele
  • docs verify: der Linkziel-Check erreicht auch die instanz-eigenen kb/CONVENTIONS.md und COLLECTION.md - daher Grenzuebertritt
  • TOC-Scope auf types/ und docs/ erweitert, Sprachregeln zentralisiert, --breaking akkumuliert
  • types/: Seiten-Type-Spec-Anleitungsprosa in stackeigene guidance-Datei ausgelagert

  Medium impact

  • docs verify: ein nur als .template ausgeliefertes Linkziel gilt als aufgeloest
  • Control-Plane-Sprache universell: Achse ist das Publikum, kein Instanz-Schalter
  • types/type-spec.schema.yaml enforced against real type-spec frontmatter
  • search: Pfad und Titel vollstaendig, Trunkierung sichtbar

  Low impact

  • gates.md/session-setup.md: die Budget-Ausnahme von version regrade haengt an der Aufrufform
  • types/type-spec.md: Ownership und Sprache getrennt benannt (Nachzug zu #99)

  Ausgangspunkt war ein realer Bruch: instructions sync kopiert jede SKILL.md in eine andere
  Verzeichnistiefe, und 52 von 58 relativen Links darin zeigten in der publizierten Kopie ins Leere,
  unbemerkt, weil kein Check je ein Linkziel gelesen hat. Die Reparatur - repo-root-relative Pfade
  statt ../-Links - zieht zwei neue mechanische Checks nach sich (instructions verify verbietet
  relative Links in SKILL.md, docs verify loest Linkziele in allen Referenzdateien auf), und der
  zweite Check erreicht auch instanz-eigene Prosa (kb/CONVENTIONS.md, COLLECTION.md), die ein
  Drop-in-Copy nicht ersetzt - der Grenzuebertritt, der diesen Kandidaten auf 6.0.0 eskaliert hat.
  Denselben Linkziel-Check bekommt die TOC-Pflicht gleich mit auf types/ und docs/ erweitert, und
  die Sprachregeln fuer die Control-Plane sind zu einer einzigen, publikumsbasierten Regel in
  AGENTS.md zentralisiert statt eines Instanz-Schalters. Daneben, unabhaengig vom Linkproblem: die
  Seiten-Type-Spec-Anleitungsprosa ist in eine stackeigene Guidance-Datei ausgelagert,
  type-spec.schema.yaml wird jetzt gegen echte Type-Spec-Frontmatter durchgesetzt, und search
  zeigt Pfad und Titel eines Treffers vollstaendig statt trunkiert.

  gates.md/session-setup.md: die Budget-Ausnahme von version regrade haengt an der Aufrufform

  Doku-Nachzug zu 5.1.0. Beide Dateien beschrieben die Budget-Ausnahme als feste Liste pro
  Kommandoname ("fixed allowlist"); version regrade ist die erste Ausnahme, die nur in einer
  Aufrufform liest - bar listet sie, mit Positionen schreibt sie CHANGES.md. Die Liste selbst
  bleibt an ihrem einen Ort (tools/CONTRACT.md), beide Stellen benennen jetzt aber, dass dort ein
  Eintrag pro Aufruf statt pro Namen gilt. Aufgefallen in der Schlussphase derselben Arbeit, deshalb
  ein eigener Patch-Bump: der Pfad instructions/ liegt im Version-Gate der CI.

  SKILL.md: relative Links durch repo-root-relative Pfade ersetzt, docs verify/instructions verify pruefen Linkziele

  instructions sync kopiert jede SKILL.md byteidentisch in .agents/skills/ und
  .claude/skills/ - eine andere Verzeichnistiefe als die Quelle, ohne deren Nachbardateien. 52 von
  58 relativen Markdown-Links in den sieben Skills zeigten deshalb in der publizierten Kopie ins
  Leere, unbemerkt, weil kein Check je ein Linkziel gelesen hat (Gitea-Meldung: ein session-setup.md-Read
  schlug in einer ausgelieferten Instanz fehl). Alle 58 Links sind jetzt repo-root-relative
  Klartextpfade (instructions/session-setup.md statt [session-setup.md](../session-setup.md)) -
  sie ueberleben die Kopie unveraendert, weil sie nicht von der Position der lesenden Datei abhaengen.
  instructions/CONTRACT.md § "A skill's outbound reference is a plain path, not a link" traegt die
  Regel.

  Zwei neue mechanische Checks verhindern das Wiederauftreten: instructions verify verbietet jeden
  relativen Markdown-Link in einer SKILL.md (check_skill_reference_paths), docs verify loest
  jeden relativen Link in den flachen Instructions und Contracts gegen den Arbeitsbaum auf
  (check_reference_targets, ueber denselben Dateisatz wie docs toc). Nebenbei behoben:
  instructions/dev/doc-pull-through.md hatte zwei Links mit falscher ../-Tiefe, unabhaengig vom
  Skill-Copy-Problem.

  docs verify: der Linkziel-Check erreicht auch die instanz-eigenen kb/CONVENTIONS.md und COLLECTION.md - daher Grenzuebertritt

  Nachtraegliche Neueinstufung des Bumps darueber, kein zusaetzlicher Code. check_reference_targets
  laeuft ueber den Dateisatz von docs toc, und fuenf Dateien darin gehoeren der Instanz statt dem
  Stack: kb/CONVENTIONS.md und die vier kb/<collection>/COLLECTION.md. Ein Drop-in-Copy von
  tools/, types/, instructions/ und AGENTS.md ersetzt sie nicht - ein toter relativer Link
  darin laesst docs verify nach dem Update fehlschlagen, wo es vorher durchlief. Genau die Form,
  die tools/README.md § Adding a command Schritt 5 als MAJOR-Zeile benennt ("a stricter check that
  newly fails on shipped content an instance already had"), und instructions/dev/version-parts.md
  entscheidet den Zweifelsfall zugunsten des Grenzuebertritts.

  Gemessen bricht heute nichts: die zweite bekannte Instanz traegt 25 relative Links in diesen fuenf
  Dateien, davon null tote; dieses Repo ebenso. Die Einstufung folgt der Reichweite des Checks, nicht
  einem beobachteten Schaden - der Preis einer unnoetigen MAJOR ist eine Release-Notiz, der Preis
  einer MINOR, die doch bricht, ist eine Instanz mit fehlschlagendem Update-Pfad unter einer
  Versionsnummer, die Drop-in versprochen hat. Aufgefallen ist es in der Schlussphase beim Lesen der
  eigenen Regel in tools/README.md, nicht durch einen Check - was docs/version-model.md ueber
  genau diese Stelle sagt ("a person looking at the diff ... not a validator"), hat sich hier
  wiederholt.

  docs verify: ein nur als .template ausgeliefertes Linkziel gilt als aufgeloest

  Defektbehebung am Check aus den beiden Bumps darueber, gefunden unmittelbar nach deren Publish.
  check_reference_targets meldete auf einem frisch exportierten Baum 13 tote Links - kb/CONTRACT.md
  neunmal, dazu german-terminology.md, kb-profiles.md und link-taxonomy.md - und zwar dafuer,
  dass der Export tut, was er soll. kb/CONVENTIONS.md und die vier kb/<name>/COLLECTION.md sind
  instanz-eigen: die Distribution traegt <name>.template, und die Instanz uebernimmt sie erst im
  Personalisierungsschritt von instructions/setup-instance.md durch Umbenennen. Zwischen
  dist export und diesem Schritt existiert die fertige Datei berechtigterweise nicht, waehrend die
  stack-eigenen Dateien sie unter ihrem kuenftigen Namen verlinken - korrekt, denn so wird sie heissen.

  Ein Linkziel gilt jetzt auch dann als aufgeloest, wenn daneben <ziel>.template liegt. Die
  Ausnahme ist eng: fehlt beides, bleibt es ein Befund. Damit beschreibt der Check nicht laenger
  "noch nicht personalisiert" als "kaputter Link" - diesen Zustand meldet doctor unter
  conventions praezise und zustaendig.

  CI war davon nie rot: der Replay in .gitea/workflows/ci.yml uebernimmt die Templates, bevor er
  docs verify aufruft, und der dokumentierte Weg in setup-instance.md stellt die Personalisierung
  (Schritt 5/6) ebenfalls vor die Verifikation (Schritt 13). Getroffen haette es jeden, der nach dem
  Export einmal zur Kontrolle docs verify aufruft. Aufgefallen ist es, weil die Verifikation des
  vorherigen Publishes den Arbeitsbaum geprueft hatte und nicht den exportierten - ausgerechnet bei
  einer Aenderung, deren ganzer Gegenstand Kopien in anderer Verzeichnistiefe sind.

  TOC-Scope auf types/ und docs/ erweitert, Sprachregeln zentralisiert, --breaking akkumuliert

  Drei Straenge, ausgeloest von einer Beobachtung: manche agentengeladene Referenzdatei trug keine
  TOC, und manche Instruction war teilweise deutsch.

  TOC-Scope. Die Pflicht aus 5.0.0 galt fuer AGENTS.md, die Stage-Contracts,
  kb/CONVENTIONS.md, jede COLLECTION.md und die flache instructions/**.md-Form. docs/ und die
  Seiten-Type-Specs fielen ohne genannten Grund heraus - waehrend SKILL.md und die Menschendoku
  ihren Ausschlussgrund im Docstring stehen hatten, was die beiden anderen Luecken wie Absicht
  aussehen liess. docs/ ist dabei genau der Fall, fuer den die Schwelle existiert:
  AGENTS.md § File naming fuehrt es als agentengeladen per Link, also am zweiten Hop. Beide sind
  jetzt drin; vier Dateien haben eine Region bekommen. SKILL.md bleibt die eine Ausnahme, und
  zwar belegt statt behauptet: die vendorte Guidance setzt den SKILL.md-Body auf die Ladeebene, die
  beim Triggern ganz gelesen wird, und richtet ihren eigenen TOC-Rat an die gebuendelten
  Referenzdateien daneben. Ein Type-Spec wird zwar auch ganz geladen, aber eben auch als Datei
  gelesen - deshalb traegt es eine Region, und types describe strippt sie aus seiner Ausgabe, weil
  dort der ganze Body ohnehin mitkommt.

  Sprache. Die Regel gab es schon ("the control plane stays English"), sie stand nur in
  kb/CONVENTIONS.md - einer Datei, die der Instanz gehoert und die sie umschreiben darf, waehrend
  die Regel stackeigene Dateien bindet. Sie ist nach AGENTS.md § File naming gezogen, zusammen mit
  einer zweiten, die vorher gar nicht geschrieben stand: ein Agent spricht die KB-Sprache der
  Instanz. Der Wert dafuer lebt weiter in kb/CONVENTIONS.mds language:; SOUL.mds eigene
  Sprache:-Zeile war damit eine Dublette und ist weg. instructions/setup-instance.md - 297 Zeilen,
  die einzige vollstaendig deutsche Instruction, verbatim an jede Instanz ausgeliefert - ist
  uebersetzt, samt description:. Die zwei deutschen Blockquotes in den Dev-Skills sind es auch; sie
  lesen sich jetzt als englisches Modell der Nachricht, die der Agent in der KB-Sprache ausspricht.

  Dieselbe Regel gilt fuer alles, was als Template ausgeliefert wird - eine Instanz adoptiert es,
  bevor sie ihre Sprache ueberhaupt gewaehlt hat. USER.md.template, SOUL.md.template und
  ENVIRONMENT.md.template waren vollstaendig deutsch und sind uebersetzt; kb/sources/ und
  kb/concepts/COLLECTION.md waren es in Teilen und ziehen jetzt mit kb/entities/ und
  kb/comparisons/ gleich, die es laengst waren. Bei den vier Seiten-Type-Specs laeuft der Schnitt
  mitten durch die Datei, und zwar entlang derselben Prosa/Identifier-Grenze, die kb/CONTRACT.md
  schon innerhalb einer Seite zieht: die Anleitungsprosa ist Anweisung an einen Agenten und damit
  Control Plane, der ## Template-Block und die layout:-Titel sind Seitentext und bleiben in der
  KB-Sprache - wikitool new entity scaffoldet also weiter deutsche Ueberschriften.
  kb/CONVENTIONS.md behauptete bis hierher, die Type-Specs folgten als Ganzes der KB-Sprache; der
  Satz ist auf den tatsaechlichen Schnitt nachgezogen.
  Mechanisch geprueft wird nichts davon: ein Stoppwort-Scan schluege auf dem zitierten Vokabular in
  kb-profiles.md und link-taxonomy.md falsch an. Stattdessen nennen
  instructions/CONTRACT.md § "Writing an instruction" und stack-dev die Regel an der Stelle, an
  der sie befolgt oder verloren wird.

  --breaking akkumuliert. Bis hierher ersetzte ein zweites --breaking die Zeile des
  Kandidaten - der Eintrag versprach dann einen Bruch und lieferte zwei. Genau dieser Kandidat ist der
  Fall: sein Linkziel-Uebertritt aus beta.1 und der TOC-Uebertritt von hier sind zwei Dinge, auf die
  ein Betreiber getrennt reagieren muss. Eine Begruendung bleibt flach auf der Markerzeile, ab der
  zweiten werden es Bullets; eine vor dieser Aenderung geschriebene Einzelzeile liest sich unveraendert
  als Ein-Element-Liste zurueck, also musste kein bestehender Eintrag angefasst werden. --migration:
  bleibt bewusst eine Einzelzeile - sie beantwortet eine Ja/Nein-Frage ueber den Kandidaten als Ganzes,
  und --migration-required ist ihr Ruecknahmepfad. Fuer eine falsche Breaking-Begruendung gibt es
  keinen; der Kandidat ist bis zum Release dev-lokal.

  Nebenbefund, den die Scope-Erweiterung sofort aufgedeckt hat: docs/version-model.md verlinkte nach
  instructions/dev/version-parts.md, das dist export wegschneidet - im Ursprungs-Repo gruen, in
  jeder ausgelieferten Instanz ein toter Link. Jetzt ein Klartextpfad mit dem Satz, warum er keiner
  ist.

  types/type-spec.md: Ownership und Sprache getrennt benannt (Nachzug zu #99)

  types/type-spec.md sagte weiterhin, Prosa, ## Template-Body und Sprache eines
  Seiten-Type-Specs gehoerten der Instanz, die bei anderer KB-Sprache "einfach die Datei
  uebersetzt" - genau das Gegenteil des Schnitts, den der Bump davor ausgeliefert hat. Aufgefallen
  in der Schlussphase, beim Nachdenken darueber, welche Sprachregel fuer einen instanz-eigenen
  neuen Seitentyp gilt.

  Der Abschnitt trennt die zwei Fragen jetzt: Ownership sagt, wer eine Zeile aendern darf, die
  Sprache folgt davon unabhaengig dem Publikum der Zeile - Anleitungsprosa an einen Agenten ist
  Control Plane und englisch, ## Template-Body und layout:-Titel sind Seitentext in der
  KB-Sprache, Feldnamen und Enum-Werte sind Identifier und werden nie uebersetzt. Als Tabelle, weil
  der Schnitt mitten durch eine Datei laeuft und eine Aufzaehlung im Fliesstext ihn genau deshalb
  nicht haelt. Der Satz bindet ausdruecklich auch einen Type-Spec, den eine Instanz sich selbst
  schreibt: der ist zwar durchgaengig instanzeigen, aber seine Anleitungshaelfte hat trotzdem einen
  Agenten als Leser.

  Control-Plane-Sprache universell: Achse ist das Publikum, kein Instanz-Schalter

  Die Sprachregel in AGENTS.md ruhte auf einer Begruendung, die schmaler war als sie selbst:
  "Every file in the table above belongs to the stack and ships to instances that share none of
  this instance's language choices, so:". Das traegt nur fuer ausgeliefertes Material und laesst
  offen, was fuer ein Control-Plane-Dokument gilt, das eine Instanz nur fuer sich selbst schreibt -
  eine eigene Instruction, ein selbst angelegter Seitentyp (types/ nimmt einen ohne Code-Aenderung
  auf), ein weiterer Stage-Contract. Genau dort fallen Ownership und Publikum auseinander: die Datei
  ist durchgaengig instanzeigen, ihre Anleitungshaelfte hat trotzdem einen Agenten als Leser.

  Der Vorsatz nennt jetzt die tatsaechliche Achse - die For-Spalte der Tabelle darueber, also wer
  die Zeile liest, und weder wem die Datei gehoert noch ob sie den Checkout je verlaesst. Regel 1
  sagt ausdruecklich, dass sie auch fuer ein nie ausgeliefertes Control-Plane-Dokument gilt und dass
  es neben kb/CONVENTIONS.mds language: bewusst keinen zweiten Sprachwert gibt.
  kb/CONVENTIONS.md und ihr .template sagen dasselbe von ihrer Seite aus: die
  Control-Plane-Sprache ist keine Einstellung, die diese Datei zurueckhaelt - es ist gar keine.

  Die Begruendung dazu steht als neue docs/-Seite
  (docs/language-boundaries.md), weil sie sonst in einem Jahr neu
  verhandelt wird: warum Englisch (der Stack redet fast nur ueber Identifier, und die sind
  englisch), warum kein Parameter (die Kosten traegt jede Datei, den Nutzen haette ein Dokument, das
  ohnehin nur ein Agent liest), und was die Entscheidung wieder aufmachen wuerde. Die Seite haelt
  zugleich fest, welches Argument falsch war: "Sprache folgt der Ownership" hat funktioniert,
  solange nur ausgeliefertes Material betrachtet wurde, und faellt am instanz-eigenen Typ.

  Nebenbei zwei Befunde derselben Ecke behoben. Der Docstring von
  dist_cmd.instance_owned_type_stems() behauptete weiter, "its prose, its template and its
  language are the instance's business" - Stand vor dem TOC-/Sprach-Bump oben. Und die
  Aufzaehlung der docs/-Seiten in AGENTS.md sagte "Four pages exist today", waehrend das
  Verzeichnis fuenf trug: docs/model-and-effort-selection.md fehlte, und zwar absichtlich, weil
  ein Link dorthin die Claude-Code-eigene Entscheidung in die anderen drei Harnesses laden wuerde.
  Der Satz zaehlt jetzt, was von hier aus verlinkt ist, und benennt die sechste Seite samt Grund.

  types/: Seiten-Type-Spec-Anleitungsprosa in stackeigene guidance-Datei ausgelagert

  Ein root: kb Type-Spec (entity, concept, source, comparison) hatte zwei Publika in
  einer Datei: Anleitungsprosa fuer den Agenten (When to use/When NOT to use/Authoring guidance),
  und Seitenmaterial (## Template-Block, layout:-Titel). Ownership gilt pro Datei, also wurde
  die ganze Datei beim Setup als .template adoptiert und danach nie wieder angefasst - eine
  Instanz, die ihre Type-Specs frueh adoptiert hat, las bis in alle Zukunft die Anleitung vom Tag
  ihrer Erzeugung, weil dist upgrade das .template neben die adoptierte Datei schrieb, nie die
  Datei selbst (docs/ownership-and-templates.md § "Where the file boundary strains").

  Der urspruengliche Vorschlag drehte den Schnitt um (Type-Spec stackeigen, Seitenmaterial heraus)
  und wurde beim Pruefen gegen setup-instance.md und evolve-subtypes.md verworfen: die
  Frontmatter-Konfiguration (layout:, Enum-Werte, base_dir) ist instanzeigener Inhalt, keine
  Stack-Maschinerie - beide Instructions weisen die Instanz an, Enum und layout:-Eintrag in
  derselben Aenderung zu setzen. Stattdessen bleibt der Type-Spec instanzeigen, und nur die
  maschinenabgeleitete Anleitungsprosa zieht in eine neue, stackeigene types/<name>.guidance.md,
  verknuepft ueber ein optionales guidance:-Frontmatterfeld (neuer, nicht instanziierbarer Typ
  type-guidance, wie lint-report ohne base_dir:). tools/wikitool types describe <name>
  komponiert beide Haelften weiterhin zu einer Antwort - ein Agent muss nie wissen, dass ein Typ aus
  zwei Dateien besteht. type_resolver.extract_template() liest das Template unveraendert allein
  aus types/<name>.md; kein zweiter Ladepfad fuer wikitool new.

  dist_cmd._plan_types()/find_leaks() teilten sich vorher name.split(".", 1)[0] als
  Stamm-Berechnung - beides haette entity.guidance.md faelschlich als instanzeigenen Stamm
  "entity" erkannt (die eine haette sie zum .template gemacht, die andere sie als Leak gemeldet).
  Neuer gemeinsamer Prädikat _owned_type_stem() prueft die exakte Endung (<stem>.md oder
  <stem>.schema.yaml), nicht den ersten Punkt.

  Grenzuebertritt-Frage bewusst geprueft und verneint: Drop-in in beide Richtungen (ein Type-Spec
  ohne guidance: verhaelt sich unveraendert, eine alte Maschinerie liest types/<name>.md wie
  zuvor und die Guidance-Datei ist fuer sie inert), also --minor statt --major. Die einmalige
  Adoption in einer bestehenden Instanz ist als instructions/migrations/6.0.0-type-guidance-split.md
  dokumentiert - obligation: offered, der erste Gebrauch dieses seit 4.0.0 existierenden, bis jetzt
  unbenutzten Mechanismus fuer ein instanzeigenes, upgradebares Machinery-File.

  Verifiziert: tools/wikitool docs verify/instructions verify gruen, 1261 Tests gruen (8 neu:
  get_guidance, das Template bleibt auf types/<name>.md allein geladen, die Guidance-Datei
  schifft verbatim neben einem .template-adoptierten Type-Spec statt als weiteres .template,
  ein dist upgrade schreibt verbesserte Guidance-Prosa in eine adoptierte Instanz obwohl deren
  Type-Spec selbst nie im Stamp stand, types describe komponiert beide Haelften in JSON und
  Textausgabe getrennt nachweisbar).

  types/type-spec.schema.yaml enforced against real type-spec frontmatter

  Bei der Vorbereitung der Aenderung oben fiel auf: types/type-spec.schema.yaml traegt
  additionalProperties: false, kannte aber root: und capture_fields: nicht, obwohl
  types/instruction.md bzw. types/source.md beide Felder tragen und type_resolver.get_root()/
  get_capture_fields() sie lesen. Gegen das Schema validiert waeren beide Type-Specs ungueltig
  gewesen. Dass es niemandem auffiel, war der eigentliche Befund: Type-Spec-Frontmatter wurde
  nirgends gegen sein eigenes Schema validiert - resolver.validate_frontmatter() lief nur ueber
  kb/-Seiten, neu erzeugte Seiten und Instruktionsdateien, nie ueber die Type-Specs selbst.
  TypeResolver._validate_type_spec(), der einzige Weg, den der Selbstbezug type: types/type-spec.md
  nimmt, prueft ausschliesslich, ob type/name/description vorhanden sind.

  Beide fehlenden Felder ergaenzt (root: als Enum kb/repo, capture_fields: als Liste wie
  page_ref_fields:), dazu guidance: (seit der Aenderung oben real benutzt, aber noch nie im
  Schema). docs verify bekommt eine neue Pruefung: jede Datei unter types/ mit
  type: types/type-spec.md validiert jetzt gegen types/type-spec.schema.yaml
  (check_type_spec_frontmatter(), wiederverwendet resolver.list_type_specs() statt eines zweiten
  Parse-Durchlaufs). types/type-spec.md § Validation Contract und die beiden docs verify-Zeilen
  in tools/CONTRACT.md nennen das jetzt.

  Daneben ein zweiter, unabhaengiger Befund derselben Aufraeumrunde behoben:
  instructions/dev/doc-pull-through.md verwies fuer docs/-Seiten weiter auf "AGENTS.md § File
  naming lists all four" - der Zaehler in AGENTS.md selbst war beim vorigen Bump schon auf fuenf
  (plus eine sechste, nur von CLAUDE.md aus verlinkte) korrigiert worden, diese eine verbliebene
  Stelle nicht.

  Grenzuebertritt-Frage geprueft und verneint: additiv in beide Richtungen - eine bestehende Instanz
  validiert bereits (0 Befunde gegen den realen Baum), und ein Type-Spec ohne die drei neuen Felder
  bleibt unveraendert gueltig. --patch, kein --breaking, keine neue Migration noetig.

  Verifiziert: tools/wikitool docs verify/instructions verify gruen, 1263 Tests gruen (2 neu:
  alle Type-Specs dieses Repos validieren gegen ihr eigenes Schema; ein Type-Spec mit einem dem
  Schema unbekannten Feld wird gemeldet, mit Dateiname und Feldname in der Meldung).

  search: Pfad und Titel vollstaendig, Trunkierung sichtbar

  Gemeldet wurde eine Sitzung, die nach wikitool search zusaetzlich grep -rl ueber kb/
  laufen liess. Der Grep war redundant - search ist ein rg-Lauf ueber kb/ und kann keine
  Seite verfehlen, die ein Grep findet -, aber die Ausgabe gab ihr drei Gruende dafuer, und die
  sind der eigentliche Befund.

  Die Tabelle nannte keinen Pfad, obwohl wiki-query verlangt, nur die Seiten zu lesen, auf
  die die Suche zeigt. Sie kappte ausserdem den Titel auf 34 Zeichen - im gemeldeten
  Transkript vier von fuenf Treffern -, und der Titel ist nach Invariante 2 der einzige
  Identifier einer Seite und das Argument, das touch, xref add und cite add nehmen. Die
  Sitzung hatte also weder etwas zum Oeffnen noch etwas zum Weiterreichen; grep -rl lieferte
  genau beides.

  Drittens war N result(s). die gekappte Zahl: run_search gab nur die beschnittene Liste
  zurueck, also konnte kein Adapter die Gesamtzahl melden, und 20 result(s). auf einer Anfrage
  mit 182 Treffern war von einem vollstaendigen Ergebnis nicht zu unterscheiden. Eine
  Vollstaendigkeitsaussage, zu der die Ausgabe nicht berechtigt war - der staerkste denkbare
  Anlass, ihr zu misstrauen.

  Die Zeile hat jetzt die Form score | kind/subtype | titel | pfad | summary, ohne
  Spaltenauffuellung. Titel und Pfad werden nie gekappt; die Summary ist das einzige verlustige
  Feld und steht deshalb am Ende, wo ein | in Prosa beim Trennen mit maxsplit=4 folgenlos
  bleibt (ein | im Titel schliesst die Wikilink-Syntax ohnehin aus). JSON als Default-Ausgabe
  wurde erwogen und verworfen: ein Treffer ist flach, JSON kostet dafuer ein Vielfaches an Tokens,
  und search existiert dafuer, Retrieval billig zu machen - der Fehler war ein fehlendes Feld,
  kein Parse-Problem. Wer Struktur braucht, hat --json, api.search und MCP.

  run_search gibt jetzt ein SearchResult mit Treffern, Gesamtzahl und Limit zurueck. Die
  Tabelle schreibt 50 of 182 result(s) - raise --limit (0 for all) or narrow the query., das
  JSON traegt total/truncated/limit neben count, dessen Bedeutung unveraendert bleibt
  (len(results)), und api.search sowie der MCP-search-Tool tragen dieselben Felder. Das
  Default-Limit steigt von 20 auf 50 und liegt als eine Konstante DEFAULT_LIMIT statt als drei
  Literale in drei Adaptern: gekappt wurden bisher vor allem die strukturellen Sweeps
  (--field '!sources'), die alphabetisch und nicht nach Relevanz sortiert sind, wo die Kappung
  also eine beliebige Scheibe der Antwort wegwirft statt ihres schwaechsten Endes. Sichtbar zu
  sein ist es, was ein endliches Default ueberhaupt erst unbedenklich macht.

  AGENTS.md § Routing traegt die Regel an genau einer Stelle - search ist erschoepfend, ein
  eigener Grep ueber kb/ fuegt nur die generierten Dateien hinzu, die Invariante 1 ohnehin
  verbietet; tools/CONTRACT.md traegt daneben nur den Mechanismus.

  Grenzuebertritt-Frage geprueft und verneint: kein Flag entfernt oder umbenannt, keine
  Umgebungsvariable, keine maschinengelesene Datei in ihrer Form veraendert, JSON rein additiv.
  Die Tabelle liest ein Agent, kein Skript, und ihre Aenderung verlangt keiner Instanz Handarbeit
  ab.

  Verifiziert: docs verify/instructions verify gruen, 1272 Tests gruen (9 neu: Pfad vorhanden;
  Titel und Pfad ungekappt bei langem Titel; eine Trefferzeile zerfaellt trotz | in der Prosa in
  ihre fuenf Felder; ein gekapptes Ergebnis nennt die Gesamtzahl, ein ungekapptes behauptet
  nichts; --limit 0 gilt nie als gekappt; die Gesamtzahl ueberlebt das Limit in run_search;
  api.search meldet dasselbe; alle drei Adapter teilen ein Default-Limit - der MCP-Golden-Test
  haelt die neuen Felder zwischen CLI und Server zusammen).

  ---

  This note is a snapshot of the CHANGES.md entry as it stood when the tag was cut, and
  is never edited afterwards. The maintained version of this text - including any later
  correction - is the entry for this version in CHANGES.md in the repository.

  Downloads

  • chemenu-stack-6.0.0.tar.gz
    651 KiB

    2026-09-15 19:38:53 +00:00
  • chemenu-stack-6.0.0.tar.gz.sha256
    93 B

    2026-09-15 19:38:53 +00:00
  • Source Code (ZIP)
  • Source Code (TAR.GZ)