testeiya 0.2.1 → 0.3.9

package/skills/playwright-cli/references/tracing.md

@@ -1,139 +0,0 @@
-# Tracing
-
-Capture detailed execution traces for debugging and analysis. Traces include DOM snapshots, screenshots, network activity, and console logs.
-
-## Basic Usage
-
-```bash
-# Start trace recording
-playwright-cli tracing-start
-
-# Perform actions
-playwright-cli open https://example.com
-playwright-cli click e1
-playwright-cli fill e2 "test"
-
-# Stop trace recording
-playwright-cli tracing-stop
-```
-
-## Trace Output Files
-
-When you start tracing, Playwright creates a `traces/` directory with several files:
-
-### `trace-{timestamp}.trace`
-
-**Action log** - The main trace file containing:
-- Every action performed (clicks, fills, navigations)
-- DOM snapshots before and after each action
-- Screenshots at each step
-- Timing information
-- Console messages
-- Source locations
-
-### `trace-{timestamp}.network`
-
-**Network log** - Complete network activity:
-- All HTTP requests and responses
-- Request headers and bodies
-- Response headers and bodies
-- Timing (DNS, connect, TLS, TTFB, download)
-- Resource sizes
-- Failed requests and errors
-
-### `resources/`
-
-**Resources directory** - Cached resources:
-- Images, fonts, stylesheets, scripts
-- Response bodies for replay
-- Assets needed to reconstruct page state
-
-## What Traces Capture
-
-| Category | Details |
-|----------|---------|
-| **Actions** | Clicks, fills, hovers, keyboard input, navigations |
-| **DOM** | Full DOM snapshot before/after each action |
-| **Screenshots** | Visual state at each step |
-| **Network** | All requests, responses, headers, bodies, timing |
-| **Console** | All console.log, warn, error messages |
-| **Timing** | Precise timing for each operation |
-
-## Use Cases
-
-### Debugging Failed Actions
-
-```bash
-playwright-cli tracing-start
-playwright-cli open https://app.example.com
-
-# This click fails - why?
-playwright-cli click e5
-
-playwright-cli tracing-stop
-# Open trace to see DOM state when click was attempted
-```
-
-### Analyzing Performance
-
-```bash
-playwright-cli tracing-start
-playwright-cli open https://slow-site.com
-playwright-cli tracing-stop
-
-# View network waterfall to identify slow resources
-```
-
-### Capturing Evidence
-
-```bash
-# Record a complete user flow for documentation
-playwright-cli tracing-start
-
-playwright-cli open https://app.example.com/checkout
-playwright-cli fill e1 "4111111111111111"
-playwright-cli fill e2 "12/25"
-playwright-cli fill e3 "123"
-playwright-cli click e4
-
-playwright-cli tracing-stop
-# Trace shows exact sequence of events
-```
-
-## Trace vs Video vs Screenshot
-
-| Feature | Trace | Video | Screenshot |
-|---------|-------|-------|------------|
-| **Format** | .trace file | .webm video | .png/.jpeg image |
-| **DOM inspection** | Yes | No | No |
-| **Network details** | Yes | No | No |
-| **Step-by-step replay** | Yes | Continuous | Single frame |
-| **File size** | Medium | Large | Small |
-| **Best for** | Debugging | Demos | Quick capture |
-
-## Best Practices
-
-### 1. Start Tracing Before the Problem
-
-```bash
-# Trace the entire flow, not just the failing step
-playwright-cli tracing-start
-playwright-cli open https://example.com
-# ... all steps leading to the issue ...
-playwright-cli tracing-stop
-```
-
-### 2. Clean Up Old Traces
-
-Traces can consume significant disk space:
-
-```bash
-# Remove traces older than 7 days
-find .playwright-cli/traces -mtime +7 -delete
-```
-
-## Limitations
-
-- Traces add overhead to automation
-- Large traces can consume significant disk space
-- Some dynamic content may not replay perfectly

package/skills/playwright-cli/references/video-recording.md

