/1c-qa-testing

name: 1c-qa-testing
description: "UI checks in the 1C thin client through QA MCP (`1c-qa`, `qa_*` / `ui_*`): session, observe → act → assert, platform behaviour, unknown outcomes, journal and verdicts. Main UI route when connected and TOOL_QA allows it; the web client is the fallback."
argument-hint: "<feature or scenario to check>"

1c-qa-testing — UI checks through QA MCP

QA MCP (connection `1c-qa`) is the 1C test manager: it connects to a 1C test client (`/TestClient`) and drives its forms through the platform testing model — windows, fields, tables, commands, messages. It reads structured state, not pixels, so it is the main route for checking behaviour in the 1C interface. The web client (`content/rules/ui-testing-tools.md`) is the fallback.

When this route applies

All of these hold:

• `UI_TESTING` allows the check (`content/rules/dev-standards-env.md → UI_TESTING`): `essential` / `auto` after the change reached the dev/test infobase, `manual` on an explicit request, never under `off`.
• `TOOL_QA` is not `off` (`content/rules/mcp-policy.md → Tool availability`).
• The `qa_*` / `ui_*` tools are exposed in this session and `qa_status` answers. A config entry or `/healthz` proves nothing.
• The target is an authorized dev/test infobase (`INFOBASE_ROLE`), the one in `.dev.env`.

Otherwise use the web fallback of `ui-testing-tools.md`, or report the check unrun with the reason. `TOOL_QA=required` with the server missing blocks the check; the web client does not replace it.

**Before the first action load `content/rules/qa-testclient.md`.** It owns what the server does not do: starting and stopping the test client, visible or hidden window, screenshots, Windows-MCP, and confirming data through `1c-data-mcp`. Tool argument names come from the exposed schemas; `qa_playbook` returns the sequence for the current executor.

Other MCP servers in a check

When a check needs metadata, form structure, impact, error source or live data, load the matching entry in [context-sources.md](docs/context-sources.md). Use indexes only when they cover the configuration loaded into the tested infobase; confirm element names in the live window.

Session

1. `qa_status` — the executor decides who starts 1C:

| `executor` | What it is | Test client | |---|---|---| | `native` | The container is the test manager and speaks the test-client protocol; no 1C platform inside | The agent starts it by `qa-testclient.md`; the server only connects | | `platform` | Windows manager next to the platform | `qa_start` starts it itself |

2. Start or find the test client (`qa-testclient.md`), then `qa_start(connection="<session name>")`; `port=` overrides the port of `MCP_QA_TESTCLIENT`. No Windows account is needed: the test client accepts the channel's Windows authentication from any identity (8.3.27.2130); the 1C sign-in happens when the client starts. 3. `qa_status` again: executor, link, target. A `test client is already connected to another manager` answer means another agent owns the client — a conflict to resolve, not a client to close. 4. At the end: `qa_stop`. In `native` it only disconnects; the client is closed by the tool that started it (`qa-testclient.md`). A new MCP session or a restarted client needs a new `qa_start`; `save_as` aliases and `ui_here` pins do not survive it.

After `/update1cbase`, `/deploy-and-test` or `/restore-testbase` the update ends the sessions of the infobase: a client started before it is stale. Start a fresh client, `qa_start`, and read the main window before the first step.

Observe → act → read the change → assert

1. Read before acting: `ui_active_window`, then `ui_window_tree(detail="lite")` or `ui_inspect`. Use the names and paths they return; never invent element names. 2. One purposeful action: `ui_open`, `ui_click`, `ui_set` / `ui_input`, `ui_field`, `ui_table`, `ui_list`, `ui_command`, `ui_dialog`, `ui_form`. 3. Read the result: `ui_window_changes`, `ui_wait` (form, element or closing), `ui_messages`, `ui_errors`. 4. Assert on read values: `ui_get_text`, `ui_find`, table rows from `ui_table` / `ui_list`. A command accepted is not an effect observed. 5. Re-read the window after navigation, a closed form or anything that invalidates the tree; earlier snapshots and `ui_here` pins are stale then.

The first form may still be loading right after the client starts: repeat read-only reads within a bounded wait.

Forms

• `ui_open(kind=, metadata_name=)` without `form_name` opens and recognises the default form, including one defined in the configuration (`Вид.Объект.Форма.<Имя>`). When the configuration opens another form instead (ZUP: the employee list is a data-processor form), the single new form is accepted and the answer carries `substituted_for`. A failed open lists the forms that did appear. `ui_open(link="e1cib/…", target_title=…)` opens by navigation link.
• `e1cib/data/<Type>.<Name>` without `?ref` opens a new object; the auto-generated object form is `<Type>.<Name>.ФормаОбъекта`, without `.Форма.`.
• `ui_close_form` closes the named form (`form=`, `title=`, `name=`, `form_name=`) or the active non-main window. It never closes the main window and closes nothing when the named form is not found.
• The MCPQAClient extension enables `ui_form_schema`, `qa_data_candidates` and `ui_open` through `ОткрытьФорму`; without it `ui_open` opens forms by navigation link. Installing it is a change of the test infobase (`qa-testclient.md → MCPQAClient extension`).

Recipes

Before list navigation, field entry, table editing, save/post or dialog actions, read the matching recipe and its pitfalls in [interaction-recipes.md](docs/interaction-recipes.md). Read-only window inspection needs no recipe. Two failed attempts by one method require a fresh window read, then another method or an explicit unverified result; never vary arguments blindly.

Platform behaviour (8.3.27.2130, measured)

Before asserting changed field values, navigating table rows/