Вторая пчела работает, но её работу никто не судит

[gHashTag]

Часть #1090. Найдено первым в истории проекта параллельным прогоном.

Параллель работает — это доказано

Один запуск, два задания (TRIOS_E2E_DELEGATE_SECOND), #1147 и #1149:

07:15:51  #1147  Worker turn starting
07:15:55  #1149  Worker turn starting      внахлёст
07:16:15  #1149  Committed 1 file(s)
07:16:30  #1147  Committed 1 file(s)

Обе пчелы работали одновременно, обе написали свой файл, обе закоммитили в свою ветку. Комментарий в main.swift говорил, что этого «ни разу не показывали» — теперь показано.

Что не работает

Вердикты пришли только для #1147:

07:16:13  #1149  characterCount
07:16:14  #1149  Judged what the files show
07:17:06  #1147  Reviewer returned 2 verdict(s)     ← только первая

У #1149 есть свидетельство и счёт знаков, а вердиктов нет вовсе. Обе задачи стоят в awaitingReview; вторая не будет принята никогда, потому что её никто не спросил.

Причина в том, что приёмка запрашивается для той задачи, которую назвал человек, а не для каждой, что у королевы в работе. По замыслу MVP судит она, а не проба.

Готово, когда

• Каждая работающая задача получает вердикты, а не только названная человеком.
• Две одновременные задачи обе доходят до принятого состояния.
• Ни одна не остаётся в awaitingReview без запроса вердиктов.
• Доказано прогоном двух задач в одном запуске.
• Проверка ломается, если вернуть запрос вердиктов только для первой.

Границы

rings/SR-02/ChatViewModel.swift

[gHashTag]

Уточнение спеки: место названо.

Три делегирования по этой задаче кончились ничем — 52 и 50 вызовов инструментов без единой правки. Причина в #1157: файл в 6026 строк больше, чем то, что исполнитель успевает удержать. Отраслевая практика на этот счёт однозначна — точная выдержка вместо файла целиком; каждый лишний кусок в окне ухудшает работу с остальными, и разбивать задачу надо до неё, а не во время.

Где именно

rings/SR-02/ChatViewModel.swift, функция handleWorkerFinished (начинается на строке 3511). Внутри неё, около строки 3700:

let unanswered = current.acceptanceCriteria.filter {
    current.criterionVerdicts[$0] == nil
}
if !unanswered.isEmpty {
    ...
    reviewerVerdictsRecorded = await requestReviewerVerdicts(...)
}

Это единственное место, где вердикты запрашиваются. Читать весь файл не нужно: хватит области 3500-3730.

Что должно измениться

Запрос вердиктов должен случаться для каждой задачи, дошедшей до awaitingReview, а не только для той, чей работник только что закончил в этом вызове.

Доказательство

Два задания в одном запуске (SECOND=) — обе получают вердикты, обе доходят до принятого состояния. Сейчас вторая остаётся в awaitingReview навсегда.

[gHashTag]

Правка сделана и не работает — это отдельно от #1157.

Пчела впервые дотянулась до этого файла (нацеленная спека, 40 строк, сборка и 594 проверки чистые). Но прогон двух задач показывает прежнее:

09:50:22  #1147  Committed 1 file(s)
09:50:25  #1149  Committed 1 file(s)
09:50:52  #1147  Reviewer returned 2 verdict(s)
09:50:53  #1147  Opened a pull request (22)
у #1149 вердиктов нет

Обе пчелы работают и коммитят параллельно; судят по-прежнему одну. Задача остаётся открытой, но теперь с рабочим способом её делегировать.

[gHashTag]

Уточнение спеки: обход написан, но нем.

Прошлая попытка добавила верное по замыслу — обход прочих задач в awaitingReview (rings/SR-02/ChatViewModel.swift, строки 3772-3822, внутри handleWorkerFinished). Прогон двух задач показывает, что он не срабатывает, и узнать почему нельзя: обход не пишет в журнал ни строки. Это моё упущение в прошлой спеке.

Что известно из прогона

09:50:25  #1149  running -> awaitingReview
09:50:52  #1147  Reviewer returned 2 verdict(s)
09:50:53  #1147  Opened a pull request (22)
          #1149  вердиктов нет

К моменту работы обработчика #1147 задача #1149 уже была в awaitingReview. Значит либо обход до неё не доходит, либо отсеивает её одним из своих guard.

Что должно измениться

Читать только строки 3760-3830.

1. Обход пишет событие на каждую рассмотренную задачу: сколько нашёл в awaitingReview, по скольким запросил вердикты, и по какой причине пропустил остальные (нет ветки, нет неотвеченных критериев, уже спрашивали). Без этого следующая неудача снова будет неразличима.
2. Задача, дошедшая до awaitingReview, получает вердикты независимо от того, чей работник только что закончил.

Доказательство

Два задания в одном запуске: обе получают вердикты. Сейчас — только первая.

[gHashTag]

Наблюдаемость исправила диагноз с первого прогона.

Обход теперь говорит вслух, и видно, что вердиктов второй задаче хватает:

10:36:50  Sweeping 1 other task(s) in awaitingReview
10:36:50  #1149  sweep.skip — All criteria already have verdicts
10:36:50  Sweep complete: 1 considered, 0 got verdicts

Их дал детерминированный счётчик знаков (#1151), поэтому ревьюер и не нужен. Значит утверждение «вторую никто не судит» было неверным — её судят, и она всё равно стоит.

Что на самом деле не работает

Задача с полным набором вердиктов остаётся в awaitingReview навсегда, потому что попытка принять делается только для той задачи, чей работник только что закончил. Для остальных её не делает никто.

Что должно измениться

Читать только строки 3760-3840 в rings/SR-02/ChatViewModel.swift.

Обход уже находит такие задачи и правильно их пропускает по вердиктам. Пропуск «все критерии уже с вердиктами» должен вести не в continue, а в попытку приёмки — ту же, что делается для основной задачи.

Доказательство

Два задания в одном запуске: обе доходят до accepted, обе получают PR. Сейчас первая доходит, вторая стоит.

[gHashTag]

Закрыто. Обе задачи доходят до принятия параллельно — и причина была в моём способе проверки.

11:21:24  #1147  queued -> running
11:21:28  #1149  queued -> running        внахлёст
11:21:51  #1147  awaitingReview -> accepted
11:21:57  #1149  awaitingReview -> accepted
11:21:57  #1149  queen.auto_accept  «Accepted without a human»

Разница с прежними прогонами одна: AUTONOMY=1. Первая строка autoAcceptIfUnambiguous:

guard ProcessInfo.processInfo.environment["TRIOS_QUEEN_AUTONOMY"] == "1" else { return }

Без неё приёмка выходит молча, не оставляя записи. Мои прогоны её не включали, поэтому вторая задача стояла — а выглядело это как дефект приёмки.

Обход, добавленный по этой задаче, здесь не сработал ни разу: все записи говорят «Sweeping 0 other task(s)». Задачи приняты собственными обработчиками. То есть приёмка каждой задачи работала и раньше; не работала моя проверка.

Что осталось настоящим и вынесено отдельно: страж автономии молчит. Именно это сделало три прохода диагностики неверными.