# 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 `Person`s. 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.