@skyramp/mcp 0.4.3 → 0.4.4-rc.1

package/plugin/skills/enhance-assertions/reference/ui.md

@@ -126,7 +126,7 @@ if (await existingSecret.isVisible().catch(() => false)) {
 
 Before editing `$2`, you must output a `<thinking>` block. It states the behaviour each test evaluates, then works through the rules for the items that behaviour depends on, so no rule that applies is overlooked. The JSON array should match the template below — every assertion category and every rule title under it must appear as a key, with `[]` where the rule does not apply.
 
-1. For each test in scope, name the behaviour it evaluates in one line, taken from the recommendation it came from, and name the page where that behaviour shows. Generated specs are usually named `testUi`, which claims nothing — use the name only when it is specific enough to add something.
+1. For each test in scope, name the behaviour it evaluates in one line, taken from the recommendation it came from, and name the page where that behaviour shows. A generated spec may carry a title that names its behaviour — trust that title when it does. A spec still named `testUi` claims nothing, so use the name only when it is specific enough to add something.
 2. Selector inventory — list every selector already present in `$2` (`data-testid`, role + name, text, label, etc.). New assertions may use only selectors from this list. An assertion the recorder dropped because it failed during recording may use the selector of the element named in that recording's blueprint capture. Do not invent `data-testid` values, role names, or aria attributes. Also note captured network responses, repeated element patterns, exact rendered text/value/attribute from trace/source, and existing `toBeVisible()` assertions whose exact text is knowable.
 3. Process — Replay → Identify → Fix or Add — walk through these three steps explicitly.
    a. Replay the scenario mentally. At each state-changing action (form submit, item add/edit/delete), ask: "What is the EXPECTED outcome based on the action performed?"
@@ -206,7 +206,7 @@ expect(trigger).to_be_focused()
 When the PR changes how an element looks or where it sits (colour, class, size, `flex-direction`, a moved block), assert the changed property on the element that OWNS it — `flex-direction` belongs to the flex container, not the clicked child, and an order check needs both compared elements. Use a selector already in the file; if the owner has none, report a recording gap in your `<thinking>` block — do not invent one or screenshot it.
 
 - Colour / class: a class assertion recorded at capture is already written as a bounded regex (`toHaveClass(/(^|\s)bg-blue-600(\s|$)/)`) — leave it as generated. Use `toContainClass('bg-blue-600')` only for a class assertion you add yourself (1.52+; it matches one token, unlike a bare `/bg-blue-600/` which also passes on `hover:bg-blue-600`). For a style, `toHaveCSS('background-color', <the value the app computes>)` — take it from the app, do not convert the diff's hex: Tailwind v4 serializes `oklch(...)`, not `rgb(...)`.
-- Order: compare both elements' `boundingBox()` on the changed axis (holds for `flex-direction` / `order` / `dir` / grid); `toHaveCSS('flex-direction', 'row-reverse')` only when the container is `display: flex` with an unconditional class.
+- Order: an order assertion recorded at capture (`browser_assert` type `order`) is already in the file as two `boundingBox()` reads compared on one axis (inside `expect(async () => …).toPass()` in TS/JS) — leave it as generated. When none was recorded, add that comparison on the changed axis (holds for `flex-direction` / `order` / `dir` / grid / reordered markup): wait for both elements, read each one's box (`const aBox = await a.boundingBox()`), then compare the boxes' `x` (left/right) or `y` (above/below), e.g. `expect(aBox.x).toBeLessThan(bBox.x)` for "a left of b" — a locator itself has no `.x`; `toHaveCSS('flex-direction', 'row-reverse')` only when the container is `display: flex` with an unconditional class.
 - Size: `toHaveCSS('width', <the computed width>)`. Name the value; never copy a `...` or `/…/` placeholder.
 
 A `toHaveScreenshot()` baseline is right only for a look no property expresses (image, gradient, chart) or to refresh an already-committed baseline (SKYR-4298) — never a new one for a colour, class or order change.

package/plugin/skills/fix-test-import-errors/SKILL.md

@@ -56,7 +56,7 @@ python3 -m robot <robot-file>.robot
 
 Inspect package.json before installing anything:
 
-- If a required package is already declared, install from the existing manifest without changing its version.
+- If a required package is already declared, install from the existing manifest without changing its version, unless `skyramp_execute_test` refuses the run over an older Skyramp SDK. Then do what the refusal says.
 - If no JavaScript/TypeScript manifest exists at the test project root, create `package.json` with only `{ "devDependencies": {} }` before adding the missing approved package.
 - If an approved package is missing, add it with the repository's package manager as a devDependency. For npm, use `npm install --save-dev --legacy-peer-deps <package>`.
 - Never add, upgrade, or downgrade Playwright or @playwright/test when either is already declared. If its version is incompatible with Skyramp, report the conflict.