P2: CRM-Loeschungen sichtbar machen — Espo-Audit-Zeile im Gate-Batch

[munirad7s]

Mission

Jedes delete im CRM wird sichtbar: der Gate-Batch (#10) bekommt eine Zeile aus Espos Audit-Spur, sobald ein Datensatz verschwindet.

Money-Link

Nach buzz#29, #52 und #53 kann kein API-User mehr fremde CRM-Datensätze löschen — aber „kann nicht" ist eine Annahme, solange niemand hinsieht. Espo löscht soft: ein gelöschter Lead ist für jeden normalen Lesepfad 404, der Grabstein bleibt mit deleted: true liegen. Genau deshalb kann eine stille Löschwelle heute unbemerkt laufen: KPI-Zahlen sinken, Brief-Vorrat sinkt, niemand sieht die Ursache. Eine Zeile pro Tag schließt die Lücke zwischen „gehärtet" und „bewiesen sauber".

Kontext

• Der Gate-Batch läuft täglich 20:45 (.empire/tools/ritual.sh, buzz#10) und liefert Munir eine vorgekaute Lage — der natürliche Ort für eine Löschzeile. P2: Führungsrituale auf echte Daten — Morgenbrief 08:45 + Gate-Batch 20:45 #10 gehört einem anderen Agenten; erst prüfen, ob es geschlossen ist.
• Espo-Rechtestand: buzz-agent löscht nichts, claude-mcp-admin löscht nichts (buzz#52), n8n-agent löscht nur ihm zugewiesene Lead/CTouchpoint (buzz#53). Ein Löschvorgang außerhalb des Funnel-Probes ist damit erklärungsbedürftig.
• Quellen für die Messung (nicht geraten, in buzz#52 gefunden): ActionHistoryRecord (Espo, aber read: own für Nicht-Admins), der Grabstein deleted: true in der Datenbank, und das Access-Log des Containers (docker logs agency-crm-espocrm) mit Methode + User-Agent — dort steht jedes DELETE /api/v1/<Entity>/<id> mit Zeitstempel.
• Der ACL-Wächter ([BUZZ-28] espo-acl-drift, n8n) ist das Muster: n8n misst, der Report geht in einen Kanal, Alarm nur bei Abweichung. Doktrin 3 — wiederkehrende Mechanik gehört nach n8n, nicht in den Fork.

Vorflug-Check (nach Claim, vor Arbeit)

1. P2: Führungsrituale auf echte Daten — Morgenbrief 08:45 + Gate-Batch 20:45 #10 geschlossen? Sonst dieses Ticket zurück auf ready und später wiederkommen — der Gate-Batch wird sonst zeitgleich von zwei Seiten editiert.
2. Kein anderer Agent auf n8n oder Espo.
3. Entscheiden und begründen, welche Quelle die Wahrheit ist: Access-Log (vollständig, aber ohne Record-Identität) vs. deleted: true (identitätsgenau, aber ohne Urheber-Zeitstempel) vs. ActionHistoryRecord (beides, aber Admin-Rechte nötig — und Admin-Rechte sind genau das, was diese Ticket-Reihe abgebaut hat).

Auftrag

1. Eine Messung bauen, die pro Tag beantwortet: wie viele Datensätze wurden gelöscht, von wem, welche Entity — ohne dafür einen neuen Admin-Key zu schaffen.
2. Ergebnis in den Gate-Batch einhängen: eine Zeile bei 0 Löschungen, eine benannte Liste sonst.
3. Schwelle definieren: der Funnel-Probe löscht täglich genau ein Lead + dessen Touchpoints. Alles darüber ist erklärungsbedürftig und gehört hervorgehoben, nicht nur gezählt.

Nicht-Ziele / Guardrails

• Kein neuer Espo-Admin-User und keine Rechteerweiterung für bestehende — sonst macht das Ticket kaputt, was P1: claude-mcp-admin entschaerfen — erst den Verbraucher finden, dann die Adminrechte kuerzen #52/P2: funnel-probe delete-frei machen — danach faellt delete:all beim n8n-CRM-User #53 gebaut haben.
• Keine Änderung an den Cleanup-Nodes des Funnel-Probes.
• Keine Kundendaten in Issue/PR (Zahlen und Entity-Namen reichen, keine Lead-Namen).

Verifikation (Befehle + erwartete Ausgabe)

#	Aktion	Erwartung
1	Testlöschung (ein eigener Wegwerf-Lead, admin)	erscheint in der Messung
2	Tag ohne Löschung außer dem Probe	Zeile meldet „1 (Funnel-Probe), sonst 0"
3	Gate-Batch-Lauf	Zeile ist im Kanal sichtbar
4	Kein neuer privilegierter Zugang entstanden	ACL-Wächter grün, 3/3 User unverändert

Definition of Done

• Quelle gewählt und begründet
• Messung läuft täglich, ohne neue Rechte
• Gate-Batch zeigt die Zeile, Testlöschung nachweislich sichtbar
• .empire/AGENTS.md ergänzt (via PR), Issue 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#53)

[munirad7s]

🐝 buzz_empire 2026-08-01 20:34 übernimmt.

[munirad7s]

✅ Ergebnis: Der Gate-Batch (20:45) trägt ab sofort eine CRM-Löschzeile. Jedes delete im CRM ist sichtbar — mit User, Entity und Anzahl.

Quellenwahl (Vorflug-Punkt 3), drei Kandidaten gemessen:

Quelle	Kann	Kann nicht	Urteil
Access-Log des Containers	jede DELETE-Zeile	keine Entity-Identität, kein User	verworfen
Grabstein deleted: true	identitätsgenau	kein Urheber, kein verlässlicher Löschzeitpunkt (Espo fasst modified_at beim Remove nicht an)	verworfen
action_history_record	user_id + action + target_type + target_id + created_at	über die Espo-API nur read: own → als Wächter wertlos	gewählt, aber über die DB gelesen

Entscheidend: read-only über den bestehenden ssh-Pfad (docker exec agency-crm-mariadb). Kein neuer Espo-User, kein neuer Key, keine Rechteerweiterung — ein Admin-API-Key hätte genau das kaputtgemacht, was #29/#52/#53 abgebaut haben.

Schwelle gemessen, nicht gesetzt: 8 Tage Aktionshistorie zeigen 26.07.–31.07. täglich exakt n8n-agent: 1× Lead + 1× CTouchpoint (Funnel-Probe aus #53) und sonst nichts. Das ist der Erwartungswert; alles darüber wird namentlich aufgeschlüsselt.

Verifiziert — 5 Proben am laufenden System:

#	Probe	Ergebnis
1	Ruhetag (24 h endend vor 48 h = 31.07.)	✅ 2 Löschungen — ausschließlich der Funnel-Probe (n8n-agent): 1× Lead, 1× CTouchpoint. Erwartet.
2	Ausschlag (letzte 24 h)	⚠️ 61 Löschungen, davon 59 außerhalb des Funnel-Probes + Aufschlüsselung je User
3	Detektor rot→grün	3-h-Fenster meldete 0 Löschungen; dann Wegwerf-Lead über n8n-agent (delete: own, kein Sonderrecht) angelegt und gelöscht (DELETE 200, GET danach 404); dasselbe 3-h-Fenster meldete danach 1 Löschung … 1× Lead
4	Quelle tot	RITUAL_CRM_CONTAINER=gibtsnicht → ⚠️ LÜCKE — die Löschspur wurde NICHT erhoben. Das ist kein "0 Löschungen", Grund benannt, Exit 1
5	Kein neuer Zugang	ACL-Wächter (#28) nach der Arbeit: OK buzz-agent / OK claude-mcp-admin / OK n8n-agent, Exit 0

Kanal-Beweis: echter Gate-Batch-Lauf gepostet — Buzz-Event 10f831820480c508, die Zeile steht drin.

0 ist kein Ruhezustand: bei 0 Löschungen meldet die Zeile ausdrücklich, dass auch der Funnel-Probe nichts gelöscht hat, und nennt den Zeitpunkt der letzten Löschung überhaupt — sonst sähe ein toter Probe-Workflow wie ein sauberer Tag aus.

Gefangene Falle: Die erste Fassung schrieb im Gutfall die feste Formel „(n8n-agent, 1× Lead + 1× CTouchpoint)". Bei genau einem gelöschten Lead behauptete der Führungsbrief damit einen CTouchpoint, den es nicht gab. Die Zusammensetzung wird jetzt gerechnet — auch der Gutfall wird gemessen, nicht formuliert. Steht als Regel in .empire/AGENTS.md.

Gemerged: #111. Live: ja — der nächste 20:45-Lauf (Windows-Aufgabe) trägt die Zeile ohne weiteres Zutun.