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