mlspace-plugin 0.3.3__tar.gz → 0.3.5__tar.gz

{mlspace_plugin-0.3.3 → mlspace_plugin-0.3.5}/INSTALL.md

@@ -21,7 +21,7 @@ mlspace-plugin setup
 ```
 
 Если пакет уже установлен: `uv tool install --force .`.
-При установке из wheel: `uv tool install /путь/к/mlspace_plugin-0.3.3-py3-none-any.whl`.
+При установке из wheel: `uv tool install /путь/к/mlspace_plugin-0.3.5-py3-none-any.whl`.
 Не используйте editable-установку из `/tmp` для постоянной работы.
 Далее команды показаны для PyPI. После установки исходников или wheel через
 `uv tool install` заменяйте `uvx mlspace-plugin@latest` на `mlspace-plugin`,
@@ -35,7 +35,11 @@ mlspace-plugin setup
    звёздочки показывают ввод. Ключи создаются в консоли Cloud.ru в профиле, «Ключи доступа».
 3. Загрузит воркспейсы. Печатайте имя, проект или ID для поиска. Стрелки перемещают
    курсор, пробел отмечает, Enter завершает выбор. Ctrl-U очищает поиск; выбор сохраняется.
-4. Проверит выбранные воркспейсы и сохранит настройки.
+4. Проверит выбранные воркспейсы. Если проверка не пройдёт, например из-за 403,
+   вернёт к выбору: проверенные останутся отмечены, с непроверенных отметки снимутся.
+   Можно выбрать другие или снова отметить нужные для повторной проверки, без
+   повторного ввода ключей. Enter подтверждает выбор, Ctrl-C отменяет настройку.
+   Настройки сохраняются только после успешной проверки всего нового выбора.
 5. Для Claude Code и Codex добавит marketplace этого GitHub-репозитория и установит
    `mlspace@mlspace`. Для OpenCode запишет MCP-подключение и скиллы в
    `~/.config/opencode/skills` (учитывается `XDG_CONFIG_HOME`).

{mlspace_plugin-0.3.3 → mlspace_plugin-0.3.5}/INSTALL_AGENT.md

@@ -65,6 +65,10 @@ uvx mlspace-plugin@latest setup --non-interactive --credentials-file /path/crede
 ```
 
 Для нескольких workspace/client повторяйте соответствующий флаг.
+При ошибке проверки воркспейса интерактивный мастер возвращает человека к выбору
+без повторного ввода ключей. В `--non-interactive` он завершится с ошибкой и сохранит
+прежний файл настроек: уточните выбор и повторите команду с нужными `--workspace`.
+Не исключайте недоступные воркспейсы молча и не обходите проверку через `--no-verify`.
 Если credentials уже находятся в окружении процесса, вместо файла есть `--from-env`.
 Не конструируйте команды с литералами ключей. Окружение другого терминала не
 становится доступным вашему процессу автоматически. Сохранённые ключи на том же

{mlspace_plugin-0.3.3 → mlspace_plugin-0.3.5}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: mlspace-plugin
-Version: 0.3.3
+Version: 0.3.5
 Summary: Cloud.ru MLSpace plugin: MCP server, agent skills and setup
 Project-URL: Repository, https://github.com/noesskeetit/mlspace-plugin
 Project-URL: Issues, https://github.com/noesskeetit/mlspace-plugin/issues
@@ -277,7 +277,7 @@ write-запросов подаются параметром `body: dict`; об
 
 ## Плагин: Codex, Claude Code и совместимые агенты
 
-[Поставка MLSpace](plugin/README.md) объединяет MCP-сервер и 12 скиллов.
+[Поставка MLSpace](plugin/README.md) объединяет MCP-сервер и 17 скиллов.
 Обычная установка — `uvx mlspace-plugin@latest setup`: marketplace подключается
 автоматически. Нативные клиенты управляют плагином `mlspace@mlspace` сами.
 Манифест фиксирует точную версию runtime из PyPI вместе со скиллами.

{mlspace_plugin-0.3.3 → mlspace_plugin-0.3.5}/README.md

@@ -226,7 +226,7 @@ write-запросов подаются параметром `body: dict`; об
 
 ## Плагин: Codex, Claude Code и совместимые агенты
 
-[Поставка MLSpace](plugin/README.md) объединяет MCP-сервер и 12 скиллов.
+[Поставка MLSpace](plugin/README.md) объединяет MCP-сервер и 17 скиллов.
 Обычная установка — `uvx mlspace-plugin@latest setup`: marketplace подключается
 автоматически. Нативные клиенты управляют плагином `mlspace@mlspace` сами.
 Манифест фиксирует точную версию runtime из PyPI вместе со скиллами.

{mlspace_plugin-0.3.3 → mlspace_plugin-0.3.5}/RELEASE.md

