7fbb9a99df
Files changed: - kb/log.md - kb/sources/Source - MCP Read Server Implementation Session 2026-09-02.md
110 lines
6.2 KiB
Markdown
110 lines
6.2 KiB
Markdown
---
|
|
type: types/source.md
|
|
source_type: notes
|
|
author: Torben
|
|
raw_files: [raw/notes/Conversation Transcript - MCP Read Server Implementation Session 2026-09-02.md]
|
|
source_language: de
|
|
date: 2026-09-02
|
|
tags: []
|
|
entities: [wikitool, Chemenu]
|
|
concepts: [Publish-Remote Gate, Mass-Update Gate, Iteration and Cost Limits, MCP-Leseserver]
|
|
summary: 'Sitzung, die die Sequenz aus Issue #36 umsetzt: Publish-Remote Gate scharf, Lesepfad gehaertet, Root-Aufloesung und Bibliotheksgrenze gezogen, MCP-Leseserver gebaut - vier Versionsstufen 2.2.3 bis 2.4.0, dazu INSTALL-MCP.md und Issue #37.'
|
|
---
|
|
# Source: MCP Read Server Implementation Session 2026-09-02
|
|
|
|
**Autor:** Torben
|
|
**Datum:** 2026-09-02
|
|
**Raw-Dateien:** raw/notes/Conversation Transcript - MCP Read Server Implementation Session 2026-09-02.md
|
|
**Typ:** Notes
|
|
|
|
## Zusammenfassung
|
|
|
|
Diese Sitzung arbeitet die vierstufige Sequenz aus Issue #36 ab, dem Sammel-Issue für den Weg
|
|
zum MCP-Leseserver: #34 (Publish-Remote-Gate scharf stellen), #33 (Lesepfad vor der Exposition
|
|
härten), #31 (Root-Auflösung von der Importzeit lösen und eine Bibliotheksgrenze ziehen), #19
|
|
(der Leseserver selbst). Jeder Schritt endet mit einem Versions-Bump und einem Testlauf; die
|
|
Reihenfolge folgt dem Master-Issue, weil #33 dieselben Dateien anfasst, die #31 strukturell
|
|
umbaut, und #31 die Grenze liefert, auf der #19 aufsetzt.
|
|
|
|
`.wikitool-remotes.json` fehlte in diesem Checkout trotz Dokumentation, die das Gegenteil
|
|
behauptete - angelegt und gegen ein erfundenes Ziel gegengeprüft (Exit 42). Der Lesepfad bekam
|
|
sechs Fixes gegen einen 267-Byte-YAML-Alias, der zu 672.603 Knoten expandiert, gegen einen
|
|
ReDoS-Zweig in der Ranking-Funktion, einen fehlenden Subprozess-Timeout, und einen Korpus-Cache,
|
|
der nie einen schmutzigen Arbeitsbaum cacht. `config.ROOT` und alle abgeleiteten Pfade waren zur
|
|
Importzeit gebunden; die Auflösung ist jetzt lazy (`CHEMENU_ROOT` → Walk-up), und der reine
|
|
Lesekern (`search/service.py`, `lint_core.py`, `types_core.py`) importiert kein `typer` mehr.
|
|
Der MCP-Server (`tools/chemenu/mcp/`) exponiert `search`/`types`/`describe_type`/`lint`/`status`
|
|
über `chemenu.api.Corpus` - strukturell ohne Schreibpfad, mit Commit-Stempel auf jeder Antwort
|
|
und einer Startverweigerung, falls Telemetrie in den bedienten Baum schreiben würde.
|
|
|
|
Nach Freigabe des 37-Datei-Changesets (Mass-Update-Gate, Token `46442f4419c1`) folgten
|
|
`INSTALL-MCP.md` für Menschen, ein Verweis auf die separate Traefik-ForwardAuth-Middleware
|
|
(`gitea-mcp-forward-auth`), und Issue #37 für das noch fehlende Container-Image - mit den
|
|
konkreten CI-Vorlagen aus `gitea-mcp-forward-auth` (Registry-Push) und `gitea-mcp`
|
|
(Dockerfile-Form, aber DockerHub statt der eigenen Registry). Alle vier Sequenz-Issues wurden
|
|
geschlossen, #36 blieb offen, weil sein eigenes Abschlusskriterium - ein Konsument, der
|
|
nachweislich über die Middleware antwortet - erst mit #37 erfüllbar ist.
|
|
|
|
## Kernaussagen
|
|
|
|
- Gemessen: Korpus-Parse 265 ms → 54 ms (`CSafeLoader`), `wikitool search` end-to-end
|
|
593 ms → 347 ms; die verbleibenden ~262 ms sind Modulimport und entfallen erst im residenten
|
|
MCP-Prozess.
|
|
- Der ReDoS-Zweig (`_contains` mit `re.search` gegen nutzergesteuerten Regex) wurde gelöscht,
|
|
nicht begrenzt - `rg` wendet das Muster ohnehin mit einer linearen Engine an, bevor die
|
|
Funktion je läuft.
|
|
- `monkeypatch.setattr(config, "ROOT", ...)` baute nach der lazy-Auflösung die stale Bindung
|
|
beim Teardown wieder auf, weil es den *aufgelösten* alten Wert zurückschreibt - `config.reset()`
|
|
musste dazukommen, in derselben autouse-Fixture, die das Problem eine Ebene höher (Umgebungsvariablen)
|
|
bereits kannte.
|
|
- Der MCP-Server hat keinen Schreibpfad, weil `chemenu.api` nichts unter `chemenu.commands`
|
|
importiert - nicht, weil eine Liste gefiltert wird. Ein Test importiert das Servermodul in
|
|
einem frischen Interpreter und prüft `sys.modules`.
|
|
- Ein Stempel-Bug wurde beim Schreiben des Golden-Tests selbst gefunden: `_stamp()` fragte nach
|
|
der *aktuellen* statt der beim Laden tatsächlich gelesenen Revision und hätte bei einem
|
|
minimal verzögerten zweiten Zugriff `commit: null` auf einem sauberen Baum liefern können.
|
|
- `gitea-mcp` ist als Registry-Vorlage ungeeignet - sein Release-Workflow pusht nach DockerHub
|
|
(Fork des Upstream), nicht in die eigene Gitea-Registry.
|
|
|
|
## Aufgaben
|
|
|
|
- [x] #34, #33, #31, #19 umgesetzt und mit Abschlusskommentar geschlossen
|
|
- [x] `INSTALL-MCP.md` geschrieben, in `INSTALL.md`/`README.md` verlinkt, in `dist export` aufgenommen
|
|
- [x] Issue #37 (Container-Image) angelegt, mit neun offenen Entscheidungen benannt
|
|
- [ ] #37 selbst umsetzen
|
|
- [ ] #36 schließen, sobald #37 den Middleware-Nachweis liefert
|
|
- [ ] #23 (Env-Var-Erzwingung) - `CHEMENU_ROOT` wurde von Hand in `_WIKITOOL_ENV` eingetragen
|
|
- [x] `kb/entities/tools/qmd.md` - falsche Sprachangabe korrigiert (siehe Korrektur unten)
|
|
|
|
## Korrektur zum Transkript-Kopf
|
|
|
|
Der Fidelity-Block des Rohtranskripts sagt: "One of two transcripts cut from this session; the
|
|
other covers fixing `kb/entities/tools/qmd.md`". Dieses zweite Transkript wurde nie geschrieben
|
|
- `raw/` ist unveränderlich, die Korrektur gehört hierher, nicht in die Datei selbst. Tatsächlich
|
|
lief die Korrektur ohne eigenes Transkript: direkt gegen `tobi/qmd` auf GitHub geprüft und als
|
|
eigene Quelle mit eigenem Raw-Beleg abgelegt (`Source - qmd - GitHub Repository`,
|
|
`raw/documents/qmd - GitHub Repository.md`) - eine Quellen-Verifikation statt eines
|
|
Gesprächsprotokolls, was für eine Sprachangaben-Korrektur die passendere Belegform ist.
|
|
|
|
## Nicht übernommen
|
|
|
|
- Der vollständige Wortlaut der geprüften Docstrings, Kommentare und Testfälle - das Transkript
|
|
benennt Dateien und die tragenden Eigenschaften, der Code selbst ist die Quelle.
|
|
- Die exakten neun offenen Entscheidungspunkte aus Issue #37 (Korpus im Image vs. Volume,
|
|
Basis-Image, Healthcheck etc.) - dort bereits vollständig dokumentiert, hier nicht dupliziert.
|
|
- Der Wortlaut der abgerufenen READMEs von `gitea-mcp-forward-auth` und `gitea-mcp` - nur die
|
|
für die Entscheidung relevanten Fakten (Config-Variablen, Workflow-Form, Registry-Ziel)
|
|
wurden übernommen.
|
|
|
|
## Verwandte Entities
|
|
|
|
- [[wikitool]]
|
|
- [[Chemenu]]
|
|
|
|
## Verwandte Concepts
|
|
|
|
- [[Publish-Remote Gate]]
|
|
- [[Mass-Update Gate]]
|
|
- [[Iteration and Cost Limits]]
|
|
- [[MCP-Leseserver]]
|