«Плавающие» ошибки в проектах. Как поставить задачу так, чтобы их избежать и не прослыть придирой и формалистом

Частично или полностью эту задачу можно (и нужно!) поручить тестировщикам

Кхм... Ну, хоть не техподдержке - и на том спасибо...

Рассмотреть все частные случаи разрабатываемого процесса

По мере перебора крайностей документация всё пухнет-пухнет, а вероятность поймать дефект логики в конечном продукте всё не падает и не падает...

Подумать и сформулировать набор правил для каждой сущности.

Вы использовали слишком общие сущности в качестве примера. У читателя могут возникнуть стрёмные идеи по итогу. Идеи, коих Вы в виду не имели, надеюсь.

Я полагаю, что Вы задумывали написать что-то о разделении единого кома проекта на конечное количество самодостаточных И НЕ ДЕЛИМЫХ МЕЛЬЧЕ без потери контекста сущностей.

Т. е. набор сущностей для примера должен быть не "«Переписка», «Оплата», «Отзывы»" (что слишком крупно для адекватного ТЗ), а что-то вроде "письмо в переписке", "транзакция в системе оплаты" и "отзыв".
Причём, каждая из этих сущностей имеет при себе не только перечень правил обработки, но и ПРИМЕРНЫЙ перечень обязательных атрибутов (в примере - ID автора для всех трёх, привязка к задаче для всех трёх, текстовое содержание для всех трёх (с указанием, где зачем текст будет использоваться), цифровое значение рейтинга для отзыва (и его способ отображения на фронтэнде)), etc-etc.

При таком делении можно накрыть уйму блох одной шапкой (и даже облегчить программистам задачу по дальнейшей проработке архитектуры), заранее прикинув, где у нас похожие (или даже полностью идентичные) операции (и заранее их сгруппировав или даже объединив), какие данные лучше объединить в какие таблицы, какие сущности у нас вообще дублируются (и подумать - а может, не дублируются?), может быть даже заранее стребовать и включить в ТЗ какое-то кэширование...

Но вот беда...

А так уж устроен наш мозг, что ему нужна конкретика и образы, а не полотна с текстом!

Риск услышать ненавистное мне "Лень читать!" (о, если бы только это...) в этом случае и правда велик.

Причём, независимо от способа отображения и последующей интерпретации ТЗ.

Способа заставить программиста "попасть" в ТЗ (и при этом не наделать дефектов логики, именуемых Вами как "плавающие ошибки"), при этом не заставляя читать ТЗ, мне не известно.

Мне эта задача видится как требующая решения на уровне архитектуры приложения. Если это фактически самое самое важное место в программе, вокруг которого вращается все, то я бы выделил его в независимую единицу с четким интерфейсом, грубо говоря "движок приложения" (есть шаблоны архитектурные для таких типовых задач), и покрыл бы юнит тестами так, чтобы мышь не проскочила.

Если, конечно, писать "сверху вниз" безо всякой архитектуры, тогда логика расползется по всему коду, будет нечитаемая каша, страх изменений и постоянный регресс. (Страх кстати и есть одна из причин ругани в команде). Дальнейший рефекторинг станет сложным. Интервалы релизов будут увеличиватсья. Тестирование превратится в гонку на время. По причине этого введут автоматизацию тестирования, которая не решит это проблему. Это перекладывание отсутствующих тестов с уровня кода (юнит-тесты) на уровень пользовательского интерфейса. Где они сложнее, и менее надежны по своей природе.

требует от нас предварительно проделать достаточно большой объем аналитической работы

Опыт подсказывает, что без "достаточно большого объема аналитической работы" любая система средней сложности и выше не взлетит.