---
type: JS Module
title: scheduler.mjs
resource: npm/scripts/lib/lint-surface/scheduler.mjs
docgen:
  crc: e909628f
  model: openai-codex/gpt-5.4-mini
  tier: cloud-min
  score: 100
  issues: judge:inaccurate:0.99
  judgeModel: openai-codex/gpt-5.4-mini
---

## Огляд

Bounded two-lane concurrent scheduler для `detectAll`, який активується лише коли `concurrency > 1`; за `concurrency === 1` `detectAll` лишається на повністю послідовному шляху, спостережувано ідентичному до-ADR поведінці, і цей scheduler там навіть не викликається. Має два лейни: **serial lane** з власним sequential runner і mutex-ефектом, де items ніколи не перекриваються самі з собою, та **parallel lane** з bounded pool до `concurrency` слотів. Обидва лейни навмисно виконуються конкурентно один з одним: для serial-lane це лише структурна конкурентність, бо його blocking `spawnSync` все одно заморожує event loop, а parallel-lane отримує реальну вигоду від одночасного очікування кількох `spawnAsync`-викликів. Перша помилка від `runItem` зупиняє нові старти в обох лейнах, `controller.abort` сигналізує вже запущеним async-детекторам, і функція чекає завершення всіх уже стартованих items; кожен `runOne` ловить власну помилку, тож зовнішній `Promise.all` не відхиляється назовні.

## Поведінка

1. `runPlanConcurrently` розділяє вхідний план на два потоки виконання: serial і parallel, щоб паралельно обслуговувати незалежні елементи та не перекривати послідовні між собою.

2. `runPlanConcurrently` запускає serial-потік як суворо послідовний прогін, а parallel-потік — як обмежений пул із максимальною кількістю одночасних активних елементів, визначеною рівнем concurrency.

3. `runPlanConcurrently` збирає результат кожного реально стартованого елемента в порядку завершення, а не в початковому порядку плану.

4. `runPlanConcurrently` сприймає першу помилку як інфраструктурну: зупиняє старт нових елементів у обох потоках і надсилає сигнал скасування вже запущеним асинхронним виконавцям.

5. `runPlanConcurrently` не перериває зовнішнє виконання аварійним винятком: усі вже стартовані елементи дочікуються завершення, а помилки фіксуються в результатах і повертаються разом із першим інфраструктурним збоєм.

6. `runPlanConcurrently` повертає пару: список фактично виконаних елементів із їхнім підсумком або причиною скасування, та першу помилку, якщо вона була; якщо збоїв не було, помилка дорівнює null.

## Публічний API

- runPlanConcurrently — зупиняє запуск нових items після кидка, абортує `signal`; `results` містить лише реально запущені items у порядку завершення; `infraError` фіксує першу помилку `runItem` або лишається `null`, якщо все завершилось успішно

## Гарантії поведінки

- Read-only: не виконує операцій запису (ФС/БД).
- Перехоплює помилки і не пропускає винятків назовні (fail-safe).