@@ -1,143 +0,0 @@
-# Video Recording
-
-Capture browser automation sessions as video for debugging, documentation, or verification. Produces WebM (VP8/VP9 codec).
-
-## Basic Recording
-
-```bash
-# Open browser first
-playwright-cli open
-
-# Start recording
-playwright-cli video-start demo.webm
-
-# Add a chapter marker for section transitions
-playwright-cli video-chapter "Getting Started" --description="Opening the homepage" --duration=2000
-
-# Navigate and perform actions
-playwright-cli goto https://example.com
-playwright-cli snapshot
-playwright-cli click e1
-
-# Add another chapter
-playwright-cli video-chapter "Filling Form" --description="Entering test data" --duration=2000
-playwright-cli fill e2 "test input"
-
-# Stop and save
-playwright-cli video-stop
-```
-
-## Best Practices
-
-### 1. Use Descriptive Filenames
-
-```bash
-# Include context in filename
-playwright-cli video-start recordings/login-flow-2024-01-15.webm
-playwright-cli video-start recordings/checkout-test-run-42.webm
-```
-
-### 2. Record entire hero scripts.
-
-When recording a video for the user or as a proof of work, it is best to create a code snippet and execute it with run-code.
-It allows inserting appropriate pauses between the actions and annotating the video. There are new Playwright APIs for that.
-
-1) Perform scenario using CLI and take note of all locators and actions. You'll need those locators to request their bounding boxes for highlight.
-2) Create a file with the intended script for video (below). Use pressSequentially w/ delay for nice typing, make reasonable pauses.
-3) Use playwright-cli run-code --filename your-script.js
-
-**Important**: Overlays are `pointer-events: none` — they do not interfere with page interactions. You can safely keep sticky overlays visible while clicking, filling, or performing any actions on the page.
-
-```js
-async page => {
-  await page.screencast.start({ path: 'video.webm', size: { width: 1280, height: 800 } });
-  await page.goto('https://demo.playwright.dev/todomvc');
-
-  // Show a chapter card — blurs the page and shows a dialog.
-  // Blocks until duration expires, then auto-removes.
-  // Use this for simple use cases, but always feel free to hand-craft your own beautiful
-  // overlay via await page.screencast.showOverlay().
-  await page.screencast.showChapter('Adding Todo Items', {
-    description: 'We will add several items to the todo list.',
-    duration: 2000,
-  });
-
-  // Perform action
-  await page.getByRole('textbox', { name: 'What needs to be done?' }).pressSequentially('Walk the dog', { delay: 60 });
-  await page.getByRole('textbox', { name: 'What needs to be done?' }).press('Enter');
-  await page.waitForTimeout(1000);
-
-  // Show next chapter
-  await page.screencast.showChapter('Verifying Results', {
-    description: 'Checking the item appeared in the list.',
-    duration: 2000,
-  });
-
-  // Add a sticky annotation that stays while you perform actions.
-  // Overlays are pointer-events: none, so they won't block clicks.
-  const annotation = await page.screencast.showOverlay(`
-    <div style="position: absolute; top: 8px; right: 8px;
-      padding: 6px 12px; background: rgba(0,0,0,0.7);
-      border-radius: 8px; font-size: 13px; color: white;">
-      ✓ Item added successfully
-    </div>
-  `);
-
-  // Perform more actions while the annotation is visible
-  await page.getByRole('textbox', { name: 'What needs to be done?' }).pressSequentially('Buy groceries', { delay: 60 });
-  await page.getByRole('textbox', { name: 'What needs to be done?' }).press('Enter');
-  await page.waitForTimeout(1500);
-
-  // Remove the annotation when done
-  await annotation.dispose();
-
-  // You can also highlight relevant locators and provide contextual annotations.
-  const bounds = await page.getByText('Walk the dog').boundingBox();
-  await page.screencast.showOverlay(`
-    <div style="position: absolute;
-      top: ${bounds.y}px;
-      left: ${bounds.x}px;
-      width: ${bounds.width}px;
-      height: ${bounds.height}px;
-      border: 1px solid red;">
-    </div>
-    <div style="position: absolute;
-      top: ${bounds.y + bounds.height + 5}px;
-      left: ${bounds.x + bounds.width / 2}px;
-      transform: translateX(-50%);
-      padding: 6px;
-      background: #808080;
-      border-radius: 10px;
-      font-size: 14px;
-      color: white;">Check it out, it is right above this text
-    </div>
-  `, { duration: 2000 });
-
-  await page.screencast.stop();
-}
-```
-
-Embrace creativity, overlays are powerful.
-
-### Overlay API Summary
-
-| Method | Use Case |
-|--------|----------|
-| `page.screencast.showChapter(title, { description?, duration?, styleSheet? })` | Full-screen chapter card with blurred backdrop — ideal for section transitions |
-| `page.screencast.showOverlay(html, { duration? })` | Custom HTML overlay — use for callouts, labels, highlights |
-| `disposable.dispose()` | Remove a sticky overlay added without duration |
-| `page.screencast.hideOverlays()` / `page.screencast.showOverlays()` | Temporarily hide/show all overlays |
-
-## Tracing vs Video
-
-| Feature | Video | Tracing |
-|---------|-------|---------|
-| Output | WebM file | Trace file (viewable in Trace Viewer) |
-| Shows | Visual recording | DOM snapshots, network, console, actions |
-| Use case | Demos, documentation | Debugging, analysis |
-| Size | Larger | Smaller |
-
-## Limitations
-
-- Recording adds slight overhead to automation
-- Large recordings can consume significant disk space

