Commit Graph

4 Commits

Author SHA1 Message Date
creator ed2a69798a docs(1c-analyst): URL-схема UI Devprom, карточка артефакта по /pm/<project>/<UID> 2026-05-17 00:30:59 +03:00
creator 7365242875 fix(1c-analyst): поле Description (не Content) + обязательная верификация GET-ом
Критичный баг-фикс по режиму «Пожелания из совещания».

Проблема: сервер Devprom на POST /issue/items молча игнорирует поле
Content, упомянутое в публичной документации /docs/8835.html.
Запись создаётся с пустым телом, HTTP 200, UID возвращается —
никакого сигнала об ошибке. Правильное имя поля для тела пожелания
на эндпоинте /issue/items — Description.

Выявлено при проверке U-6186 (Артур): поле Description пустое,
хотя POST вернул валидный UID. Та же проблема обнаружилась на 6
пожеланиях Тепловин U-6189..U-6194 — все с пустым телом.
Пересоздано как U-6198..U-6203 с полем Description, размер тела
1565–2172 символа, верификация пройдена.

Правки скилла:
- devprom-alm-api.md §0: новый блок «Критично: сервер молча отбрасывает
  незнакомые поля» + обязательная схема контрольного GET с ассертами.
  Список известных тихих ловушек (Content вместо Description, Type.Id=''
  в request/items, Requirement в POST).
- devprom-alm-api.md §2: рецепт с Description + встроенные ассерты.
- devprom-alm-api.md §3: справочник полей — Description с пояснением
  про Content и документацию, требование GET-проверки.
- devprom-alm-api.md appendix: curl-примеры с Description.
- meeting-wishes-extraction.md Шаг 6: Description в инструкции + ссылка
  на секцию «тихое отбрасывание».
- meeting-wishes-extraction.md Шаг 7: жёсткая формулировка
  «Ответ POST — недостаточное подтверждение успеха», ассерты
  на префикс UID, содержимое Description, Priority, Function;
  визуальная проверка в UI.
- meeting-wishes-extraction.md Python-шаблон: Description + ассерты
  на размер тела (>100 символов).
2026-04-22 07:02:53 +00:00
creator dee7d51c19 fix(1c-analyst): DELETE через /issue/items работает для любых записей Request
На пути /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 больше не нужен
2026-04-22 00:25:35 +00:00
creator dd1a85fc01 feat(1c-analyst): режим «Пожелания из совещания» + Devprom ALM API reference
- Новый режим работы: извлечение Пожеланий из транскрипции совещания
  с заказчиком и загрузка в 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-примеры.
2026-04-21 23:48:51 +00:00