Статус — GET /api/jira/status возвращает { connected, issueCount, lastSyncedAt }.

Данные для дашборда — GET /api/jira/issues отдаёт содержимое таблицы issues, агрегированное для Dashboard.jsx (total/byStatus/byTeam/byType/issues), плюс lastSyncedAt. App.jsx подгружает эти данные автоматически при каждой загрузке страницы, если Jira подключена — если в БД уже есть данные, дашборд открывается сразу, без промежуточного экрана; если данных ещё нет (первое подключение), показывается приглашение синхронизироваться. Кнопка «Обновить данные из Jira» в шапке дашборда вызывает POST /api/jira/sync → GET /api/jira/issues, подставляет новые данные без перезагрузки страницы и обновляет отметку времени синхронизации; во время запроса кнопка блокируется и показывает прогресс. Рядом — «Полная пересинхронизация» (?force=1): пересчитывает lead_time_days/cycle_time/reopen_count для всех задач заново, даже если updated в Jira не менялся — нужно после изменения логики расчёта на бэкенде, иначе уже засинканные задачи бессрочно отдают старые сохранённые значения.

• Фильтры дашборда — панель над карточками статистики: Проект/Команда/Тип задачи/Статус/Приоритет и Период (7/30/90 дней/всё время), плюс кнопка «Сброс» (FilterBar.jsx). Полностью клиентские на Дашборде — работают над уже загруженным stats.issues, ничего не запрашивают у бэкенда; при активном фильтре карточки и разбивки «По статусу/команде/типу» пересчитываются на лету (computeStats в Dashboard.jsx) вместо агрегатов, присланных GET /api/jira/issues. GET /api/jira/issues для этого дополнительно отдаёт project/priority/assignee в каждой issue. Открытие виджета на весь экран (WidgetDrilldown.jsx, см. ниже) наследует уже применённый на дашборде фильтр и добавляет к нему свои локальные.
• Общий фильтр между «Дашборд» и «Задачи» — тот же набор из шести полей (Проект/Команда/Тип задачи/Статус/Приоритет/Период) общий для обоих разделов: FilterBar.jsx рендерит одинаковый UI в обоих, а состояние живёт в одном месте — useSharedFilters.js, созданном один раз в App.jsx и переданном в Dashboard/Tasks пропсами, плюс сохраняется в localStorage (delivery-board:filters) на каждое изменение, так что значения переживают переключение вкладок (компоненты размонтируются при смене таба) и перезагрузку страницы. Строка поиска по ключу/названию на «Задачах» — не часть этого состояния, остаётся локальной. В «Задачах» те же фильтры теперь бьют в бэкенд как query-параметры GET /api/jira/tasks (project, periodDays — новые, status/team/type/priority были и раньше); periodDays фильтрует по created_at >= now() - N дней, аналогично клиентскому «Периоду» на Дашборде. Клик по строке/числу в развёрнутом виджете дашборда (onNavigateToTasks) заменяет общий фильтр целиком кликнутым измерением и переключает на «Задачи» — раньше это шло через одноразовый initialFilters-проп, теперь просто пишет в то же общее состояние.

Маппинг полей — id кастомных полей (customfield_XXXXX) уникальны для каждого Jira-сайта, поэтому Sprint/Team/Story Points не хардкодятся, а настраиваются через UI:

• GET /api/jira/fields — список всех полей текущего Jira-сайта (id + name) через GET /rest/api/3/field.
• GET /api/jira/field-mapping / POST /api/jira/field-mapping — чтение и сохранение соответствия canonical_field → jira_field_id в таблице jira_field_mapping (ключ — cloud_id, так что маппинг привязан к конкретному Jira-сайту).
• На фронтенде это экран «Настройка полей Jira» (FieldMapping.jsx) — dropdown на каждое поле, опции берутся из /api/jira/fields, кнопка «Сохранить маппинг». Открывается автоматически сразу после первого подключения Jira (если маппинг ещё пустой) и в любой момент повторно — кнопкой «Настройки полей» в JiraPanel.jsx.
• Если маппинг не настроен, POST /api/jira/sync не падает и не блокируется — просто использует null для несопоставленных canonical-полей (для team дополнительно есть фолбэк на labels, как и раньше).