package/skills/testeiya/README.md

@@ -1,29 +0,0 @@
-# Testeiya internal skills
-
-First-party skills authored in this repo and shipped with every Testeiya build.
-This folder is **not** managed by `cli/skills.yaml` — `bunosh skills:update`
-never touches it (it only replaces manifest-owned vendor folders).
-
-A skill is a folder with a `SKILL.md` — YAML frontmatter (`name` +
-`description`) followed by the instructions:
-
-    cli/skills/testeiya/my-skill/SKILL.md
-
-Scaffold one with `bunosh skills:create <name>`.
-
-Rules:
-
-- The frontmatter `name` must be a slug (`[a-z0-9-]`) — it is the `/mention`
-  token in the chat input. A non-slug name falls back to the folder name.
-- Skills placed directly in this folder get the **Testeiya** category in the
-  skills menu. To use a different category, nest a category subfolder:
-  `testeiya/<category>/<skill>/SKILL.md`.
-- A skill here **overrides** a vendored skill with the same name only by
-  load-order dedupe — avoid reusing external names; `bunosh skills:update`
-  warns on collisions.
-- Check the result with `bunosh skills:list` (this folder shows as internal).
-
-One exception to "hand-authored": `testomatio-docs/` carries generated data.
-Its `SKILL.md` is source and safe to edit, but `docs/`, `INDEX.md` and
-`docs.lock.json` are written by `bunosh docs:update` (re-run on release) from
-github.com/testomatio/docs — edit those upstream, not here.

package/skills/testeiya/answer-formatting/SKILL.md

@@ -1,30 +0,0 @@
----
-name: answer-formatting
-description: How to compose Testeiya's answer to any data question — counts, lists, statuses, trends, coverage, plan reviews, comparisons, reports. Use BEFORE composing such a reply. Defines the answer blocks (headline, chart, list, insights, offer) and the proof rules.
-license: MIT
-metadata:
-  author: Testomat.io
-  version: 2.0.0
----
-
-# Answer formatting
-
-A data question gets a visual answer. Build the reply from these blocks, in this order. Include a block when its data exists in the answer; skip it when it doesn't.
-
-1. **Headline** — one sentence: the verdict and its key number.
-2. **Chart** — `render_chart` or diagram if data can be explained with visuals.
-3. **List** — `render_result({call_id})` if data can be presented as a table. One entity → `render_item`. A hierarchy → `render_tree`.
-4. **Insights** — up to 3 bullets: what stands out, each citing its source.
-5. **Offer** — the obvious next action as an `ask_question`; a pick-a-subset proposal is its multi-select checklist. Skip when the answer closes the topic.
-
-Example: "how many of X passed?" → headline with the ratio, chart of the status split, one list of all X with status marks.
-
-## Rules
-
-- Every visual has a `title`: what it shows and how it was filtered.
-- No prose that repeats what a visual shows. Short sentences. No filler. Bold key numbers only. Never italic.
-- Workspace files as inline code (renders as a clickable link). Entities by their id.
-- Only numbers you computed from fetched data — derive counts/ratios with `query_result` on the fetched result, never by eyeballing a digest's sample; partial coverage is declared.
-- A flow or sequence → a `mermaid` block in the text.
-- Tool params live in the app-interface section of your system prompt — follow it, never invent fields.
-- No render tools in this host (terminal)? Same blocks as markdown: table with ✅ ❌ ⚠️ ⏭ marks instead of list/chart.

package/skills/testeiya/check-cucumber/SKILL.md

