ДокументацияОткрыть Kanyman
Разделы документации

Разработчикам

Solution Packs

Как подключать продуктовые роли и сценарии декларативно, не добавляя product-specific код в Kanyman Core.

Обновлено: 11 августа 2026

Что хранит manifest (сокращённый пример)

jsonKanyman docs
{
  "schema": "kanyman.solution-pack.v1",
  "id": "example.support",
  "version": "1.0.0",
  "core_contract": "kanyman.external-integrations.v1",
  "roles": [{ "key": "support", "title": "Support" }],
  "scenarios": [{
    "key": "support.diagnostics",
    "version": "1.0.0",
    "entry_role": "support",
    "allowed_capabilities": ["project.get_diagnostics"]
  }],
  "required_capabilities": [{
    "name": "project.get_diagnostics",
    "version": "1.0.0",
    "kind": "read",
    "side_effect": "none"
  }]
}
  • Manifest содержит роли, сценарии, policies, требования к знаниям, UI labels и acceptance fixtures.
  • Credentials, приватные ключи, токены и прямой доступ к базе продукта в manifest запрещены.
  • Capability указывается по стабильному имени и точной версии; текущий контракт принимает read и draft.
  • DISP и VerifyBox используют тот же schema contract, что и любой третий продукт.

Установка и совместимость

  1. 1Создайте и активируйте внешнюю интеграцию.
  2. 2Добавьте и протестируйте capabilities, которые требует выбранный pack.
  3. 3Установите pack на интеграцию. Kanyman сохранит неизменяемый snapshot manifest и digest.
  4. 4Если capability отсутствует, неактивна или имеет другую policy/version, установка получает статус blocked.
  5. 5После изменения capabilities запустите повторную проверку и активируйте pack.
  6. 6Pack можно отключить без удаления истории; rollback переключает указатель только на ранее установленный immutable snapshot.
  7. 7В runtime модель выбирает точные pack, scenario и specialist role, а сервер повторно проверяет выбор и пропускает только capabilities текущего шага сценария.
  8. 8Blocked или disabled pack работает fail-closed: его capabilities не передаются агенту до успешной повторной проверки и активации.
httpKanyman docs
GET /api/projects/{project_id}/external-integrations/{integration_id}/connectors/{connector_id}/versions/{version}/manifest
Authorization: Bearer <Kanyman access token>

{
  "schema": "kanyman.connector-contract.v1",
  "digest_scope": "manifest_without_lifecycle_status",
  "digest": "<sha256 canonical contract>",
  "manifest": {
    "schema": "kanyman.connector-manifest.v1",
    "id": "example.support-api",
    "version": "1.0.0",
    "status": "planned",
    "capabilities": ["...full input/output schemas..."]
  }
}

Scenario Library и постоянное состояние

jsonKanyman docs
{
  "schema": "kanyman.solution-scenario.v1",
  "pack_id": "example.support",
  "pack_version": "1.0.0",
  "scenario_key": "support.diagnostics",
  "scenario_version": "1.0.0",
  "status": "active",
  "entry_step": "identify_issue",
  "steps": [{
    "key": "identify_issue",
    "kind": "question",
    "role_keys": ["support"],
    "allowed_capabilities": ["project.get_diagnostics"],
    "answer_options": [{
      "key": "resolved",
      "next_step": "completed"
    }]
  }]
}
  • Определение сценария хранится отдельно от immutable pack manifest и связывается по точным pack/scenario versions.
  • Поддерживаются статусы draft, review, active, paused и archived; runtime исполняет только active.
  • В кабинете owner/admin может проверить JSON на сервере, сохранить immutable draft, отправить его на review и отдельно активировать; draft и review не влияют на runtime и могут быть отменены в архив без потери истории.
  • Активная tenant-scoped версия переопределяет code default без релиза Core, а при её отсутствии runtime использует поставляемое с pack определение.
  • Каждый run сохраняет immutable definition snapshot и SHA-256 digest, текущий step, role и control version.
  • В журнал попадают только безопасные ключи шагов/ответов и product/tariff signals — текст пользователя, токены и PII туда не копируются.
  • Следующий step и role вычисляет сервер из snapshot; модель не может передать произвольное направление перехода.
  • Переход фиксируется в одной транзакции с разрешённым ответом. Retry не создаёт повторный переход.
  • Disable, несовместимость или смена версии pack отменяет активный run fail-closed и сохраняет событие cancelled.

API кабинета

textKanyman docs
GET  /api/projects/{project_id}/solution-packs/catalog
GET  /api/projects/{project_id}/solution-packs
POST /api/projects/{project_id}/solution-packs/install
POST /api/projects/{project_id}/solution-packs/{installation_id}/refresh
POST /api/projects/{project_id}/solution-packs/{installation_id}/activate
POST /api/projects/{project_id}/solution-packs/{installation_id}/disable
POST /api/projects/{project_id}/solution-packs/{installation_id}/rollback

GET  /api/projects/{project_id}/solution-packs/{installation_id}/scenarios
POST /api/projects/{project_id}/solution-packs/{installation_id}/scenarios/{scenario_key}/preview
POST /api/projects/{project_id}/solution-packs/{installation_id}/scenarios/{scenario_key}/drafts
POST /api/projects/{project_id}/solution-packs/{installation_id}/scenarios/versions/{version_id}/submit
POST /api/projects/{project_id}/solution-packs/{installation_id}/scenarios/versions/{version_id}/activate
POST /api/projects/{project_id}/solution-packs/{installation_id}/scenarios/versions/{version_id}/archive

Продолжить

Read-only инструментыБезопасные HTTP-вызовы для получения актуальной диагностики.Действия с подтверждениемAction lifecycle, Idempotency-Key и безопасная обработка неизвестного результата.API и ошибкиПубличные endpoints Web Chat и безопасные коды ошибок.
Solution Packs — Kanyman Docs