@oriro/orirocli 0.1.9 → 0.1.11

package/skills/craft/playwright-cli/references/test-generation.md

@@ -1,134 +1,134 @@
-# Test Generation
-
-Generate Playwright test code automatically as you interact with the browser.
-
-## How It Works
-
-Every action you perform with `playwright-cli` generates corresponding Playwright TypeScript code.
-This code appears in the output and can be copied directly into your test files.
-
-## Example Workflow
-
-```bash
-# Start a session
-playwright-cli open https://example.com/login
-
-# Take a snapshot to see elements
-playwright-cli snapshot
-# Output shows: e1 [textbox "Email"], e2 [textbox "Password"], e3 [button "Sign In"]
-
-# Fill form fields - generates code automatically
-playwright-cli fill e1 "<email>"
-# Ran Playwright code:
-# await page.getByRole('textbox', { name: 'Email' }).fill('<email>');
-
-playwright-cli fill e2 "password123"
-# Ran Playwright code:
-# await page.getByRole('textbox', { name: 'Password' }).fill('password123');
-
-playwright-cli click e3
-# Ran Playwright code:
-# await page.getByRole('button', { name: 'Sign In' }).click();
-```
-
-## Building a Test File
-
-Collect the generated code into a Playwright test:
-
-```typescript
-import { test, expect } from "@playwright/test";
-
-test("login flow", async ({ page }) => {
-  // Generated code from playwright-cli session:
-  await page.goto("https://example.com/login");
-  await page.getByRole("textbox", { name: "Email" }).fill("<email>");
-  await page.getByRole("textbox", { name: "Password" }).fill("password123");
-  await page.getByRole("button", { name: "Sign In" }).click();
-
-  // Add assertions
-  await expect(page).toHaveURL(/.*dashboard/);
-});
-```
-
-## Best Practices
-
-### 1. Use Semantic Locators
-
-The generated code uses role-based locators when possible, which are more resilient:
-
-```typescript
-// Generated (good - semantic)
-await page.getByRole("button", { name: "Submit" }).click();
-
-// Avoid (fragile - CSS selectors)
-await page.locator("#submit-btn").click();
-```
-
-### 2. Explore Before Recording
-
-Take snapshots to understand the page structure before recording actions:
-
-```bash
-playwright-cli open https://example.com
-playwright-cli snapshot
-# Review the element structure
-playwright-cli click e5
-```
-
-### 3. Add Assertions Manually
-
-Generated code captures actions but not assertions. Add expectations in your test using one of the recommended matchers:
-
-- `toBeVisible()` — element is rendered and visible
-- `toHaveText(text)` — element text content matches
-- `toHaveValue(value) / toBeEmpty()` — input/select value matches
-- `toBeChecked() / toBeUnchecked()` — checkbox state matches
-- `toMatchAriaSnapshot(snapshot)` — page (or locator) matches a partial accessibility snapshot
-
-Use `playwright-cli generate-locator <target>` to produce the locator expression for the assertion, and the snapshot/eval commands to capture the expected value.
-
-When asserting text content, make sure that generated locator does not contain text from the element itself. `getByTestId()` or `getByLabel()` usually work well with asserting text. When locator is text-based, prefer `toBeVisible()` instead.
-
-Snapshot to be matched does not have to contain all the information - only capture what's necessary for the assertion. You can use regular expressions for unstable values.
-
-```bash
-# Get a stable locator for an element ref to use in the assertion
-playwright-cli --raw generate-locator e5
-# getByRole('button', { name: 'Submit' })
-
-# Capture expected text content for toHaveText
-playwright-cli --raw eval "el => el.textContent" e5
-
-# Capture expected input value for toHaveValue/toBeEmpty
-playwright-cli --raw eval "el => el.value" e5
-
-# Capture expected aria snapshot for toMatchAriaSnapshot/toBeChecked
-# (whole page, or use a ref to scope to a region)
-playwright-cli --raw snapshot
-playwright-cli --raw snapshot e5
-```
-
-```typescript
-// Generated action
-await page.getByRole("button", { name: "Submit" }).click();
-
-// Manual assertions using the outputs above:
-await expect(page.getByRole("alert", { name: "Success" })).toBeVisible();
-await expect(page.getByTestId("main-header")).toHaveText("Welcome, user");
-await expect(page.getByRole("textbox", { name: "Email" })).toHaveValue("<email>");
-await expect(page.getByRole("checkbox", { name: "Enable notifications" })).toBeChecked();
-
-// toMatchAriaSnapshot on the whole page, finds a matching region
-await expect(page).toMatchAriaSnapshot(`
-  - heading "Welcome, user"
-  - link /\\d+ new messages?/
-  - button "Sign out"
-`);
-
-// toMatchAriaSnapshot scoped to a region
-await expect(page.getByRole("navigation")).toMatchAriaSnapshot(`
-  - link "Home"
-  - link /\\d+ new messages?/
-  - link "Profile"
-`);
-```
+# Test Generation
+
+Generate Playwright test code automatically as you interact with the browser.
+
+## How It Works
+
+Every action you perform with `playwright-cli` generates corresponding Playwright TypeScript code.
+This code appears in the output and can be copied directly into your test files.
+
+## Example Workflow
+
+```bash
+# Start a session
+playwright-cli open https://example.com/login
+
+# Take a snapshot to see elements
+playwright-cli snapshot
+# Output shows: e1 [textbox "Email"], e2 [textbox "Password"], e3 [button "Sign In"]
+
+# Fill form fields - generates code automatically
+playwright-cli fill e1 "<email>"
+# Ran Playwright code:
+# await page.getByRole('textbox', { name: 'Email' }).fill('<email>');
+
+playwright-cli fill e2 "password123"
+# Ran Playwright code:
+# await page.getByRole('textbox', { name: 'Password' }).fill('password123');
+
+playwright-cli click e3
+# Ran Playwright code:
+# await page.getByRole('button', { name: 'Sign In' }).click();
+```
+
+## Building a Test File
+
+Collect the generated code into a Playwright test:
+
+```typescript
+import { test, expect } from "@playwright/test";
+
+test("login flow", async ({ page }) => {
+  // Generated code from playwright-cli session:
+  await page.goto("https://example.com/login");
+  await page.getByRole("textbox", { name: "Email" }).fill("<email>");
+  await page.getByRole("textbox", { name: "Password" }).fill("password123");
+  await page.getByRole("button", { name: "Sign In" }).click();
+
+  // Add assertions
+  await expect(page).toHaveURL(/.*dashboard/);
+});
+```
+
+## Best Practices
+
+### 1. Use Semantic Locators
+
+The generated code uses role-based locators when possible, which are more resilient:
+
+```typescript
+// Generated (good - semantic)
+await page.getByRole("button", { name: "Submit" }).click();
+
+// Avoid (fragile - CSS selectors)
+await page.locator("#submit-btn").click();
+```
+
+### 2. Explore Before Recording
+
+Take snapshots to understand the page structure before recording actions:
+
+```bash
+playwright-cli open https://example.com
+playwright-cli snapshot
+# Review the element structure
+playwright-cli click e5
+```
+
+### 3. Add Assertions Manually
+
+Generated code captures actions but not assertions. Add expectations in your test using one of the recommended matchers:
+
+- `toBeVisible()` — element is rendered and visible
+- `toHaveText(text)` — element text content matches
+- `toHaveValue(value) / toBeEmpty()` — input/select value matches
+- `toBeChecked() / toBeUnchecked()` — checkbox state matches
+- `toMatchAriaSnapshot(snapshot)` — page (or locator) matches a partial accessibility snapshot
+
+Use `playwright-cli generate-locator <target>` to produce the locator expression for the assertion, and the snapshot/eval commands to capture the expected value.
+
+When asserting text content, make sure that generated locator does not contain text from the element itself. `getByTestId()` or `getByLabel()` usually work well with asserting text. When locator is text-based, prefer `toBeVisible()` instead.
+
+Snapshot to be matched does not have to contain all the information - only capture what's necessary for the assertion. You can use regular expressions for unstable values.
+
+```bash
+# Get a stable locator for an element ref to use in the assertion
+playwright-cli --raw generate-locator e5
+# getByRole('button', { name: 'Submit' })
+
+# Capture expected text content for toHaveText
+playwright-cli --raw eval "el => el.textContent" e5
+
+# Capture expected input value for toHaveValue/toBeEmpty
+playwright-cli --raw eval "el => el.value" e5
+
+# Capture expected aria snapshot for toMatchAriaSnapshot/toBeChecked
+# (whole page, or use a ref to scope to a region)
+playwright-cli --raw snapshot
+playwright-cli --raw snapshot e5
+```
+
+```typescript
+// Generated action
+await page.getByRole("button", { name: "Submit" }).click();
+
+// Manual assertions using the outputs above:
+await expect(page.getByRole("alert", { name: "Success" })).toBeVisible();
+await expect(page.getByTestId("main-header")).toHaveText("Welcome, user");
+await expect(page.getByRole("textbox", { name: "Email" })).toHaveValue("<email>");
+await expect(page.getByRole("checkbox", { name: "Enable notifications" })).toBeChecked();
+
+// toMatchAriaSnapshot on the whole page, finds a matching region
+await expect(page).toMatchAriaSnapshot(`
+  - heading "Welcome, user"
+  - link /\\d+ new messages?/
+  - button "Sign out"
+`);
+
+// toMatchAriaSnapshot scoped to a region
+await expect(page.getByRole("navigation")).toMatchAriaSnapshot(`
+  - link "Home"
+  - link /\\d+ new messages?/
+  - link "Profile"
+`);
+```

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

@@ -1,142 +1,142 @@
-# 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
+# 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