Критичный баг-фикс по режиму «Пожелания из совещания».
Проблема: сервер 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 символов).
На пути /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-примеры.
- rewrite ucnl-market-memory/SKILL.md with final layout (accounts/products/campaigns/markets + insights/conversations/inbox), extended frontmatter (sensitive flag), domain routing table with border examples
- refresh obsidian-memory/SKILL.md with the same domain-routing section placed at top, matching examples, and updated description with negative trigger
- Новый skill ucnl-market-memory для репо ucnlmarket/ucnl-market-memory
(маркетинг и продажи UCN)
- В obsidian-memory добавлено domain routing: личное → obsidian-vault,
UCN sales/marketing → ucnl-market-memory
- Description обоих skills обновлены для корректного triggering
- README верхнего уровня обновлён
obsidian-memory/SKILL.md:
- vault layout дополнен веткой memory/1c/files/ (README.md + list.md)
- в секцию '1С — special case' добавлены шаги 5-7: при запросе
на генерацию документа читать files/list.md, искать подходящий
шаблон, использовать как основу; если нет — генерировать и
предлагать сохранить как новый шаблон
- явное правило: 'файл без строки в list.md для Claude не существует'
1c-analyst/SKILL.md:
- в 'Правила формирования выходных документов' добавлен шаг 0
(выполняется ДО п.1 про docx): проверить реестр шаблонов
- в таблицу интеграций дополнено упоминание files/list.md в списке
того, что читать в начале 1С-разговора
obsidian-memory/SKILL.md:
- структура vault дополнена веткой memory/1c/ (configurations/, projects/)
- новая секция про 'Areas vs projects': когда заводить целую подпапку
вместо одного файла в memory/projects/
- добавлен explicit protocol для 1С-разговоров: какие файлы читать
в начале, как работать параллельно с 1c-analyst
1c-analyst/SKILL.md:
- в таблицу 'Интеграция с другими скиллами' добавлен obsidian-memory
с явным указанием читать memory/1c/ в начале каждого 1С-разговора
- явно разведена ответственность: 1c-analyst = процедурные знания,
obsidian-memory/1c = персональный контекст пользователя (конкретные
конфигурации, клиентские проекты, принятые решения)
Протокол работы Claude с creator/obsidian-vault как долговременной
памятью через Gitea REST API.
Покрывает:
- структуру vault (claude/** — RW, остальное RO)
- frontmatter-конвенции (type, project, tags, created/updated,
relevance, confidence, private)
- протокол: когда искать, что читать, куда писать, что НЕ делать
- Gitea REST API шпаргалка (read/list/search/create/update/batch)
- gotchas trial-and-error (поле 'content' а не 'content_base64',
URL-encode путей, sha для PUT)
- формат коммит-сообщений (claude: …)
- правила именования, boundaries, private-флаг
The original setup guide covered connecting Altium directly to the
portal SQL server. That works but has three drawbacks under RU
conditions: ~60-second Altium startup over VPN, daily VPN dependency,
single point of failure at Mark Harris's hosting.
New section 11 documents the self-hosted alternative we just built and
verified end-to-end:
- Two independent mirrors:
- homework/altium-library: Gitea pull-mirror of issus/altium-library
with LFS (SchLib + PcbLib + STEP, ~6 GB)
- homework/celestial-mirror-db: MSSQL 2022 Express in Docker on
192.168.9.147, populated weekly by a pymssql-based sync job with
best-effort + row-count/schema fingerprint skip logic
- Results: Altium startup <1s (100x faster), VPN only needed once a
week for the sync runner, full control over the dataset
- Full deployment sequence (Gitea migrate API → docker compose up →
first manual full-sync → client DbLib rewrite)
- ConnectionString rewrite details (altium_reader user, LAN IP,
Encrypt=Optional/TrustServerCertificate=Yes for self-signed cert)
- MPN-to-view lookup strategies (Shift+C in Altium; dynamic SQL that
scans all 168 tables)
- Troubleshooting specific to the mirror stack
creator
creator
creator
Claude
Claude
unavlab