[NurRobin]

Pull request

What changed?

REQ-457, Teil A von zwei: Job 3 (Konsolidieren), Job 5 (Regressionsschutz) und der Herkunftstest (Kriterium 3). Teil B (Job 4 Ledger, Job 1 Ghosts) ist nicht angelegt.

Grundregel unverändert: Der Gärtner schlägt vor, ein Mensch entscheidet. Alles, was er schreibt, trägt Harness gardener und Confidence staged; jede Änderung an anderen Einträgen ist ein Knopf auf der Review-Seite, den ein Mensch mit den nötigen Rechten drückt.

Duplikate zusammenführen (Job 3a). Eine Duplikat-Notiz auf /ui/review hat jetzt „Zusammenführen“. Die Karte zeigt vorher, welcher Eintrag bleibt (der neueste) und welche ersetzt werden. Der Knopf ruft dieselbe Store-Funktion wie context_supersede (SupersedeKnowledge) mit dem Grund „Gärtner-Vorschlag #, bestätigt von “ und schließt die Notiz als bestätigt. Er wird abgelehnt (409), wenn ein Eintrag nicht mehr gilt, die Scopes verschieden sind oder der bleibende Eintrag noch nicht vertrauenswürdig ist. Die Duplikat-Notiz hat kein einfaches „Bestätigen“ mehr, und „Alle freigeben“ überspringt sie. Verwerfen bleibt wie vorher.

Widersprüche als Thread (Job 3b). --propose öffnet je validiertem Widerspruch einen Thread statt einer Notiz: verknüpft mit allen betroffenen Einträgen, Titel als Frage mit „[Gärtner]“, erster Beitrag mit Begründung und wörtlichen Zitaten, geschrieben vom Konto des Gärtners. Der Client konnte das schon (CreateThread, LinkThread, ThreadsForObject, SendCoordMessage); ergänzt habe ich nur die schmale Schnittstelle garden.ThreadSink ohne jeden Aufruf, der einen Thread-Zustand setzt. Der Gärtner meldet sich dafür als Agent gardener:<projekt> im Projektraum an, weil Threads ohne Web-Sitzung nur so lesbar und eröffnbar sind. Kann ein Thread nicht geöffnet werden, entsteht wie bisher eine gestagte Notiz.

Idempotenz der Threads. Die Frage des Threads enthält eine Zeile „Stand der Einträge beim Fund: #12 (hash), #15 (hash)“ (HashOf, Wortlaut der Einträge). Vor dem Öffnen werden die Threads an allen Einträgen gesucht:

• ein offener Thread an denselben Einträgen: kein zweiter;
• ein vom Menschen geschlossener, geparkter oder archivierter Thread: wird nicht wieder geöffnet und nicht mit einem neuen beantwortet, solange die Hashes gleich sind; ändert sich ein Eintrag, darf ein neuer Thread fragen, der alte bleibt unberührt;
• ein Thread von Menschen an allen Einträgen (ohne Stand-Zeile) zählt in jedem Zustand;
• eine Gärtner-Notiz zur selben Beziehung (in jedem Zustand) zählt als „gesehen“;
• sind die vorhandenen Threads nicht abfragbar, wird nichts geöffnet.

Regressionsschutz (Job 5). Im selben Paket, ohne zusätzliche Sessions, bekommen offene Pitfalls (ohne Urteil in context_regression_cover, ohne stehenden Vorschlag des Gärtners, höchstens 8 je Session) eine Zusatzfrage: ein vorhandener Test (Datei und Name; func TestX muss in einer getrackten _test.go-Datei stehen, die die Session gelesen hat; bei anderen Sprachen der Name als Wort), eine Skizze (Datei, Name, 3 bis 6 Zeilen; Datei-Verzeichnis muss existieren, der Name darf es noch nicht geben) oder „nicht testbar“ mit Grund. Was der Checkout nicht belegt, wird verworfen und im Bericht genannt. Je Antwort entsteht eine gestagte Gärtner-Notiz. Auf der Review-Seite setzen „Als abgesichert vermerken“ (vorhandener Test) und „Als nicht testbar vermerken“ über SetRegressionCover covered mit Testname bzw. not_applicable, mit dem Recht zu verifizieren (wie das Regressions-Werkzeug); Skizzen haben nur Bestätigen/Verwerfen und stehen zusätzlich in einem eigenen Abschnitt „Testskizzen“ im Morgenbericht (--out). Das Antwortformat wächst nur um das optionale Feld regression.

