sdlc-hub/openspec/changes/archive/2026-10-26-hub-backend-fixes/specs/data-model/spec.md

MODIFIED Requirements

Requirement: Настройки

Таблица setting SHALL хранить парами ключ–JSON: project_key, field_ids, issue_types, priority_map, link_types, pacing, tokens (агентский и клиентский), settings_version (увеличивается при любой правке), backup_keep, auto_refresh_minutes, relay_dir (абсолютный путь папки реле или null, по умолчанию null; относительный путь и не-строка при записи — 422; агенту не передаётся), closed_statuses (список имён статусов Jira, считающихся закрытыми, по умолчанию ["Готово", "Снято"]; не-список при записи — 422; агенту не передаётся; на существующей базе появляется со значением по умолчанию при открытии хаба). Базовая JQL вычисляется из проектов, доска — свойство проекта (требование «Проекты»); на новой базе ключей base_jql и board_id нет. Ключи, которые модуль объявил устаревшими (у jira — status_labels, transitions_map, оставшиеся от v3 base_jql и board_id), хаб SHALL удалять при каждом заполнении умолчаний, не меняя settings_version; агенту они не передаются. GET /settings SHALL отдавать вычисленную base_jql только для чтения, а запись base_jql или board_id через PUT /settings — 422 с пояснением. Спринты агент читает с досок проектов, отдельной настройки имён спринтов нет. Начальные значения SHALL импортироваться из admin/jira-sync/config.example.json командой sdlc-hub init; пароль и логин Jira в настройках MUST NOT присутствовать. issue_types — объект {task, epic, bug}, у каждого {name, id} (id может быть null); init берёт их из ключей конфига issue_type_<тип> и issue_type_<тип>_id; bug попадает в issue_types, только если в конфиге есть хотя бы один из ключей issue_type_bug, issue_type_bug_id (task и epic — как раньше, всегда).

Scenario: Правка настроек поднимает версию

• WHEN через API изменён pacing
• THEN settings_version увеличен, следующий claim отдаёт агенту новую версию

Scenario: Конфиг без ключей ошибки

• WHEN sdlc-hub init --config с issue_type_task, issue_type_epic, без issue_type_bug
• THEN issue_types содержит task и epic, bug нет; постановка ensure_issue с issue_type = bug — 422

Scenario: Неверный relay_dir

• WHEN PUT /settings с relay_dir = "rshb/jira-bridge"
• THEN 422, значение не записано, settings_version не изменился

Scenario: Закрытые статусы по умолчанию

• WHEN хаб открыл базу, в которой нет ключа closed_statuses
• THEN GET /settings отдаёт closed_statuses = ["Готово", "Снято"]; claim агенту этого ключа не передаёт

Scenario: Запись базовой JQL

• WHEN PUT /settings {base_jql: "project = AURORA"}
• THEN 422 «базовая JQL собирается из проектов»; settings_version не изменился

Scenario: Создание проекта не трогает версию настроек

• WHEN создан проект STOCKS_DRRK
• THEN settings_version прежний; GET /settings отдаёт base_jql с обеими метками

Scenario: Ключи вернул процесс прежней версии

• WHEN база v8, процесс со старым кодом (MCP-сессия до reconnect) вставил status_labels = {} и transitions_map = {}, затем вызван ensure_defaults текущего кода (старт хаба, новая MCP-сессия)
• THEN ключей в setting нет, settings_version прежний

Scenario: Ключей статуса по факту нет

• WHEN хаб открыл базу v8
• THEN GET /settings не содержит status_labels и transitions_map; GET /agent/settings агенту jira их не отдаёт

Scenario: Ключи v3 в живой базе

• WHEN в setting лежат base_jql и board_id (база, поднятая с v3), хаб открыл базу
• THEN ключей base_jql и board_id в setting нет, settings_version прежний; GET /settings отдаёт вычисленную base_jql, board_id в ответе нет; PUT /settings {board_id: 1} — 422 «доска Jira — свойство проекта»