lmcp/auftrag_c.md

PHASE C — DIE FASSUNG DURCHSETZEN. Auftrag an die Gesellschaft.

Phase B hat das Modul geliefert: versions.lua liegt in marfrit/lmcp auf master (Commit 3409a41), abgenommen mit Prüfling und Test auf demselben Commit. Es prüft eine Fassung — benutzt wird es noch nirgends.

Der Befund, an dem Phase C hängt

lmcp.lua:40 setzt MCP_VERSION = "2025-06-18" und meldet sie in initialize (Zeile 531). Der Kopf Mcp-Protocol-Version taucht im ganzen Server genau einmal auf: in der CORS-Erlaubnisliste (Zeile 1192). Er wird nie gelesen. Deshalb antwortet lmcp auf jede Fassungsangabe mit 200, auch auf 1999-01-01.

Ziel: der Server liest den Kopf und weist ab, was er nicht spricht — mit dem Fehlerkode und der supported-Liste, die versions.lua schon liefert.

Reihenfolge — und diesmal ist @architect dabei

1. @architect zuerst, als Entwurfsdebatte. Nicht implementieren, entscheiden. Drei Fragen, die der Code nicht beantworten kann:

   a) Wo greift die Prüfung? Nur bei initialize, oder bei jeder Anfrage mit gesetztem Kopf? Beides ist vertretbar, das eine ist strenger.

   b) Was passiert mit Anfragen OHNE Kopf? Der Vertrag von versions.lua lässt sie ausdrücklich zu — die sitzungslose Abkürzung schickt ihn oft nicht und trägt den meisten Verkehr. Eine Verschärfung hier legt die halbe Flotte still. Das ist die teuerste der drei Fragen.

   c) Wie sieht die Ablehnung auf der Leitung aus? JSON-RPC-Fehler mit -32022 im Rumpf, oder ein HTTP-Statuskode? Ein Klient, der nur den Status liest, merkt vom Rumpf nichts.

   @foreman: @architect ist ein Gesprächspartner, kein Arbeiter — er liest nur type=chat. Ein ask ist für ihn unsichtbar. Beruf ihn mit room_say ... type=chat, und poste während einer laufenden Runde KEIN weiteres chat, sonst nimmst du ihm den Stab.

2. Implementieren — gegen einen Abnahmetest, den @testdesigner vorher schreibt und dessen roten Ausgangszustand er attestiert. Der Test gehört nach tests/phase_c_acceptance.lua.

   Neu seit heute: ein Ticket kann SPEC: <pfad> tragen, dann attestiert der Grinder selbst und liefert seine Urkunde mit. Nutzt das — dann gibt es zwei unabhängige Urkunden über dieselben Bytes, und übereinstimmende sha256 sind der Beweis, den der fehlende gemeinsame Speicher sonst nicht zulässt.

3. @reviewer zum Schluss, bevor irgendetwas herausgeht. Er bekommt: den Entwurf von @architect, die Änderung, beide Urkunden. Seine Frage ist nicht „läuft es", sondern „ist es richtig, und was bricht es".

4. Erst danach holt @deus das Ergebnis heraus.

Eine Warnung, die keine Formsache ist

Diese Änderung fasst lmcp.lua an — den Server, auf dem dieser Raum läuft. Ein voreiliges Ausrollen killt den Kanal, über den ihr euch verständigt, und zwar mitten im Satz.

Deshalb: die Änderung landet im Repo und wird gegen den Test attestiert. Sie wird NICHT in einen laufenden Raum eingespielt. Das Ausrollen ist Operatorarbeit und passiert später, mit einem Weg zurück. Wer versucht, lmcp.service neu zu starten, um „mal zu sehen ob es geht", nimmt der ganzen Gesellschaft die Stimme.

Was schon feststeht und nicht neu verhandelt wird

• M.SUPPORTED = {"2025-06-18"} — gemessen, nicht geraten. initialize meldet genau diese Fassung.
• Aus „der Server antwortet mit 200" folgt nichts. Er tut das auch bei 1999-01-01. Wer damit argumentiert, wiederholt B3.
• Abnahme ist eine Urkunde, kein Satz. @foreman spricht keine aus.

Deine Schlussmeldung, deus

Der Entwurf von @architect in drei Sätzen, die Urkunden, @reviewers Befunde, und was offen blieb. Ein ehrliches ROT ist ein gültiges Ergebnis.