familienarchiv/docs/adr/030-briefwechsel-removal-unidirectional-search.md

ADR-030 — Removing Briefwechsel trades bidirectional correspondence for a unidirectional search filter

Date: 2026-06-02 Status: Accepted Issue: #716 (remove the Briefwechsel view; retarget its links to document search) Milestone: —

---

Context

The standalone Briefwechsel view (/briefwechsel) was a bilateral letter timeline between two Persons. It was not in the main navigation; its only inbound product link was the "Häufige Korrespondenten" card on a person's detail page. It was backed by a dedicated endpoint (GET /api/documents/conversation) and two repository queries (findConversation, findSinglePersonCorrespondence) that nothing else used.

The view's data source, findConversation, was bidirectional: it returned letters where (sender = A AND receiver = B) OR (sender = B AND receiver = A) — i.e. the exchange in both directions. We removed the view entirely (frontend and backend) and retargeted the one inbound link into the existing document search (/documents?senderId=A&receiverId=B).

Document search composes its senderId/receiverId filters with AND (sender.id = A AND receivers contains B), so the retargeted link shows only the A→B direction. The reverse direction (B's replies to A) is no longer surfaced by clicking a correspondent.

Decision

Accept the behaviour change: the retargeted card link is unidirectional (A→B only). The reverse direction is intentionally dropped rather than preserved with a redirect shim or a new bidirectional search filter.

• The card link sets both params (senderId=A&receiverId=B); the destination is the consistent, already-tested document search rather than a separate dedicated view.
• The "×N" badge on each correspondent chip remains bilateral — it counts shared letters in both directions as a relationship-strength signal — so the badge may exceed the unidirectional search result count. This is surfaced in the badge's title, not recomputed.

Consequences

• Regression: a reader can no longer reach B→A replies in one click from the correspondents card. They must run a second search with sender/receiver swapped.
• The bilateral query code (findConversation, findSinglePersonCorrespondence, the /api/documents/conversation endpoint, and the getConversationFiltered service method) is fully removed — no dormant dead code.
• No data migration and no schema change: only query/endpoint code was removed; the documents, persons and join tables are untouched. The hasSender/hasReceiver specifications stay — document search still uses them.
• Future enhancement (out of scope here): a bidirectional "between these two people, either direction" document-search filter would restore the dropped direction without reviving the standalone view. If built, it supersedes the unidirectional link.