mikhail
230c534403
- Data хранит base64-байты; сырые PNG-байты надо отдавать через FromBytes, иначе изображение портится на проводе (0x89 -> U+FFFD) - проверено сквозным прогоном по MCP-протоколу: connect -> document_create -> sketch_create -> add_circle -> close -> extrude_boss -> model_snapshot, получен валидный PNG (~19 КБ) цилиндра - docs/OPEN_QUESTIONS.md: конкурентность вызовов MCP и нюанс FromBytes Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
54 lines
4.4 KiB
Markdown
54 lines
4.4 KiB
Markdown
# Открытые вопросы для проработки
|
|
|
|
Журнал спорных моментов и решений, принятых автономно (ночная сессия 2026-05-25/26).
|
|
Помечено: ⚠️ = требует вашего решения; ✅ = решено по умолчанию, можно пересмотреть.
|
|
|
|
---
|
|
|
|
## ⚠️ 1. API5 vs API7 для построения 3D
|
|
**Контекст.** Примеры SDK строят 3D через **API5** (`ksPart.NewEntity(o3d_*)` →
|
|
`ksBossExtrusionDefinition` → `Create()`). API7 предлагает `IPart7` → `IModelContainer` →
|
|
`IExtrusions.Add()`.
|
|
**Решение по умолчанию (✅ в коде):** в v1 строю 3D через **API5 `ksPart`** (надёжно, повторяет
|
|
рабочие примеры Step3d1). API7 использую для приложения/документов/версии.
|
|
**На проработку:** переводить ли операции на чистый API7 позже (плюс — единообразие, минус — риск).
|
|
|
|
## ✅ 2. Точка входа подключения — API5
|
|
Для построения 3D нужен `KompasObject` (API5), а для снимка — `ksDocument3D` (API5).
|
|
Поэтому `KompasSession` подключается через `KOMPAS.Application.5` → `KompasObject`, затем
|
|
`ksGetApplication7()` → `IApplication`. Держит обе ссылки. (Ранее в спайке заходили через `.7`.)
|
|
|
|
## ✅ 3. Состав проектов v1
|
|
Вместо 4 проектов (Host/Tools/Core/Interop) сделано компактно: **Core** (COM + сервисы) +
|
|
**Host** (MCP + определения инструментов) + **Tests**. Interop — вендорские DLL в `libs/`.
|
|
Разнести на больше проектов можно позже.
|
|
|
|
## ✅ 4. Тестовые артефакты
|
|
Тестовые документы КОМПАС сохраняю в `.scratch/` (gitignore). Снимки рендера — туда же,
|
|
для визуальной проверки.
|
|
|
|
---
|
|
|
|
## Журнал решений по ходу
|
|
(дополняется автоматически во время работы)
|
|
|
|
### ⚠️ Конкурентность вызовов MCP и состояние сессии
|
|
MCP-сервер обрабатывает запросы **конкурентно**. Цикл моделирования с реестром эскизов по id
|
|
(`sketch_create` → `sketch_add_*`) предполагает, что клиент **ждёт ответа** на каждый вызов перед
|
|
следующим (нормальное поведение LLM-клиентов). При «конвейерной» отправке зависимых вызовов
|
|
возможна гонка (id ещё не зарегистрирован). STA-диспетчер сериализует COM, но не порядок постановки задач.
|
|
**На проработку:** нужна ли серверная сериализация вызовов инструментов (очередь) для надёжности
|
|
stateful-сессии? Пока полагаемся на последовательное поведение клиента.
|
|
|
|
### ✅ Возврат изображения: ImageContentBlock.FromBytes
|
|
Поле `ImageContentBlock.Data` хранит **base64-байты**, а не сырые. Сырые байты PNG нужно
|
|
передавать через `ImageContentBlock.FromBytes(bytes, mimeType)` — он сам кодирует. Прямое
|
|
присваивание `Data = rawBytes` портит изображение на проводе. Исправлено в VisionTools.
|
|
|
|
### ✅ Снимок 3D: рендер через файл, а не resultArrayBytes
|
|
`ksDocument3D.SaveAsToRasterFormat(fileName, param)` при **непустом** `fileName` возвращает TRUE,
|
|
пишет корректный PNG на диск, но `param.resultArrayBytes` остаётся **пустым**. Поэтому
|
|
`SnapshotService` рендерит во временный файл и читает байты обратно (надёжно проверено на v24 Home).
|
|
**На проработку:** пустое имя файла + `returnResultAsArrayBytes=true` для чистого in-memory —
|
|
не проверено; текущий путь через temp-файл работает.
|