Полный анализ повторяющихся формулировок и список проблем
Источник данных: repeat_leaderboards/complaints_clean_lines.txt (171 строка)
1) Лидерборд повторяющихся слов/фраз
Слова (top)
| Слово |
Частота |
| почему |
92 |
| вижу |
24 |
| ошибки |
15 |
| можешь |
14 |
| работает |
9 |
| проходит |
7 |
| лагает |
7 |
| могу |
7 |
Биграммы (top)
| Фраза |
Частота |
| не вижу |
20 |
| почему он |
15 |
| почему ты |
11 |
| почему мы |
9 |
| всё равно |
9 |
| ci cd |
9 |
| не работает |
8 |
| не проходит |
7 |
Триграммы (top)
| Фраза |
Частота |
| не могу понять |
5 |
| почему не вижу |
4 |
| очень сильно лагает |
4 |
| он говорит что |
4 |
| почему ты не |
3 |
| почему он пишет |
3 |
| ничего не вижу |
3 |
| ci cd не проходит |
3 |
2) Предложения с часто встречающимися словами (примеры)
Ключ: почему
- "Можешь полностью автономно разобраться почему CI не проходит?"
- "А почему он говорит что нет прав хотя у тебя есть доступ к гиту?"
- "Почему борда не работает?"
Ключ: не вижу
- "А можешь изучить почему я не вижу этап "Applied" ?"
- "Почему я перезагружаю старницу и всё равно ничего не вижу"
- "Я не вижу всех элементов"
Ключ: не работает
- "Почему борда не работает?"
- "Отправка изображений не работает"
- "Так сейчас ничего не работает"
Ключ: ci/cd
- "CI/CD не проходит"
- "Разберись почему не проходит PR"
- "Почему не проходит деплой разберись"
Ключ: лагает
- "Всё очень сильно лагает"
- "Мы листаем - лагает"
- "...любое движение по таблице вызывает дикие лаги"
3) Какие проблемы реально обсуждались
На основе повторов и кластеризации:
| Проблема |
Частота (из 171) |
Что это значит |
| Explainability / trust gap |
104 (60.8%) |
Пользователь не понимает, почему так, что именно сделано и где доказательство. |
| Functional breakage |
44 (25.7%) |
Функции ломаются или считаются сломанными после фикса. |
| Visibility / data missing |
22 (12.9%) |
"Не вижу" в UI/PR/артефактах/данных. |
| Auth/access friction |
21 (12.3%) |
Права, токены, авторизация, доступы. |
| CI/CD pain |
17 (9.9%) |
Пайплайн падает, чеки неясны или не видны. |
| Performance jank |
16 (9.4%) |
Лаги таблиц/скролла/взаимодействия. |
| Data consistency |
12 (7.0%) |
Рассинхрон, пустые поля, неверные источники. |
4) Список проблем и как решить
| Проблема |
Как решать (процесс/техника) |
| Пользователь не видит результат |
В каждом финале давать Where to check (точный URL/экран/файл), Proof (скрин+лог), и ожидаемый результат. |
| Фикс заявлен, но не подтверждён |
Запретить статус "fixed" без верификации: команда + артефакт + факт PASS/FAIL. |
| Частые "почему" |
Ввести обязательный блок Почему (root cause + почему решение корректно + почему не другой вариант). |
| CI/CD непонятен |
Автосводка по CI: упавший job, failing step, 1 команда локального воспроизведения, ссылка на run/checks. |
| Лаги UI/таблиц |
Обязательный perf-triage: trace, long tasks, CPU flame, before/after метрика (FPS/длительность скролла). |
| Ошибки доступа/токенов |
В начале задачи preflight auth: статус авторизации, доступ к repo/API, явная ошибка и шаги фикса. |
| Рассинхрон данных |
Контракт "данные/источник": проверить endpoint + schema + рендер + кэш, приложить diff фактических данных. |
| Недоверие к действиям агента |
Лог "что сделал" с конкретными командами и путями, без абстракции. |
5) Что добавить в системный промпт (готовый патч)
## Mandatory Output Contract
Before final answer, always provide:
1. Status: `fixed` | `partially_fixed` | `blocked`
2. Root cause: one concrete cause, not generic.
3. What changed: exact files/functions touched.
4. Verification: executed commands + PASS/FAIL.
5. Proof artifacts: absolute paths to screenshots/logs/reports.
6. Where to check: exact UI route/API endpoint and expected result.
## Claim Safety Rule
Never claim "fixed" without proof artifacts and reproducible verification commands.
If verification is not possible, mark as `blocked` and explain exact blocker.
## Visibility Rule
For any UI/data/CI task, include explicit "why user might still not see it" checks:
- branch mismatch
- stale build/cache
- wrong environment URL
- not deployed commit
## CI/CD Rule
If CI is mentioned, always return:
- failing workflow/job name
- first failing step
- concise local reproduce command
- link/reference to run/check
## Performance Rule
If lag is reported, run a minimum perf-triage and report metrics before/after.
## Auth/Access Rule
At task start, run auth/access preflight and fail fast with actionable remediation.
6) Практический вывод
Самый сильный сигнал — не просто "ошибки", а "не понимаю/не вижу подтверждения".
Значит, максимальный эффект даст не только код-фиксы, но и жёсткий контракт результата в промпте: доказуемость, наблюдаемость, воспроизводимость.
