docs(xdto-guide,xdto-decompile): вернуть рецепт версионной копии исполнителю

Предыдущая правка гайда изложила копирование пакета пошагово в повелительном
наклонении, и стало неясно, кому эти шаги адресованы: гайд построен на том, что
задачу ставят словами, а шаги делает агент. Пользователь мог прочитать это как
работу, которую надо сделать самому.

В гайде теперь сказано, что происходит и чего достаточно назвать в задаче.
Сами шаги и острая кромка (менять targetNamespace вместе с объявлением xmlns,
не заменять все вхождения строки) — в SKILL.md навыка выгрузки, там же, где
описан путь «выгрузить → поправить → собрать».

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

.claude/skills/xdto-decompile/SKILL.md

@@ -36,6 +36,13 @@ powershell.exe -NoProfile -File "${CLAUDE_SKILL_DIR}/scripts/xdto-decompile.ps1"
 включая имя, синоним и комментарий объекта метаданных — они выгружаются
 в `xs:annotation/xs:appinfo`.
 
+Этот же путь даёт версионную копию пакета: смени в схеме `targetNamespace` и собери
+её с `-Name` нового пакета — имя и синоним задаются флагами `/xdto-compile`, внутри
+схемы их править не нужно. Меняя пространство имён, поправь **и объявление `xmlns`
+с тем же URI**: внутренние ссылки пользуются им как префиксом. Заменять все вхождения
+строки нельзя — пострадает импорт пространства имён, для которого старый URI является
+префиксом (`urn:пример:обмен` и `urn:пример:обмен:legacy`).
+
 Этот путь нужен, когда схему меняют широко или сначала надо разобраться, как она
 устроена. Чтобы поправить одно свойство, схему целиком читать не нужно — `/xdto-edit`.
 Если нужна не схема, а сводка «что присвоить и что обязательно», — `/xdto-info`.

docs/xdto-guide.md

@@ -113,20 +113,13 @@
 
 Типовой приём: рядом со старым пакетом появляется новый с другим пространством
 имён (`EnterpriseData_1_19` → `_1_20`), а старые потребители продолжают смотреть
-на прежний namespace. Копия делается через выгрузку схемы и сборку под новым именем:
+на прежний namespace.
 
-1. `/xdto-decompile` исходного пакета в файл схемы;
+Отдельной команды для этого нет: агент выгружает схему исходного пакета, меняет в ней
-2. в схеме поменять `targetNamespace` — **и связанное с ним объявление `xmlns`**,
+пространство имён и собирает под новым именем. Дополнительных действий это не требует —
-   которым внутренние ссылки пользуются как префиксом;
+достаточно назвать в задаче исходный пакет, новое имя и новый namespace. Внутренние
-3. `/xdto-compile` этой схемы с `-Name` нового пакета (имя и синоним задаются
+ссылки переводятся на него целиком, импорты чужих пакетов сохраняются, исходный пакет
-   флагами, править их внутри схемы не нужно).
+остаётся как был.
-
-Внутренние ссылки при этом переводятся на новый namespace целиком, импорты чужих
-пакетов сохраняются, исходный пакет не меняется.
-
-Менять `targetNamespace` **заменой всех вхождений строки** — плохая идея: если пакет
-импортирует пространство имён, у которого старый URI является префиксом
-(`urn:example:exchange` и `urn:example:exchange:legacy`), заменится и оно.
 
 Если же надо сменить namespace **у существующего** пакета, а не сделать копию, агент
 перепишет все внутренние ссылки и перечислит пакеты, которые импортируют старый — но