1c/crm3_26.rhana
4
0
Fork 0
Code Issues 7 Pull Requests Actions Packages Projects Releases 1 Wiki Activity

Выгрузка в файлы на dt-021: кривой configVersion в ConfigDumpInfo.xml #16

New Issue
Closed
opened 2026-08-18 12:40:14 +00:00 by kma · 8 comments
kma commented 2026-08-18 12:40:14 +00:00
Owner
Copy Link
Copy Source

✅ Решено (2026-08-18). Выгрузка расширения в D:\projects\crm3-26\crm3-26.rhana\src проходит.

Канон для всего монорепозитория вынесен в общий проект: rhana/crm3-migration#19 и docs/1c_standarts/Выгрузка_в_файлы_ConfigDumpInfo.md. Эта задача — запись инцидента на dt-021.

Причина

Не длина пути. Инкрементальная выгрузка читает src/ConfigDumpInfo.xml. Атрибут configVersion — SHA-1, ровно 40 hex-символов [0-9a-f].

Обработка РК_ПроверкаСерий была добавлена XML-правками. В git для неё стояли невалидные configVersion (шаблон 40 символов; форма — 42; Form.Form — 41). UUID объектов конфигуратор принял. Падение давал configVersion неверной длины.

Предупреждение «Длина пути к каталогу выгрузки превышает 30 символов» — эвристика MAX_PATH, не причина крэша.

Решение

  1. src восстановлен из git HEAD.
  2. В ConfigDumpInfo.xml три configVersion заменены на валидные 40-hex заглушки SHA-1.
  3. Выгрузка поверх git-src на dt-021 успешна.

Обход «пустая папка + robocopy» больше не нужен. Не выгружать в корень диска (S:\).