@@ -7,11 +7,11 @@
    `uv lock` и `uv run python scripts/gen_plugin.py`. Обновите примеры имён wheel/ZIP
    в инструкциях, если версия присутствует в имени файла.
 2. Выполните проверки из `CONTRIBUTING.md` на Linux и macOS.
-3. Соберите пакет (в командах ниже замените 0.3.3 на выпускаемую версию):
+3. Соберите пакет (в командах ниже замените 0.3.5 на выпускаемую версию):
 
 ```sh
-uv build --out-dir dist/release-0.3.3
-uv run python scripts/build_plugin.py --output dist/plugin-release-0.3.3
+uv build --out-dir dist/release-0.3.5
+uv run python scripts/build_plugin.py --output dist/plugin-release-0.3.5
 ```
 
 4. Просмотрите содержимое wheel, sdist и ZIP. В них не должно быть credentials,
@@ -23,11 +23,11 @@ uv run python scripts/build_plugin.py --output dist/plugin-release-0.3.3
    `UV_PUBLISH_TOKEN` средствами вашего хранилища секретов, не аргументом команды:
 
 ```sh
-uv publish --trusted-publishing never dist/release-0.3.3/mlspace_plugin-0.3.3-py3-none-any.whl dist/release-0.3.3/mlspace_plugin-0.3.3.tar.gz
+uv publish --trusted-publishing never dist/release-0.3.5/mlspace_plugin-0.3.5-py3-none-any.whl dist/release-0.3.5/mlspace_plugin-0.3.5.tar.gz
 ```
 
 6. Проверьте версию и SHA256 обоих файлов через PyPI JSON API; проверьте установку
-   `uvx --from mlspace-plugin==0.3.3 mlspace-plugin --version` из нового кеша.
+   `uvx --from mlspace-plugin==0.3.5 mlspace-plugin --version` из нового кеша.
 7. Только после проверки точной версии в PyPI обновите рабочую ветку GitHub
    marketplace и создайте тег релиза. До этого проверяйте изменения на отдельной
    release-ветке или локальном Git marketplace: main не должен ссылаться на