Herkunftstest (Kriterium 3). cmd/ctx/garden_provenance_test.go lässt den Gärtner im Agent-Modus mit einem Claude-Stand-in gegen den echten Server (Store im Speicher, server.New) laufen und zeichnet jeden Schreibzugriff auf. Er belegt (a) jede Notiz hat Harness gardener und Confidence staged und ersetzt nichts, (b) Thread und erster Beitrag gehören dem Konto des Gärtners und sind markiert, (c) nur POST auf Wissen, Raum-Anmeldung, Threads, Verknüpfungen und Beiträge, nichts, was ändert, löscht, schließt, ablöst, zurückzieht, ein Regressionsurteil oder Kriterium setzt oder einen Request abschließt (Wissen, Relationen, Auftrag danach unverändert), ein zweiter Lauf schreibt nichts Neues, ein vom Menschen geschlossener Thread bleibt geschlossen, (d) das Konto des Gärtners (Rolle member) wird vom Server für alle diese Schritte abgelehnt. Die Review-Aktionen sind in internal/web/review_garden_actions_test.go mit Lead, Reviewer, Mitglied, Gast und Fremdem getestet; dazu ein Test, der die Methodenliste von garden.Sink und garden.ThreadSink festhält.

Rechte der neuen Review-Aktionen.

Aktion	Recht
Zusammenführen (POST /ui/review/{id}/merge)	Ändern aller beteiligten Einträge (wie context_supersede), dazu Verifizieren der Notiz. Praktisch Lead/Owner; ein Mitglied nur an eigenen Einträgen und mit Reviewrecht.
Als abgesichert / nicht testbar vermerken (POST /ui/review/{id}/cover)	Verifizieren des Pitfalls (wie context_regression_cover) und der Notiz: Lead, Owner, Mitglied mit Reviewrecht.
Gast, Fremder	404 (sie sehen die gestagte Notiz nicht), Mitglied ohne Rechte 403. Ohne Formular-Token passiert nichts.

Prompt-Zuwachs. Die Frage steht in der Aufgabe eines Pakets mit offenen Pitfalls, nicht in der Standardanweisung: einmal rund 1.000 Zeichen je Session plus ein Marker je Frage. Gemessen im Test an einem Paket mit 30 Pitfalls zu je 2.000 Zeichen: 73.644 auf 74.677 Zeichen, +1,4 Prozent (bei realen Texten von 3.000 Zeichen eher +1 Prozent). Dazu kommen höchstens 8 Antworten (rund 500 Ausgabe-Tokens) und möglicherweise zusätzliche Nachschlage-Turns je Pitfall; das ist geschätzt, nicht gemessen. Die Obergrenze (--max-usd 3, Teilergebnis bei Limit) bleibt.

Herkunft der Notizen (zwei Sicherheitsbefunde der Review, Confused Deputy). Ohne weitere Prüfung hätte jedes Konto per POST /api/knowledge (oder context_remember) mit harness: gardener und passender session_ref eine Notiz anlegen können, die wie ein Gärtner-Vorschlag aussieht; die Karte hätte ein anderes Ziel gezeigt, als „Zusammenführen“ bzw. „Als abgesichert vermerken“ trifft. Gelöst so:

1. Das Gärtner-Konto ist eine Konto-Nummer, kein Name. Ein erster Entwurf löste es über den Kontonamen auf; der Review-Befund dazu: Wer seinen Anzeigenamen selbst ändern kann (Profil, Name des Identitätsanbieters), bekäme mit dem Namen die Rolle, und ein umbenanntes Konto verschöbe sie still. Deshalb steht jetzt die Nummer in org_state (vorhandene Tabelle, keine Schemaänderung), und nur der Betreiber des Server-Hosts setzt sie, mit ctx account set-gardener <name|person:N|N> --db <pfad> (wie die übrigen ctx account-Befehle: Datenbankzugriff statt Token). Der Befehl löst einmal auf und speichert die Nummer; --clear nimmt die Rolle weg, ctx account list markiert das Konto mit gardener=true, ctx serve loggt beim Start gardener_account. Der laufende Server liest die Einstellung bei jeder Prüfung, ein Neustart ist nicht nötig. Umgebungsvariable und Flag mit dem Namen gibt es nicht; es bleibt kein Weg über Namen, also braucht der Name auch keine Reservierung für SetOwnName und den Provider-Abgleich (das Umbenennen auf den alten Namen weist der Store ohnehin ab). Nichts, was über HTTP erreichbar ist, schreibt die Einstellung (ein Test liest server, web, mcpserver und client darauf). Konto-Nummern ändern sich nicht und werden nicht wieder vergeben (INTEGER PRIMARY KEY, es gibt keinen Löschpfad).
2. Schreib-Gate am Server (fail-closed). Harness gardener und gardener:-Verweise (jede Schreibweise) darf nur dieses Konto mit einem Token schreiben, auch über supersedes und POST /api/migrated-knowledge. Alle anderen, Owner eingeschlossen, bekommen 403 gardener_reserved; ist kein Konto gesetzt, bekommt es niemand, und die Meldung nennt den Befehl.
3. Autor. Die Review-Aktionen handeln nur bei einer Notiz, die dieses Konto geschrieben hat (Konto-Nummer aus knowledge_authors, nie das Label), die seitdem niemand bearbeitet hat (kein Eintrag in der Historie) und nur im Zustand gestaged/aktiv. Ohne gesetztes Konto sind die Aktionen aus.
4. Ziel. Der Titel (#<id>) muss dieselben Einträge nennen wie die session_ref, sonst Hinweis „Herkunft nicht bestätigt: keine Aktion“ und 403. Die Karte zeigt die Einträge der session_ref mit ID, Titel und Link („Betrifft“ bzw. „Bleibt“/„Wird ersetzt“), nie die des Titels.
5. Testzeile. Ein erneutes Prüfen gegen das Repo geht am Server nicht, er hat keinen Checkout; ctx hat es vor dem Anlegen getan. Stattdessen: feste Form (relativer/pfad:Funktionsname, keine Leerzeichen, kein .., kein .git, höchstens 300 Zeichen), die Zeile steht ganz auf der Karte, wird so eingetragen, wie die Notiz sie hält, und die Anfrage trägt keinen eigenen Test (Zusatzfelder im Formular wirken nicht). Wer die Zeile bearbeitet, entzieht der Notiz damit die Aktion.

Negativtests für jede Prüfung: Autor Reviewer/Mitglied/Lead/Owner/unbekannt, kein Konto gesetzt, anderes Konto gesetzt, Umbenennen des Gärtner-Kontos ändert nichts an seinen Rechten, ein Konto mit dem alten Namen bekommt keine (über SetOwnName und über direkte Namensänderung), fremder Titel, bearbeitete Notiz, 11 Formen einer unmöglichen Testzeile, Zusatzfelder, Laufzeit-Store mit Writer und ein zweiter Prozess. Mutationsproben (jede Prüfung einzeln ausgebaut, dazu eine namensbasierte Identität) lassen den jeweiligen Test fehlschlagen.

Betrieb vor dem nächsten Lauf. Auf jedem Server, der den Gärtner betreut, einmal ctx account set-gardener <Kontoname des Gärtner-Tokens> --db <Datenbank> ausführen, mit dem Benutzer, dem die Datenbank gehört (Beispiel mit transienter Unit in deploy/README.md); sonst lehnt der Server die Vorschläge mit 403 gardener_reserved ab. Alte Notizen ohne Autor oder von einem anderen Konto bekommen keine Aktion mehr (Bestätigen/Verwerfen bleiben).

Nicht enthalten / bekannte Grenzen. Der Server erzwingt staged für das Konto des Gärtners selbst nicht; das hält der Befehl ein und der Herkunftstest belegt es. Das Konto sollte die Rolle member haben, nicht Lead.

Verification

gofmt -l .                      # leer
go vet ./...
go build ./...
go test ./internal/garden/... ./cmd/ctx/... ./internal/client/...
go test ./internal/store/... -timeout 30m
go test ./internal/web/... -timeout 55m

Ergebnisse: siehe Kommentar unten. Manuell geprüft: Aufruf ctx garden zeigt die neue Hilfe; Mutationsprobe (Notiz mit trusted statt staged schreiben) lässt den Herkunftstest fehlschlagen.

Release impact

• major — incompatible after 1.0
• minor — compatible feature, or incompatible before 1.0
• patch — compatible fix
• none — no release impact

Checklist

• This pull request targets dev (or is an approved release/hotfix promotion).
• Tests cover changed behavior.
• I did not add credentials, private infrastructure details, or internal planning documents.
• User-facing behavior and the changelog are updated where needed.
• I have read and agree to the Contributor License Agreement, and I am authorized to make this contribution.

[NurRobin]

Lokale Ergebnisse (Branch feat/garden-consolidate-regression, Stand 086f209, gemergt mit origin/dev 96c8e17):

• gofmt -l .: leer
• go vet ./...: sauber
• go build ./...: ok
• go test ./internal/garden/... ./cmd/ctx/... ./internal/client/...: ok (zusätzlich ./internal/server/... und ./internal/mcpserver/...: ok)
• go test ./internal/web/... -timeout 55m: ok (auf e6953af; danach nur noch Store-Leseweg und Inventar)
• go test ./internal/store/... -timeout 30m: ein Lauf auf e6953af mit zwei Fehlern. TestRuntimeStoreWriterInventory hat die neuen öffentlichen Store-Methoden bemängelt; behoben in 7b471c0 (klassifiziert, Leseweg über den Reader), danach grün. TestRuntimeWriterCrashRestartMatrix ("child did not reach crash boundary") ist der bekannte flaky Test; er scheitert unter derselben Last auch auf unverändertem origin/dev (geprüft).
• markdownlint-cli2 lokal auf deploy/README.md und CHANGELOG.md: 0 Funde.
• Mutationsproben: jede Herkunftsprüfung einzeln ausgebaut (Autor, Titel gegen Ref, unbearbeitete Notiz, Form der Testzeile, Schreib-Gate an beiden Wegen) sowie eine namensbasierte Identität des Gärtner-Kontos: jeweils scheitert der zugehörige Test.