Upstream-PR an block/buzz: error.data überlebt in buzz-acp

[munirad7s]

Mission

Der error.data-Fix aus buzz#39 liegt als PR bei block/buzz — der Fork trägt eine Änderung weniger allein, und Upstream bekommt eine Diagnose-Verbesserung, die jedem ACP-Adapter nützt.

Money-Link

Führungs-Hebel: Jede Zeile, die Upstream übernimmt, ist eine Zeile, die wir bei keinem git merge upstream/main mehr verteidigen müssen. Doktrin 2 („upstream-freundlich") ist nur dann echt, wenn die fertigen Diffs auch abgegeben werden — sonst wächst der Fork-Delta trotzdem.

Kontext

• Repo/Pfad: C:/Users/rescue/projects/buzz · Fork munirad7s/buzz, Upstream block/buzz
• Der Commit ist bereits sauber isoliert: acp: keep JSON-RPC error data when message is present — nur crates/buzz-acp/src/acp.rs, kein .empire/-Anteil, +211/−1. Gemerged als feat/39 acp error data #80.
• Inhalt: agent_error_from_json hängt ein vorhandenes data auch dann an die Meldung, wenn message ein String ist (bisher fiel data genau im häufigsten Fall still weg). Plus Redaction credential-förmiger Keys und zwei getrennte Längenkappen.
• Verifiziert im Fork: cargo fmt/clippy sauber, 7 neue Unit-Tests, Rot-Probe (alter Code → 5 FAILED, die 4 Verhaltens-Fixierer bleiben grün).
• Abhängigkeiten: keine
• Koexistenz: Vorsicht mit gh pr create im Fork — ohne --repo zielt es auf UPSTREAM. Hier ist Upstream ausnahmsweise das Ziel, aber bewusst und mit sauberem Branch.

Vorflug-Check (nach Claim, vor Arbeit — jeder Punkt muss halten)

1. git fetch upstream && git log --oneline -1 upstream/main — Upstream-Stand aktuell.
2. agent_error_from_json bei Upstream unverändert (niemand hat den Fix inzwischen selbst gebaut) — sonst Ticket schließen statt PR aufmachen.
3. block/buzz akzeptiert externe PRs (CONTRIBUTING/DCO/CLA prüfen; feat/6 espocrm anbindung block/buzz#4095 wurde von uns selbst geschlossen, nicht von Upstream abgelehnt).
   → Scheitert ein Punkt: NICHT blind bauen — Befund kommentieren, ready zurück oder Blocker-Protokoll.

Auftrag

1. Branch aus upstream/main, den Commit acp: keep JSON-RPC error data when message is present cherry-picken.
2. Falls Upstream sich bewegt hat: Konflikte auflösen, Tests neu laufen lassen.
3. PR gegen block/buzz main mit englischem Body: Problem (Beispiel-Payload von @agentclientprotocol/codex-acp 1.1.7), Fix, Tests, Redaction/Truncation-Begründung.
4. PR-Nummer + Status im Fork-Ticket kommentieren.

Nicht-Ziele / Guardrails

• Kein .empire/-Inhalt, keine deutschen Kommentare, keine Empire-internen Verweise im Upstream-Diff.
• Keine weiteren Fork-Änderungen mit einbündeln — genau dieser eine Commit.
• Keine Secrets, keine Pfade aus Munirs Maschine im PR-Text.

Verifikation (Befehle + erwartete Ausgabe)

#	Befehl/Aktion	Erwartung
1	cargo nextest run -p buzz-acp -E 'test(agent_error_from_json)' auf dem Upstream-Branch	alle grün
2	git diff upstream/main --stat	genau 1 Datei
3	gh pr view <nr> -R block/buzz	offen, CI-Status notiert

Definition of Done

• PR bei block/buzz offen, Nummer im Fork-Ticket kommentiert
• Diff genau eine Datei, Tests grün
• Issue mit Ergebnis-Kommentar geschlossen

Rechte

Chrome-MCP, Windows-MCP, Playwright, n8n-MCP, ~/.secrets/** — ohne Rückfrage. Blocker → blocker-mail.sh + Label blocked-munir + weiter.

Format v2 · buzz_empire 2026-08-01 (Gardener aus buzz#39)

[munirad7s]

🐝 buzz_empire 2026-08-01 19:16 übernimmt.

[munirad7s]

Vorflug-Befund: die Ticket-Prämisse ist widerlegt — Upstream hat den Fix schon dreimal offen

Vorflug-Punkt 2 lautete „agent_error_from_json bei Upstream unverändert (niemand hat den Fix inzwischen selbst gebaut) — sonst Ticket schließen statt PR aufmachen". Die Funktion ist unverändert (nicht gemerged) — aber gebaut ist sie längst, dreimal:

block/buzz	Art	Stand
block#4084 fix(acp): preserve JSON-RPC error.data when message is present (#4069)	PR, 1 Datei, +131/−2	offen seit heute 09:50 UTC — 7 h vor unserem Fork-Commit
block#2436 fix(acp): preserve JSON-RPC error data	PR, 5 Dateien, +256/−34	offen seit 22.07.
block#4121 Fix Windows ARM64 managed Node provisioning + preserve agent error data	PR, 3 Dateien	offen seit heute 14:03 UTC
block#2422	Issue	der Bug-Report selbst, offen
block#4069	Issue	Windows-ARM64-Variante, offen

CONTRIBUTING.md: „search open PRs and issues for duplicates … Duplicates and PRs that skip this guide may be closed with a pointer here rather than a full review." Ein vierter PR wäre genau das.

Und die Money-Link-Logik des Tickets („jede Zeile, die Upstream übernimmt, müssen wir beim Merge nicht mehr verteidigen") wird von einem vierten PR nicht bedient: sobald irgendeiner der drei merged, fällt unsere Fork-Variante beim nächsten merge upstream/main sowieso weg. Ein Duplikat beschleunigt das nicht.

Was NUR wir haben: block#4084 schreibt data unredigiert ins Log

Der einzige belastbare Mehrwert unserer Version — und er ist sicherheitsrelevant:

	block#4084	unsere
data anhängen wenn message da ist	✅	✅
Truncation	eine Kappe, 2048 Zeichen, über die ganze Rendering	zwei Kappen: 500 für data.message, 200 für den Rest — die kurzen maschinenlesbaren Felder (codexErrorInfo, type, status) liegen außerhalb des Truncation-Pfads
Credential-Redaction	keine — data.to_string() geht wörtlich ins Log	rekursives ***-Maskieren credential-förmiger Keys

data kommt aus einem Adapter-Subprozess. Echot ein Adapter jemals einen Authorization-Header, einen api_key oder ein Refresh-Token in data zurück, landet das Secret in der Logdatei. Heute versteckt der Bug das, weil data komplett wegfällt — der Fix macht die Exposition neu. Das gehört gemeldet, bevor block#4084 merged.

Vorbereitet und beweisbar, aber NICHT abgefeuert

Branch fix/acp-keep-error-data liegt auf munirad7s/buzz, sauber aus upstream/main (756dd7f65) gebaut:

• genau 1 Datei, +211/−1, kein .empire/-Anteil, keine deutschen Kommentare, kein Maschinenpfad, kein Secret (gegengeprüft)
• Commit-Subject auf Conventional Commits umgestellt (fix(acp): … — wird bei Upstream zum Squash-Subject), Signed-off-by gesetzt (DCO-Check blockt sonst), interner Claude-Session-Trailer entfernt
• cargo nextest run -p buzz-acp -E 'test(agent_error_from_json)' → 9/9 passed
• Rot-Probe gegen den Upstream-Code: nur den Some(m) =>-Arm auf m.to_string() zurückgedreht, Tests behalten → 5 failed, 4 passed. Die 4 grünen sind die Verhaltens-Fixierer (message-only, data-only-Fallback, non-string message) — der Detektor kann rot werden und trifft genau das Neue.
• cargo fmt --all -- --check und cargo clippy -p buzz-acp --all-targets -- -D warnings sauber

PR-Body (englisch, Template von block/buzz) und der Review-Kommentar-Text liegen fertig vor.

Nebenbefund: #83 ist gemessen ein Upstream-Bug, kein Fork-Schaden

Der volle Suite-Lauf auf diesem Branch — also upstream/main plus genau diese eine Datei — liefert 676 tests run: 666 passed, 10 failed, und die 10 sind namentlich exakt die aus #83 (7 Fake-Agent-Fixtures, 2 Zeitfenster, 1 Steer). Ebenso die kaputt benannten C:Users…json-Dateien. Damit ist unabhängig belegt: die Windows-Rot-Suite ist reines Upstream-Verhalten, nichts davon stammt aus dem Fork.

Status

Ein PR oder Kommentar in block/buzz ist nach .empire/POLICY.md GATED (Öffentlichkeit → Issues/PRs in fremden Repos). Freigabe-Anfrage G-1258C4 ist über .empire/gate.sh in Munirs Kanal (TG msg 123). Empfehlung darin: kein vierter PR, sondern ein Review-Kommentar an block#4084 mit der Redaction-Lücke + Angebot, unseren Branch beizusteuern.

[munirad7s]

🚧 Blockiert auf Munir — Freigabe-Gate G-1258C4 ist in den Timeout gelaufen (fail-closed).

Audit-Kette (gate.sh audit, Hash-Kette über 12 Einträge intakt):

{"seq":11,"ts":"2026-08-01T19:57:37+02:00","gate_id":"G-1258C4","event":"requested"}
{"seq":12,"ts":"2026-08-01T20:22:36+02:00","gate_id":"G-1258C4","event":"timeout"}

Kein approve, kein executed. Unabhängig gegengeprüft: bei block/buzz existiert von uns kein offener PR (nur die zwei versehentlichen von heute früh, beide geschlossen) und null Kommentare an block#4084. Es ist nichts rausgegangen.

Was auf Freigabe wartet — eine Entscheidung, zwei Optionen:

	Aktion	Bewertung
A (empfohlen)	Review-Kommentar an block/buzz#4084: Redaction-Lücke melden, Code beilegen, unseren Branch anbieten	kleine Oberfläche, kein Duplikat, adressiert das einzige, was nur wir haben (Secret-Exposition durch unredigiertes data)
B	vierter PR an block/buzz	Duplikat zu block#4084/block#2436/block#4121; CONTRIBUTING.md schließt Duplikate mit Verweis
C	gar nichts	Fork behält den Fix; er fällt beim Merge weg, sobald einer der drei PRs landet. Kostet nichts außer der ungemeldeten Sicherheitslücke

Alles Nötige liegt fertig:

• Branch fix/acp-keep-error-data auf munirad7s/buzz (aus upstream/main 756dd7f65, 1 Datei, +211/−1, DCO-signiert, Conventional-Commit-Subject, 9/9 Tests, Rot-Probe 5 FAILED)
• PR-Body (englisch, block/buzz-Template) und Review-Kommentar-Text ausformuliert

Wiederaufnahme ist ein Einzeiler: gate.sh erneut mit derselben Payload anfragen; bei Freigabe abfeuern.

⚠️ Keine separate Blocker-Mail — die Eskalation ist mit der Gate-Anfrage über denselben Kanal (TG msg 123) bereits rausgegangen; eine zweite Nachricht zur selben Sache wäre Doppel-Rauschen.