- form-info/{rich-form,simple-form}: тип реквизита Объект исправлен
с ExternalDataProcessorObject на DataProcessorObject — preRun создаёт
обычную обработку, и платформа отвергала несоответствие XDTO-исключением.
- verify-snapshots.mjs: поддержка setup="external:<path>" — копирует
внешний дамп (выгрузку ERP/БП) в workDir, пропускает cf-init и
авто-регистрацию объектов через cf-edit. Платформенная загрузка
целой вендорской конфы скипается — кейсы real-acc-form-* проверяют
скрипт против реального XML, а не пригодность всей БП к чистой базе.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
getStructuralDeps теперь сканирует все inputs (caseData.input + preRun.input),
а не только верхний — без этого регистры, созданные через preRun, оставались
без документа-регистратора и платформа отвергала конфиг с
«Ни один из документов не является регистратором».
Добавлен случай ChartOfAccounts: при maxExtDimensionCount>0 (или непустых
extDimensionAccountingFlags) и без явной ссылки extDimensionTypes
автоматически создаётся стаб ChartOfCharacteristicTypes и линкуется через
meta-edit modify-property уже после preRun. Для этого getStructuralDeps
возвращает теперь { deps, hostEdits }, а в основной поток добавлен Step 3.5
(host-level structural edits).
InformationRegister с writeMode=Subordinate/RecorderSubordinate тоже
получает документ-регистратор.
Полный прогон verify-snapshots: 193/193.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Готовый Template.xml оборачивается в исходники EPF: epf-init создаёт
скелет, template-add регистрирует SpreadsheetDocument-макет, MXL копируется
поверх дефолтного, далее epf-build реально проверяет, что платформа
принимает разметку. mxl-compile убран из STANDALONE_SKILLS.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
После main-скрипта определяется тип артефакта в workDir: Configuration.xml
→ обычная загрузка конфигурации, иначе по корню *.xml выбирается ветка
epf-build (.epf для ExternalDataProcessor, .erf для ExternalReport). Для
кейсов с cf-init теперь configDir переустанавливается на workDir, так что
конфиг действительно грузится в БД, а не пропускается.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
EPF_SKILLS превращён из «skip» в реальную сборку через epf-build —
строится .epf или .erf по расширению из map. Имя источника берётся
из caseData.params.name. erf-init добавлен в DEFAULT_SKILLS.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
skd-edit добавлен в SKD_PLATFORM_VERIFY — результат заворачивается в ERF и
собирается через epf-build, как уже сделано для skd-compile. Резолвер пути
шаблона теперь учитывает params.templatePath (фолбэк: outputPath, Template.xml).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
До сих пор для skd-compile (как и других STANDALONE_SKILLS)
verify-snapshots просто запускал скрипт и помечал PASS — без
платформенной нагрузки. Опасный пробел: можно было закоммитить
snapshot, который 1С Designer не примет.
Теперь для skd-compile snapshot оборачивается во внешний отчёт
(erf-init --WithSKD), Template.xml подменяется на сгенерированный
кейсом, и запускается erf-build. Платформа парсит схему — если
принимает, кейс PASS; если отклоняет, в errors попадает её stderr.
Ссылочные типы (CatalogRef.X и т.п.) не требуют реальной базы:
epf-build сам поднимает временную stub-конфигурацию.
Если v8 недоступен — мягкий skip с пометкой "no v8 context".
Замер: 21 кейс x ~5s avg = ~110s на полный verify-snapshots
--skill skd-compile. Все 21 текущих кейса проходят — значит каждый
snapshot гарантированно платформо-валиден.
Аналогичная обёртка для mxl-compile / role-compile — отдельной
задачей по образцу.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
form-add теперь покрывает и объекты конфигурации, и standalone EPF/ERF
source tree (тип определяется из корневого XML, маппинг типов уже был).
Изменения form-add scaffold:
- Module.bsl: пустые регионы вместо скелета процедуры ПриСозданииНаСервере
- Form.xml: убран <Events> (раньше привязывал OnCreateAtServer к процедуре)
- Form.xml: <SavedData>true</SavedData> теперь условный — ставится для
Catalog/Document/etc (стандарт ERP, 99% форм), не ставится для
DataProcessor/Report/External* (где у объекта нет состояния)
Это согласуется с workflow: form-compile перегенерирует Form.xml целиком,
поэтому привязки в scaffold могут стать orphan; пустые регионы +
без Events — корректная стартовая точка, которую form-edit/form-compile
наполняют атомарно.
Удалён навык epf-add-form (директория + тесты), вызовы заменены на
form-add в integration-тестах, в кейсах epf-validate/help-add, в
description epf-init/epf-bsp-init, в docs и README.
Перегенерированы snapshot'ы 5 навыков (form-add, form-compile,
form-edit, form-info, form-validate). Платформенная верификация в 1С 8.3.24
прошла для всех 9 кейсов form-add.
Bump form-add v1.3 → v1.4.
Two harness gaps that masked real issues and leaked stray files:
1. Case-level `setup: "fixture:<name>"` was ignored — runner.mjs handled
it, verify-snapshots did not. skd-edit/add-drilldown silently failed
with "File not found: Template.xml" because the fixture never reached
workDir. Added Step 0 fixture copy mirroring runner.mjs behavior.
2. `skillConfig.cwd === "workDir"` was ignored — main skill always ran
with cwd=REPO_ROOT. mxl-compile cases pass relative -OutputPath
"Template.xml", which landed in the repo root on every run. Plumb cwd
through execSkill and set mainCwd from skillConfig.cwd.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
cf-edit add-childObject was a low-level XML-manipulation operation
with no file-existence validation — callers could register a reference
to any Type.Name in Configuration.xml's ChildObjects without the
underlying file existing on disk. Platform then refused to load:
"Файл объекта не существует".
The 4 failing tests (add-objects, remove-object, add-default-role,
set-default-roles) all used this operation with fake references in
either main input or preRun, and had no way to pass verify-snapshots
because the cf-init-ed config had no actual object files.
User observation: this is the tests being wrong, not the skill.
meta-compile/role-compile/subsystem-compile already auto-register
every new object in Configuration.xml as part of their normal flow
(meta-compile.ps1:2949-3068, role-compile.ps1:667-747,
subsystem-compile.ps1:430-506). Nobody should be calling cf-edit
add-childObject to create a new object — they should be calling the
profile skill. cf-edit add-childObject is only for rare recovery
scenarios: rolled-back Configuration.xml with intact object files,
re-import from DB dump that clobbered the root but left srcfiles.
Changes:
1. cf-edit.ps1/py: Do-AddChildObject now checks that the target file
exists at {ConfigDir}/{PluralDir}/{Name}.xml before registering.
On miss, exits 1 with a message that names the expected path and
points the user at the right skill (/meta-compile, /role-compile,
or /subsystem-compile depending on type). TYPE_TO_DIR mapping for
all 44 metadata types covers irregular plurals (FilterCriteria,
BusinessProcesses, ChartsOfAccounts, ChartsOfCharacteristicTypes,
ChartsOfCalculationTypes).
2. Tests: 4 existing cases rewritten to build realistic fixtures via
meta-compile/role-compile preRun (both skills auto-register, so
the resulting Configuration.xml already references the preRun
objects). add-objects now exercises the round-trip recovery
scenario: meta-compile creates Catalog.Товары and Document.ПриходТоваров
(auto-registered) → cf-edit remove-childObject un-registers both
(files remain) → main run re-registers via add-childObject. This
tests exactly the rollback-recovery use case the operation exists for.
3. New add-missing-errors case: negative test with expectError:
"Object file not found". Verifies the new hard-error path.
4. verify-snapshots.mjs: added symmetric expectError handling (runner.mjs
already had it at line 514). If caseData.expectError is set,
expect skill to fail; check stderr substring match; skip db-load
and mark passed. Without this, negative tests would go red in
verify-snapshots even though runner.mjs accepts them.
5. SKILL.md / reference.md: documented the new constraint and the
redirection to profile skills. Kept mention of legitimate use case
(rollback recovery).
Bumped cf-edit.ps1/py v1.0→v1.1.
Verification:
- runner --filter cf-edit (PS1): 2/6 → 7/7 (6 positive + 1 negative)
- runner --filter cf-edit --runtime python: 7/7 (dual-port clean)
- verify-snapshots --skill cf-edit: 2/6 → 7/7
With this landed P3 from debug/snapshot-verify/NEXT-STEPS.md is closed.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The bottom-up flow (compile child with -Parent pointing at parent's
XML — skill creates the real child file AND registers it in parent's
ChildObjects) has been the documented canonical way to build nested
subsystems since forever. It's in SKILL.md Примеры:58 and implemented
in subsystem-compile.ps1:430-506. But zero test cases exercised it —
all 7 pre-existing cases used the top-down `children: [...]` shortcut
that aa93031 made honest with stubs.
Two problems with the status quo:
1. A model reading SKILL.md saw `"children": ["ДочерняяА", "ДочерняяБ"]`
right in the main JSON-definition example and took it as the
canonical way to create nested structure. It's a trap — the
shortcut creates placeholder stubs with empty Synonym/Content that
the model almost never actually wants. The natural flow (one
subsystem-compile call per real subsystem) wasn't visible where
the model looks first.
2. The canonical flow had no test safety net — nothing caught regressions
in the register-in-parent code path (lines 430-506).
Fix, minimal surface:
- SKILL.md: remove `"children": [...]` from the JSON-definition example.
Leave the `-Parent` example in the Примеры section (already there).
The children field stays fully supported in the scripts (aa93031 stub
behavior unchanged) for legacy JSON — just not advertised.
- New test case `nested-parent.json`: preRun compiles "Продажи" parent,
main run compiles "Настройки" child with `-Parent Subsystems/Продажи.xml`.
Verifies the real bottom-up flow: snapshot shows full child file with
real Synonym/Explanation AND parent's `<ChildObjects>` updated to
reference the child. verify-snapshots confirms platform accepts it.
- Runner plumbing: `_skill.json` gains `{ "flag": "-Parent", "from":
"workPath", "field": "parent", "optional": true }`. Required extending
both `tests/skills/runner.mjs` and `tests/skills/verify-snapshots.mjs`
(they each have their own copy of buildArgs) to support `optional: true`
on workPath mappings — otherwise existing cases without params.parent
would get the flag pushed with an empty value.
Verification:
- runner --filter subsystem-compile (PS1): 8/8 (was 7/7 +1)
- runner --filter subsystem-compile --runtime python: 8/8 (dual-port clean)
- verify-snapshots --skill subsystem-compile: 8/8
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Platform writes load-time property/type/enum rejections ("Неверное
свойство объекта метаданных", "Неизвестное имя типа" и т.п.) into the
/Out log but still exits with code 0, silently dropping the offending
metadata. db-load-xml now parses the log for these patterns and prints
a yellow "[warning] N rejection(s)" block to stdout so users (and the
model) can see them immediately.
Exit code still mirrors the platform by default — we don't second-guess
its verdict. With the new -StrictLog switch, rejection patterns are
elevated to exit code 1, which is the mode verify-snapshots.mjs uses
for honest E2E verdicts. All three db-load-xml call sites in the
verifier (main config, CFE base, CFE extension) now pass -StrictLog.
Found while investigating upload/form-baseline/gotchas.md #4 where AR
attribute emission was wrong but verify-snapshots showed green because
the old exit-code-only check missed the silent drops.
Bumped db-load-xml.ps1 + .py to v1.3.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Runs each test case through the full pipeline: cf-init → stubs → preRun →
skill script → cf-edit → db-create → LoadConfigFromFiles → UpdateDBCfg.
Handles typed-input, args-only, standalone (SKD/MXL), and EPF skills.
Results: 118/145 pass, findings documented in debug/snapshot-verify/.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Nick Shirokov