На пути /request/items/{id} DELETE действительно заблокирован
(возвращает Unable access entity), но тот же Id можно убрать
через DELETE /issue/items/{id} — он универсален и работает как
для U-записей (созданных через /issue/items), так и для I-записей
(созданных через /request/items). Эмпирически подтверждено чисткой
33 зомби-записей I-6122..I-6176 в test-api-claude за один проход.
Поправлены разделы:
- devprom-alm-api.md §4 «Удаление» — таблица расширена комментарием
про универсальность /issue/items DELETE
- devprom-alm-api.md §6 «Что НЕ работает» — DELETE request/items
отмечен как «не препятствие»
- SKILL.md §«Критически важно» — корректное правило про DELETE
- meeting-wishes-extraction.md антипаттерн №7 — UI больше не нужен
- Новый режим работы: извлечение Пожеланий из транскрипции совещания
с заказчиком и загрузка в Devprom ALM через REST API. Один POST
на одно Пожелание (без PUT), без привязки к требованиям — она
остаётся за пользователем в UI. Границы режима описаны явно:
скрипт не создаёт Company, Feature, IssueAuthor, документы
требований.
- references/meeting-wishes-extraction.md — методика: критерии отбора
(что становится Пожеланием, а что нет), 8-шаговый pipeline,
HTML-шаблон Description с блоками «Заказчик / Описание / Источники /
Цитаты / Предметная область / Источник», Python-шаблон скрипта,
антипаттерны.
- references/devprom-alm-api.md — шпаргалка Devprom ALM REST API:
таблица сущностей со ссылкой на /pm/all/apidocs/list (issue=Пожелание
строка 45, request=Доработка строка 18), каноническое имя сущности
issue для пожеланий, полный справочник полей, алгоритм POST,
ограничения прав (IssueAuthor/User — только UI, DELETE на request
заблокирован), порядок подготовки проекта (UI vs API), curl-примеры.
creator