Целостность сайта: end-to-end за один проход

full-functional-qa-end-to-end охотится за багами и нарушениями корректности: работает ли функция, не падает ли 500, нет ли IDOR. Этот orchestrator отвечает на другой вопрос: внутренне ли согласован сайт и насколько хорошо всё работает. Разница между «кнопка Delete работает» (QA) и «кнопка Delete в трёх разных местах выглядит, формулируется и ведёт себя одинаково, и нигде не fragile под стрессом» (integrity).

Применяй этот orchestrator когда у продукта накопился drift: несколько спринтов новых фич, несколько разработчиков, дизайн «немного разъехался» — и никто не смотрел на сайт как на целое.

Product: {{product_url}} Context: {{context}}

Когда применять

• Перед polish milestone или крупным публичным запуском — убедиться что продукт выглядит и ведёт себя как единое целое
• После серии быстрых спринтов, где новые фичи добавлялись без оглядки на соседние
• После онбординга нового дизайнера или разработчика в команду
• Перед демо инвестору или партнёру — первое впечатление решает

Когда НЕ применять:

• На MVP до достижения product-market fit — избыточный overhead, фокус должен быть на validated learning
• Как per-PR QA — слишком тяжело; для PR используй smoke + targeted regression
• Как замену full-functional-qa-end-to-end — те два аудита дополняют, не дублируют друг друга; при серьёзном релизе запускай оба

4 фазы

Phase 1: UI-консистентность и паритет (день 1 — полный)

Цель: найти все визуальные расхождения — где одинаковые элементы выглядят или анимируются по-разному.

Действия:

• Пройти все surfaces с открытым реестром расхождений: кнопки, отступы, цвета, типографика, анимации, иконки
• Зафиксировать каждое отклонение: что отличается, где именно, каково ожидаемое значение
• Отдельно: mobile vs desktop паритет — нет ли элементов которые на мобайле выглядят принципиально иначе без дизайн-причины
• Отдельно: light/dark паритет (если есть темы)

Output: divergence ledger — таблица расхождений с точными значениями, именами файлов и способом исправления. Done when: ledger сформирован, каждое расхождение имеет severity и canonical value.

Использовать: ui-consistency-parity-audit.

Phase 2: Логическое соответствие между фичами (день 2 — полный)

Цель: найти все правила продукта, которые нарушены в каком-либо из контекстов.

Действия:

• Сформулировать имплицитные правила продукта: «деструктивное действие всегда требует подтверждения», «даты показываются в относительном формате до 24 часов», «admin может удалять везде»
• Проверить каждое правило по всем surfaces: где нарушается? какая версия поведения каноничная?
• Отдельно: терминология — одно ли слово используется для одной сущности по всему продукту?
• Отдельно: форматы — даты, числа, валюта, статусы — единообразны?

Output: conformance matrix — правило × surface × pass/fail; violation list с canonical resolution; terminology audit. Done when: 0 unresolved Critical violations; все High violations имеют assigned fix.

Использовать: cross-feature-logic-conformance.

Phase 3: Глубокая проверка качества функций (день 3 — полный)

Цель: убедиться что каждая критическая функция не просто работает, но работает хорошо — под стрессом, с плохими данными, при прерывании.

Действия:

• По каждой критической функции пройти стресс-сценарии: пустой/плохой ввод, double-submit, Slow 3G, offline mid-action, back button, refresh mid-state
• Выставить Robustness Score 0-3 по рубрике (0 = broken, 1 = fragile, 2 = works-but-janky, 3 = solid)
• Оценить воспринимаемое качество: latency feedback ≤100ms, layout shift, optimistic UI rollback

Output: quality score table по функциям + blockers (score 0-1) с repro + polish backlog (score 2). Done when: 0 blockers score 0; все score 1 имеют assigned fix; score 2 занесены в backlog с effort.

Использовать: functional-verification-deep-test.

Phase 4: Синтез — единый integrity report (день 4 — половина дня)

Цель: объединить три ledger'а из фаз 1-3 в один приоритизированный integrity report; исключить дублирование находок; определить exit bar.

Действия:

Дедупликация: пройти по всем трём отчётам и найти overlapping findings (например, кнопка с неправильным цветом И неправильным поведением при double-submit — это два отдельных бага, не один).

Приоритизация по матрице severity × effort:

Fix sequence: упорядочить top-20 fixes в последовательность с учётом зависимостей (UI-консистентность часто блокирует logic fixes если они в одних файлах).

Definition of coherent — измеримые exit criteria для «integrity достигнута»:

• 0 расхождений severity High в divergence ledger
• 0 Critical violations в conformance matrix
• 0 blockers (score 0) в quality score table
• Score 1 функции: ≤2 (minor fragile, нет data-loss)
• Terminology: 0 synonyms для core entities
• Format audit: 0 conflicting formats для date/currency

Output: INTEGRITY_REPORT.md со структурой:

1. Executive summary — три цифры: расхождения / нарушения / fragile functions
2. Divergence ledger (из Phase 1) — с severity и canonical
3. Conformance matrix (из Phase 2) — с violation list
4. Quality score table (из Phase 3) — с blockers и polish backlog
5. Priority fix list — top-20 severity × effort
6. Fix sequence — numbered с зависимостями
7. Definition of coherent — exit bar с конкретными числами
8. Won't fix — явно задокументировано с обоснованием

Контракт между фазами

• 1 → 2: divergence ledger сформирован — иначе logic violations смешиваются с UI-расхождениями
• 2 → 3: conformance matrix готов — иначе quality check не знает что считать canonical behaviour
• 3 → 4: все три отчёта собраны — синтез без полных данных даёт неполный exit bar

Anti-patterns

• ❌ Начинать с Phase 4 (синтеза) без завершения остальных — нечего синтезировать
• ❌ Объединять Phase 1 и Phase 2 в один проход — разные фокусы; смешивание снижает качество каждого
• ❌ Считать overlapping finding одним — UI-расхождение и logic violation в одном месте — два разных типа долга
• ❌ Exit bar «всё fixed» — нереалистично; exit bar должен быть measured, не absolute
• ❌ Пропустить Phase 3 «потому что QA уже проверял» — full-functional-qa-end-to-end проверял корректность, не quality под стрессом
• ❌ Запускать без контекстной информации о намеренных исключениях — не все отличия это баги; некоторые задокументированы как intentional
• ❌ Забыть про email/push notifications в Phase 2 — они часть продукта и нарушают terminology и форматы чаще всего

Output

Финальный артефакт — INTEGRITY_REPORT.md с разделами из Phase 4.

Цель не «продукт идеально согласован» (такого не бывает после активной разработки), а «все несогласованности известны, приоритизированы и имеют план». Этот orchestrator — система которая отделяет intentional design decisions от накопившегося drift.