Раздел «Задачи» (Tasks.jsx) — таблица issues из БД с живым локальным поиском (debounce 300 мс) и общим с Дашбордом фильтром (FilterBar.jsx, см. пункт 4a выше), пагинацией по 20 и экспортом текущей выборки в CSV. Backing endpoint GET /api/jira/tasks (query: search, повторяемые status/team/type/priority/project, periodDays, page; с export=csv отдаёт файл без пагинации) и GET /api/jira/tasks/filters (списки значений для дропдаунов, включая projects, — только то, что реально есть в БД). Колонка «Дней в статусе» считается на бэкенде от updated_at до текущего момента и показывает —, если status_category уже Done. Клик по строке открывает боковую панель со всеми полями задачи (TaskDetailPanel.jsx) и ссылкой «Открыть в Jira» — {site_url}/browse/{issue_key}, где site_url (например, https://your-domain.atlassian.net) сохраняется в jira_tokens при OAuth (Jira отдаёт его в том же ответе accessible-resources, откуда берётся cloud_id).

• «Время в статусах» (в той же панели) — суммарное время в каждом статусе, где задача когда-либо была (повторные визиты, например после reopen, суммируются; текущий статус считается до настоящего момента, а не только до последнего события). Считается из того же changelog-replay, что и Cycle Time (computeLeadCycleReopen в routes/jira.js) — тем же проходом по сегментам статусов, без отдельного запроса к Jira, и сохраняется в issues.status_time_breakdown (JSONB, [{status, days}] в хронологическом порядке первого попадания в статус) при каждом синке, где changelog реально перезапрашивался (при пропуске — как и cycle_time/lead_time_days — переносится из уже сохранённого значения). В отличие от cycle_time/lead_time_days, считается и для нерезолвленных задач. null (ещё не посчитано — changelog не запрашивался или задача синкана до появления этой колонки) отличается от пустого массива: панель в этом случае блок не показывает вовсе, а не рисует пустой/битый список.

Верхняя навигация (TopNav.jsx) — табы «Дашборд», «Задачи», «Настройки» рабочие; «Команды», «Спринты», «Отчёты» показаны как заглушки (неактивны, без обработчиков) — задел под будущие разделы по общему макету продукта. 7a. Раздел «Настройки» (Settings.jsx) — два блока:

• Подключение Jira — только статус/домен (site_url) и «Переподключить Jira» (снова ведёт на /api/auth/login); полей для ручного ввода URL/токена нет и не будет, т.к. вся авторизация идёт через OAuth. Там же — «Настройки полей» (открывает существующий FieldMapping.jsx).
• Синхронизация (SyncHistory.jsx) — таблица последних 20 запусков из таблицы sync_history (Время/Источник/Задач/Итог, с текстом ошибки в title при наведении на «ошибка») и кнопка «Обновить сейчас» (тот же syncJira(), с тем же live-прогрессом через useSyncProgress, что и кнопки на дашборде).
• Настроек, ограничивающих какие задачи синкаются из Jira, здесь намеренно нет — sync всегда тянет все issues сайта (SYNC_JQL в routes/jira.js, с единственным техническим ограничением updated >= -3650d, нужным лишь потому что /search/jql отклоняет полностью неограниченный JQL). Фильтрация — это фильтры на «Дашборде» и в «Задачах» (Tasks.jsx, MultiSelectFilter.jsx), которые работают клиентски/по уже загруженным из БД данным, а не управляют тем, что попадает в БД при sync.
• Расписание автосинхронизации и алерты сознательно не реализованы — отдельная задача, требующая cron/email-Slack инфраструктуры.

Разворот виджетов дашборда (WidgetDrilldown.jsx) — карточки «По статусу», «По команде», «По типу» получили иконку ⛶, разворачивающую виджет на весь экран поверх обычного дашборда (не роут, локальный expandedWidget state в Dashboard.jsx). Полноэкранный вид считает группировку прямо на клиенте из уже загруженного stats.issues — никаких новых полей в БД не потребовалось. Слева — локальные фильтры (Период/Команда/Тип задачи), которые сужают только это представление и не трогают stats в Dashboard. «По команде» — единственная группировка с реальной вложенностью (команда → статус, разворачивается стрелкой, если у команды больше одного статуса); «По статусу» и «По типу» — плоские таблицы. Клик по названию группы (или по числу в строке без вложенности) переключает верхнюю навигацию на «Задачи» с фильтром по этому одному измерению; клик по числу в развёрнутой подстроке — с комбинированным фильтром (например, команда + статус одновременно). Передача фильтра между экранами — через navigateToTasks в App.jsx, который пишет кликнутое измерение в общее состояние фильтров (useSharedFilters.js, см. пункт 4a) и переключает вкладку на «Задачи».

Спринты (Jira Agile API, только бэкенд) — POST /api/jira/sync дополнительно тянет данные о спринтах через /rest/agile/1.0/*, отдельным best-effort шагом после основной синхронизации issues (syncSprintsForCloud в routes/jira.js):

• Для каждого Jira-проекта, уже встречающегося в синканных issues, — GET /rest/agile/1.0/board?projectKeyOrId={project} (доски этого проекта; пагинация startAt/maxResults/isLast, как и у остальных Agile-эндпоинтов — в отличие от курсорной пагинации /rest/api/3/search/jql).
• Для каждой доски — GET /rest/agile/1.0/board/{boardId}/sprint?state=active,closed. Kanban-доска без спринтов отвечает 400 — это нормальный случай, не ошибка синка (fetchSprintsForBoard в этом случае просто возвращает []).
• Из полученных спринтов не сохраняются все — только активный(е) и последние CLOSED_SPRINTS_TO_KEEP = 3 завершённых по каждой доске (selectSprintsToTrack), чтобы не тянуть всю историю. Апсертятся в таблицу sprints (jira_sprint_id UNIQUE).
• Для каждого выбранного спринта — GET /rest/agile/1.0/sprint/{sprintId}/issue?fields=created (только key+created, больше для этой задачи не нужно). Для каждой найденной там issue, если она уже есть в нашей таблице issues (иначе пропускается — например, задача была отфильтрована SYNC_JQL или относится к другому проекту), апсертится строка в issue_sprints (issue_id, sprint_id, added_after_sprint_start).
• Модель issue↔sprint — связка issue_sprints (issue может быть в нескольких спринтах за свою жизнь), а не колонка на issues; существующая текстовая issues.sprint (имя последнего спринта из маппинга полей) не тронута и продолжает работать как раньше.
• added_after_sprint_start — простое сравнение issue.created_at > sprint.start_date (не по changelog поля Sprint — это было бы точнее, но означало бы ещё один запрос к Jira на issue сверх того, что и так уже делает основной синк).
• Сбои на уровне отдельного проекта/доски/спринта (нет доступа, доска без спринтов, Jira Software не подключён и т.п.) не роняют весь /sync — best-effort, обёрнуто в свой try/catch; итоговая ошибка (если есть) попадает в sprintSyncError в ответе /sync и в колонку error строки sync_history. sync_history дополнительно получила колонки sprints_synced/sprint_issue_links, отдаются и в GET /api/jira/sync/history.
• UI для «Команды» на этих данных описан в пункте 10 ниже.

⚠️ В процессе донастройки на реальном Jira-сайте: Agile-эндпоинты требуют granular-скоупы, по одному на ресурс, а не один общий — классических read:jira-work/read:jira-user (достаточных для обычного /rest/api/3/*) не хватает ни для одного из них. Найдено методом «чиним 401 scope does not match по очереди»: /rest/agile/1.0/board заработал после read:board-scope:jira-software + read:project:jira, /board/{id}/sprint — после read:sprint:jira-software. GET /sprint/{id}/issue (issues спринта) с той же ошибкой оказался упрямее: read:issue-details:jira (не -jira-software — такого granular-скоупа не существует в Developer Console) сам по себе не хватило; по форумному треду Atlassian с точно такой же ошибкой на этом же эндпоинте туда же нужен read:jql:jira (эндпоинт под капотом устроен как JQL-поиск). Текущий scope в routes/auth.js: read:jira-work read:jira-user offline_access read:board-scope:jira-software read:project:jira read:sprint:jira-software read:issue-details:jira read:jql:jira — пока не подтверждено на реальном сайте, следующая проверка после переподключения Jira покажет, хватило ли этого набора. Смешивание classic- и granular-скоупов в одном запросе авторизации это конкретное приложение принимает нормально. Ошибка не проходит незамеченной: первая по любому проекту/доске/спринту (firstError в syncSprintsForCloud) попадает в sprintSyncError в ответе /sync и в error соответствующей строки sync_history — видна в колонке «Спринтов» истории синхронизаций в «Настройках» (SyncHistory.jsx, которая показывает и число синканных спринтов, и число связей issue↔спринт отдельно, даже когда сам синк issues прошёл успешно).

Раздел «Команды» (Teams.jsx, backend в routes/teams.js, смонтирован как /api/teams) — целиком читает уже засинканные данные, живых запросов к Jira не делает.

• Собственные фильтры страницы (Спринт/Команда/Проект) — намеренно отдельное состояние от общего фильтра Дашборда/Задач (useSharedFilters.js): локальный useState в Teams.jsx, в localStorage не пишется. «Спринт» фильтрует по внутреннему sprints.id (не по Jira jira_sprint_id).
• Issue Links / блокеры — issuelinks добавлено в список полей issue-запроса (BASE_FIELDS в routes/jira.js), приходит бесплатно с обычным синком issues, отдельных запросов в Jira не требует. На каждый синк для issue таблица issue_links полностью перестраивается (DELETE + вставка из текущего issuelinks). Каждая связь хранится с точки зрения issue, из которой её видно — link_type это конкретная фраза направления («is blocked by» / «blocks»), а не просто имя типа связи, чтобы блокер определялся простым ILIKE '%blocked by%' без знания всех возможных типов связей сайта. «Блокер» = issue, у которой есть такая связь на issue с status_category != done.
• Роли участников — блок «Команды и роли» в «Настройках» (TeamRoles.jsx): список (команда, исполнитель) собирается из уже загруженных issues (GET /api/jira/team-roles), сгруппирован по командам; у каждого участника dropdown с ролью (Аналитик/Разработчик/QA/Дизайнер/своя через «Другое...»), сохраняется сразу (POST /api/jira/team-roles, свободный текст — с debounce 600 мс) в таблицу team_roles (UNIQUE (team, assignee_name)). Без роли участник помечается «роль не задана» и не учитывается в сумме WIP-лимита команды (см. ниже).
• WIP-лимиты — блок «Настройка WIP» (WipLimitsModal.jsx) с кнопкой «Настроить», открывающей модалку: шаг 1 — выбор команды; шаг 2 — по каждому её текущему indeterminate-статусу пары (роль → лимит «на человека этой роли»), роли предлагаются из уже назначенных в team_roles этой команды, «+ добавить роль» — вторая пара роль/лимит на тот же статус. «Сохранить» разом заменяет весь конфиг команды (POST /api/jira/wip-limits, body { team, entries }) в таблице wip_limits (UNIQUE (team, status_name, role)) — в отличие от остальных настроек, здесь уместна явная кнопка «Сохранить», это разовое действие в модалке, а не постоянно видимая форма. Общий лимит команды (используется в таблице «Команды» и в сигнале «WIP» ниже) = Σ limit_value × (число участников команды с этой ролью в team_roles) по всем её строкам wip_limits — не плоский лимит на статус, как было в первой версии этой фичи (полностью удалена вместе со старой глобальной таблицей wip_limits; при апгрейде с той версии db.js один раз дропает старую схему таблицы — см. комментарий в ensureSchema).
• Таблица «Команды» — на команду: людей (уникальных assignee), «Загрузка» (текущий WIP в indeterminate-статусах / общий лимит команды с прогресс-баром — если у команды нет ни одной строки в wip_limits, или ни одному участнику не назначена роль, показывается только число WIP без дроби), Velocity SP (сумма story points всех задач выбранного спринта — или, если фильтр «Спринт» не выбран, последнего спринта команды: активного, иначе последнего закрытого), Cycle time (среднее по завершённым задачам команды), Баги % (доля issue_type = Bug), Блокеры (см. выше), Здоровье.
• Здоровье — три сигнала, каждый сравнивается с историей самой команды (resolveLastSprint/health-блок в routes/teams.js): (1) текущий WIP / лимит команды (см. выше; сигнал пропускается, если лимит не настроен), срабатывает при > 1.0; (2) средний cycle time завершённых задач за последние 30 дней / средний cycle time по всем завершённым задачам команды, срабатывает при > 1.3; (3) SP завершённых задач последнего закрытого спринта / средняя по предыдущим (до 5) закрытым спринтам, срабатывает при < 0.7. Итог — «норма» (0 сработавших), «риск» (1), «перегруз» (2+). Если у команды меньше 3 завершённых задач за всё время или нет ни одного закрытого спринта — «недостаточно данных», сигналы вообще не считаются.
• Карточка команды (клик по строке) — график SP по последним до 5 спринтам («Взято» = все задачи спринта, «Сделано» = только завершённые) и разбивка по issue_type за выбранный период (весь спринт, если активен фильтр «Спринт», иначе всё время команды) — типы берутся из реальных данных, не захардкожены.
• Загрузка людей (в той же карточке) — по каждому исполнителю среди текущих indeterminate-задач команды: сколько в работе, сумма SP, максимум дней в текущем статусе среди его активных задач, статус (1–3 задачи — норма, 4–6 — на пределе, 7+ — перегруз; пороги временные, колонки «Ревью» нет).
• «Здоровье последнего спринта» — отдельная таблица по всем командам (не зависит от фильтра «Спринт» страницы — всегда именно последний спринт каждой команды): Взято (SP задач, бывших в спринте с его старта — added_after_sprint_start != true), Сделано (SP завершённых), Перенесено (число незавершённых на конец), Scope creep % (доля added_after_sprint_start = true).
• «Зависимости между командами» — сознательно не реализовано, только визуальная заглушка с текстом «Скоро: анализ зависимостей между командами», место в макете зарезервировано.

Раздел «Спринты» (Sprints.jsx, backend в routes/sprints.js, смонтирован как /api/sprints) — burndown, cumulative flow, история спринтов и риски активного спринта, целиком из уже засинканных данных.

• issue_status_events — новая таблица, ключевая для этого раздела: одна строка на каждую смену категории статуса issue (плюс синтетическая «genesis»-запись в created_at с исходной категорией) — {issue_id, changed_at, status, status_category}. Строится тем же changelog-replay проходом, что и cycle_time/status_time_breakdown (computeLeadCycleReopen в routes/jira.js, теперь дополнительно возвращает statusTimeline), перестраивается (DELETE+вставка) только когда синк реально перезапрашивал changelog для issue — как и issue_links. Это то, что позволяет восстановить «в какой категории была задача на день D» без повторного похода в Jira: берётся последняя запись с changed_at <= D.
• Собственные фильтры страницы (Спринт — одиночный выбор, по умолчанию активный спринт / Команда / Тип задачи) — отдельное состояние, не связанное с фильтрами других разделов.
• KPI-карточки — Взято в спринт (SP всех issues спринта, независимо от added_after_sprint_start, + число задач), Сделано (SP завершённых + % с прогресс-баром), Прогноз завершения (только для активного спринта: (Сделано / дней с начала) × общая длительность / Взято, обрезано до [0,100]; для закрытого спринта карточка заменяется на «Итог» с фактическим %), Добавлено после старта (SP + scope creep % — доля issues с added_after_sprint_start = true), Риски (число + через «+» какие категории из блока ниже встретились).
• Burndown — таймлайн всегда покрывает весь спринт от start_date до end_date (реальные даты из Jira Agile API, не предположение о стандартной длине — настройки «длины спринта» поэтому нет и не нужно: для только что стартовавшего спринта ось X сразу показывает все дни до конца, а не только 1–2 прошедших). Линия «факт» — сумма SP issues, чья категория на конец дня (через issue_status_events) ещё не done, определена только по дни min(today, end_date) включительно (для будущих дней actualSp = null, точка на графике не рисуется вместо падения в 0) — линия «идеал» определена на весь диапазон сразу. Идеальная линия — прямая от текущего общего SP спринта (то же число, что в KPI «Взято») до 0 на end_date. «Отставание N SP» = факт − идеал на последний день с реальным фактом, показывается только когда положительное и только для активного спринта. Поток по статусам (CFD), в отличие от burndown, дальше min(today, end_date) не продлевается — будущее состояние статусов неизвестно по определению; в легенде под графиком показаны актуальные (на последний день) количества по каждой категории.
• Cumulative flow — по каждому дню то же самое переигрывание issue_status_events, но количество issues (не SP) по трём категориям done/indeterminate/new. Issue, ещё не существовавшая на день D (создана позже), в этот день нигде не учитывается — упрощение: точная дата добавления в спринт не хранится (только флаг added_after_sprint_start), поэтому used proxy — дата создания задачи.
• История спринтов — независимо от выбранного в фильтре спринта: активный + до 4 последних закрытых (MAX_HISTORY_SPRINTS = 5), но соблюдает Команда/Тип задачи фильтры. Колонки — Взято/Сделано SP, Выполнение % (Сделано/Взято), Перенесено (issues не в done к текущему моменту/концу спринта), Scope creep %, Ср. cycle time (среднее cycle_time завершённых issues спринта). «Итог»: closed для закрытых; для активного — в риске/на треке через сравнение факта с ожидаемым по линейному темпу процентом на сегодняшний день спринта. Кнопка «Экспорт» формирует CSV на клиенте (данные уже загружены, отдельный backend-эндпоинт не нужен) — кнопка «Сравнить спринты» из макета не реализована.
• Риски спринта — только для активного спринта (для закрытого показывается пояснение вместо пустой/бессмысленной таблицы): «блокер» (issue с активной «is blocked by»-связью через issue_links, см. пункт 10 выше — таблица уже была реализована в задаче «Команды», отдельно реализовывать не потребовалось), «висит на ревью» (текущий статус содержит «ревью»/review, регистронезависимо, и в нём дольше REVIEW_STALE_DAYS = 3 дней — временный фиксированный порог, второй вариант из ТЗ, «1.5× среднего по команде», не реализован, т.к. требует отдельного расчёта baseline'ов по командам, которого пока нигде нет), «без исполнителя» (assignee IS NULL и категория indeterminate). Категория «не успеет» не реализована (в ТЗ отмечена как ненадёжно вычислимая). Если issue подходит под несколько категорий сразу, показывается одна — по приоритету блокер → ревью → без исполнителя, чтобы не дублировать строки. Сортировка — блокеры первыми, затем по убыванию «Дней».

Библиотека виджетов на Дашборде — без drag&drop и без конструктора метрик: виджет либо есть на дашборде целиком (заранее запрограммированный компонент), либо его нет.

• dashboard_widgets (id, widget_type UNIQUE, position, enabled) — какие виджеты сейчас на дашборде и в каком порядке. При первом запуске (таблица реально пустая — не «все виджеты убраны», для этого отдельная проверка WHERE NOT EXISTS (SELECT 1 FROM dashboard_widgets)) сеется 4 виджета по умолчанию: stats_cards (все 4 карточки статистики — одним виджетом, не по отдельности), by_status, by_team, by_type. Пятый тип, attention, не сеется по умолчанию. Удаление — не DELETE, а enabled = false, поэтому повторное добавление того же виджета восстанавливает его на старой позиции, а не в конец.
• GET /api/dashboard/widgets / POST /api/dashboard/widgets/:type (body { enabled }) в routes/dashboard.js — список читает и «Библиотека виджетов» (WidgetLibraryModal.jsx: без категорий/поиска/настройки ширины — при пяти виджетах это не нужно), и сам Dashboard (только enabled: true, по position). У каждого виджета на дашборде — меню «···» (WidgetMenu.jsx) с «Удалить виджет». Раскладка (3 узких by_*-виджета в один ряд, stats_cards/attention каждый на всю ширину) — фиксированные метаданные по типу виджета в Dashboard.jsx (FULL_WIDTH_TYPES), не настройка конкретного экземпляра.
• Виджет «Требует внимания» (AttentionWidget.jsx) — две категории проблемных задач, общая логика с фильтром «Проблема» в «Задачах» (см. ниже) вынесена в lib/problemIssues.js, чтобы виджет и фильтр не могли разойтись в классификации:
  • «блокер» — issue с активной «is blocked by»-связью через issue_links (таблица уже существовала — см. пункт 10, отдельно реализовывать не пришлось).
  • «зависла» (aging WIP) — открытая (indeterminate) задача, у которой (сегодня − started_at) / эталон > 0.9. Эталон — среднее cycle_time завершённых задач той же команды с ТЕМ ЖЕ story_points (если таких ≥ 3), иначе 85-й перцентиль cycle_time по всем завершённым задачам команды (nearest-rank, без интерполяции — в ТЗ не оговорён метод). Задача без story_points или без истории (< 3 в своей SP-группе) тоже уходит на перцентильный fallback. Без эталона вообще (у команды нет ни одной завершённой задачи) — задача не классифицируется никак, не «зависла» по умолчанию.
  • Если задача подходит под обе категории — показывается только как «блокер» (совпадает с требуемой сортировкой: блокеры первыми, затем «зависла» по убыванию aging_ratio).
  • «Просрочка SLA» не реализована — нет данных о согласованных SLA, отдельная метрика вне охвата задачи.
  • GET /api/dashboard/attention учитывает текущий общий фильтр Дашборда (Проект/Команда/Тип/Статус/Приоритет/Период) — точно так же, как остальные виджеты; превью — 10 строк, при большем числе — «N задач всего» и переход в «Задачи» с уже применённым фильтром «Проблема» = обе категории сразу (onNavigateToTasks({ problem: [...] }), тот же механизм полной замены общих фильтров, что и у клика по виджетам По статусу/По команде/По типу). Клик по строке открывает ту же боковую панель (TaskDetailPanel.jsx), что и в «Задачах» — эндпоинт отдаёт задачи в том же формате, что и GET /api/jira/tasks, так что клик не требует отдельного похода за деталями.
• Фильтр «Проблема» в «Задачах» — новое поле в общем (используемом и Дашбордом, и Задачами) объекте фильтров FilterBar.jsx/useSharedFilters.js (сохраняется и сбрасывается вместе с остальными), но рендерится только на экране «Задачи» — через проп showProblem, которым Dashboard.jsx не пользуется. GET /api/jira/tasks резолвит значения «Блокер»/«Зависла» в конкретный список id через computeProblemIssues() и подмешивает id = ANY($n::int[]) к остальным условиям buildTaskFilters — то есть фильтр «Проблема» комбинируется с любыми другими фильтрами Задач как обычное условие, не отдельный режим.