What happened

The “AI for 1C” product bundles MCP connectors: configuration metadata, help, live data, BSL/XML editing, admin commands. UI tests initially wrapped Vanessa Automation — a mature BDD layer with Russian Gherkin steps and .feature files.

On Linux headless with Xvfb, that is tolerable: tests run in the background. On a daily-driver Windows laptop, the agent launches a full 1C session with windows plus a test manager; forms flash on screen, accidental clicks break half-hour runs, memory drains. The idea: keep Gherkin, drive TestClient directly from Python, drop the extra runtime.

Official 1C testing pairs a test manager (/TESTMANAGER) and test client (/TESTCLIENT) exchanging binary frames. Vanessa maps human-readable scenarios into that mechanism. The target architecture: .feature → transpiler → native protocol → real 1C forms.

A week with Codex in deep reasoning mode: pcap captures, field-length guesses, frame replay — partial wins, no complete map. At that pace, replacing a working layer looked like a year-long project.

Fable 5 (“trimmed Mythos”) arrived. For ~$20 pro access, the author fed raw dumps, failed hypotheses, and Python fragments. In under a day: handshake structure, reusable frames, dynamic fields, and boundaries where capture beats guessing. Codex and Claude Code Opus 4.8 then spent ~two more weeks turning specs into product.

qa-mcp as of 2026-06-23: ~60 MCP tools, 475 offline tests, Vanessa corpus transpile from 12% to 100% on their scenarios, Gherkin/BDD, JUnit/Allure reports, UI → database checks via OData, metadata-driven smoke generation, coverage/timing via debug protocol, protocol drift detection when the platform version changes.

Why it matters

This is a rare public case where AI did not “write CRUD” but dissected a closed ERP binary protocol — work teams usually defer. For 1C developers and agent builders, the lesson: keep the top layer (Gherkin, familiar steps) and replace the middle with direct TestClient when you need agent-first QA without a second fullscreen 1C on your laptop.

qa-mcp adds what Vanessa-MCP lacked: assert_data over OData (button clicked ≠ document posted), role matrices, smoke from metadata, CI gates on step duration and line coverage via /e1crdbg/. The caveat is honest: the protocol is not a public 1C API — templates bind to platform version (lab: 8.3.27.2130); a drift detector warns on mismatch.

In practice

1. Do not rush to drop Vanessa — if your BDD corpus and headless farm work, qa-mcp targets agent workflow, not “Vanessa is bad.”
2. Split research and coding — heavy protocol reverse went to a large-context model (Fable 5); application code followed specs via Codex/Claude.
3. Transpile with unmapped steps — unknown steps surface in reports instead of silent passes.
4. UI + data — after saving a form, verify OData, not just window close.
5. Platform version — pin a template manifest; on 1C upgrades, run live regression and python -m qa_mcp.regression.versioning.
6. Smoke from meta-mcp — generate_smoke_suite opens main catalog/document forms from the metadata map.

Takeaway

The post is about balancing a mature BDD tool with agent-native QA: Fable 5 unblocked the protocol “last mile,” qa-mcp kept Gherkin and added data and performance gates. If you build AI-assisted 1C development, watch the project — and plan for protocol drift, not eternal byte-template compatibility.