@@ -1,200 +0,0 @@
----
-name: check-cucumber
-description: Sync Gherkin `.feature` files with Testomat.io using the check-cucumber CLI. Import Features as suites and Scenarios as tests, write `@S`/`@T` IDs back, check or clean IDs, and pull manual BDD tests as feature files. The BDD counterpart to check-tests; Testeiya's built-in sync never touches `.feature` files. Use in a Cucumber, CodeceptJS-BDD, or Gherkin repo to import, push, sync, pull, or ID-tag features and scenarios.
-license: MIT
-metadata:
-  author: Testomat.io
-  version: 1.0.0
----
-
-# check-cucumber
-
-The `check-cucumber` CLI syncs Gherkin `.feature` files with Testomat.io. npm package `check-cucumber` (v0.6.x), run with `npx`. It:
-
-- imports every Feature as a suite and every Scenario as a test case;
-- writes `@S`/`@T` IDs back into the files for round-tripping;
-- pulls manual BDD tests from Testomat.io as `.feature` files.
-
-## Use cases
-
-- Import a Cucumber repo's features and scenarios into Testomat.io.
-- Write `@S`/`@T` IDs into the feature files so they round-trip with the TMS.
-- Import one directory without detaching the rest of the project.
-- Import into a branch, with labels, excluding drafts.
-- Gate CI on missing IDs (`--check-ids`).
-- Pull the project's manual BDD tests down as `.feature` files.
-- Diagnose an import that printed success but changed nothing.
-
-## Which tool for which tests
-
-A Cucumber project's `.feature` files ARE its tests. They are not `*.test.md`, and Testeiya's built-in sync does not cover them.
-
-- `*.test.md` markdown or code-based specs → `check-tests`.
-- Gherkin `.feature` files → this skill.
-- Test run RESULTS → `@testomatio/reporter` (`testomatio-reporter`, `qa-e2e-tests-reporting`).
-- Unsure of the project kind → `scan-automation-project` first.
-
-Never run `check-tests` over a `features/` directory, or `check-cucumber` over a markdown manual-tests directory.
-
-## Critical rules
-
-- **The import command REQUIRES the positional glob.** `npx check-cucumber -d features` alone prints the banner and exits 0 — a silent no-op. Always pass the pattern: `npx check-cucumber "**/*.feature" -d features`.
-- **Import failures exit 0.** A rejected import logs `✖️` and exits 0; a missing key logs `Cant send report, api key not set` and exits 0. Judge success by the output text (`Data sent to Testomat.io`), never the exit code.
-- **A partial import detaches everything else.** Importing a subset marks every test not in the payload as detached. Pass `--no-detached` for partial imports.
-- **Destructive flags need explicit confirmation first.** `--purge`/`--unsafe-clean-ids` regex-strip every `@S`/`@T`-shaped tag (may eat unrelated tags like `@Test1234`); `--clean-ids` removes this project's IDs; `pull` overwrites same-named files. Preflight: clean/committed git tree; `pull --dry-run` first; grep for near-miss tags before a purge.
-- **`Rule:` blocks crash the parser** (`TypeError: Cannot read properties of null (reading 'tags')`, exit 1). Scenarios must sit directly under `Feature:`.
-- **Do not pass options to the `push` subcommand.** A parsing quirk makes the root command swallow shared options (`-d`, `--sync`, `--update-ids`, `--check-ids`, …). Use the root form `check-cucumber "<glob>" [options]` for every import.
-- One source of truth per test — never double-import. A scenario synced here is automated in Testomat.io; don't also push it as markdown via check-tests.
-- Quote the glob so the shell doesn't expand it.
-
-## Testeiya workspace context
-
-- A workspace is the session cwd representing one project; metadata in `.testeiya/testeiya.json` (`{projectId, baseUrl, title}`). When `baseUrl` isn't `https://app.testomat.io`, export it as `TESTOMATIO_URL`.
-- `cli/src/workspace-model.ts` classifies a Cucumber repo as an automation workspace (`.feature` files + a cucumber config or `@cucumber/cucumber` dependency mark `hasAutomationConfig`).
-- So Testeiya's built-in pull omits `--export-automated` here: `.testeiya/manual-tests/` holds only manual markdown, and the `.feature` files stay the single source for automated ones. Keep it that way.
-- The built-in sync never picks up `features/` — feature-file sync is always an explicit check-cucumber run by the agent.
-
-### Token resolution
-
-check-cucumber reads only `TESTOMATIO` (a `tstmt_…` key; `.env` in the cwd is auto-loaded). Resolve in Testeiya's order:
-
-1. the managed session's project token;
-2. else the linked project's `apiKey` from the connected account;
-3. else the folder's own `.env` `TESTOMATIO`;
-4. else ask the user (Settings → Project → Project Reporting API key).
-
-### Manual vs automated
-
-- Each pulled markdown test carries `type: manual` or `type: automated`; a missing `type:` means manual.
-- Gherkin scenarios imported here land on the automated side — they are backed by step definitions.
-- Two exceptions import as manual: a `*.manual.feature` file (every scenario in it), and files created by `check-cucumber pull` (the pull exports the project's manual tests as Gherkin).
-- If a case already exists as a manual markdown test and the user automates it, bind them by putting the existing `@T…` ID on the scenario — don't import a duplicate. See `automate-manual-test-cases`.
-
-## Commands
-
-```bash
-npx check-cucumber "<glob>" [options]     # analyze + import (the push direction)
-npx check-cucumber pull [--dry-run]       # pull manual tests as .feature files (into cwd)
-```
-
-The glob resolves relative to `-d` (default cwd). `node_modules` is excluded automatically, but scope with `-d` on large repos anyway.
-
-### Import options (root command)
-
-| Flag | Meaning |
-|---|---|
-| `<glob>` (positional) | Required. `"**/*.feature"` for the whole tree |
-| `-d, --dir <dir>` | Scan root (default cwd). Scope to `features/` etc. |
-| `-e, --exclude <glob>` | Skip files: `-e "**/wip/*.feature"` |
-| `--sync` | Wait until the server finishes. Use in CI and whenever a next step depends on the import |
-| `-U, --update-ids` | Import, wait, then write `@S`/`@T` IDs back. Needs the key |
-| `--check-ids` | Exit 1 when any feature/scenario lacks an ID (CI guard); proceeds with the import when all present |
-| `--create` | Create tests/suites for IDs not found in the project |
-| `--no-detached` | Don't detach absent tests. Required for partial imports |
-| `--no-empty` | Delete suites left empty after import. Conflicts with `--keep-structure` |
-| `--keep-structure` | Force the source structure onto the project |
-| `-c, --codeceptjs` | CodeceptJS-BDD projects; accepted for compatibility, no payload change in 0.6.0 |
-| `--clean-ids` | **Destructive.** Remove this project's IDs (needs the key). Confirm first |
-| `--purge` / `--unsafe-clean-ids` | **Destructive.** Strip all `@S`/`@T`-shaped tags, no server check (no key needed). Confirm first |
-
-### Pull options
-
-- `--dry-run` — preview the file list without writing. Always run first.
-- `pull -d` is BROKEN in 0.6.0 (swallowed by the root command) — pull always writes to the cwd, so `cd` into the target dir before pulling.
-- Pull calls `GET {TESTOMATIO_URL}/api/test_data?api_key=…&with_files=true`, creates nested dirs, and overwrites same-named files.
-
-## Environment variables
-
-A `.env` in the cwd is auto-loaded (dotenv).
-
-| Variable | Purpose |
-|---|---|
-| `TESTOMATIO` | Project API key (`tstmt_…`). Required for import, IDs, pull |
-| `INPUT_TESTOMATIO-KEY` | Alternative key slot (GitHub Actions); takes precedence over `TESTOMATIO` |
-| `TESTOMATIO_URL` | Instance URL (default `https://app.testomat.io`). Set from `.testeiya/testeiya.json` `baseUrl` on self-hosted |
-| `TESTOMATIO_BRANCH` | Import into this branch; created if missing |
-| `TESTOMATIO_SUITE` | Import everything into an existing suite by ID (`@Sa1b2c3d4`) |
-| `TESTOMATIO_PREPEND_DIR` | Wrap imported files under a new top folder |
-| `TESTOMATIO_WORKDIR` | Rebase reported file paths to this directory |
-| `TESTOMATIO_LABELS` | Comma-separated labels on every imported test; `label:value` sets values. Alias `TESTOMATIO_SYNC_LABELS` |
-| `TESTOMATIO_NO_DETACHED` | `1` = same as `--no-detached` |
-| `TESTOMATIO_TITLE_IDS` | `1` = write test IDs into Scenario titles instead of tags |
-
-## Gherkin → Testomat.io mapping
-
-| Gherkin | Testomat.io | Notes |
-|---|---|---|
-| folder / `x.feature` file | suite hierarchy | folders and file names become parent suites |
-| `Feature:` | suite | feature tags travel with the suite; empty title = file skipped with an error |
-| `Scenario:` | test (automated) | full source block becomes the test body; empty title = scenario skipped |
-| `Scenario Outline:` + `Examples:` | ONE test | not expanded per row; the Examples table stays in the body |
-| tags (`@smoke`, `@severity:critical`) | tags on the test | sent without `@`; `@S`/`@T` ID tags are treated as sync IDs, not tags |
-| `Background:` | NOT imported | parses fine, but its steps appear in no test — keep critical context in scenarios |
-| `Rule:` | NOT supported | crashes the analyzer |
-| `And` / `But` | normalized | inherit the preceding Given/When/Then keyword |
-| `*.manual.feature` | manual tests | the marker for manual BDD cases kept in the repo |
-
-`--update-ids` write-back: IDs are inserted as tags — appended to an existing tag line, else a new tag line above `Feature:`/`Scenario:`, indentation preserved. Files carrying IDs from another project warn `Some tests have IDs from another project` and are left alone — clean with `--clean-ids` (old key) or a confirmed `--purge`.
-
-## Recipes
-
-From the workspace root, token in `.env` or env:
-
-```bash
-# First import, waiting for the server
-npx check-cucumber "**/*.feature" --sync
-
-# Import and write IDs back (the standard round-trip sync)
-npx check-cucumber "**/*.feature" --update-ids
-
-# CI guard — fail when IDs are missing
-npx check-cucumber "**/*.feature" --check-ids
-
-# Partial import of one directory, rest untouched
-npx check-cucumber "**/*.feature" -d features/checkout --no-detached
-
-# Import into a branch, with labels, excluding drafts
-TESTOMATIO_BRANCH="release-2.4" TESTOMATIO_LABELS="smoke,severity:high" \
-  npx check-cucumber "**/*.feature" -e "**/wip/*.feature" --sync
-
-# Self-hosted instance
-TESTOMATIO_URL="https://testomatio.example.com" npx check-cucumber "**/*.feature" --sync
-
-# Pull manual BDD tests into a dedicated directory (pull writes to cwd)
-mkdir -p features/manual && cd features/manual
-npx check-cucumber pull --dry-run
-npx check-cucumber pull
-
-# Re-import as a new project (confirm + commit first)
-npx check-cucumber "**/*.feature" --purge
-TESTOMATIO=<new-project-key> npx check-cucumber "**/*.feature" --update-ids
-```
-
-## Exit codes and troubleshooting
-
-Exit 1: `--check-ids` found missing IDs; `pull` without a key or with a failed request; the `Rule:` analyzer crash. Everything else — rejected imports, parse errors, a missing key on import — exits 0, so always read the output.
-
-| Symptom | Cause | Fix |
-|---|---|---|
-| Banner prints, nothing else, exit 0 | Positional glob missing | Add `"**/*.feature"` |
-| `Cant send report, api key not set` | `TESTOMATIO` unset | Resolve the token; the run parsed files but imported nothing |
-| `✖️ <server message>` after `Sending data…` | Server rejected the import (bad/foreign token) — exit still 0 | Verify the key matches this project |
-| `✖️ Error: Server cannot be reached` | Network / wrong `TESTOMATIO_URL` | Check the URL against `.testeiya/testeiya.json` `baseUrl` |
-| `TypeError: … (reading 'tags')` | A `Rule:` block | Flatten scenarios directly under `Feature:` |
-| `Errors :` listing `expected: #EOF, …` | Gherkin syntax error — that file is skipped, exit stays 0 | Fix the reported line; re-run |
-| `Total Scenarios skipped N` | Scenarios with empty titles | Give every scenario a title |
-| `N suites and M tests are missing test IDs!` (exit 1) | `--check-ids` failed | Run with `--update-ids` |
-| `Some tests have IDs from another project` | Foreign `@S`/`@T` tags | `--clean-ids` with the old key, or a confirmed `--purge` |
-| Tests unexpectedly detached | A partial import without `--no-detached` | Re-import the full tree; use `--no-detached` for partial runs |
-| Pull wrote files to the wrong place | `pull -d` not honored in 0.6.0 | `cd` into the target dir first |
-| Pull says `No files found on server` | The project has no manual tests to export | Nothing to pull; check the project kind |
-
-## Related skills
-
-- `check-tests` — the markdown/code counterpart; Testeiya's built-in sync path.
-- `sync-test-cases-with-tms` — markdown pull/push workflow details.
-- `testomatio-reporter` / `qa-e2e-tests-reporting` — report cucumber RUN RESULTS; check-cucumber only syncs definitions.
-- `scan-automation-project` — detect the framework before choosing a sync tool.
-- `automate-manual-test-cases` — bind existing manual cases to new scenarios by ID.
-- `qa-test-code-coverage` — map source files to imported test IDs.
-- `testomatio-mcp` — query the project's suites and tests directly.