docs: Agent-Definitionen bereinigt (192.168.1.131 raus) + Dual-Source-Falle dokumentiert

192.168.1.131 gehört seit 2026-09-01 nicht mehr zum archivmail-Projekt (User-Bestätigung).
Alle Referenzen in CLAUDE.md und Agent-Defs auf den verbleibenden Server 192.168.1.132
korrigiert (Test/Prod-Paar existiert nicht mehr).

Zusätzlich Erkenntnisse aus PROJ-86-Audit (Subagenten db-migrator + mailarchiv-architect)
in die Agent-Defs eingearbeitet: emails.tenant_id vs. email_refs Dual-Source-Falle,
MailDocument-Fan-out-Drift-Muster, emails_global-Mirror-Pflicht, --tenant-Reindex-Lücke.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UPFC6Jk2ke1Pq9XcuVGP1R

.claude/agents/mailarchiv-architect.md

@@ -16,7 +16,7 @@ Du entwickelst **archivmail** – ein selbst gehostetes, unternehmenstaugliches
 - Frontend: Next.js 16 (App Router), TypeScript, Tailwind CSS, shadcn/ui
 - Datenbank: PostgreSQL (pgx/v5)
 - Volltext-Index: Manticore Search (MySQL-Protokoll, Port 9306)
-- Deployment: Debian on-premise (192.168.1.131), Systemd
+- Deployment: Debian on-premise (192.168.1.132), Systemd
 
 **Go-Modul: `archivmail`** — Imports sind immer `archivmail/internal/...`, NIEMALS `github.com/archivmail/...`
 
@@ -32,6 +32,29 @@ Gedächtnis annehmen (die Datei wird laufend fortgeschrieben).
 4. **Modularer Code** – klare Interfaces, lose Kopplung, hohe Kohäsion
 5. **Ressourcenschonend** – <200 MB RAM, optimierter Disk-Zugriff
 
+## Bekanntes Strukturproblem: MailDocument-Fan-out-Drift (PROJ-86, 2026-09-01)
+
+10 Stellen bauen `index.MailDocument{}` manuell (internal/pop3/importer.go:167,
+internal/imap/importer.go:289, internal/api/upload.go:216, cmd/archivmail/cmd_index_pending.go:133,
+cmd_import.go:270, cmd_reindex.go:119, cmd_fix_subjects.go:248, main.go:609+751,
+cmd/archivmail-import/main.go:124) plus separate Delete-Pfade (cmd_purge.go,
+dsgvo_handlers.go). Grund: Ingest-Vielfalt (IMAP/POP3/SMTP/Upload/CLI-Import/Reindex/
+Backfill/Purge) × wachsende Fan-out-Pflichten (Global-Mirror-Index, Datums-Fallback,
+email_refs-Sync) — jede neue Pflicht multipliziert sich mit der Zahl der Ingest-Pfade.
+Zwei reale Produktionsbugs binnen kurzer Zeit entstanden genau so (emails_global bekam
+nie Tenant-Mails gespiegelt; date_ts=0 bei fehlendem Date-Header).
+
+**Empfehlung bei künftigen Änderungen an MailDocument/Indexierung:** Nicht an allen 10
+Stellen einzeln nachziehen (Copy-Paste-Konsistenz = Antipattern). Stattdessen zwei
+schmale zentrale Funktionen einführen (noch nicht umgesetzt, ~0,5-1 PT):
+1. `index.NewMailDocument(...)` — reiner Konstruktor, setzt alle Pflichtfelder inkl.
+   `EffectiveDate`-Fallback korrekt, ersetzt die 10 manuellen Struct-Literale.
+2. `index.IndexWithMirror(ctx, tenantIdx, doc)` / `DeleteWithMirror(...)` — schreibt
+   immer sowohl `emails_tenant_N` als auch `emails_global`, ersetzt die 5
+   Doppel-Write-Stellen.
+`email_refs`-Sync bewusst NICHT mit hineinpacken — das ist ein eigenständiges
+Datenmodell-Problem (siehe db-migrator.md), keine Index-Fabrik-Aufgabe.
+
 ## Systemarchitektur
 
 ### Tatsächliche Projektstruktur
@@ -207,7 +230,7 @@ mitübernehmen kann.
 
 Nach Abschluss von Implementierungsarbeiten:
 
-- **→ devops-deploy**: Wenn Code bereit zum Testen/Deployen ist — Agent führt `update.sh` zuerst auf 192.168.1.132 (Test) aus, nach erfolgreicher Prüfung erst auf 192.168.1.131 (Produktiv)
+- **→ devops-deploy**: Wenn Code bereit zum Testen/Deployen ist — Agent führt `update.sh` auf 192.168.1.132 (einziger Server, seit 2026-09-01 kein separater Testserver mehr) aus
 - **→ manticore-admin**: Wenn der Manticore-Index-Schema geändert wurde (neue Felder, neue Tabellen) — Agent führt `ALTER TABLE` + `reindex` durch
 - **→ QA Engineer**: Wenn Feature implementiert ist und gegen Acceptance-Criteria getestet werden soll