@skyramp/mcp 0.4.2 → 0.4.3-rc.2

package/node_modules/playwright/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@skyramp/playwright",
-  "version": "1.58.2-skyramp.8.14.11",
+  "version": "1.58.2-skyramp.8.14.13",
   "description": "Skyramp's fork of Playwright with trace recording for UI test generation",
   "publishConfig": {
     "access": "public"

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@skyramp/mcp",
-  "version": "0.4.2",
+  "version": "0.4.3-rc.2",
   "main": "build/index.js",
   "exports": {
     ".": "./build/index.js",
@@ -71,12 +71,12 @@
   "dependencies": {
     "@modelcontextprotocol/sdk": "^1.24.3",
     "@playwright/test": "^1.55.0",
-    "@skyramp/skyramp": "1.3.46",
+    "@skyramp/skyramp": "1.3.47",
     "dockerode": "^5.0.0",
     "fast-glob": "^3.3.3",
     "js-yaml": "^4.1.1",
     "picomatch": "^4.0.5",
-    "playwright": "file:vendor/skyramp-playwright-1.58.2-skyramp.8.14.11.tgz",
+    "playwright": "file:vendor/skyramp-playwright-1.58.2-skyramp.8.14.13.tgz",
     "simple-git": "^3.30.0",
     "smol-toml": "^1.8.0",
     "ts-is-record": "^3.0.5",

package/plugin/prompts/code-reuse/hand-off.md

@@ -9,7 +9,11 @@ modularize → reuse chain. `buildModularizeFirstNextSteps` in
 routes assertion enhancement through the skill when skills are loaded and the
 legacy tool otherwise.
 
-## Enhance first
+## Page-object pass
+
+Call `skyramp_reuse_code` with {reuseArgs}. This is the page-object pass: follow its steps to completion, INCLUDING its verification loop (`skyramp_reuse_code` with `verify: true`, until it reports PASSED). A response starting "No reusable POM layer detected" also finishes this pass — continue immediately (do NOT retry). Do NOT call `skyramp_modularization` before this pass is finished.
+
+## Assertion enhancement
 
 {enhanceCall} — BEFORE modularization, while the file's selectors are still inline.
 
@@ -28,3 +32,11 @@ three sub-steps, STRICTLY SEQUENTIAL (never in the same tool-call batch)
 ## Ordering without the enhancer
 
 two sub-steps, STRICTLY SEQUENTIAL (never in the same tool-call batch), BOTH BEFORE `skyramp_enhance_assertions`
+
+## Page objects with the enhancer
+
+four sub-steps, STRICTLY SEQUENTIAL (never in the same tool-call batch)
+
+## Page objects without the enhancer
+
+three sub-steps, STRICTLY SEQUENTIAL (never in the same tool-call batch), ALL THREE BEFORE `skyramp_enhance_assertions`

package/plugin/prompts/plan-tests.md

@@ -18,7 +18,7 @@ Do the steps in this order.
 3. **Write the changes.** List every change, one line each, with a short id and where you read it. Write the list in your reply before you go on.
    Keep each line through the rest of the procedure. Do not fold a change into another one or drop it because no test covers it.
    For each edit in the diff, write one line: what it makes different for a user or a caller.
-   For each requirement the title, the description or a requirements file states, write one line, even when no edit in the diff serves it.
+   For each requirement the title, the description or a requirements file states, write one line, even when no edit in the diff serves it. If the requirement is an item of a numbered or bulleted list, put its number in the line's `source`: `spec:<path>#11` or `pr-description#3`.
 4. **Declare the test cases each request must refuse.**
    - For each input a request takes, declare one test case with a value the request must reject. Declare it even when the code does not reject that value today.
    - For each list a request takes, declare one test case that is valid except for one item in the list. Give the test case one `param` and one `value`: the invalid item. The step that sends the test case carries the rest of the list.
@@ -48,7 +48,7 @@ Do the steps in this order.
    If a state comes from time passing, create the record with the nearest allowed deadline and wait for it.
 10. **Walk each page behaviour once, as its test will run.** Start at login, do the steps of the behaviour, run `browser_blueprint` on each page you use, and export the trace when the flow ends. Name only elements from those captures. Do not try other values or read messages; the recording is the test.
 11. **Declare each planned test.** The tool schema says what goes in each field, `defects` included.
-    - A test that expects a rejection sends an accepted request first and asserts it succeeds. That request and its assertion are the test's setup.
+    - A test that expects a rejection sends an accepted request first. That request is the test's setup.
     - Two planned tests on one endpoint each say how they differ.
     - A test that expects to fail proves one test case: its first assertion after setup is the one the defect breaks, and a red step stops every step after it. Declare one such test per test case the defect breaks, so each test case reports on its own.
     - Accepted test cases may share one test that expects to pass.

package/plugin/skills/enhance-assertions/reference/shared-rules.md

@@ -51,6 +51,7 @@ Every test needs at least one assertion that fails when the behaviour it claims
 - Name the behaviour, then ask what value in the response changes when it breaks. Assert that value exactly.
 - When the test claims a state change ("Updates X", "Increments Y", "rejects Z"), the assertion must prove the change, not merely that the call succeeded.
 - When the PR changed the behaviour, the expected value is the one the diff, the PR description, or the referenced spec establishes — even when the running service still returns the old value. The test is expected to fail until the code is fixed.
+- A request the test sends before the request under test is setup. Assert only that the setup request was accepted: its status code, and its error field if the API returns errors with a success status. Add no other assertion to it.
 
 ```javascript
 // "PATCH /orders applies the coupon discount" — the discount is the behaviour.