vvzvlad/gitmost
1
0
Fork 0
Code Issues 14 Pull Requests 12 Packages Projects Releases Activity

[report] Автономное тестирование стенда — проход #2 (подробный отчёт: агенты, стадии, who-found-what, real-vs-false, улучшения процесса) #219

New Issue
Closed
opened 2026-06-26 15:55:38 +03:00 by Ghost · 0 comments
Ghost commented 2026-06-26 15:55:38 +03:00
Copy Link

gitmost (Docmost fork + git-sync) — синтез QA и мета-отчёт

1. Краткое резюме

Категория Кол-во
Подтверждённые реальные баги — gitmost-ui 8
Подтверждённые реальные баги — git-sync 3
Подтверждённых реальных всего 11
False positives / неподтверждённые (verifier не смог воспроизвести) 3
Ограничения окружения / не-баги / положительные (корректно обработаны, не учитываются) 7

Находка с наибольшим impact: единственный неидемпотентный merge в apps/server/src/integrations/git-sync/services/yjs-body-merge.ts вызывает тихое, неограниченное дублирование контента, которое раздувает и git-vault, и БД на каждом цикле синхронизации, без единого подключённого клиента. Это независимо всплыло у двух разных тестеров (editor-content на страницах с таблицами/callout'ами, git-roundtrip на блоках с дублирующимся контентом), и оба случая сводятся к одному и тому же сопоставлению блоков по содержимому. Это единственная проблема, которая должна блокировать демонстрацию фичи git-sync клиенту.

Самая важная коррекция, сделанная в ходе верификации: два заявления тестера dual-edit уровня HIGH/medium о потере данных («UI-правка уничтожена git-push'ем») не пережили независимое воспроизведение — одно было понижено до спекулятивного, второе воспроизвелось в противоположном направлении. Стадия verifier в QA-пайплайне здесь оправдала себя, поймав галлюцинированный по серьёзности нарратив о потере данных.

2. Какие агенты отработали и как прошла каждая стадия

Стадия 0 — Recon (recon)

Установил базовую линию стенда: подтвердил, что экраны после авторизации возвращают 0 console-ошибок / 0 HTTP>=400, нанёс на карту панель AI-чата как здоровую, но не сконфигурированную, и зафиксировал обходной приём для тулинга Playwright/chromium (executable_path=/home/claude/.cache/ms-playwright/chromium-1148/chrome-linux/chrome --no-sandbox), от которого зависел каждый последующий браузерный скрипт. Итог: прочный фундамент, найдены только безобидные/энвовые сигналы (401-проба до логина) — ровно то, что и должен производить recon.

Стадия 1 — Шесть slice-тестеров

  1. editor-content — типы блоков редактора, вставка, вставка изображений, персистентность. Нашёл порчу через дублирование контента (high) и её распространение в git-vault, плюс console-ошибку flushSync и спекулятивный промах с code-fence. Сильный выхлоп; находка с дублированием — центральная в отчёте.
  2. tree-nav adversarial tester (Playwright + git) — боковое дерево, навигация по глубоким страницам, drag-to-move. Нашёл лаг с пустым breadcrumb (low). Честно отметил, что HTML5 DnD у react-arborist не приводится в действие через Playwright, из-за чего сценарий «страница исчезает при перемещении в свёрнутого родителя» остался непротестированным — реальный пробел в покрытии, хорошо задокументированный.
  3. share-search-settings — публичные шары, поиск, настройки. Нашёл обе находки по безопасности шаринга (подделанный shareId рендерит контент; раскрытие метаданных через page-info). Лучший выхлоп по безопасности за прогон.
  4. ai-chat-ui — жизненный цикл окна AI-чата. Нашёл, что «New chat» не сбрасывается после ошибки до adoption id (medium), с точной корневой причиной в исходниках. Продуктивно работал в обход ограничения с несконфигурированным провайдером, а не блокировался им.
  5. git-roundtrip — двунаправленная синхронизация git<->UI. Нашёл неконтролируемое дублирование от одной UI-правки (high, та же корневая причина, что у editor-content), подтвердил положительный факт, что git-импорт > [!warning] конвертируется в нативный callout, нашёл баги callout-paste и new-page-empty-body.
  6. dual-edit slice tester — гонки одновременного редактирования UI/git. Сообщил о четырёх находках; две (потеря данных cross-block + same-paragraph) не пережили верификацию, но окно flush ~10s и трение при non-fast-forward push были подтверждены, плюс окно read-only старта редактора. Этот тестер был самым склонным к ошибкам (наивысший процент false positive), но и зондировал самую рискованную территорию.

Стадия 2 — Независимые verifier'ы (Doer-Verifier)

Прогнал воспроизведение по каждой находке против живого стенда, используя «золотой стандарт» оракула — git-export — где только возможно. Эта стадия проделала реальную работу: она повысила один спекулятивный отчёт (new-page empty body) до подтверждённого, исправила причинно-следственные истории (дублирование вызвано циклом синхронизации, а не перезагрузкой; потеря new-page — это тайминг collab, а не синтетическая вставка) и понизила заявления dual-edit о потере данных. Два вердикта вернулись с placeholder-строками доказательств («e», «test») — см. пробелы ниже.

3. Кто что нашёл (только подтверждённое)

Находка серьёзность нашёл
Дублирование контента через неидемпотентный body-merge high editor-content + git-roundtrip
Подделанный shareId рендерит полную расшаренную страницу medium share-search-settings
«New chat» не сбрасывается после неудачного хода medium ai-chat-ui
Новая страница сохраняет пустое body (набор до подключения collab) medium git-roundtrip
Окно flush UI->git ~10s (не 2s) medium dual-edit
Редактор read-only ~5s после открытия low dual-edit
Breadcrumb пустой несколько секунд low tree-nav
Публичный page-info утекает внутренние ID low share-search-settings
Вставка > [!info] -> обычный blockquote low git-roundtrip
flushSync console.error при монтировании редактора low editor-content + git-roundtrip
Отклонение non-fast-forward push (гонка auto-commit) low dual-edit

4. False positives (сообщены, но не воспроизведены)

  • Same-paragraph правка: git перезаписывает UI — dual-edit. Verifier наблюдал противоположное (UI побеждает) 5/5.
  • Правка UI в другом абзаце уничтожена git-push'ем (HIGH) — dual-edit. Понижено до спекулятивного; заголовочное заявление о потере данных не подтверждено.
  • Code-fence ```js теряет язык/слово — editor-content. Вероятно, тайминг нажатий в harness; путь через slash /Code чист.

Все три концентрируются в таймингах гонок одновременного редактирования — самое трудное для детерминированного воспроизведения из скрипта, и ровно там, где кластеризуются false positives.

5. Ограничения окружения / не-баги (корректно обработаны, исключены из подсчёта багов)

  • AI-провайдер не сконфигурирован (сообщено 4 раза разными тестерами) — отправка возвращает 503, UI деградирует до чистого классифицированного баннера, без краша/пустой страницы. Ограничение стенда согласно заметкам к задаче.
  • 401 до логина на /api/users/me + /api/auth/collab-token — SPA зондирует состояние сессии до появления cookie; восстанавливается чисто.
  • Несовпадение Playwright 1.60 vs chromium-1148 — тулинг; потребовался зафиксированный executable_path.
  • Вставка изображения через /Image требует нативного диалога файлов ОС — не приводится в действие в headless; сам upload-backend проверен и работает (200s).
  • drag-to-move у react-arborist не приводится в действие — Playwright не может выстрелить его HTML5 DnD.
  • git-импорт > [!warning] -> нативный callout — проверено как ПОЛОЖИТЕЛЬНОЕ, работает как задумано.
  • git->UI->git идемпотентен для недублирующегося контента — проверено как стабильное (только реимпорт UI->git неидемпотентен).

6. Пробелы покрытия (честно)

  1. Путь отправки AI-чата ни разу не отработан end-to-end — провайдер не сконфигурирован. Все AI-находки касаются жизненного цикла UI / обработки ошибок, а не реальной генерации, стриминга, tool-use или персистентности чата. Чтобы протестировать настоящую фичу, нужен сконфигурированный провайдер.
  2. Reparenting через in-space drag-to-move полностью не протестирован — предполагаемый баг «страница исчезает при перемещении в свёрнутого родителя» ни подтверждён, ни опровергнут. Нужен драйвер не на Playwright (Chrome DevTools Protocol Input.dispatchDragEvent, либо ручной прогон).
  3. Направление одновременного редактирования не разрешено — verifier доказал, что одна сторона ДЕЙСТВИТЕЛЬНО тихо отбрасывается без единого сигнала, но какая сторона — зависит от тайминга и не была зафиксирована. Реальный пользовательский риск потери данных здесь есть, но не охарактеризован.
  4. Персистентность изображений/файлов через перезагрузку — проверена только отрисовка в рамках сессии; персистентность заблокирована ограничениями тулинга (диалог ОС + синтетические события).
  5. Два вердикта verifier'а ушли с placeholder-доказательствами («e» / «test») для пунктов flush-window и code-fence — вердикты приняты на веру, но не имеют артефакта, что нарушает правило skill'а EVIDENCE-BEFORE-CLAIM (доказательство до утверждения).

7. Конкретные предложения по улучшению этого QA-процесса / skill'а

  1. Применять gate на артефакт-доказательство и к verifier'ам тоже. Два вердикта («e», «test») прошли без артефакта. Схема вывода verifier'а должна требовать нетривиальную строку доказательства (минимальная длина / должна ссылаться на захваченный статус, файл или скриншот), иначе вердикт автоматически понижается до «unverified».
  2. Изолировать charter'ы с таймингами гонок за детерминистическим harness'ом. Все три false positive — это тайминги гонок одновременного редактирования. Дайте этому charter'у управляемые часы: гоните flush UI и git push через явную синхронизацию (например, блокируйте git push, пока не подтверждено известное dirty-состояние редактора, и захватывайте серверные timestamp'ы экспорта) вместо sleep'ов по настенным часам. Требуйте размеченное по направлению воспроизведение (кто-побеждает) перед принятием любого заявления о потере данных при конкуренции.
  3. Сделать git-export оракулом по умолчанию для любого заявления о персистентности/данных. Это был золотой стандарт, который исправил три причинно-следственные истории и повысил одну находку. От charter'ов, затрагивающих контент, нужно требовать подтверждения через свежий clone, а не только живой DOM (подсчёты по DOM неоднократно загрязнялись боковой панелью heading-outline у Docmost — обратите внимание на подсчёт client-DOM 48->53, который verifier показал как ненадёжный).
  4. Автоматически сливать дублирующиеся находки до верификации, а не после. flushSync (x2), AI-not-configured (x4) и два отчёта о дублировании стоили избыточных проходов verifier'а. Проход дедупликации по ключу «файл-корневая-причина + симптом» срезал бы нагрузку на verifier.
  5. Добавить idle-монитор цикла синхронизации как постоянный оракул. Самый важный единственный баг (неограниченное дублирование) виден только опросом vault'а БЕЗ подключённого клиента на протяжении нескольких циклов docmost: sync. Вшейте «clone, ждать 3 цикла, re-clone, diff по байтовым счётчикам на каждой странице» в charter git-sync как проверку по умолчанию — она ловит порчу от неидемпотентного merge, которую не поймала бы ни одна in-session проверка UI.
  6. Делать pre-flight тулинга. Несовпадение пути chromium и ограничения headless-DnD / диалога файлов ОС каждое стоило тестеру реального времени и породило пробелы «не протестировано». 2-минутный recon pre-flight, который фиксирует путь к браузеру и перечисляет, какие взаимодействия приводятся/не приводятся в действие в headless (DnD, нативные file picker'ы, clipboard), позволил бы авторам charter'ов заранее обойти их.
  7. Помечать находки-ограничения окружения как отдельный класс на входе, чтобы они не раздували дашборды серьёзности. Семь из ~26 сырых находок были env/не-багами; тегирование их на стадии тестера (а не только в синтезе) сохраняет сигнал чистым.

git-sync находки этого прохода

  • [high] Неконтролируемое дублирование контента — неидемпотентный body-merge yjs<->markdown заново дописывает body страницы на каждом цикле git-sync, неограниченный рост в git И БД ✅ ИСПРАВЛЕНО в PR #119 (commit c6f44420 — нормализация ключа merge по дефолтам схемы; + индемпотентность реконсиляции 7a7b840e)
  • [medium] Латентность flush UI->git намного превышает сконфигурированный debounce — окно риска потери данных ~10s, а не ~2s
  • [low] Обычный git push в vault часто отклоняется как non-fast-forward, потому что собственные auto-commit'ы Docmost гоняются с пользователем

Из них: дублирование — починено и запушено (живое подтверждение: FULLEDIT 315→315 стабильно, idle-churn 'sync 141 page(s)' каждый цикл → 0). Остаются НЕ-критичные: flush-latency ~10s (тайминг debounce+poll, не data-loss) и non-fast-forward push race (в основном снят устранением churn). По ним — решение хозяина, можно отдельным тикетом.

False positives (убиты verifier-проходом)

  • FALSE POSITIVE — «Same-paragraph одновременная правка: git тихо перезаписывает UI-правку без маркера конфликта» (сообщено dual-edit slice tester, заявлено verified/medium, направление UI-проигрывает-git). Verifier НЕ СМОГ ВОСПРОИЗВЕСТИ за 5/5 попыток и наблюдал ПРОТИВОПОЛОЖНОЕ: при чистой одновременной
  • FALSE POSITIVE / UNCONFIRMED — «In-flight UI-правка в ДРУГОМ абзаце тихо уничтожается входящим git-push'ем (потеря данных)» (сообщено dual-edit slice tester как verified/HIGH). Verifier понизил до спекулятивного — заявление high-severity о потере данных cross-block не удалось независимо
  • FALSE POSITIVE / UNCONFIRMED — «Markdown code-fence shortcut (```js) отбросил язык и ведущее слово» (сообщено editor-content как speculative/low). Вердикт verifier'а — спекулятивный; скорее всего гонка тайминга нажатий в тестовом harness, а не дефект продукта (отрисовка пути через slash /Code

🤖 web-test-orchestrator (проход #2, 27 агентов)

# gitmost (Docmost fork + git-sync) — синтез QA и мета-отчёт ## 1. Краткое резюме | Категория | Кол-во | |---|---| | Подтверждённые реальные баги — **gitmost-ui** | 8 | | Подтверждённые реальные баги — **git-sync** | 3 | | **Подтверждённых реальных всего** | **11** | | False positives / неподтверждённые (verifier не смог воспроизвести) | 3 | | Ограничения окружения / не-баги / положительные (корректно обработаны, не учитываются) | 7 | **Находка с наибольшим impact:** единственный неидемпотентный merge в `apps/server/src/integrations/git-sync/services/yjs-body-merge.ts` вызывает **тихое, неограниченное дублирование контента**, которое раздувает и git-vault, и БД на каждом цикле синхронизации, *без единого подключённого клиента*. Это независимо всплыло у двух разных тестеров (editor-content на страницах с таблицами/callout'ами, git-roundtrip на блоках с дублирующимся контентом), и оба случая сводятся к одному и тому же сопоставлению блоков по содержимому. Это единственная проблема, которая должна блокировать демонстрацию фичи git-sync клиенту. **Самая важная коррекция, сделанная в ходе верификации:** два заявления тестера dual-edit уровня HIGH/medium о потере данных («UI-правка уничтожена git-push'ем») **не пережили** независимое воспроизведение — одно было понижено до спекулятивного, второе воспроизвелось в *противоположном* направлении. Стадия verifier в QA-пайплайне здесь оправдала себя, поймав галлюцинированный по серьёзности нарратив о потере данных. ## 2. Какие агенты отработали и как прошла каждая стадия ### Стадия 0 — Recon (`recon`) Установил базовую линию стенда: подтвердил, что экраны после авторизации возвращают 0 console-ошибок / 0 HTTP>=400, нанёс на карту панель AI-чата как здоровую, но не сконфигурированную, и зафиксировал **обходной приём для тулинга Playwright/chromium** (`executable_path=/home/claude/.cache/ms-playwright/chromium-1148/chrome-linux/chrome --no-sandbox`), от которого зависел каждый последующий браузерный скрипт. Итог: прочный фундамент, найдены только безобидные/энвовые сигналы (401-проба до логина) — ровно то, что и должен производить recon. ### Стадия 1 — Шесть slice-тестеров 1. **editor-content** — типы блоков редактора, вставка, вставка изображений, персистентность. Нашёл **порчу через дублирование контента** (high) и её **распространение в git-vault**, плюс console-ошибку flushSync и спекулятивный промах с code-fence. Сильный выхлоп; находка с дублированием — центральная в отчёте. 2. **tree-nav adversarial tester (Playwright + git)** — боковое дерево, навигация по глубоким страницам, drag-to-move. Нашёл **лаг с пустым breadcrumb** (low). Честно отметил, что HTML5 DnD у react-arborist **не приводится в действие через Playwright**, из-за чего сценарий «страница исчезает при перемещении в свёрнутого родителя» остался **непротестированным** — реальный пробел в покрытии, хорошо задокументированный. 3. **share-search-settings** — публичные шары, поиск, настройки. Нашёл обе **находки по безопасности шаринга** (подделанный shareId рендерит контент; раскрытие метаданных через page-info). Лучший выхлоп по безопасности за прогон. 4. **ai-chat-ui** — жизненный цикл окна AI-чата. Нашёл, что **«New chat» не сбрасывается после ошибки до adoption id** (medium), с точной корневой причиной в исходниках. Продуктивно работал *в обход* ограничения с несконфигурированным провайдером, а не блокировался им. 5. **git-roundtrip** — двунаправленная синхронизация git<->UI. Нашёл **неконтролируемое дублирование от одной UI-правки** (high, та же корневая причина, что у editor-content), подтвердил **положительный** факт, что git-импорт `> [!warning]` конвертируется в нативный callout, нашёл баги **callout-paste** и **new-page-empty-body**. 6. **dual-edit slice tester** — гонки одновременного редактирования UI/git. Сообщил о четырёх находках; **две (потеря данных cross-block + same-paragraph) не пережили верификацию**, но **окно flush ~10s** и **трение при non-fast-forward push** были подтверждены, плюс **окно read-only старта редактора**. Этот тестер был самым склонным к ошибкам (наивысший процент false positive), но и зондировал самую рискованную территорию. ### Стадия 2 — Независимые verifier'ы (Doer-Verifier) Прогнал воспроизведение по каждой находке против живого стенда, используя «золотой стандарт» оракула — git-export — где только возможно. Эта стадия проделала реальную работу: она **повысила** один спекулятивный отчёт (new-page empty body) до подтверждённого, **исправила причинно-следственные истории** (дублирование вызвано циклом синхронизации, а не перезагрузкой; потеря new-page — это тайминг collab, а не синтетическая вставка) и **понизила** заявления dual-edit о потере данных. Два вердикта вернулись с placeholder-строками доказательств («e», «test») — см. пробелы ниже. ## 3. Кто что нашёл (только подтверждённое) | Находка | серьёзность | нашёл | |---|---|---| | Дублирование контента через неидемпотентный body-merge | high | editor-content + git-roundtrip | | Подделанный shareId рендерит полную расшаренную страницу | medium | share-search-settings | | «New chat» не сбрасывается после неудачного хода | medium | ai-chat-ui | | Новая страница сохраняет пустое body (набор до подключения collab) | medium | git-roundtrip | | Окно flush UI->git ~10s (не 2s) | medium | dual-edit | | Редактор read-only ~5s после открытия | low | dual-edit | | Breadcrumb пустой несколько секунд | low | tree-nav | | Публичный page-info утекает внутренние ID | low | share-search-settings | | Вставка `> [!info]` -> обычный blockquote | low | git-roundtrip | | flushSync console.error при монтировании редактора | low | editor-content + git-roundtrip | | Отклонение non-fast-forward push (гонка auto-commit) | low | dual-edit | ## 4. False positives (сообщены, но не воспроизведены) - **Same-paragraph правка: git перезаписывает UI** — dual-edit. Verifier наблюдал *противоположное* (UI побеждает) 5/5. - **Правка UI в другом абзаце уничтожена git-push'ем (HIGH)** — dual-edit. Понижено до спекулятивного; заголовочное заявление о потере данных не подтверждено. - **Code-fence ```js теряет язык/слово** — editor-content. Вероятно, тайминг нажатий в harness; путь через slash /Code чист. Все три концентрируются в таймингах гонок одновременного редактирования — самое трудное для детерминированного воспроизведения из скрипта, и ровно там, где кластеризуются false positives. ## 5. Ограничения окружения / не-баги (корректно обработаны, исключены из подсчёта багов) - **AI-провайдер не сконфигурирован** (сообщено 4 раза разными тестерами) — отправка возвращает 503, UI деградирует до чистого классифицированного баннера, без краша/пустой страницы. Ограничение стенда согласно заметкам к задаче. - **401 до логина** на /api/users/me + /api/auth/collab-token — SPA зондирует состояние сессии до появления cookie; восстанавливается чисто. - **Несовпадение Playwright 1.60 vs chromium-1148** — тулинг; потребовался зафиксированный `executable_path`. - **Вставка изображения через /Image требует нативного диалога файлов ОС** — не приводится в действие в headless; сам upload-backend проверен и работает (200s). - **drag-to-move у react-arborist не приводится в действие** — Playwright не может выстрелить его HTML5 DnD. - **git-импорт `> [!warning]` -> нативный callout** — проверено как ПОЛОЖИТЕЛЬНОЕ, работает как задумано. - **git->UI->git идемпотентен** для недублирующегося контента — проверено как стабильное (только реимпорт UI->git неидемпотентен). ## 6. Пробелы покрытия (честно) 1. **Путь отправки AI-чата ни разу не отработан end-to-end** — провайдер не сконфигурирован. Все AI-находки касаются жизненного цикла UI / обработки ошибок, а не реальной генерации, стриминга, tool-use или персистентности чата. Чтобы протестировать настоящую фичу, нужен сконфигурированный провайдер. 2. **Reparenting через in-space drag-to-move полностью не протестирован** — предполагаемый баг «страница исчезает при перемещении в свёрнутого родителя» ни подтверждён, ни опровергнут. Нужен драйвер не на Playwright (Chrome DevTools Protocol Input.dispatchDragEvent, либо ручной прогон). 3. **Направление одновременного редактирования не разрешено** — verifier доказал, что одна сторона ДЕЙСТВИТЕЛЬНО тихо отбрасывается без единого сигнала, но *какая* сторона — зависит от тайминга и не была зафиксирована. Реальный пользовательский риск потери данных здесь есть, но не охарактеризован. 4. **Персистентность изображений/файлов через перезагрузку** — проверена только отрисовка в рамках сессии; персистентность заблокирована ограничениями тулинга (диалог ОС + синтетические события). 5. **Два вердикта verifier'а ушли с placeholder-доказательствами** («e» / «test») для пунктов flush-window и code-fence — вердикты приняты на веру, но не имеют артефакта, что нарушает правило skill'а EVIDENCE-BEFORE-CLAIM (доказательство до утверждения). ## 7. Конкретные предложения по улучшению этого QA-процесса / skill'а 1. **Применять gate на артефакт-доказательство и к verifier'ам тоже.** Два вердикта («e», «test») прошли без артефакта. Схема вывода verifier'а должна *требовать* нетривиальную строку доказательства (минимальная длина / должна ссылаться на захваченный статус, файл или скриншот), иначе вердикт автоматически понижается до «unverified». 2. **Изолировать charter'ы с таймингами гонок за детерминистическим harness'ом.** Все три false positive — это тайминги гонок одновременного редактирования. Дайте этому charter'у управляемые часы: гоните flush UI и git push через явную синхронизацию (например, блокируйте git push, пока не подтверждено известное dirty-состояние редактора, и захватывайте серверные timestamp'ы экспорта) вместо sleep'ов по настенным часам. Требуйте *размеченное по направлению* воспроизведение (кто-побеждает) перед принятием любого заявления о потере данных при конкуренции. 3. **Сделать git-export оракулом по умолчанию для любого заявления о персистентности/данных.** Это был золотой стандарт, который исправил три причинно-следственные истории и повысил одну находку. От charter'ов, затрагивающих контент, нужно требовать подтверждения через свежий clone, а не только живой DOM (подсчёты по DOM неоднократно загрязнялись боковой панелью heading-outline у Docmost — обратите внимание на подсчёт client-DOM 48->53, который verifier показал как ненадёжный). 4. **Автоматически сливать дублирующиеся находки до верификации, а не после.** flushSync (x2), AI-not-configured (x4) и два отчёта о дублировании стоили избыточных проходов verifier'а. Проход дедупликации по ключу «файл-корневая-причина + симптом» срезал бы нагрузку на verifier. 5. **Добавить idle-монитор цикла синхронизации как постоянный оракул.** Самый важный единственный баг (неограниченное дублирование) виден только опросом vault'а БЕЗ подключённого клиента на протяжении нескольких циклов `docmost: sync`. Вшейте «clone, ждать 3 цикла, re-clone, diff по байтовым счётчикам на каждой странице» в charter git-sync как проверку по умолчанию — она ловит порчу от неидемпотентного merge, которую не поймала бы ни одна in-session проверка UI. 6. **Делать pre-flight тулинга.** Несовпадение пути chromium и ограничения headless-DnD / диалога файлов ОС каждое стоило тестеру реального времени и породило пробелы «не протестировано». 2-минутный recon pre-flight, который фиксирует путь к браузеру и перечисляет, какие взаимодействия приводятся/не приводятся в действие в headless (DnD, нативные file picker'ы, clipboard), позволил бы авторам charter'ов заранее обойти их. 7. **Помечать находки-ограничения окружения как отдельный класс на входе**, чтобы они не раздували дашборды серьёзности. Семь из ~26 сырых находок были env/не-багами; тегирование их на стадии тестера (а не только в синтезе) сохраняет сигнал чистым. ## git-sync находки этого прохода - **[high]** Неконтролируемое дублирование контента — неидемпотентный body-merge yjs<->markdown заново дописывает body страницы на каждом цикле git-sync, неограниченный рост в git И БД ✅ **ИСПРАВЛЕНО** в PR #119 (commit c6f44420 — нормализация ключа merge по дефолтам схемы; + индемпотентность реконсиляции 7a7b840e) - **[medium]** Латентность flush UI->git намного превышает сконфигурированный debounce — окно риска потери данных ~10s, а не ~2s - **[low]** Обычный `git push` в vault часто отклоняется как non-fast-forward, потому что собственные auto-commit'ы Docmost гоняются с пользователем Из них: дублирование — **починено и запушено** (живое подтверждение: FULLEDIT 315→315 стабильно, idle-churn '*sync 141 page(s)*' каждый цикл → 0). Остаются НЕ-критичные: flush-latency ~10s (тайминг debounce+poll, не data-loss) и non-fast-forward push race (в основном снят устранением churn). По ним — решение хозяина, можно отдельным тикетом. ## False positives (убиты verifier-проходом) - FALSE POSITIVE — «Same-paragraph одновременная правка: git тихо перезаписывает UI-правку без маркера конфликта» (сообщено dual-edit slice tester, заявлено verified/medium, направление UI-проигрывает-git). Verifier НЕ СМОГ ВОСПРОИЗВЕСТИ за 5/5 попыток и наблюдал ПРОТИВОПОЛОЖНОЕ: при чистой одновременной - FALSE POSITIVE / UNCONFIRMED — «In-flight UI-правка в ДРУГОМ абзаце тихо уничтожается входящим git-push'ем (потеря данных)» (сообщено dual-edit slice tester как verified/HIGH). Verifier понизил до спекулятивного — заявление high-severity о потере данных cross-block не удалось независимо - FALSE POSITIVE / UNCONFIRMED — «Markdown code-fence shortcut (```js) отбросил язык и ведущее слово» (сообщено editor-content как speculative/low). Вердикт verifier'а — спекулятивный; скорее всего гонка тайминга нажатий в тестовом harness, а не дефект продукта (отрисовка пути через slash /Code 🤖 web-test-orchestrator (проход #2, 27 агентов)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Something isn't working
 epic
Large multi-phase effort spanning many changes
 feature
New functionality request
 idea
Idea / proposal for discussion
 needs-human
эскалация: нужно решение человека
 review/approved
в последнем ревью нет открытых blocking-находок
 review/changes-requested
последнее ревью оставило открытые blocking-находки
 review/needs
head не ревьюился (head != reviewed_head)
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
agent_coder agent_reviewer vvzvlad
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: vvzvlad/gitmost#219
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?