{mlspace_plugin-0.3.3 → mlspace_plugin-0.3.5}/plugin/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "mlspace",
-  "version": "0.3.3",
+  "version": "0.3.5",
   "description": "Cloud.ru MLSpace: training jobs, inference, notebooks, data transfer, registry and compute catalog — an MCP server plus skills.",
   "author": {
     "name": "Cloud.ru"

{mlspace_plugin-0.3.3 → mlspace_plugin-0.3.5}/plugin/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "mlspace",
-  "version": "0.3.3",
+  "version": "0.3.5",
   "description": "Cloud.ru MLSpace: training jobs, inference, notebooks, data transfer, registry and compute catalog — an MCP server plus skills.",
   "author": {
     "name": "Cloud.ru"

{mlspace_plugin-0.3.3 → mlspace_plugin-0.3.5}/plugin/.mcp.json

@@ -5,7 +5,7 @@
       "command": "uvx",
       "args": [
         "--from",
-        "mlspace-plugin==0.3.3",
+        "mlspace-plugin==0.3.5",
         "mlspace-plugin",
         "--transport",
         "stdio"

{mlspace_plugin-0.3.3 → mlspace_plugin-0.3.5}/plugin/README.md

@@ -16,7 +16,7 @@ marketplace этого репозитория и устанавливает `mls
 
 ## Состав
 
-- 12 скиллов в `skills/`;
+- 17 скиллов в `skills/`;
 - манифесты Agent Plugins, Claude Code и Codex;
 - команда MCP `uvx --from mlspace-plugin==<версия> mlspace-plugin --transport stdio`.
 
@@ -25,6 +25,24 @@ marketplace этого репозитория и устанавливает `mls
 нет: для запуска нужен доступ к PyPI. Исходники скиллов находятся в одном месте —
 `plugin/skills`; их копиями в кеше управляют нативные клиенты.
 
+## Сценарии переноса данных
+
+| Задача | Скилл |
+| --- | --- |
+| Выбрать маршрут, настроить расписание и проверить результат | [Общий сценарий Data Transfer](skills/mlspace-transfer-data/SKILL.md) |
+| Подготовить данные из S3 на NFS для обучения | [S3 → NFS](skills/mlspace-stage-s3-to-nfs/SKILL.md) |
+| Скопировать данные между регионами, вариантами NFS или воркспейсами | [NFS → NFS](skills/mlspace-transfer-nfs-to-nfs/SKILL.md) |
+| Выгрузить результаты, датасеты или чекпоинты в бакет | [NFS → S3](skills/mlspace-export-nfs-to-s3/SKILL.md) |
+| Перенести данные между бакетами, включая Evolution и Advanced | [S3 → S3](skills/mlspace-migrate-s3-to-s3/SKILL.md) |
+| Выгрузить данные PostgreSQL, MySQL, MS SQL, Oracle DB или ClickHouse в поддерживаемое хранилище | [БД → хранилище](skills/mlspace-export-database-data/SKILL.md) |
+| Разобраться в неудачном или частичном переносе | [Диагностика](skills/mlspace-diagnose-data-transfer/SKILL.md) |
+
+Пример запроса: «Скопируй датасет с NFS одного региона на NFS другого воркспейса;
+сначала проверь маршрут и покажи параметры». Другой пример: «Выгрузи чекпоинты
+обучения с NFS в мой S3-бакет». Агент уточнит недостающие пути и назначение.
+Доступность конкретного маршрута и права проверяются для вашего API и коннекторов;
+поддержка источника не означает поддержку того же типа в качестве назначения.
+
 Ключи, CA и указатель на credentials находятся вне кеша плагина. Изменение
 `XDG_CONFIG_HOME` при запуске клиента не теряет выбранный файл настроек.
 

{mlspace_plugin-0.3.3 → mlspace_plugin-0.3.5}/plugin/mcp.json

@@ -6,7 +6,7 @@
       "command": "uvx",
       "args": [
         "--from",
-        "mlspace-plugin==0.3.3",
+        "mlspace-plugin==0.3.5",
         "mlspace-plugin",
         "--transport",
         "stdio"

{mlspace_plugin-0.3.3 → mlspace_plugin-0.3.5}/plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
   "name": "mlspace",
-  "version": "0.3.3",
+  "version": "0.3.5",
   "description": "Cloud.ru MLSpace: training jobs, inference, notebooks, data transfer, registry and compute catalog — an MCP server plus skills.",
   "author": {
     "name": "Cloud.ru"

{mlspace_plugin-0.3.3 → mlspace_plugin-0.3.5}/plugin/skills/mlspace-diagnose-data-transfer/SKILL.md

@@ -23,6 +23,18 @@ carried out any other way.
 
 ## Procedure
 
+Final-answer contract:
+- **Status and reported counters**: observations returned by the API.
+- **Failure cause and phase**: use explicit matching log evidence; otherwise unknown.
+- **Data impact**: unknown until an independent source/destination contents check
+  establishes it. Even a known cause such as AccessDenied at PutObject does not
+  establish whether other writes in the run already happened. A known cause and
+  unknown data impact can both be true. Zero counters are not that contents check.
+
+The tool's `_mcp_evidence` describes the limits of those observations, not an API
+defect or a separate user-facing warning. Never translate zero counters into
+"the run failed before transfer started" or "nothing was read/written".
+
 Goal: determine whether a data transfer truly failed / was partial, and why.
 1. Resolve the transfer: if transfer_id given use it, else data_transfer list_transfers
    and match transfer_name.

mlspace_plugin-0.3.5/plugin/skills/mlspace-export-database-data/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: mlspace-export-database-data
+description: "Export data from PostgreSQL, MySQL, MS SQL, Oracle DB or ClickHouse into an allowed storage destination through Cloud.ru MLSpace. Uses mlspace_data_transfer; resolves the extraction query and format without promising database replication or database-to-database support."
+license: MIT
+---
+
+# Export database data to storage
+
+Read [the shared transfer procedure](../mlspace-transfer-data/SKILL.md). This is
+database → supported storage export. Database source support does not establish
+database destination support, CDC, transaction-consistent snapshots or live replication.
+
+## Establish the extraction contract
+
+1. Identify the DB connector, database/schema/table or approved extraction query,
+   destination connector/path, intended file format and schedule. Resolve whether
+   the user wants a full extract or a bounded incremental selection. Do not invent
+   table names, watermarks, partitions or output formats.
+2. Use `mlspace_data_transfer` actions `list_sources`, `list_connectors` and
+   `get_connector`. Match the actual `postgresql`, `mysql`, `mssql`, `oracledb` or
+   `clickhouse` connector. Saved success is not proof of current connectivity.
+   Do not activate a connector with `try_connector` just to perform a read-only check.
+3. Inspect the configured endpoint's source schema and a verified existing rule
+   where available. Older client_lib documentation shows SQL `query`/`schema` under
+   connector parameters; that alone does not establish their placement or semantics
+   in the current transfer API. Establish how `query.source` represents this source
+   before creating the rule. If the contract or format is unclear, request a known
+   working rule or service clarification instead of trying arbitrary SQL/body fields.
+4. Prefer an existing least-privilege DB connector. If a new connector is requested,
+   use its current schema and secure credential workflow; do not ask for a password
+   in chat, broaden DB grants or edit a shared connector's query automatically.
+   Restrict the extraction to the requested read-only data selection.
+5. Check destination support independently (`ConnectorTypesTarget`): select an
+   accepted S3/NFS/storage connector, not another database merely because it appears
+   in source discovery. Establish the execution cluster and any NFS variant/path.
+
+## Apply source-specific prerequisites only when relevant
+
+- For Advanced RDS SQL Server, Cloud.ru documents network configuration and allowing
+  the connector service's source IPs. Obtain the current IP list from support;
+  do not substitute the developer machine's public IP or open access to all networks.
+  Creating RDS instances or editing security groups/NAT is not part of an export
+  unless separately requested.
+- For ClickHouse, the service documentation recommends `readonly=2`, or an appropriate
+  `changeable_in_readonly` configuration when using `readonly=1`. Treat this as a
+  prerequisite to resolve with the DB owner; never change server settings automatically.
+- Apply current driver/version prerequisites from the source documentation if a
+  compatibility question arises. Do not turn an old supported-version list into
+  a blanket claim that every later DB version fails.
+
+## Run and assess the export
+
+Use the shared write/readback/history procedure after the extraction contract is
+established. `append_new` is a service transfer strategy, not evidence that SQL rows
+are deduplicated or that a changing database is captured consistently. A recurring
+full extract is not automatically incremental extraction.
+
+Report the rule/run ID, destination, observed status and reported rows/bytes.
+Distinguish those counters from source-to-destination reconciliation. For failure,
+use matching event evidence; do not infer a missing table or unchanged destination
+from a generic error or zero counters.
+
+## Sources
+
+- [Supported DB sources and ClickHouse prerequisites](https://cloud.ru/docs/aicloud/mlspace/concepts/data-catalog__data-processing__data-migration)
+- [Connector configuration](https://cloud.ru/docs/aicloud/mlspace/concepts/guides/guides__dc/data-catalog__data-processing__data-migration__create-connector)
+- [Advanced SQL Server connectivity](https://cloud.ru/docs/aicloud/mlspace/concepts/guides/guides__advanced/guides__sql_adv__connect)
+- [Older client_lib SQL parameter reference](https://cloud.ru/docs/aicloud/mlspace/concepts/client-lib__copy-to-nfs)

mlspace_plugin-0.3.5/plugin/skills/mlspace-export-nfs-to-s3/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: mlspace-export-nfs-to-s3
+description: "Export datasets, model checkpoints or job results from NFS to S3 on Cloud.ru MLSpace, including Evolution, Advanced and compatible external buckets. Uses mlspace_data_transfer; preserves source files and verifies the destination connector and prefix."
+license: MIT
+---
+
+# Export NFS files to an S3 bucket
+
+Read [the shared transfer procedure](../mlspace-transfer-data/SKILL.md). This skill
+handles NFS → S3; for the reverse direction use `mlspace-stage-s3-to-nfs`.
+
+## Establish the export destination
+
+1. Resolve the NFS workspace, region/storage variant and connector-relative path.
+   A job's region identifies relevant storage, but does not prove its output files
+   exist. Obtain a verified output path instead of assuming the script directory
+   contains the checkpoint. The MCP is not a general NFS file browser.
+2. With `mlspace_data_transfer` actions `list_connectors` and `get_connector`,
+   identify the destination by endpoint, bucket and connector ID, not name alone.
+   Confirm the object prefix and intended overwrite/append/sync behavior. A local
+   directory path and an S3 object prefix are different namespaces.
+3. Select a destination type accepted by the endpoint's `ConnectorTypesTarget`.
+   An Amazon/Google source connector type is not automatically accepted as a target;
+   use a verified destination-compatible connector (often `s3custom`). Reuse an
+   existing system Evolution connector where available. For a new custom connector,
+   use the current create_connector schema and an authorized credential workflow;
+   do not ask for keys in chat or derive S3 credentials from unrelated Registry secrets.
+4. For Advanced, check the migration guide's SSE-KMS prerequisite if relevant.
+   Never disable encryption on an existing bucket automatically. Ask for a destination
+   compatible with the documented transfer path or resolve the prerequisite first.
+5. Confirm `cluster_name` for the selected NFS storage using the endpoint schema and
+   verified context. Do not hardcode a tutorial's cluster or infer it from the bucket
+   endpoint. Apply the shared transfer file-count limits.
+
+## Run and verify
+
+Create/update the requested rule using the actual connector types and
+`query.source`/`query.destination` paths. For a recurring export, retain the shared
+schedule checks; recurrence does not imply full synchronization or deduplication.
+
+Read back the rule and inspect its matching history/status. Report API-reported
+bytes/objects separately from an independent destination-content check. Do not claim
+that a backup is restorable, checksums match, or the model artifact is valid solely
+because the transfer status is successful. Keep the NFS originals unless deletion
+was separately requested and verified as safe.
+
+## Sources
+
+- [Transfers between S3 and NFS](https://cloud.ru/docs/aicloud/mlspace/concepts/guides/guides__dc/data-catalog__data-processing__move-data-s3-nfs)
+- [Destination connector types](https://cloud.ru/docs/aicloud/mlspace-cli/topics/references__transfer-create)
+- [Advanced destination prerequisites](https://cloud.ru/docs/aicloud/mlspace/concepts/tutorials/data-use/data-use-migration-from-s3-to-adv)

mlspace_plugin-0.3.5/plugin/skills/mlspace-migrate-s3-to-s3/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: mlspace-migrate-s3-to-s3
+description: "Copy or sync between S3 buckets through Cloud.ru MLSpace Data Transfer, including external S3 to Evolution/Advanced and cross-project buckets. Uses mlspace_data_transfer; checks endpoint/bucket identity and destination-specific prerequisites."
+license: MIT
+---
+
+# Migrate data between S3 buckets
+
+Read [the shared transfer procedure](../mlspace-transfer-data/SKILL.md). Use this
+for object-storage → object-storage, without silently introducing NFS as a staging hop.
+
+## Resolve two independent S3 ends
+
+1. Establish source and destination endpoint, bucket, prefix and owning project/account.
+   Equal bucket names on different endpoints do not identify the same storage.
+   Resolve identical or overlapping prefixes on the same bucket before synchronizing.
+2. Use `mlspace_data_transfer` actions `list_connectors` and `get_connector` to reuse
+   matching connectors. Confirm IDs and actual types separately. Cross-project
+   migration can require a custom connector for the other project's bucket;
+   availability of one project's system connector does not establish access to another.
+3. Check source and destination enums separately. The current target schema includes
+   `s3custom` and `s3evolution`, but not every S3 source type. Select a verified target
+   connector; do not relabel an existing connector to force a match.
+4. Evolution's documented migration path can use a Custom S3 destination. Obtain
+   its precise endpoint and S3-compatible authentication through the approved secret
+   workflow; do not guess credential formatting from an IAM Key ID alone. Advanced
+   uses its bucket endpoint and OBS AK/SK. Reuse existing connectors without reading
+   or displaying their secret values.
+5. The Advanced migration guide requires a destination compatible with its SSE-KMS
+   restriction. Do not automatically disable bucket encryption. Resolve this with
+   the user or choose an agreed compatible destination. Recommended chunking in
+   that tutorial is preparation guidance, not a universal API object-size limit.
+
+## Configure a copy, not an implicit cutover
+
+- Use the actual endpoint's transfer schema. Older tutorials include `legacy` and
+  a fixed cluster: do not copy those into `TransferInputViewModelV5` blindly. Even an
+  S3 → S3 rule needs a verified execution `cluster_name`; no NFS end is implied.
+- Preserve exact object-prefix semantics. Multiple source prefixes, where supported,
+  go into the API's `query.source` list; the CLI's comma syntax is not proof that the
+  API wants a comma-joined string.
+- Confirm copy/append/sync intent and apply shared file-count checks. Neither a
+  scheduled copy nor `append_new` proves bidirectional replication or CDC.
+- Create/update once, then read back and track the matching run. On an uncertain
+  write result, locate the existing rule/run before retrying. Report any unverified
+  destination-content checks explicitly.
+- Do not delete the source bucket, rotate keys, switch application endpoints or
+  perform a cutover as an implicit part of migration. Those are separate operations.
+
+## Sources
+
+- [External S3 to Evolution](https://cloud.ru/docs/aicloud/mlspace/concepts/tutorials/data-use/data-use-migration-from-s3-to-evo)
+- [External S3 to Advanced](https://cloud.ru/docs/aicloud/mlspace/concepts/tutorials/data-use/data-use-migration-from-s3-to-adv)
+- [Cross-project S3 transfers](https://cloud.ru/docs/aicloud/mlspace/concepts/faq__data-catalog)

{mlspace_plugin-0.3.3 → mlspace_plugin-0.3.5}/plugin/skills/mlspace-stage-s3-to-nfs/SKILL.md

@@ -9,6 +9,13 @@ compatibility: Requires the `mlspace` MCP server from this plugin (Cloud.ru MLSp
 
 Copy/sync S3 -> NFS for a GPU job, optionally on a schedule. Write action.
 
+Read [the shared transfer checks](../mlspace-transfer-data/SKILL.md) for file-count
+limits, connector permissions and destination prerequisites, then follow this
+S3-specific procedure. Do not reload this file when following the shared router.
+
+For NFS -> NFS, cross-cluster/cross-workspace transfers, other connector routes,
+or checking NFS file-count limits, use `mlspace-transfer-data` from this plugin.
+
 This skill drives the `mlspace` MCP server shipped in the same plugin. If its
 tools are not connected, say so instead of guessing — none of these steps can be
 carried out any other way.
@@ -29,8 +36,11 @@ carried out any other way.
 Goal: copy/sync S3 -> NFS, optionally on a nightly schedule (write actions;
 refused under MLSPACE_READONLY=true).
 1. data_transfer list_connectors with page=1, page_size=20; continue as needed to
-   locate the requested connectors. SOURCE: an object-storage connector (s3amazon/
-   s3custom/s3google). DEST: an NFS/cluster connector. Capture both connector ids.
+   locate the requested connectors. SOURCE: a verified object-storage connector
+   (e.g. s3amazon/s3custom/s3google/s3evolution, as supported by the endpoint).
+   DEST: an NFS/cluster connector with its actual nfs/nfsprivate/nfsshared type.
+   Capture both connector ids. Do not create a custom s3evolution or NFS connector;
+   reuse system connectors or use an authorized custom S3 connector where appropriate.
    Reuse existing system connectors rather than attempting to create them. A system
    NFS connector may be absent from list output. For the selected destination
    workspace, its workspace ID can be tested as a candidate via get_connector
@@ -44,7 +54,10 @@ refused under MLSPACE_READONLY=true).
    direct route is not established; do not launch a multi-hop transfer without an
    agreed intermediate destination and confirmation of both supported legs.
    If names or destination remain ambiguous, ask the user.
-3. (optional, S3 only) try_connector to pre-check connectivity (+ its /try/logs).
+3. Read existing connector details/logs first. Only for a supported custom S3
+   connector, and when activation is authorized, use try_connector to check
+   connectivity and activate it. Never use it for a system s3evolution connector
+   or merely to read logs; get_connector_logs reads the existing logs.
 4. Ensure source_path + destination_path are known (ask if absent). Choose the
    strategy from the user's overwrite/append/sync intent; recurrence alone does
    not determine it. For a schedule, confirm the time and timezone and build
@@ -57,10 +70,14 @@ refused under MLSPACE_READONLY=true).
    For a one-off run omit crontab; creation starts the transfer immediately.
 5. list_transfers; if one matches this source->dest and the user means "edit", capture
    its id for update instead of create.
-6. create_transfer (body=TransferInputViewModelV5: name, connector ids, paths,
-   cluster_name, strategy, optional crontab) OR update_transfer(id_, full body).
+6. create_transfer (body=TransferInputViewModelV5: name, cluster_name, connector_id,
+   destination_connector_id, connector_type, destination_connector_type, strategy,
+   favorite, query={source, destination}, optional crontab/description)
+   OR update_transfer(id_, full body).
    To just enable/disable: switch_transfer(id_, body={"active": true|false}).
-7. Verify: list_history(transfer_id) -> latest run id + status; get_history_status.
+7. Verify: get_transfer(transfer_id) to read back the rule; list_history(transfer_id,
+   page=1, page_size=20) to identify the matching run by IDs and times rather than
+   list order; get_history_status(ids=[history_id]) to check that run's status.
 Output: source and destination, the created/updated transfer id, schedule with
 timezone, and verified run status. A future scheduled run has not succeeded yet.
 Before writing, summarize the destination, strategy and schedule for the user;

mlspace_plugin-0.3.5/plugin/skills/mlspace-transfer-data/SKILL.md

@@ -0,0 +1,124 @@
+---
+name: mlspace-transfer-data
+description: "Plan Cloud.ru MLSpace data movement when the route is not yet chosen, or apply the shared create/update/schedule/verification procedure for mlspace_data_transfer. Route-specific skills cover NFS to NFS, NFS to S3, S3 to NFS, S3 to S3 and database exports."
+license: MIT
+compatibility: Requires the `mlspace` MCP server from this plugin (Cloud.ru MLSpace credentials needed).
+---
+
+# Transfer data between supported sources and destinations
+
+Use `mlspace_data_transfer` to prepare and, when requested, create/update a transfer.
+An explanation or route feasibility question needs reads only. Creation without a
+schedule starts a transfer immediately; it is not a dry run. Respect read-only mode.
+
+For a known route, read only the matching procedure:
+
+| Requested movement | Procedure |
+| --- | --- |
+| NFS → NFS, including other regions/workspaces | [NFS transfer](../mlspace-transfer-nfs-to-nfs/SKILL.md) |
+| NFS → S3: results, checkpoints, datasets | [S3 export](../mlspace-export-nfs-to-s3/SKILL.md) |
+| S3 → NFS: staging data for jobs | [NFS staging](../mlspace-stage-s3-to-nfs/SKILL.md) |
+| S3 → S3, including Evolution/Advanced | [Bucket migration](../mlspace-migrate-s3-to-s3/SKILL.md) |
+| Database → supported storage | [Database export](../mlspace-export-database-data/SKILL.md) |
+
+If arriving from that procedure, continue below without reloading it. Do not read
+all sibling skills for one request.
+
+## Resolve both ends
+
+1. Identify the workspace where the rule will live (`target`), source and destination
+   connectors, both paths, and the user's copy/append/sync intent. For each NFS end,
+   identify its workspace and exact region/storage variant separately. The same path
+   in two regions need not refer to the same files. Do not silently use the current
+   workspace for a destination in another workspace.
+2. Find connectors with `list_connectors(page=1, page_size=20)`, paging as needed,
+   and confirm selected IDs/types with `get_connector(connector_type, id_)` in the
+   relevant connected workspace. Keep `target` explicit for multi-workspace work.
+   A system NFS connector can be absent from the list: the intended workspace ID
+   can be checked as a candidate with `get_connector(connector_type="nfs", id_=...)`.
+   Use it only after confirming its identity. Do not treat every workspace ID as
+   a connector ID or probe unrelated workspaces.
+3. Reuse system connectors (`nfs`, `nfsprivate`, `nfsshared`, etc.). `list_sources`
+   describes types/parameters; it does not authorize creating every listed type.
+   Only create a custom connector when requested, using the create_connector schema.
+   Do not request connector passwords in chat or expose them in the answer.
+
+## Establish the route before writing
+
+- Read the configured endpoint's current transfer schema: `TransferInputViewModelV5`,
+  `TransferClusterEnum`, `TransferMultiClusterEnum`, `ConnectorTypes` and
+  `ConnectorTypesTarget`. These are in `/public/v2/openapi.json`; use schemas already
+  exposed by the connected tools or retrieve that public document if available.
+  If unavailable, use verified task context or ask for the missing route details.
+  A bundled schema is a snapshot, not evidence of current access or reachability.
+- A source type is not automatically allowed as a destination. Check both enums.
+- For cross-cluster NFS → NFS, use an exact directed value from
+  `TransferMultiClusterEnum` for `cluster_name`. Do not concatenate region labels,
+  infer the reverse route, or assume all pairs are supported. Two NFS variants
+  within one region may also require an explicit route. A shared connector ID
+  does not make two storage locations identical; check the route and paths.
+- Enum membership establishes an accepted value, not permission or a working
+  data path. Verify both connectors and available access information. If a route
+  cannot be established, explain what is missing before creating anything.
+  Do not substitute another region or start a two-hop copy via S3 without an agreed
+  intermediate destination and verification of both legs.
+- `try_connector` is for supported custom connectors and changes state. Do not
+  apply it to system NFS connectors or use it as a read-only route check.
+
+## Relevant NFS limits
+
+The official documentation linked below was checked on 2026-10-13. Recheck it
+when the requested scale, storage type or deployment makes these limits relevant.
+
+- The documented per-transfer threshold is 400,000 files. For append-new and full
+  synchronization, count source and destination files together. The prose and
+  example disagree at exactly 400,000: do not promise that boundary succeeds;
+  confirm it with the service team or propose smaller batches with the user.
+- NFS also has namespace file quotas. Byte capacity alone does not establish room
+  for the copy. The MCP does not provide a general NFS directory walk: do not invent
+  file counts or available capacity. Use available evidence, or explain which size
+  check remains unverified when it affects the requested transfer.
+- For a Personal Directory destination, documentation requires updating workspaces
+  created before 2024-11-01. Check whether it is already updated; do not update a
+  workspace automatically as part of copying data.
+
+These are task-specific checks, not a general warning block for every answer.
+
+## Create, update and verify
+
+1. For an existing rule, use `get_transfer(transfer_id)` or locate it with
+   `list_transfers`. A shortened list does not establish that no matching rule
+   exists. Do not create a duplicate to work around an unknown ID.
+2. Build the write schema explicitly; do not POST the GET response unchanged:
+   `name`, `cluster_name`, `connector_id`, `destination_connector_id`,
+   `connector_type`, `destination_connector_type`, `strategy`, `favorite`,
+   `query={source, destination}`, and optional `description`/`crontab`.
+   Use the actual connector type returned for each end, not a guessed generic NFS type.
+3. Choose `write_all`, `append_new` or `sync_all` from the requested behavior and
+   verified service semantics. A recurring schedule alone does not determine the
+   strategy. For scheduling use a `CronViewModel` object, not a cron string; establish
+   period units and timezone semantics before converting a human recurrence.
+4. Summarize source → destination, region/storage variants, strategy and schedule.
+   Obtain missing intent before writing, particularly destructive sync behavior.
+   Use `create_transfer(body=...)` or `update_transfer(id_, body=...)` as requested.
+   If a write times out, check whether the rule/run already exists before retrying.
+5. Read back with `get_transfer`, comparing both ends, route, strategy and schedule.
+   Use `list_history(transfer_id, page=1, page_size=20)` and
+   `get_history_status(ids=[history_id])` for the matching run. A saved rule or future
+   scheduled run is not a completed copy. Do not assume list ordering proves which
+   run belongs to this request; compare IDs and times.
+6. On failure, use `get_event_logs(history_id, offset=0, limit=50,
+   as_enum_resolved=true)` or the `mlspace-diagnose-data-transfer` skill. Zero counters
+   or AccessDenied do not prove that the destination was unchanged. Do not rerun
+   merely to diagnose a failure.
+
+Answer in the user's language: what was configured, where data goes, rule/run ID,
+and observed status. Keep tool-specific cautions internal unless they block this
+task or the user asks for diagnosis. For the narrower S3 → NFS staging workflow,
+the `mlspace-stage-s3-to-nfs` skill is also available.
+
+## Official references
+
+- [Cross-region and cross-workspace NFS transfers](https://cloud.ru/docs/aicloud/mlspace/concepts/faq__data-catalog)
+- [Creating a rule and Personal Directory prerequisites](https://cloud.ru/docs/aicloud/mlspace/concepts/guides/guides__dc/data-catalog__data-processing__create-transfer-rule)
+- [File-count limits](https://cloud.ru/docs/aicloud/mlspace/concepts/overview__limitations)

mlspace_plugin-0.3.5/plugin/skills/mlspace-transfer-nfs-to-nfs/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: mlspace-transfer-nfs-to-nfs
+description: "Copy or sync NFS data on Cloud.ru MLSpace between regions, storage variants or workspaces, including Personal Directory and shared NFS. Uses mlspace_data_transfer; verifies both locations and the directed route before writing."
+license: MIT
+---
+
+# Copy NFS data between storage locations
+
+Use this for NFS → NFS, including regional migration and copying a dataset to
+another workspace. Read [the shared transfer procedure](../mlspace-transfer-data/SKILL.md)
+for discovery, write authorization, limits, scheduling and verification, then apply
+the checks below. Tools must be connected before carrying out the operation.
+
+## Resolve the two locations
+
+- Ask only for missing source/destination workspace, region/storage variant and path.
+  Confirm which workspace owns the transfer rule (`target`). Never change `target`
+  implicitly halfway through a multi-workspace operation.
+- Inspect both connectors with `mlspace_data_transfer` actions `list_connectors`
+  and `get_connector`. Use their actual `nfs`, `nfsprivate` or `nfsshared` type.
+  System connectors are reused, not created as custom connectors.
+- A notebook's `/home/jovyan/...` mount is not automatically the transfer-service
+  path. Establish the connector-relative path from the selected storage's metadata,
+  a verified existing rule or the user's copied NFS object path; do not strip or
+  prepend path segments by guesswork.
+- The same workspace/connector ID can address different regional NFS locations.
+  Compare workspace, storage variant, route and path together. Conversely, copying
+  onto the exact same storage/path is not a migration; resolve that ambiguity before
+  creating a rule. Check overlapping source/destination folders when synchronizing.
+
+## Match the exact direction
+
+For cross-cluster or cross-storage transfer, select the directed value published
+in the configured endpoint's `TransferMultiClusterEnum`. Never turn UI labels into
+a route by joining them with `->`. Do not infer a supported reverse route from
+the forward one. For a same-storage copy, use the applicable single-cluster value.
+Schema acceptance is not a reachability or permissions test.
+
+If the requested direct route is absent or uncertain, keep the task pending at
+route selection. A two-leg copy via S3 requires an agreed intermediate location
+and verification of both legs; it is not an automatic fallback.
+
+Before writing, apply the shared file-count and namespace quota checks. For an
+individual notebook's Personal Directory, establish whether the documented
+pre-2024-11-01 workspace update prerequisite is satisfied. Do not update the
+workspace, change quota or create a notebook to make the copy work automatically.
+
+## Complete the requested copy
+
+Use `create_transfer` or `update_transfer` with the confirmed connector IDs,
+types, direction, paths and strategy. Follow the shared readback/history checks.
+Report both storage locations and the matching run status. A successful copy does
+not authorize deleting the original data, and a scheduled rule is not completed
+data movement.
+
+## Sources
+
+- [NFS transfers across regions and workspaces](https://cloud.ru/docs/aicloud/mlspace/concepts/faq__data-catalog)
+- [Rule creation and Personal Directory prerequisites](https://cloud.ru/docs/aicloud/mlspace/concepts/guides/guides__dc/data-catalog__data-processing__create-transfer-rule)
+- [Transfer limits](https://cloud.ru/docs/aicloud/mlspace/concepts/overview__limitations)

{mlspace_plugin-0.3.3 → mlspace_plugin-0.3.5}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "mlspace-plugin"
-version = "0.3.3"
+version = "0.3.5"
 description = "Cloud.ru MLSpace plugin: MCP server, agent skills and setup"
 keywords = ["mlspace", "mcp", "agent-skills", "cloudru"]
 classifiers = [