Остаток из #63 (закрыта частично, см. её комментарий).
Проблема
В test/tbank-operations-sync.e2e-spec.ts около 14 await delay(N) перед конкурентными действиями. Механическая замена на сигнал опасна: мутант на кейсе publishes the forced visible period before unrelated pending history показал, что без delay тест падает. Порядок history → screen зависит от записи в БД, а не от старта upstream. Замена на барьер состояния state(running) изменила результат теста, поэтому откатано.
Что сделать
Для каждого delay: определить, на что он реально полагается (старт upstream, запись в БД, захват работы), выбрать точный барьер, подтвердить мутантом (без барьера тест должен падать), либо явно оставить delay с обоснованием.
Критерии готовности
Каждый оставшийся delay либо заменён на барьер с доказанным мутантом, либо задокументирован комментарием с причиной.
Нет ложной зелёности: мутанты для каждого изменённого кейса.
npm run verify и npm run test:e2e зелёные.
Ограничения
Hourly (tbank-hourly-lifecycle, pump(N)) вне scope. Новый framework для гонок не строить.
Остаток из #63 (закрыта частично, см. её комментарий).
## Проблема
В `test/tbank-operations-sync.e2e-spec.ts` около 14 `await delay(N)` перед конкурентными действиями. Механическая замена на сигнал опасна: мутант на кейсе `publishes the forced visible period before unrelated pending history` показал, что без `delay` тест падает. Порядок history → screen зависит от записи в БД, а не от старта upstream. Замена на барьер состояния `state(running)` изменила результат теста, поэтому откатано.
## Что сделать
Для каждого `delay`: определить, на что он реально полагается (старт upstream, запись в БД, захват работы), выбрать точный барьер, подтвердить мутантом (без барьера тест должен падать), либо явно оставить `delay` с обоснованием.
## Критерии готовности
- Каждый оставшийся `delay` либо заменён на барьер с доказанным мутантом, либо задокументирован комментарием с причиной.
- Нет ложной зелёности: мутанты для каждого изменённого кейса.
- `npm run verify` и `npm run test:e2e` зелёные.
## Ограничения
Hourly (`tbank-hourly-lifecycle`, `pump(N)`) вне scope. Новый framework для гонок не строить.
Сделано в #145 (squash в develop). Таблица delay → решение → мутант приведена в описании PR. Оставшиеся паузы помечены комментарием: отсутствие события нельзя дождаться иначе, кроме как ограниченной паузой.
Сделано в #145 (squash в develop). Таблица delay → решение → мутант приведена в описании PR. Оставшиеся паузы помечены комментарием: отсутствие события нельзя дождаться иначе, кроме как ограниченной паузой.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Остаток из #63 (закрыта частично, см. её комментарий).
Проблема
В
test/tbank-operations-sync.e2e-spec.tsоколо 14await delay(N)перед конкурентными действиями. Механическая замена на сигнал опасна: мутант на кейсеpublishes the forced visible period before unrelated pending historyпоказал, что безdelayтест падает. Порядок history → screen зависит от записи в БД, а не от старта upstream. Замена на барьер состоянияstate(running)изменила результат теста, поэтому откатано.Что сделать
Для каждого
delay: определить, на что он реально полагается (старт upstream, запись в БД, захват работы), выбрать точный барьер, подтвердить мутантом (без барьера тест должен падать), либо явно оставитьdelayс обоснованием.Критерии готовности
delayлибо заменён на барьер с доказанным мутантом, либо задокументирован комментарием с причиной.npm run verifyиnpm run test:e2eзелёные.Ограничения
Hourly (
tbank-hourly-lifecycle,pump(N)) вне scope. Новый framework для гонок не строить.Сделано в #145 (squash в develop). Таблица delay → решение → мутант приведена в описании PR. Оставшиеся паузы помечены комментарием: отсутствие события нельзя дождаться иначе, кроме как ограниченной паузой.