✅ Решено (2026-08-18). Выгрузка расширения в `D:\projects\crm3-26\crm3-26.rhana\src` проходит. **Канон для всего монорепозитория** вынесен в общий проект: [rhana/crm3-migration#19](https://git.p7net.ru/rhana/crm3-migration/issues/19) и `docs/1c_standarts/Выгрузка_в_файлы_ConfigDumpInfo.md`. Эта задача — запись инцидента на dt-021. ## Причина Не длина пути. Инкрементальная выгрузка читает `src/ConfigDumpInfo.xml`. Атрибут `configVersion` — SHA-1, **ровно 40** hex-символов `[0-9a-f]`. Обработка `РК_ПроверкаСерий` была добавлена XML-правками. В git для неё стояли невалидные `configVersion` (шаблон 40 символов; форма — 42; Form.Form — 41). UUID объектов конфигуратор принял. Падение давал `configVersion` неверной длины. Предупреждение «Длина пути к каталогу выгрузки превышает 30 символов» — эвристика MAX_PATH, не причина крэша. ## Решение 1. `src` восстановлен из git HEAD. 2. В `ConfigDumpInfo.xml` три `configVersion` заменены на валидные 40-hex заглушки SHA-1. 3. Выгрузка поверх git-`src` на dt-021 успешна. Обход «пустая папка + robocopy» больше не нужен. Не выгружать в корень диска (`S:\`).
cursor_ai commented 2026-08-18 12:42:48 +00:00
Member
Copy Link
Copy Source

Что выяснилось на dt-021 (kma)

  1. Выгрузка в .cfe и полная загрузка из .cfe починила внутреннее состояние расширения — после этого выгрузка в файлы снова возможна.
  2. Выгрузка в D:\projects\crm3-26\crm3-26.rhana\src (37 символов) даёт штатное предупреждение 1С «Длина пути к каталогу выгрузки превышает 30 символов» и затем конфигуратор закрывается без ошибки.
  3. Выгрузка в D:\test_src (11 символов) — без предупреждения, успешно.

Это ограничение конфигуратора (эвристика под Windows MAX_PATH ~260): к префиксу каталога добавляются длинные вложенные пути вроде DataProcessors\РК_ЗагрузкаОстатков\Forms\ПодборСкладов\Ext\Form\Module.bsl. Включение «длинных путей» в Windows (LongPathsEnabled) конфигуратору обычно не помогает — у него своя проверка на 30 символов.

Рекомендуемый рабочий цикл на dt-021

Не выгружать напрямую в git-каталог. Подключить короткий путь и выгружать туда.

Вариант A (предпочтительный) — subst на src

В PowerShell от имени пользователя (не обязательно админ):

subst S: D:\projects\crm3-26\crm3-26.rhana\src

В конфигураторе: Конфигурация → Выгрузить конфигурацию в файлы в S:\ (3 символа). Файлы сразу попадают в git-дерево.

Снять диск: subst S: /d

Чтобы буква переживала перезагрузку — задача в планировщике при входе или строка в профиле PowerShell.

Вариант B — junction

cmd /c mklink /J D:\r D:\projects\crm3-26\crm3-26.rhana

Выгрузка в D:\r\src (8 символов).

Вариант C — короткий каталог + копирование

Выгрузка в D:\src, затем:

robocopy D:\src D:\projects\crm3-26\crm3-26.rhana\src /E /XO

/MIR не использовать без необходимости — снесёт лишние файлы в src.

После любой выгрузки из корня монорепозитория:

scripts/normalize_1c_export.sh crm3-26.rhana

Что не делать

  • Не игнорировать предупреждение про 30 символов на этой платформе — на dt-021 оно заканчивается падением конфигуратора.
  • Не рассчитывать, что повтор .cfe сам по себе разрешит выгрузку в длинный путь: он чинит метаданные, но не длину пути.

Задачу оставляю открытой, пока на dt-021 не закреплён короткий путь (subst / junction).

## Что выяснилось на dt-021 (kma) 1. Выгрузка в `.cfe` и полная загрузка из `.cfe` **починила** внутреннее состояние расширения — после этого выгрузка в файлы снова возможна. 2. Выгрузка в `D:\projects\crm3-26\crm3-26.rhana\src` (**37 символов**) даёт штатное предупреждение 1С «Длина пути к каталогу выгрузки превышает 30 символов» и затем **конфигуратор закрывается без ошибки**. 3. Выгрузка в `D:\test_src` (**11 символов**) — без предупреждения, успешно. Это ограничение конфигуратора (эвристика под Windows `MAX_PATH` ~260): к префиксу каталога добавляются длинные вложенные пути вроде `DataProcessors\РК_ЗагрузкаОстатков\Forms\ПодборСкладов\Ext\Form\Module.bsl`. Включение «длинных путей» в Windows (`LongPathsEnabled`) конфигуратору обычно **не помогает** — у него своя проверка на 30 символов. ## Рекомендуемый рабочий цикл на dt-021 **Не выгружать напрямую в git-каталог.** Подключить короткий путь и выгружать туда. ### Вариант A (предпочтительный) — `subst` на `src` В PowerShell от имени пользователя (не обязательно админ): ```powershell subst S: D:\projects\crm3-26\crm3-26.rhana\src ``` В конфигураторе: **Конфигурация → Выгрузить конфигурацию в файлы** в **`S:\`** (3 символа). Файлы сразу попадают в git-дерево. Снять диск: `subst S: /d` Чтобы буква переживала перезагрузку — задача в планировщике при входе или строка в профиле PowerShell. ### Вариант B — junction ```powershell cmd /c mklink /J D:\r D:\projects\crm3-26\crm3-26.rhana ``` Выгрузка в `D:\r\src` (8 символов). ### Вариант C — короткий каталог + копирование Выгрузка в `D:\src`, затем: ```powershell robocopy D:\src D:\projects\crm3-26\crm3-26.rhana\src /E /XO ``` `/MIR` не использовать без необходимости — снесёт лишние файлы в `src`. После любой выгрузки из корня монорепозитория: ```text scripts/normalize_1c_export.sh crm3-26.rhana ``` ## Что не делать - Не игнорировать предупреждение про 30 символов на этой платформе — на dt-021 оно заканчивается падением конфигуратора. - Не рассчитывать, что повтор `.cfe` сам по себе разрешит выгрузку в длинный путь: он чинит метаданные, но не длину пути. Задачу оставляю открытой, пока на dt-021 не закреплён короткий путь (`subst` / junction).
kma commented 2026-08-18 12:59:02 +00:00
Author
Owner
Copy Link
Copy Source

Выполнил

subst S: D:\projects\crm3-26\crm3-26.rhana\src

Попытался выгрузить в файлы в путь s:\ и конфигуратор все равно падает. Ошибки про превышение длины пути 30 символов уже не было.

А вот выгрузить при этом в s:\test\ удалось.

Выполнил ``` subst S: D:\projects\crm3-26\crm3-26.rhana\src ``` Попытался выгрузить в файлы в путь `s:\` и конфигуратор все равно падает. Ошибки про превышение длины пути 30 символов уже не было. А вот выгрузить при этом в `s:\test\` удалось.
cursor_ai commented 2026-08-18 13:03:55 +00:00
Member
Copy Link
Copy Source

Ответ на комментарий kma (выгрузка в S:\ падает, в S:\test\ — нет)

Два независимых ограничения конфигуратора. Предупреждение про 30 символов здесь уже ни при чём (его не было — путь короткий).

1. Нельзя выгружать в корень диска

S:\ — корень тома. Конфигуратор это переживает плохо: часто закрывается без сообщения. Нужен подкаталог: S:\src, S:\test, не S:\.

Поэтому вариант A из прошлого комментария (subst сразу на src и выгрузка в S:\) — ошибочный. Исправляем: subst на родителя, выгрузка в S:\src.

2. Выгрузка поверх текущего src тоже опасна

S:\ сейчас указывает на уже заполненный crm3-26.rhana\src. В ConfigDumpInfo.xml у РК_ПроверкаСерий стоят синтетические configVersion неверной длины (41–42 символа вместо SHA-1 в 40). При инкрементальной выгрузке конфигуратор читает этот файл и может упасть.

S:\test\ — пустой каталог, ConfigDumpInfo пишется заново — поэтому выгрузка прошла. В src\test\ConfigDumpInfo.xml уже нормальный хеш (e9d4c6d2…, 40 символов).

Что сделать сейчас

subst S: /d
subst S: D:\projects\crm3-26\crm3-26.rhana

В конфигураторе выгружать в S:\src (6 символов, не корень).

Если S:\src всё ещё падает — не трогать конфигуратор, перенести уже готовую выгрузку из src\test в src (это та же успешная выгрузка в S:\test\), затем удалить src\test, чтобы не попало в git.

robocopy D:\projects\crm3-26\crm3-26.rhana\src\test D:\projects\crm3-26\crm3-26.rhana\src /E
Remove-Item -Recurse -Force D:\projects\crm3-26\crm3-26.rhana\src\test

После первой удачной выгрузки в сам src ConfigDumpInfo станет штатным, повторные выгрузки в S:\src должны проходить.

Не коммитить каталог src\test\ — это вложенная копия выгрузки внутри src.

Дальше из корня монорепозитория: scripts/normalize_1c_export.sh crm3-26.rhana

## Ответ на комментарий kma (выгрузка в `S:\` падает, в `S:\test\` — нет) Два независимых ограничения конфигуратора. Предупреждение про 30 символов здесь уже ни при чём (его не было — путь короткий). ### 1. Нельзя выгружать в **корень диска** `S:\` — корень тома. Конфигуратор это переживает плохо: часто закрывается без сообщения. Нужен **подкаталог**: `S:\src`, `S:\test`, не `S:\`. Поэтому вариант A из прошлого комментария (`subst` сразу на `src` и выгрузка в `S:\`) — ошибочный. Исправляем: `subst` на **родителя**, выгрузка в `S:\src`. ### 2. Выгрузка **поверх** текущего `src` тоже опасна `S:\` сейчас указывает на уже заполненный `crm3-26.rhana\src`. В `ConfigDumpInfo.xml` у `РК_ПроверкаСерий` стоят синтетические `configVersion` неверной длины (41–42 символа вместо SHA-1 в 40). При инкрементальной выгрузке конфигуратор читает этот файл и может упасть. `S:\test\` — пустой каталог, `ConfigDumpInfo` пишется заново — поэтому выгрузка прошла. В `src\test\ConfigDumpInfo.xml` уже нормальный хеш (`e9d4c6d2…`, 40 символов). ### Что сделать сейчас ```powershell subst S: /d subst S: D:\projects\crm3-26\crm3-26.rhana ``` В конфигураторе выгружать в **`S:\src`** (6 символов, не корень). Если `S:\src` всё ещё падает — не трогать конфигуратор, перенести уже готовую выгрузку из `src\test` в `src` (это та же успешная выгрузка в `S:\test\`), затем удалить `src\test`, чтобы не попало в git. ```powershell robocopy D:\projects\crm3-26\crm3-26.rhana\src\test D:\projects\crm3-26\crm3-26.rhana\src /E Remove-Item -Recurse -Force D:\projects\crm3-26\crm3-26.rhana\src\test ``` После первой удачной выгрузки в сам `src` `ConfigDumpInfo` станет штатным, повторные выгрузки в `S:\src` должны проходить. **Не коммитить** каталог `src\test\` — это вложенная копия выгрузки внутри `src`. Дальше из корня монорепозитория: `scripts/normalize_1c_export.sh crm3-26.rhana`
kma commented 2026-08-18 13:14:05 +00:00
Author
Owner
Copy Link
Copy Source

Нет. После subst S: D:\projects\crm3-26\crm3-26.rhana выгрузка в S:\src тоже выбила конфигуратор.

Полагаю, что s:\test в прошлый раз при subst S: D:\projects\crm3-26\crm3-26.rhana\src папка test отсутствовала (была пустой). То есть при выгрузке в файлы конфигуратор не читал файлы.

Нет. После `subst S: D:\projects\crm3-26\crm3-26.rhana` выгрузка в `S:\src` тоже выбила конфигуратор. Полагаю, что `s:\test` в прошлый раз при `subst S: D:\projects\crm3-26\crm3-26.rhana\src` папка `test` отсутствовала (была пустой). То есть при выгрузке в файлы конфигуратор не читал файлы.
cursor_ai commented 2026-08-18 13:16:14 +00:00
Member
Copy Link
Copy Source

Ответ на #issuecomment-286

Да, так и есть. Выгрузка в S:\src после subst на родителя подтверждает: дело не в корне диска и не только в предупреждении про 30 символов.

На dt-021 конфигуратор падает при выгрузке поверх уже существующих файлов (читает ConfigDumpInfo.xml и дерево src). В пустой каталог выгрузка проходит (D:\test_src, S:\test).

Синтетический configVersion у РК_ПроверкаСерий в текущем src\ConfigDumpInfo.xml (41–42 символа вместо SHA-1 на 40) — наиболее вероятный триггер при инкрементальной выгрузке.

Рекомендация «выгружать сразу в S:\src» снята. На этой машине в git-src напрямую не выгружать.

Рабочий цикл на dt-021

Всегда: пустой короткий каталог → копирование в git.

Remove-Item -Recurse -Force D:\e -ErrorAction SilentlyContinue
New-Item -ItemType Directory D:\e | Out-Null

В конфигураторе: выгрузить в D:\e (4 символа, не корень, каталог пустой).

Затем:

robocopy D:\e D:\projects\crm3-26\crm3-26.rhana\src /E

Из корня монорепозитория: scripts/normalize_1c_export.sh crm3-26.rhana

/MIR не использовать.

Каталог src\test\ в репозиторий не коммитить (вложенная копия). Если он ещё есть — удалить после переноса в src.

Необязательная проверка потом

Когда в src уже лежит штатный ConfigDumpInfo с выгрузки в пустой каталог, один раз можно снова попробовать S:\src. Если снова упадёт — на dt-021 навсегда оставляем только цикл «пустое D:\e → robocopy».

## Ответ на [#issuecomment-286](https://git.p7net.ru/1c/crm3_26.rhana/issues/16#issuecomment-286) Да, так и есть. Выгрузка в `S:\src` после `subst` на родителя **подтверждает**: дело не в корне диска и не только в предупреждении про 30 символов. На dt-021 конфигуратор **падает при выгрузке поверх уже существующих файлов** (читает `ConfigDumpInfo.xml` и дерево `src`). В **пустой** каталог выгрузка проходит (`D:\test_src`, `S:\test`). Синтетический `configVersion` у `РК_ПроверкаСерий` в текущем `src\ConfigDumpInfo.xml` (41–42 символа вместо SHA-1 на 40) — наиболее вероятный триггер при инкрементальной выгрузке. Рекомендация «выгружать сразу в `S:\src`» **снята**. На этой машине в git-`src` напрямую не выгружать. ## Рабочий цикл на dt-021 Всегда: **пустой короткий каталог** → копирование в git. ```powershell Remove-Item -Recurse -Force D:\e -ErrorAction SilentlyContinue New-Item -ItemType Directory D:\e | Out-Null ``` В конфигураторе: выгрузить в **`D:\e`** (4 символа, не корень, каталог пустой). Затем: ```powershell robocopy D:\e D:\projects\crm3-26\crm3-26.rhana\src /E ``` Из корня монорепозитория: `scripts/normalize_1c_export.sh crm3-26.rhana` `/MIR` не использовать. Каталог `src\test\` в репозиторий не коммитить (вложенная копия). Если он ещё есть — удалить после переноса в `src`. ## Необязательная проверка потом Когда в `src` уже лежит **штатный** `ConfigDumpInfo` с выгрузки в пустой каталог, один раз можно снова попробовать `S:\src`. Если снова упадёт — на dt-021 навсегда оставляем только цикл «пустое `D:\e` → robocopy».
cursor_ai commented 2026-08-18 13:19:39 +00:00
Member
Copy Link
Copy Source

Почему падает git-src и проходит более длинный crm3-26.rhana.test

Длина пути не причина падения. D:\projects\crm3-26\crm3-26.rhana.test\src ещё длиннее, но каталог был пустой — конфигуратор не читал чужой ConfigDumpInfo.xml. Предупреждение про 30 символов — эвристика MAX_PATH, само по себе не закрывает конфигуратор.

При выгрузке поверх существующего каталога конфигуратор читает src\ConfigDumpInfo.xml (инкрементальная выгрузка). В git этот файл для РК_ПроверкаСерий собран вручную (обработка добавлялась XML-правками, не выгрузкой из конфигуратора):

Объект git configVersion Длина Как должно быть
РК_ПроверкаСерий a1b2c3d4e5f67890… 40, но шаблон a1b2c3d4… SHA-1
…Form.Форма b2c3d4e5…901 42 ровно 40 hex
…Form.Форма.Form c3d4e5f6…012 41 ровно 40 hex

В выгрузке в crm3-26.rhana.test те же 87 записей, все configVersion — штатные SHA-1 (например форма: 0717cd97a4a9d63560c7e131d1669d4a047a854d). UUID f14e0001-… конфигуратор сохранил — они не ломают выгрузку.

Итог: конфигуратор падает на разборе битого ConfigDumpInfo.xml, не на «испорченных» XML объектов. После подмены ConfigDumpInfo.xml (или всего src) файлами из crm3-26.rhana.test выгрузка поверх git-src должна проходить; предупреждение про 30 символов может остаться, но без падения.

Не коммитить crm3-26.rhana.test в монорепозиторий как отдельный проект — это рабочая копия выгрузки.

## Почему падает git-`src` и проходит более длинный `crm3-26.rhana.test` Длина пути **не причина падения**. `D:\projects\crm3-26\crm3-26.rhana.test\src` ещё длиннее, но каталог был **пустой** — конфигуратор не читал чужой `ConfigDumpInfo.xml`. Предупреждение про 30 символов — эвристика MAX_PATH, само по себе не закрывает конфигуратор. При выгрузке **поверх** существующего каталога конфигуратор читает `src\ConfigDumpInfo.xml` (инкрементальная выгрузка). В git этот файл для `РК_ПроверкаСерий` собран вручную (обработка добавлялась XML-правками, не выгрузкой из конфигуратора): | Объект | git `configVersion` | Длина | Как должно быть | |--------|---------------------|-------|-----------------| | `РК_ПроверкаСерий` | `a1b2c3d4e5f67890…` | 40, но шаблон `a1b2c3d4…` | SHA-1 | | `…Form.Форма` | `b2c3d4e5…901` | **42** | ровно 40 hex | | `…Form.Форма.Form` | `c3d4e5f6…012` | **41** | ровно 40 hex | В выгрузке в `crm3-26.rhana.test` те же 87 записей, все `configVersion` — штатные SHA-1 (например форма: `0717cd97a4a9d63560c7e131d1669d4a047a854d`). UUID `f14e0001-…` конфигуратор **сохранил** — они не ломают выгрузку. Итог: конфигуратор падает на разборе **битого `ConfigDumpInfo.xml`**, не на «испорченных» XML объектов. После подмены `ConfigDumpInfo.xml` (или всего `src`) файлами из `crm3-26.rhana.test` выгрузка поверх git-`src` должна проходить; предупреждение про 30 символов может остаться, но без падения. Не коммитить `crm3-26.rhana.test` в монорепозиторий как отдельный проект — это рабочая копия выгрузки.
cursor_ai commented 2026-08-18 13:23:44 +00:00
Member
Copy Link
Copy Source

UUID ранее не менял — только диагностика. Из‑за этого повторная выгрузка в git-src снова упала: битый ConfigDumpInfo.xml оставался на месте.

Сейчас в crm3-26.rhana\src перенесена успешная выгрузка из crm3-26.rhana.test\src (включая штатный ConfigDumpInfo.xml, версия 1.3.1.82). Синтетические configVersion у РК_ПроверкаСерий убраны.

Можно повторить выгрузку поверх D:\projects\crm3-26\crm3-26.rhana\src. Предупреждение про 30 символов может остаться — падать не должно. crm3-26.rhana.test в git не коммитить.

UUID ранее **не** менял — только диагностика. Из‑за этого повторная выгрузка в git-`src` снова упала: битый `ConfigDumpInfo.xml` оставался на месте. Сейчас в `crm3-26.rhana\src` перенесена успешная выгрузка из `crm3-26.rhana.test\src` (включая штатный `ConfigDumpInfo.xml`, версия **1.3.1.82**). Синтетические `configVersion` у `РК_ПроверкаСерий` убраны. Можно повторить выгрузку **поверх** `D:\projects\crm3-26\crm3-26.rhana\src`. Предупреждение про 30 символов может остаться — падать не должно. `crm3-26.rhana.test` в git не коммитить.
cursor_ai changed title from ❌ Проблема выгрузки расширения в файлы на рабочем месте dt-021 to Выгрузка в файлы на dt-021: кривой configVersion в ConfigDumpInfo.xml 2026-08-18 13:35:15 +00:00
cursor_ai commented 2026-08-18 13:36:28 +00:00
Member
Copy Link
Copy Source

Хронология, которая привела к решению

  1. Симптом. На dt-021 конфигуратор при «Выгрузить конфигурацию в файлы» в D:\projects\crm3-26\crm3-26.rhana\src закрывался без диалога. Показывалось предупреждение про путь длиннее 30 символов — его сначала приняли за причину.

  2. Обход .cfe. Выгрузка в .cfe и обратная загрузка в ИБ сбрасывает внутренние идентификаторы. На падение поверх существующего src это не влияет: конфигуратор всё равно читает git-ConfigDumpInfo.xml.

  3. Пустой каталог. Выгрузка в пустые D:\test_src и позже D:\projects\crm3-26\crm3-26.rhana.test\src (путь длиннее git-src) проходила. Значит, дело не в длине пути и не в самом расширении в ИБ.

  4. subst S:. Подстановка S: на src, выгрузка в корень S:\ — падение без предупреждения про 30 символов. Выгрузка в пустой S:\test — успех. Выгрузка в непустой S:\src (поверх файлов) — снова падение. Вывод: падает инкрементальный dump по уже лежащему дереву файлов.

  5. Разбор git. Обработка РК_ПроверкаСерий добавлена правкой XML, не выгрузкой из конфигуратора. В ConfigDumpInfo.xml у неё configVersion длиной 41 и 42 символа (и шаблонный 40-символьный хеш у самой обработки). Платформа ждёт SHA-1 ровно 40 hex. Невалидная длина → конфигуратор завершается без сообщения.

  6. UUID объектов вида f14e0001-0001-4000-8000-000000000001 — валидный RFC 4122. Конфигуратор их оставил. Ломал выгрузку именно configVersion.

  7. Исправление. src возвращён из HEAD вложенного репозитория crm3-26.rhana. В ConfigDumpInfo.xml исправлены только три configVersion на 40-hex заглушки SHA-1. Остальное (CHANGELOG, VERSION 1.3.1.82) не трогали.

  8. Проверка. Выгрузка в D:\projects\crm3-26\crm3-26.rhana\src прошла успешно. Обход «пустая папка + robocopy» больше не нужен.

Не коммитить *.rhana.test и вложенный src\test.

Как пополнять постоянный контекст Cursor (монорепозиторий crm3-26)

Чтобы агент в следующих сессиях не выдумывал configVersion произвольной длины при правке XML любых конфигураций/расширений, норма фиксируется в трёх слоях (не только в этом репозитории расширения):

Слой Файл Зачем
Правило Cursor crm3-26/.cursor/rules/1c-xml-dump-ids.mdc (alwaysApply: true) Подмешивается в каждый чат агента в общем проекте
Корневой контекст crm3-26/.cursorrules Краткий указатель в блоке «Стандарты разработки 1С»
Канон crm3-26/docs/1c_standarts/Выгрузка_в_файлы_ConfigDumpInfo.md Полное описание для людей и агентов

Практический шаблон для следующих решений:

  1. Разобрать причину в issue (как здесь).
  2. Если это норма работы с кодом/выгрузкой — добавить .mdc в .cursor/rules/ общего проекта: alwaysApply: true для короткого универсального правила, либо globs: если правило нужно только при открытых определённых файлах. Формат: YAML-frontmatter + markdown, одно правило — одна тема, с примером «плохо / хорошо».
  3. Человекочитаемый канон — в docs/ (здесь: docs/1c_standarts/).
  4. При необходимости одна-две строки-указателя в .cursorrules.
  5. В issue — ссылки на эти файлы, чтобы история не жила только в чате.

Каталог docs/context/ в проекте пока не заведён; для таких норм достаточно docs/1c_standarts/ + .cursor/rules/.

## Хронология, которая привела к решению 1. **Симптом.** На dt-021 конфигуратор при «Выгрузить конфигурацию в файлы» в `D:\projects\crm3-26\crm3-26.rhana\src` закрывался без диалога. Показывалось предупреждение про путь длиннее 30 символов — его сначала приняли за причину. 2. **Обход `.cfe`.** Выгрузка в `.cfe` и обратная загрузка в ИБ сбрасывает внутренние идентификаторы. На падение **поверх существующего `src`** это не влияет: конфигуратор всё равно читает git-`ConfigDumpInfo.xml`. 3. **Пустой каталог.** Выгрузка в пустые `D:\test_src` и позже `D:\projects\crm3-26\crm3-26.rhana.test\src` (путь **длиннее** git-`src`) проходила. Значит, дело не в длине пути и не в самом расширении в ИБ. 4. **`subst S:`.** Подстановка `S:` на `src`, выгрузка в корень `S:\` — падение **без** предупреждения про 30 символов. Выгрузка в пустой `S:\test` — успех. Выгрузка в непустой `S:\src` (поверх файлов) — снова падение. Вывод: падает **инкрементальный** dump по уже лежащему дереву файлов. 5. **Разбор git.** Обработка `РК_ПроверкаСерий` добавлена правкой XML, не выгрузкой из конфигуратора. В `ConfigDumpInfo.xml` у неё `configVersion` длиной 41 и 42 символа (и шаблонный 40-символьный хеш у самой обработки). Платформа ждёт SHA-1 **ровно 40** hex. Невалидная длина → конфигуратор завершается без сообщения. 6. **UUID объектов** вида `f14e0001-0001-4000-8000-000000000001` — валидный RFC 4122. Конфигуратор их оставил. Ломал выгрузку именно `configVersion`. 7. **Исправление.** `src` возвращён из HEAD вложенного репозитория `crm3-26.rhana`. В `ConfigDumpInfo.xml` исправлены только три `configVersion` на 40-hex заглушки SHA-1. Остальное (CHANGELOG, VERSION 1.3.1.82) не трогали. 8. **Проверка.** Выгрузка в `D:\projects\crm3-26\crm3-26.rhana\src` прошла успешно. Обход «пустая папка + robocopy» больше не нужен. Не коммитить `*.rhana.test` и вложенный `src\test`. --- ## Как пополнять постоянный контекст Cursor (монорепозиторий `crm3-26`) Чтобы агент в следующих сессиях **не выдумывал** `configVersion` произвольной длины при правке XML любых конфигураций/расширений, норма фиксируется в **трёх слоях** (не только в этом репозитории расширения): | Слой | Файл | Зачем | |------|------|--------| | Правило Cursor | `crm3-26/.cursor/rules/1c-xml-dump-ids.mdc` (`alwaysApply: true`) | Подмешивается в каждый чат агента в общем проекте | | Корневой контекст | `crm3-26/.cursorrules` | Краткий указатель в блоке «Стандарты разработки 1С» | | Канон | `crm3-26/docs/1c_standarts/Выгрузка_в_файлы_ConfigDumpInfo.md` | Полное описание для людей и агентов | Практический шаблон для следующих решений: 1. Разобрать причину в issue (как здесь). 2. Если это **норма работы с кодом/выгрузкой** — добавить `.mdc` в `.cursor/rules/` общего проекта: `alwaysApply: true` для короткого универсального правила, либо `globs:` если правило нужно только при открытых определённых файлах. Формат: YAML-frontmatter + markdown, одно правило — одна тема, с примером «плохо / хорошо». 3. Человекочитаемый канон — в `docs/` (здесь: `docs/1c_standarts/`). 4. При необходимости одна-две строки-указателя в `.cursorrules`. 5. В issue — ссылки на эти файлы, чтобы история не жила только в чате. Каталог `docs/context/` в проекте пока не заведён; для таких норм достаточно `docs/1c_standarts/` + `.cursor/rules/`.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
abramova_vk (Виктория Абрамова) cursor_ai kma (Михаил Кудрявцев (разработчик)) mk (Михаил Кудрявцев (владелец git.p7net.ru)) source_craft zvereva_on (Ольга Зверева)
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: 1c/crm3_26.rhana#16
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?