Korpusmigration: confidence und confidence_base aus 152 Seiten entfernen #86

Closed
opened 2026-09-10 15:11:52 +00:00 by torben · 2 comments
Owner

Erledigt. confidence und confidence_base sind aus allen 152 betroffenen Seiten entfernt. Publiziert als 54d9540 auf main, gemeinsam mit dem Stack-Teil (#60); CI-Lauf 219 grün über alle neun Schritte.

.wikitool-kb.json steht auf kb_version: 5.0.0, Migration 5.0.0-confidence-removal mit 152 Seiten am 2026-09-10 verzeichnet.

Umfang

182 Seiten unter kb/, davon 152 mit beiden Feldern — ausschließlich Typen entity und concept. Source- und Comparison-Seiten trugen sie nie und wurden nicht angefasst.

Shape-Change im Sinne von instructions/migrate-corpus.md: nichts gelernt, nichts umformuliert, zwei Schlüssel gefallen. Kein Body angefasst.

Die Invariante — gehalten

Jede Seite unterscheidet sich von ihrem Vorzustand in genau zwei entfernten Frontmatter-Schlüsseln und in nichts sonst. Mechanisch bestätigt durch migrate verify --from HEAD --fail-on-error je Einheit: 0 Befunde über alle vier Läufe, für Wikilink- und Zitatzählungen, Fußnotendefinitionen, H1 und Strukturfelder. Stichprobe im Diff bestätigt das Bild: git diff --stat zeigt für jede der 152 Seiten exakt 2 --, keine Einfügung.

  • modified: unverändert — das Skript benutzt write_page direkt, nie touch (das bedingungslos bumpen würde).
  • Body byte-identisch: read_page gibt den Text nach dem schließenden --- verbatim zurück, write_page schreibt ihn unverändert zurück. Vorab an einer echten Seite als Round-Trip geprüft — und dabei ein Defekt gefunden, siehe unten.
  • Referenzarrays unverändert in Inhalt und Reihenfolge.
  • Feldreihenfolge bleibt der Schema-Reihenfolge treu: zwei Schlüssel aus einem geordneten Dict zu poppen ordnet die übrigen nicht um.
  • Keine ungetrackte oder gitignorierte Datei angefasst.

Vorab gefunden: die Round-Trip-Probe schlug zunächst fehl — nicht wegen dieser Migration, sondern weil der Stack-Teil (#60) den Float-Zweig aus frontmatter_io._format_scalar entfernt hatte. Ohne ihn wären unberührte Float-Felder als quotierte Strings zurückgeschrieben worden. Behoben in #60, bevor eine einzige Seite angefasst wurde. Genau der Fehlermodus, den migrate-corpus.md beschreibt: der Korpus wäre in sich konsistent geblieben, und lint hätte nichts gemeldet.

Ablauf, wie gelaufen

Workshop work/confidence-removal/ (plan.md, README.md, strip_confidence.py), vier Einheiten entlang bestehender Area-Verzeichnisse, je eigene WIKITOOL_SESSION_ID:

Einheit Verzeichnisse Seiten migrate verify
u1 concepts/architectures, decisions, protocols, problems 35 0 Befunde
u2 concepts/patterns, workflows 45 0 Befunde
u3 entities/tools, people 35 0 Befunde
u4 entities/technologies, projects, systems 37 0 Befunde

--from HEAD war für alle vier exakt: der Branch hatte kb/ bis dahin nicht angefasst, der Stack-Teil liegt vollständig in tools/, types/, instructions/ und den Verträgen.

Das Skript lief über chemenu.frontmatter_io.read_page/write_page — die eigene I/O-Schicht des Stacks, nicht von Hand und nicht durch einen Subagenten. Es ist mit dem Workshop gelöscht; die dauerhafte Ausgabe ist der bereinigte Korpus.

Erledigter Punkt: migrate verify

Zu klären, ob migrate verify eine deklarierte Feldentfernung kennt. Beantwortet und bestätigt: confidence_base stand in corpus_diff.STRUCTURAL_FIELDS und wurde dort von #60 gestrichen; confidence stand nie drin. migrate verify vergleicht das Feld danach nicht mehr und meldete seine Entfernung folglich in keiner der vier Einheiten. Keine Ausnahmeregel, keine Abschwächung an anderer Stelle — für alles Übrige blieb der Check unverändert scharf.

Ein bewusst stehengelassener Treffer

kb/concepts/patterns/Confidence Scoring.md enthält weiterhin confidence: 0.XX — innerhalb eines ```yaml-Codeblocks im Body, als Illustration des Patterns, über das die Seite handelt. Das ist Inhalt über einen Mechanismus fremder Systeme, kein Frontmatter-Feld dieser Seite; ihr eigenes Frontmatter wurde in u2 bereinigt. Body-unberührt war Scope dieser Migration, und diese Seite ist der Grund, das explizit festzuhalten.

Akzeptanzkriterien

  • Keine Datei unter kb/ enthält confidence: oder confidence_base: als Frontmatter-Schlüssel (der Body-Treffer oben ist benannt und gewollt)
  • Für jede geänderte Seite: modified: identisch zum Vorzustand
  • Für jede geänderte Seite: Body byte-identisch zum Vorzustand
  • Für jede geänderte Seite: related:, sources:, entities:, concepts: identisch in Inhalt und Reihenfolge
  • git status zeigte ausschließlich die erwarteten kb/-Seiten plus kb/index.md, die Area-Shards und kb/log.md
  • migrate verify lief pro Einheit ohne Befund durch (4 × 0)
  • wikitool lint meldet keine Frontmatter- oder Schemafehler (schema_validation_errors: 0)
  • wikitool doctor grün
  • .wikitool-kb.json steht auf 5.0.0
  • Der work/-Run ist nach work/CONTRACT.md geschlossen: Checkliste abgearbeitet, log append --op update in kb/log.md, Verzeichnis gelöscht
**Erledigt.** `confidence` und `confidence_base` sind aus allen 152 betroffenen Seiten entfernt. Publiziert als `54d9540` auf `main`, gemeinsam mit dem Stack-Teil (#60); CI-Lauf **219** grün über alle neun Schritte. `.wikitool-kb.json` steht auf `kb_version: 5.0.0`, Migration `5.0.0-confidence-removal` mit 152 Seiten am 2026-09-10 verzeichnet. ## Umfang 182 Seiten unter `kb/`, davon 152 mit beiden Feldern — ausschließlich Typen `entity` und `concept`. Source- und Comparison-Seiten trugen sie nie und wurden nicht angefasst. Shape-Change im Sinne von `instructions/migrate-corpus.md`: nichts gelernt, nichts umformuliert, zwei Schlüssel gefallen. Kein Body angefasst. ## Die Invariante — gehalten Jede Seite unterscheidet sich von ihrem Vorzustand in genau zwei entfernten Frontmatter-Schlüsseln und in nichts sonst. Mechanisch bestätigt durch `migrate verify --from HEAD --fail-on-error` je Einheit: **0 Befunde** über alle vier Läufe, für Wikilink- und Zitatzählungen, Fußnotendefinitionen, H1 und Strukturfelder. Stichprobe im Diff bestätigt das Bild: `git diff --stat` zeigt für jede der 152 Seiten exakt `2 --`, keine Einfügung. - `modified:` unverändert — das Skript benutzt `write_page` direkt, nie `touch` (das bedingungslos bumpen würde). - Body byte-identisch: `read_page` gibt den Text nach dem schließenden `---` verbatim zurück, `write_page` schreibt ihn unverändert zurück. Vorab an einer echten Seite als Round-Trip geprüft — und dabei ein Defekt gefunden, siehe unten. - Referenzarrays unverändert in Inhalt und Reihenfolge. - Feldreihenfolge bleibt der Schema-Reihenfolge treu: zwei Schlüssel aus einem geordneten Dict zu poppen ordnet die übrigen nicht um. - Keine ungetrackte oder gitignorierte Datei angefasst. **Vorab gefunden:** die Round-Trip-Probe schlug zunächst fehl — nicht wegen dieser Migration, sondern weil der Stack-Teil (#60) den Float-Zweig aus `frontmatter_io._format_scalar` entfernt hatte. Ohne ihn wären unberührte Float-Felder als quotierte Strings zurückgeschrieben worden. Behoben in #60, bevor eine einzige Seite angefasst wurde. Genau der Fehlermodus, den `migrate-corpus.md` beschreibt: der Korpus wäre in sich konsistent geblieben, und `lint` hätte nichts gemeldet. ## Ablauf, wie gelaufen Workshop `work/confidence-removal/` (`plan.md`, `README.md`, `strip_confidence.py`), vier Einheiten entlang bestehender Area-Verzeichnisse, je eigene `WIKITOOL_SESSION_ID`: | Einheit | Verzeichnisse | Seiten | `migrate verify` | |---|---|---|---| | u1 | `concepts/architectures`, `decisions`, `protocols`, `problems` | 35 | 0 Befunde | | u2 | `concepts/patterns`, `workflows` | 45 | 0 Befunde | | u3 | `entities/tools`, `people` | 35 | 0 Befunde | | u4 | `entities/technologies`, `projects`, `systems` | 37 | 0 Befunde | `--from HEAD` war für alle vier exakt: der Branch hatte `kb/` bis dahin nicht angefasst, der Stack-Teil liegt vollständig in `tools/`, `types/`, `instructions/` und den Verträgen. Das Skript lief über `chemenu.frontmatter_io.read_page`/`write_page` — die eigene I/O-Schicht des Stacks, nicht von Hand und nicht durch einen Subagenten. Es ist mit dem Workshop gelöscht; die dauerhafte Ausgabe ist der bereinigte Korpus. ## Erledigter Punkt: `migrate verify` ~~Zu klären, ob `migrate verify` eine deklarierte Feldentfernung kennt.~~ **Beantwortet und bestätigt:** `confidence_base` stand in `corpus_diff.STRUCTURAL_FIELDS` und wurde dort von #60 gestrichen; `confidence` stand nie drin. `migrate verify` vergleicht das Feld danach nicht mehr und meldete seine Entfernung folglich in keiner der vier Einheiten. Keine Ausnahmeregel, keine Abschwächung an anderer Stelle — für alles Übrige blieb der Check unverändert scharf. ## Ein bewusst stehengelassener Treffer `kb/concepts/patterns/Confidence Scoring.md` enthält weiterhin `confidence: 0.XX` — innerhalb eines ```yaml-Codeblocks im Body, als Illustration des Patterns, über das die Seite handelt. Das ist Inhalt über einen Mechanismus fremder Systeme, kein Frontmatter-Feld dieser Seite; ihr eigenes Frontmatter wurde in u2 bereinigt. Body-unberührt war Scope dieser Migration, und diese Seite ist der Grund, das explizit festzuhalten. ## Akzeptanzkriterien - [x] Keine Datei unter `kb/` enthält `confidence:` oder `confidence_base:` **als Frontmatter-Schlüssel** (der Body-Treffer oben ist benannt und gewollt) - [x] Für jede geänderte Seite: `modified:` identisch zum Vorzustand - [x] Für jede geänderte Seite: Body byte-identisch zum Vorzustand - [x] Für jede geänderte Seite: `related:`, `sources:`, `entities:`, `concepts:` identisch in Inhalt und Reihenfolge - [x] `git status` zeigte ausschließlich die erwarteten `kb/`-Seiten plus `kb/index.md`, die Area-Shards und `kb/log.md` - [x] `migrate verify` lief pro Einheit ohne Befund durch (4 × 0) - [x] `wikitool lint` meldet keine Frontmatter- oder Schemafehler (`schema_validation_errors`: 0) - [x] `wikitool doctor` grün - [x] `.wikitool-kb.json` steht auf 5.0.0 - [x] Der `work/`-Run ist nach `work/CONTRACT.md` geschlossen: Checkliste abgearbeitet, `log append --op update` in `kb/log.md`, Verzeichnis gelöscht
torben added the prio/plannedsize/Sarea/corpuskind/buildstatus/blocked labels 2026-09-10 15:11:52 +00:00
Author
Owner

Changelog: Zwei Punkte aus der Vorbereitung zu #60 eingearbeitet.

Der offene Punkt vor dem Start ist erledigt: confidence_base steht in corpus_diff.STRUCTURAL_FIELDS, und #60 streicht es dort ohnehin. Danach vergleicht migrate verify das Feld nicht mehr und meldet seine Entfernung nicht als Defekt — ohne Ausnahmeregel und ohne Abschwächung an anderer Stelle. confidence stand nie in der Liste.

Neu ist die Publish-Kopplung: dieser Lauf teilt sich einen Publish mit #60. Beide Schemas tragen additionalProperties: false, also sind die 152 Seiten zwischen Schema-Entfernung und Ende dieses Laufs schemainvalide, und ci.yml:161 fährt lint --fail-on-error auf main. Blockierung, Reihenfolge, eigener work/-Run und die Prüfvorschrift bleiben unverändert; nur Schritt 5 des Ablaufs ändert sich.

**Changelog:** Zwei Punkte aus der Vorbereitung zu #60 eingearbeitet. Der offene Punkt vor dem Start ist **erledigt**: `confidence_base` steht in `corpus_diff.STRUCTURAL_FIELDS`, und #60 streicht es dort ohnehin. Danach vergleicht `migrate verify` das Feld nicht mehr und meldet seine Entfernung nicht als Defekt — ohne Ausnahmeregel und ohne Abschwächung an anderer Stelle. `confidence` stand nie in der Liste. Neu ist die Publish-Kopplung: dieser Lauf teilt sich einen Publish mit #60. Beide Schemas tragen `additionalProperties: false`, also sind die 152 Seiten zwischen Schema-Entfernung und Ende dieses Laufs schemainvalide, und `ci.yml:161` fährt `lint --fail-on-error` auf `main`. Blockierung, Reihenfolge, eigener `work/`-Run und die Prüfvorschrift bleiben unverändert; nur Schritt 5 des Ablaufs ändert sich.
Author
Owner

Changelog: Ausgeführt und abgeschlossen, Body auf Endstand. Vier Einheiten wie geplant (35/45/35/37 = 152 Seiten), migrate verify --fail-on-error je Einheit mit 0 Befunden, migrate done 5.0.0 --pages 152 gesetzt, Workshop nach work/CONTRACT.md geschlossen und gelöscht.

Der offene Punkt zu migrate verify ist nicht nur beantwortet, sondern im Lauf bestätigt: die Feldentfernung wurde in keiner Einheit als Defekt gemeldet, ohne dass irgendeine Ausnahmeregel nötig war.

Zwei Dinge, die der Plan nicht vorhergesehen hatte und die jetzt im Body stehen: die Round-Trip-Probe vor dem ersten Schreibzugriff hat einen aus #60 stammenden Serialisierungsdefekt gefangen (Floats wären als Strings zurückgeschrieben worden) — behoben, bevor eine Seite angefasst wurde. Und kb/concepts/patterns/Confidence Scoring.md behält bewusst ein confidence: 0.XX im Body: das ist ein YAML-Beispiel über das Pattern, kein Frontmatter dieser Seite.

status/blocked kann weg — #60 ist erledigt und lief im selben Publish (54d9540).

**Changelog:** Ausgeführt und abgeschlossen, Body auf Endstand. Vier Einheiten wie geplant (35/45/35/37 = 152 Seiten), `migrate verify --fail-on-error` je Einheit mit 0 Befunden, `migrate done 5.0.0 --pages 152` gesetzt, Workshop nach `work/CONTRACT.md` geschlossen und gelöscht. Der offene Punkt zu `migrate verify` ist nicht nur beantwortet, sondern im Lauf bestätigt: die Feldentfernung wurde in keiner Einheit als Defekt gemeldet, ohne dass irgendeine Ausnahmeregel nötig war. Zwei Dinge, die der Plan nicht vorhergesehen hatte und die jetzt im Body stehen: die Round-Trip-Probe vor dem ersten Schreibzugriff hat einen aus #60 stammenden Serialisierungsdefekt gefangen (Floats wären als Strings zurückgeschrieben worden) — behoben, bevor eine Seite angefasst wurde. Und `kb/concepts/patterns/Confidence Scoring.md` behält bewusst ein `confidence: 0.XX` im Body: das ist ein YAML-Beispiel über das Pattern, kein Frontmatter dieser Seite. `status/blocked` kann weg — #60 ist erledigt und lief im selben Publish (`54d9540`).
torben removed the status/blocked label 2026-09-10 18:07:27 +00:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: torben/chemenu#86