feat(mcp): Ressourcen und Prompts fuer Claude Desktop, zwei Befunde behoben

MCP-ADAPTER 1.1

Werkzeuge ruft ein Modell von sich aus auf - Ressourcen und Prompts waehlt ein
MENSCH. In Claude Desktop sind das Anhang-Menue und Schraegstrich-Befehle, und
genau die fehlten.

  - Vier Ressourcen: dc://roadmap (fertiger Markdown-Block),
    dc://naechste-schritte, dc://projekte, dc://befunde.
  - Vier Prompts: arbeit-aufnehmen, befunde-sichten, fehler-melden,
    roadmap-pflegen. Ihr Wert liegt nicht in der gesparten Tipparbeit, sondern
    darin, dass die Hausregeln mitkommen - erst nachsehen wer dransitzt,
    Fremdmeldung nur mit Begruendung, Verworfenes nicht ohne neues Argument
    wiedervorschlagen. Bisher standen die nur in Werkzeugbeschreibungen, und
    die liest ein Modell erst, wenn es das Werkzeug schon gewaehlt hat.
  - DC_PROJECT: worauf die Ressourcen zeigen. Werkzeuge nehmen project_slug je
    Aufruf, Ressourcen haben keine Argumente.
  - Ressourcen laufen durch dieselbe Fremddaten-Abgrenzung wie
    Werkzeugergebnisse - sie sind eher ein Einfallstor, weil sie ungefragt im
    Kontext landen.
  - Einrichtung fuer claude_desktop_config.json dokumentiert.

  Behoben: "initialize" spiegelte die verlangte Protokollfassung zurueck. Ein
  Client, der 2025-06-18 anfragte, bekam sie bestaetigt, obwohl der Adapter
  fuer 2024-11-05 geschrieben war. Jetzt wird gegen eine Liste tatsaechlich
  bedienter Fassungen ausgehandelt.

  Behoben: process.exit() mitten in schliessenden libuv-Handles. Unter Windows
  eine Assertion und Rueckgabewert != 0 - ein sauber beendeter Server sah aus
  wie ein abgestuerzter.

ZWEI BEFUNDE, DIE ERST DIE RESSOURCEN ZUTAGE FOERDERTEN

  - roadmap.php?action=render lehnte fuer ein Werkbank-Token mit
    "missing_project" ab. projectFilter() laesst es beim Lesen bewusst durch
    (es soll die Landschaft sehen) und liefert null, also wurde der
    Projektbezug "all". Betroffen war ausgerechnet der Tokentyp, den der
    Adapter verlangt. Rueckfall ist jetzt das Heimatprojekt des Tokens.
  - ProjectLinks::between() benutzte :a dreimal, forProject() :slug zweimal.
    Bei ATTR_EMULATE_PREPARES = false unzulaessig -> HY093 und ein 500 auf
    /api/bugtracker/v1/projects. Derselbe Fehler wie einst in der
    Volltextsuche des Bugtrackers; ein Suchlauf ueber alle prepare()-Aufrufe
    der Codebasis fand keine weitere Stelle.

WARUM BEIDE UNBEMERKT BLIEBEN

Beide Wege laufen nur mit einem Werkbank-Token (owner_type = dev_agent). Der
Testlauf hatte keines - es gibt keine API, so eines anzulegen, und in der
Produktion geschieht das von Hand. Ein Tokentyp, den kein Testfall benutzt,
ist ein Tokentyp, dessen Sonderwege niemand prueft.

testctl.php kann jetzt action=workbench_token; vier Testfaelle decken die Wege
ab, samt Gegenprobe, dass der Rueckfall aufs Heimatprojekt das Lesen ueber alle
Projekte nicht einschraenkt. 128 Faelle, alle gruen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Deploymentcenter Bot
2026-08-29 23:14:40 +02:00
co-authored by Claude Opus 5
parent 1d5ac92051
commit 8b6d6a307e
8 changed files with 635 additions and 26 deletions
+25 -6
View File
@@ -43,13 +43,16 @@ final class ProjectLinks
*/
public function forProject(string $slug): array
{
// Zwei Platzhalter fuer denselben Wert - aus demselben Grund wie in
// between(): ein Name darf bei nativen Prepared Statements nur einmal
// vorkommen. Diese Abfrage haette beim ersten Aufruf HY093 geworfen.
$stmt = $this->db->prepare('
SELECT from_slug, to_slug, kind, integrated_version, integrated_at, notes
FROM dc_project_links
WHERE from_slug = :slug OR to_slug = :slug
WHERE from_slug = :slug_from OR to_slug = :slug_to
ORDER BY kind ASC, to_slug ASC
');
$stmt->execute([':slug' => $slug]);
$stmt->execute([':slug_from' => $slug, ':slug_to' => $slug]);
$uses = [];
$usedBy = [];
@@ -86,15 +89,31 @@ final class ProjectLinks
return ['direction' => 'self', 'kind' => 'self', 'integrated_version' => null];
}
// Jedes Vorkommen bekommt einen eigenen Platzhalter.
//
// :a stand dreimal und :b zweimal im Statement. Bei
// ATTR_EMULATE_PREPARES = false ist das nicht zulaessig - PDO reicht
// die Namen an den Server durch, und der zaehlt Parameter, statt sie
// zu benennen. Ergebnis: HY093 "Invalid parameter number", also ein
// 500 statt einer Antwort.
//
// Derselbe Fehler steckte schon einmal in der Volltextsuche des
// Bugtrackers (siehe Kopfkommentar von BugRepo). Er faellt deshalb so
// spaet auf, weil er erst bei der Ausfuehrung zuschlaegt und diese
// Abfrage nur laeuft, wenn ein Heimatprojekt gesetzt ist - also nur
// mit einem Werkbank-Token.
$stmt = $this->db->prepare('
SELECT from_slug, kind, integrated_version
FROM dc_project_links
WHERE (from_slug = :a AND to_slug = :b)
OR (from_slug = :b AND to_slug = :a)
ORDER BY from_slug = :a DESC
WHERE (from_slug = :a1 AND to_slug = :b1)
OR (from_slug = :b2 AND to_slug = :a2)
ORDER BY from_slug = :a3 DESC
LIMIT 1
');
$stmt->execute([':a' => $from, ':b' => $to]);
$stmt->execute([
':a1' => $from, ':a2' => $from, ':a3' => $from,
':b1' => $to, ':b2' => $to,
]);
$row = $stmt->fetch();
if (!is_array($row)) {