openspec/specs/data-model/spec.md

@@ -8,7 +8,7 @@
 ### Requirement: Схема базы хаба
 База хаба SHALL быть одним файлом SQLite (WAL) с таблицами `issue`, `issue_link`, `issue_comment`, `issue_change`, `issue_attachment`,
 `attachment_file`, `issue_note`, `batch`, `command`, `sync_run`, `agent_status`, `setting`, `project`. Схема SHALL создаваться и мигрироваться самим хабом при
-старте по номеру версии в `setting.schema_version` (текущая — 6). Миграция существующей базы SHALL выполняться в одной
+старте по номеру версии в `setting.schema_version` (текущая — 8). Миграция существующей базы SHALL выполняться в одной
 транзакции с блокировкой записи; в той же транзакции, после повторной проверки версии, хаб SHALL скопировать файл базы в
 `backups/<дата-время>-schema-v<старая>.sqlite` рядом с базой — одна копия на миграцию, сколько бы соединений ни
 открывалось одновременно. Каталог данных хаба и `backups/` SHALL иметь права `0700` (в базе токены): хаб выставляет их
@@ -32,6 +32,11 @@ Jira как есть (`issue_comment.created`/`updated`, `issue_change.created`,
 Миграция v5 → v6 SHALL: создать пустые `issue_attachment` (с индексом по `key`) и `attachment_file`. Списки вложений
 появляются с первым `refresh` агента v14.
 
+Миграция v7 → v8 SHALL: удалить колонку `issue_note.fact_status` (если она есть; значения удаляются безвозвратно, копия —
+в `backups/` по общему правилу) и ключи `status_labels` и `transitions_map` из `setting`, если они есть, и поднять
+`settings_version`, если хотя бы один из ключей был удалён. Прочие поля заметок, задачи и настройки миграция MUST NOT
+менять.
+
 #### Scenario: Первый запуск
 - **WHEN** хаб стартует с несуществующим файлом базы
 - **THEN** файл создаётся, таблицы и индексы на месте, `setting.schema_version` = текущая; каталог данных с правами `0700`
@@ -39,29 +44,36 @@ Jira как есть (`issue_comment.created`/`updated`, `issue_change.created`,
 #### Scenario: Миграция базы v1
 - **WHEN** хаб стартует с базой `schema_version = 1`, в которой есть задачи, заметки и команда в `claimed`
 - **THEN** в `backups/` копия базы v1; добавлена `command.deliveries` (у `claimed` — 1, у остальных — 0); добавлена пустая
-  `issue_comment`; данные на месте; `schema_version = 6`
+  `issue_comment`; данные на месте; `schema_version` = текущая
 
 #### Scenario: Миграция базы v2
 - **WHEN** хаб стартует с базой `schema_version = 2`, в которой есть задачи, связи и заметки
-- **THEN** в `backups/` копия базы v2; добавлена пустая `issue_comment`; данные на месте; `schema_version = 6`
+- **THEN** в `backups/` копия базы v2; добавлена пустая `issue_comment`; данные на месте; `schema_version` = текущая
 
 #### Scenario: Миграция базы v3
 - **WHEN** хаб стартует с базой `schema_version = 3`, `base_jql = "project = AURORA AND labels = AWPCA"`, `board_id = 4216`,
   в `sync_run` полный прогон с этой `query`
 - **THEN** в `backups/` копия базы v3; проект `AWPCA` «АРМ КА» с `board_id = 4216`, `board_type = NULL`; ключи `base_jql`
   и `board_id` в `setting` на месте; `query` того прогона — `project = AURORA AND labels in ("AWPCA")`; задачи, заметки,
-  пакеты на месте; `schema_version = 6`
+  пакеты на месте; `schema_version` = текущая
 
 #### Scenario: Миграция базы v4
 - **WHEN** хаб стартует с базой `schema_version = 4`, у задачи X комментарий с `created = "2026-10-22T13:05:11.000+0300"`,
   в `sync_run` полный прогон
 - **THEN** в `backups/` копия базы v4; есть пустая `issue_change`; у комментария `created_at = "2026-10-22T10:05:11+00:00"`,
-  `created` прежний; у прогона `history_at = NULL`; затем миграция v5 → v6; `schema_version = 6`
+  `created` прежний; у прогона `history_at = NULL`; затем миграция v5 → v6; `schema_version` = текущая
 
 #### Scenario: Миграция базы v5
 - **WHEN** хаб стартует с базой `schema_version = 5`
 - **THEN** в `backups/` копия базы v5; есть пустые `issue_attachment` и `attachment_file`; прочие таблицы не тронуты;
-  `schema_version = 6`
+  `schema_version` = текущая
+
+#### Scenario: Миграция базы v7
+- **WHEN** хаб стартует с базой `schema_version = 7`, у задачи X заметка `fact_status = "В работе"`, `work_kind =
+  "Аналитика"`, в `setting` есть `status_labels` и `transitions_map`, `settings_version = 12`
+- **THEN** в `backups/` копия базы v7; в `issue_note` нет колонки `fact_status`, у X `work_kind = "Аналитика"`,
+  `updated_at` прежний; ключей `status_labels` и `transitions_map` в `setting` нет; `settings_version = 13`;
+  `schema_version = 8`
 
 #### Scenario: refresh в очереди при миграции
 - **WHEN** в базе v3 стоит `queued` `refresh {jql: "project = AURORA AND labels = AWPCA"}`
@@ -123,15 +135,15 @@ SHALL сохранять. Так же со вложениями: прислан
 
 ### Requirement: Служебные заметки
 Таблица `issue_note` SHALL хранить поля, которых нет в Jira: `key` (PK; ключ Jira или временный `new:<n>`),
-`fact_status`, `work_kind`, `done_text`, `rest_text`, `owner_note`, `updated_at`, `updated_by`. Обновление зеркала
+`work_kind`, `done_text`, `rest_text`, `owner_note`, `updated_at`, `updated_by`. Обновление зеркала
 MUST NOT менять `issue_note`. При завершении `ensure_issue` с временным ключом хаб SHALL перенести заметку на настоящий
 ключ — в том числе по позднему отчёту `done` с ключом о команде, отменённой или переведённой в `failed` до отчёта. Если
 под настоящим ключом заметка уже есть, хаб SHALL слить их: каждое поле берётся из временной заметки, если там оно
 непустое, иначе остаётся под настоящим ключом; `updated_at`/`updated_by` — от более поздней; временная строка удаляется.
 
 #### Scenario: Заметка переживает refresh
-- **WHEN** у задачи есть `issue_note.fact_status = "В работе"` и приходит полное обновление зеркала
-- **THEN** `fact_status` не изменился
+- **WHEN** у задачи есть `issue_note.work_kind = "Аналитика"` и приходит полное обновление зеркала
+- **THEN** `work_kind` не изменился
 
 #### Scenario: Слияние с заметкой под ключом
 - **WHEN** у `new:5` заметка `work_kind = "Аналитика"`, `owner_note` пусто; у `AURORA-1640` заметка `owner_note = "спросить ИБ"`;
@@ -186,14 +198,15 @@ SHALL обнулить `issues_count` и `links_count` её `sync_run` (`started
 
 ### Requirement: Настройки
 Таблица `setting` SHALL хранить парами ключ–JSON: `project_key`, `field_ids`, `issue_types`, `priority_map`, `link_types`,
-`transitions_map`, `pacing`, `tokens` (агентский и клиентский), `settings_version` (увеличивается при любой
+`pacing`, `tokens` (агентский и клиентский), `settings_version` (увеличивается при любой
 правке), `backup_keep`, `auto_refresh_minutes`, `relay_dir` (абсолютный путь папки реле или `null`, по умолчанию `null`;
 относительный путь и не-строка при записи — 422; агенту не передаётся), `closed_statuses` (список имён статусов Jira, считающихся закрытыми, по умолчанию
 `["Готово", "Снято"]`; не-список при записи — 422; агенту не передаётся; на существующей базе появляется со значением
 по умолчанию при открытии хаба). Базовая JQL вычисляется из проектов, доска — свойство проекта (требование
 «Проекты»); на новой базе ключей `base_jql` и `board_id` нет. Оставшиеся от v3 ключи хаб SHALL NOT использовать, кроме
 передачи `board_id` агенту как запасной доски для команд без доски в параметрах (поставленных до миграции);
-`GET /settings` SHALL отдавать вычисленную `base_jql` только для чтения, а запись `base_jql` или `board_id` через
+Ключи, которые модуль объявил устаревшими (у jira — `status_labels`, `transitions_map`), хаб 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` берёт их из ключей конфига
@@ -224,6 +237,16 @@ SHALL обнулить `issues_count` и `links_count` её `sync_run` (`started
 - **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` их не
+  отдаёт
+
 ### Requirement: Проекты
 Таблица `project` SHALL хранить проекты моста — подмножества задач Jira-проекта `project_key`, выделенные меткой:
 `label` (PK, метка Jira), `name`, `created_at`. Метка SHALL быть непустой строкой до 100 символов без пробельных и

openspec/specs/hub-api/spec.md

@@ -113,10 +113,10 @@ JSON.
 ### Requirement: Маршруты интерфейсов
 Хаб SHALL предоставлять интерфейсам (MCP, веб-приложение) следующие маршруты под клиентским токеном:
 - `GET /issues` с фильтрами `project` (разрез по проекту, см. `data-model`, «Проекты»: свои и соседи, `neighbor`
-  относительно проекта; неизвестный проект — 404), `sprint`, `assignee`, `work_kind`, `fact_status`, `status`, `label`,
+  относительно проекта; неизвестный проект — 404), `sprint`, `assignee`, `work_kind`, `status`, `label`,
   `epic`, `neighbor`, `q` (подстрока темы), `hide_closed` (`1` / `true` — без задач, чей `status` входит в настройку
-  `closed_statuses`; задача без статуса не закрыта), `limit`/`offset` — строки зеркала (все поля `issue`) с `fact_status`
-  и `work_kind` из заметок; сокращение до карточки — дело интерфейса. Без `project` — всё зеркало, `neighbor` — признак
+  `closed_statuses`; задача без статуса не закрыта), `limit`/`offset` — строки зеркала (все поля `issue`) с `work_kind` из
+  заметок; параметр `fact_status` хаб игнорирует, как любой неизвестный; сокращение до карточки — дело интерфейса. Без `project` — всё зеркало, `neighbor` — признак
   зеркала (вне базовой JQL).
 - `GET /issues/{key}` — задача целиком: поля, `epic_summary` (тема эпика из зеркала или `null`), связи в обе стороны
   (`links_out: [{target_key, link_type, summary, status}]`, `links_in: [{source_key, link_type, summary, status}]`, где
@@ -127,7 +127,8 @@ JSON.
   `data-model`, «Скачанные вложения» (`error` — только при `failed`, иначе `null`); `description_attachment_ids` и
   `attachment_ids` комментария — id вложений, на которые ссылается текст (см. «Ссылки на вложения в тексте»), в порядке
   первого упоминания, без повторов.
-- `PUT /issues/{key}/note` — заметки (частичное обновление, `updated_by` из тела).
+- `PUT /issues/{key}/note` — заметки (частичное обновление, `updated_by` из тела); поле вне списка заметок (в том числе
+  `fact_status`) — 422 «неизвестные поля заметки: …», заметка не меняется.
 - `POST /batches` `{title, author, project?, commands: [...]}` → `{id, estimate_seconds}`; 422 при неизвестном типе,
   неверных параметрах (в том числе неверного типа значения), временном ключе без `ensure_issue`, двух и более
   `ensure_issue` с одинаковой `summary` (сравнение после обрезки пробелов по краям; в ответе перечислены повторяющиеся
@@ -312,7 +313,7 @@ SHALL скопировать файл базы в `backups/<дата-время>
 - `issues` — с `project` — свои задачи проекта и его соседи (см. `data-model`, «Проекты»), `neighbor` относительно
   проекта; без `project` — все задачи зеркала, включая эпики и соседей, `neighbor` — признак зеркала. Поля: `key`,
   `summary`, `issue_type`, `status`, `priority`, `assignee`, `sprint`, `duedate`, `planned_start`, `planned_end`,
-  `epic_key`, `labels` (список), `neighbor` (bool), `fact_status`, `work_kind` (из заметок, `null` если заметки нет);
+  `epic_key`, `labels` (список), `neighbor` (bool), `work_kind` (из заметки, `null` если заметки нет);
   порядок — по ключу;
 - `links` — с `project` — связи, у которых хотя бы один конец — своя задача проекта; без `project` — все связи
   зеркала: `{source, target, link_type}`, `link_type` — имя типа в Jira, направление как в `issue_link` (`source`

openspec/specs/mcp/spec.md

@@ -36,7 +36,7 @@ HTTP API хаба клиентским токеном из настроек; с
 |---|---|---|
 | `projects` | — | таблица: метка, название, доска, тип доски («неизвестен», пока агент не определил), число своих задач; в привязанной сессии текущий проект отмечен |
 | `project_create` | `label`, `name`, `board_id` (необязательно) | `POST /projects` с автором `claude`: проект, id пакета обновления и фрагмент `.mcp.json` для репозитория проекта (см. ниже); 409/422 — текст ошибки |
-| `issues` | фильтры как у `GET /issues` (кроме `project` — его задаёт привязка), `limit` (по умолчанию 50) | таблица: ключ, тема (до 80 символов), статус, срок, исполнитель, спринт, статус по факту |
+| `issues` | фильтры как у `GET /issues` (кроме `project` — его задаёт привязка), `limit` (по умолчанию 50) | таблица: ключ, тема (до 80 символов), статус, срок, исполнитель, спринт |
 | `issue` | `key` | поля, связи (обе стороны, с типом и направлением), заметки, последние команды, комментарии: «комментарии (N):» и 5 последних (номер «#<comment_id>», автор, время, текст до 300 символов с «…»), «ещё M», если их больше 5; без комментариев — «комментариев нет»; у комментария со ссылками на вложения — строка «файлы: #<id> <имя>, …»; затем вложения (см. «Вложения в MCP») |
 | `comment` | `key`, `comment_id` (номер из ответа `issue`, «#» в начале допускается) | один комментарий целиком по `GET /issues/{key}`: строка «<key> #<id> <автор>, создан <created>» (и «, изменён <updated>», если `updated` есть и отличается от `created`), под ней полный текст с переносами строк; нет такого номера — «у <key> нет комментария #<id>»; есть ссылки на вложения — после текста строка «вложения:» и по строке на каждое: «#<id> <имя> (<размер>)» |
 | `attachment` | `key`, `attachment` (номер вложения «#<id>» или «<id>», иначе — точное имя файла), `wait_seconds` (по умолчанию 120, не больше 600) | скачивает вложение и отдаёт путь к локальной копии (см. «Вложения в MCP») |

openspec/specs/migration/spec.md

@@ -7,10 +7,11 @@
 
 ### Requirement: Инициализация настроек
 `sdlc-hub init --config <admin/jira-sync/config.example.json>` SHALL перенести в `setting`: `project_key`, типы задач,
-`epic_name_field_id`, `fields`, `epic_link`, `priority_map`, `labels`, `status_labels`, `kind_labels`, `comment_marker`,
-`pacing` (в новую форму по типам команд), `transitions.map`, `link_types`; сгенерировать два токена; завести проект
+`epic_name_field_id`, `fields`, `epic_link`, `priority_map`, `labels`, `kind_labels`, `comment_marker`,
+`pacing` (в новую форму по типам команд), `link_types`; сгенерировать два токена; завести проект
 `AWPCA` «АРМ КА» с `board_id` из `sprints.board_id` конфига (если проекта `AWPCA` ещё нет). Поля `auth`, `base_url`,
-`verify_ssl`, `ca_bundle` MUST NOT переноситься (они у агента).
+`verify_ssl`, `ca_bundle` MUST NOT переноситься (они у агента); `status_labels` и `transitions` MUST NOT
+переноситься (статуса по факту в хабе нет).
 
 #### Scenario: Повторный init
 - **WHEN** `init` вызван на уже инициализированной базе
@@ -18,11 +19,13 @@
 
 #### Scenario: Первый init
 - **WHEN** `init --config` на пустой базе, в конфиге `sprints.board_id = 4216`
-- **THEN** есть проект `AWPCA` «АРМ КА» с `board_id = 4216`; в `setting` нет `base_jql` и `board_id`
+- **THEN** есть проект `AWPCA` «АРМ КА» с `board_id = 4216`; в `setting` нет `base_jql`, `board_id`, `status_labels`
+  и `transitions_map`
 
 ### Requirement: Импорт CSV-пакета
 `sdlc-hub import <папка admin/jira-sync>` SHALL прочитать `tasks.csv`, `new_tasks.csv`, `epics.csv` и заполнить
-`issue_note` по ключу Jira: статус по факту, вид работы, что сделано, что осталось, внутренние колонки. Строки
+`issue_note` по ключу Jira: вид работы, что сделано, что осталось, внутренние колонки; колонку «Статус по факту»
+импорт SHALL пропускать. Строки
 `new_tasks.csv` без ключа SHALL получать временный ключ `new:<номер строки>`; строки `tasks.csv` и `epics.csv` без ключа
 SHALL пропускаться. `links.csv` SHALL импортироваться как сверочный набор в отчёт импорта (ожидаемые связи против зеркала
 после первого `refresh`), не как команды. Связь, которой в зеркале нет как `source→target` того же типа, но есть как

openspec/specs/modules/spec.md

@@ -55,7 +55,7 @@ jira-agent, `wiki` — eva-agent). Агент SHALL определяться п
 
 #### Scenario: Настройки только своего модуля
 - **WHEN** токеном агента `wiki` вызван `GET /agent/settings`
-- **THEN** в ответе есть `wiki_pacing` и `settings_version`, ключей jira (`project_key`, `transitions_map`) нет
+- **THEN** в ответе есть `wiki_pacing` и `settings_version`, ключей jira (`project_key`, `link_types`) нет
 
 ### Requirement: Поля проекта от модулей
 Проект ядра SHALL состоять из `label`, `name`, `created_at`; остальные поля проекта SHALL объявлять модули: имя, тип,

openspec/specs/web-app/spec.md

@@ -375,8 +375,7 @@ SHALL сообщать об этом с кнопкой «Закрыть»; ха
 показывать новый «вид работы» без «Перечитать», доска под окном SHALL перечитать снимок
 (`GET /board`) без потери раскладки и прокрутки; при 422 — текст ошибки у формы без
 потери введённого. Закрытие окна, переход по связи и уход в другой раздел с несохранёнными правками SHALL требовать
-подтверждения. Статуса по факту в заметках приложения нет: форма его не показывает и не отправляет, сохранённое в хабе значение не
-меняется. Заметки пишутся только в хаб, в Jira приложение ничего не отправляет.
+подтверждения. Статуса по факту в заметках нет. Заметки пишутся только в хаб, в Jira приложение ничего не отправляет.
 
 #### Scenario: Только изменённые поля
 - **WHEN** в заметке нажато «Править», изменено только «осталось» и нажато «Сохранить»