pi-ui-extend 1.0.42 → 1.0.45

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

@@ -1,142 +0,0 @@
-# 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
-# Choose a unique name, record it as owned by this task, and start the session.
-SESSION="testgen-login-$(date +%s)-$$"
-playwright-cli -s="$SESSION" open https://example.com/login
-
-# Take a snapshot to see elements
-playwright-cli -s="$SESSION" snapshot
-# Output shows: e1 [textbox "Email"], e2 [textbox "Password"], e3 [button "Sign In"]
-
-# Fill form fields - generates code automatically
-playwright-cli -s="$SESSION" fill e1 "user@example.com"
-# Ran Playwright code:
-# await page.getByRole('textbox', { name: 'Email' }).fill('user@example.com');
-
-playwright-cli -s="$SESSION" fill e2 "password123"
-# Ran Playwright code:
-# await page.getByRole('textbox', { name: 'Password' }).fill('password123');
-
-playwright-cli -s="$SESSION" click e3
-# Ran Playwright code:
-# await page.getByRole('button', { name: 'Sign In' }).click();
-
-# Mandatory on success and errors.
-playwright-cli -s="$SESSION" close
-playwright-cli list  # verify $SESSION is absent
-```
-
-## 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('user@example.com');
-  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
-SESSION="testgen-explore-$(date +%s)-$$"
-playwright-cli -s="$SESSION" open https://example.com
-playwright-cli -s="$SESSION" snapshot
-# Review the element structure
-playwright-cli -s="$SESSION" click e5
-playwright-cli -s="$SESSION" close
-playwright-cli list  # verify $SESSION is absent
-```
-
-### 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('user@example.com');
-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/playwright-cli/references/tracing.md

@@ -1,154 +0,0 @@
-# Tracing
-
-Capture detailed execution traces for debugging and analysis. Traces include DOM snapshots, screenshots, network activity, and console logs.
-
-## Basic Usage
-
-```bash
-SESSION="trace-basic-$(date +%s)-$$"  # record as owned before first command
-# Start trace recording
-playwright-cli -s="$SESSION" tracing-start
-
-# Perform actions
-playwright-cli -s="$SESSION" open https://example.com
-playwright-cli -s="$SESSION" click e1
-playwright-cli -s="$SESSION" fill e2 "test"
-
-# Stop trace recording
-playwright-cli -s="$SESSION" tracing-stop
-playwright-cli -s="$SESSION" close
-playwright-cli list  # verify $SESSION is absent
-```
-
-## 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
-SESSION="trace-failure-$(date +%s)-$$"
-playwright-cli -s="$SESSION" tracing-start
-playwright-cli -s="$SESSION" open https://app.example.com
-
-# This click fails - why?
-playwright-cli -s="$SESSION" click e5
-
-playwright-cli -s="$SESSION" tracing-stop
-playwright-cli -s="$SESSION" close
-playwright-cli list  # verify $SESSION is absent
-# Open trace to see DOM state when click was attempted
-```
-
-### Analyzing Performance
-
-```bash
-SESSION="trace-performance-$(date +%s)-$$"
-playwright-cli -s="$SESSION" tracing-start
-playwright-cli -s="$SESSION" open https://slow-site.com
-playwright-cli -s="$SESSION" tracing-stop
-playwright-cli -s="$SESSION" close
-playwright-cli list  # verify $SESSION is absent
-
-# View network waterfall to identify slow resources
-```
-
-### Capturing Evidence
-
-```bash
-# Record a complete user flow for documentation
-SESSION="trace-evidence-$(date +%s)-$$"
-playwright-cli -s="$SESSION" tracing-start
-
-playwright-cli -s="$SESSION" open https://app.example.com/checkout
-playwright-cli -s="$SESSION" fill e1 "4111111111111111"
-playwright-cli -s="$SESSION" fill e2 "12/25"
-playwright-cli -s="$SESSION" fill e3 "123"
-playwright-cli -s="$SESSION" click e4
-
-playwright-cli -s="$SESSION" tracing-stop
-playwright-cli -s="$SESSION" close
-playwright-cli list  # verify $SESSION is absent
-# 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
-SESSION="trace-flow-$(date +%s)-$$"
-playwright-cli -s="$SESSION" tracing-start
-playwright-cli -s="$SESSION" open https://example.com
-# ... all steps leading to the issue ...
-playwright-cli -s="$SESSION" tracing-stop
-playwright-cli -s="$SESSION" close
-playwright-cli list  # verify $SESSION is absent
-```
-
-### 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,147 +0,0 @@
-# Video Recording
-
-Capture browser automation sessions as video for debugging, documentation, or verification. Produces WebM (VP8/VP9 codec).
-
-## Basic Recording
-
-```bash
-# Choose a unique name and record it as owned before opening.
-SESSION="video-demo-$(date +%s)-$$"
-# Open browser first
-playwright-cli -s="$SESSION" open
-
-# Start recording
-playwright-cli -s="$SESSION" video-start demo.webm
-
-# Add a chapter marker for section transitions
-playwright-cli -s="$SESSION" video-chapter "Getting Started" --description="Opening the homepage" --duration=2000
-
-# Navigate and perform actions
-playwright-cli -s="$SESSION" goto https://example.com
-playwright-cli -s="$SESSION" snapshot
-playwright-cli -s="$SESSION" click e1
-
-# Add another chapter
-playwright-cli -s="$SESSION" video-chapter "Filling Form" --description="Entering test data" --duration=2000
-playwright-cli -s="$SESSION" fill e2 "test input"
-
-# Stop and save
-playwright-cli -s="$SESSION" video-stop
-playwright-cli -s="$SESSION" close
-playwright-cli list  # verify $SESSION is absent
-```
-
-## 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 pulling 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) In the task-owned unique session, use `playwright-cli -s="$SESSION" run-code --filename your-script.js`, then close that exact session and verify it is absent from `playwright-cli list`, including on errors.
-
-**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/spec-wiki/SKILL.md

@@ -1,55 +0,0 @@
----
-name: spec-wiki
-description: >-
-  Use this skill for behavior-changing project work or behavioral specs/contracts:
-  write/verify as-is/change behavior from code/tests, find requirements, detect
-  spec-code drift/impact, or maintain a spec wiki. Skip mechanical/refactor/
-  debug-only changes and code-only impact with no contract/doc work. Not for
-  runbooks or general docs.
----
-
-# Spec Wiki
-
-Primary specs are the source of truth. `.spec-wiki/` is only derived navigation
-and freshness metadata. Specs may live anywhere and use any structure.
-
-## Router
-
-Choose one mode. Read only the referenced file unless the task expands.
-
-- One spec: create/update/check/verify → `references/focused-spec.md`.
-- Find/answer from specs → `references/query.md`.
-- First discovery/index build → `references/bootstrap.md`.
-- Refresh/audit/impact/repair → `references/maintenance.md`.
-- Exact CLI/state/config details → `references/index-schema.md`.
-
-Do not bootstrap or scan the whole repository for a narrow single-spec task.
-Do not load all specs when the wiki can narrow retrieval.
-
-## Invariants
-
-- Never invent spec behavior; separate code/tests/docs evidence from inference.
-- Distinguish current (`as-is`) from intended (`change`) behavior.
-- Never treat generated indexes, overviews, catalogs, or TOCs as primary specs.
-- Keep document lifecycle separate from spec type: active/proposed/historical/
-  superseded is not the same question as as-is/change.
-- Never infer semantic correctness from hashes alone. Changed inputs require
-  verification, not automatic rewriting.
-- After a material production-behavior change, run the post-change checkpoint in
-  `references/maintenance.md` before declaring the task complete.
-- Do not force specs into a new layout or template.
-- Do not change production code unless the user asked for implementation.
-
-## Bundled CLI
-
-When wiki state is involved, use:
-
-```bash
-python3 <SKILL_DIR>/scripts/spec_wiki.py --root <PROJECT_ROOT> <command>
-```
-
-Commands: `discover`, `record`, `verify`, `relate`, `search`, `changes`, `impact`,
-`remove`, `status`, `audit`, `affected`, `render`, `validate`.
-
-The CLI owns deterministic discovery, relationships, hashes, state, and
-rendering. The agent owns semantic classification and verification.

package/skills/spec-wiki/evals/evals.json

@@ -1,132 +0,0 @@
-{
-  "skill_name": "spec-wiki",
-  "evals": [
-    {
-      "id": 1,
-      "prompt": "We are going to change the session refresh contract in the supplied fixture: a transient token-load failure should be retried exactly once, while a second failure must still propagate. Before implementation, inspect the fixture code and tests and write a compact change spec named session-refresh-spec.md in the run output directory. Do not modify production code and do not bootstrap a repository-wide spec wiki for this narrow task.",
-      "expected_output": "A focused Change spec grounded in the fixture's current code/tests, with intended retry behavior, edge cases, verification, evidence/unknowns, and no production-code or wiki-state mutation.",
-      "files": [
-        "evals/files/focused/src/session.ts",
-        "evals/files/focused/tests/session.test.ts"
-      ],
-      "expectations": [
-        "The output contains a spec explicitly identified as Change/intended behavior.",
-        "The spec states that current fixture behavior performs one token-load attempt with no retry.",
-        "The intended behavior retries a transient token-load failure exactly once and propagates a second failure.",
-        "The spec contains a concrete verification path covering success, retry-success, and retry-failure behavior.",
-        "The spec explicitly distinguishes confirmed code/test evidence from inference or unknowns instead of presenting every claim at the same confidence level.",
-        "The run does not modify fixture production code and does not create .spec-wiki state for this narrow task.",
-        "The with-skill run reads focused-spec.md and does not read bootstrap.md, maintenance.md, query.md, or index-schema.md unless the task actually expands to need them."
-      ]
-    },
-    {
-      "id": 2,
-      "prompt": "In the supplied fixture, answer this narrowly from the project's primary specifications: what are the cancellation semantics for background jobs, and which primary spec defines them? There is also an overview and a retry document nearby. Do not build a wiki and do not treat an overview/index summary as primary evidence. Include source paths in the answer.",
-      "expected_output": "A concise answer grounded in the cancellation primary spec, distinguishing it from the overview and unrelated retry spec, without creating wiki state.",
-      "files": [
-        "evals/files/query/docs/spec-overview.md",
-        "evals/files/query/features/jobs/cancellation-contract.md",
-        "evals/files/query/features/jobs/retry-spec.md",
-        "evals/files/query/docs/how-to-run-jobs.md"
-      ],
-      "expectations": [
-        "The answer identifies features/jobs/cancellation-contract.md as the primary source.",
-        "The answer states that cancellation is idempotent, running jobs become cancelled, and already terminal jobs remain terminal.",
-        "The overview is not cited as primary evidence for the behavior claim.",
-        "The run does not create .spec-wiki state or perform repository-wide bootstrap.",
-        "The with-skill run reads query.md and does not read bootstrap.md or maintenance.md unless the task actually expands to need them."
-      ]
-    },
-    {
-      "id": 3,
-      "prompt": "Bootstrap a Spec Wiki for the supplied standalone fixture. Its specification knowledge is intentionally scattered across different folders and formats, and docs/overview.md is only a hand-written catalog. Build the wiki under the fixture root, classify the useful documents, exclude the catalog and user guide from primary specs, and report what was indexed. Do not edit any primary source document.",
-      "expected_output": "A schema-v2 .spec-wiki index/state containing the payment requirements and RFC as primary spec knowledge, with lifecycle recorded, overview classified as meta-index, guide excluded from primary specs, and bootstrap entries left unverified until a separate semantic code/test review; primary sources remain unchanged.",
-      "files": [
-        "evals/files/bootstrap/requirements/payment-behavior.md",
-        "evals/files/bootstrap/architecture/rfc-007.md",
-        "evals/files/bootstrap/docs/overview.md",
-        "evals/files/bootstrap/docs/how-to-pay.md",
-        "evals/files/bootstrap/src/payments.ts",
-        "evals/files/bootstrap/tests/payments.test.ts"
-      ],
-      "expectations": [
-        "The generated wiki indexes requirements/payment-behavior.md as primary spec knowledge.",
-        "The generated wiki indexes architecture/rfc-007.md as primary spec knowledge despite the different directory/convention.",
-        "docs/overview.md is classified as meta-index or otherwise excluded from primary specs.",
-        "docs/how-to-pay.md is classified as guide/other or otherwise excluded from primary specs.",
-        "Production source and test files are treated as evidence/relationships, not as primary specification documents themselves.",
-        "Bootstrap classification does not create a semantic verification baseline: newly indexed primary specs are unverified rather than fresh.",
-        "Primary entries record lifecycle separately from as-is/change type, so current requirements and an intended RFC are not forced into the same precedence state.",
-        "The generated state uses schemaVersion 2 and the generated index is a compact routing projection rather than the primary source of detailed claims.",
-        "The generated index is derived navigation and primary source documents are not modified.",
-        "The with-skill run reads bootstrap.md; it reads index-schema.md only if exact CLI/state details are needed and does not read focused-spec.md/query.md/maintenance.md without a concrete need."
-      ]
-    },
-    {
-      "id": 4,
-      "prompt": "Maintenance scenario: initialize the supplied fixture as a Git repo and commit only docs/session-refresh.md and src/session.ts as the baseline; keep incoming/refresh-worker.ts outside that baseline. Build the minimal Spec Wiki entry for the existing active as-is session refresh contract and semantically verify it. Then move incoming/refresh-worker.ts to src/refresh-worker.ts as the only post-baseline production change. Run the required post-change maintenance checkpoint. The new worker implements the same background refresh retry contract but is not yet in the spec's tracked relations. Do not change behavioral claims unless evidence shows drift. Finish with a valid rendered wiki and report the impact/repair steps.",
-      "expected_output": "The maintenance workflow notices that the new worker has no known relation, semantically associates it with the existing session refresh spec despite an initially empty direct affected result for that path, repairs the durable relation, verifies the unchanged contract against both implementation surfaces, and ends fresh.",
-      "files": [
-        "evals/files/maintenance/new-relation/docs/session-refresh.md",
-        "evals/files/maintenance/new-relation/src/session.ts",
-        "evals/files/maintenance/new-relation/incoming/refresh-worker.ts"
-      ],
-      "expectations": [
-        "The post-change workflow runs impact or equivalent task-scoped coverage analysis and treats src/refresh-worker.ts as an uncovered changed path before relation repair.",
-        "The workflow performs semantic spec retrieval/inspection even though the new path has no pre-existing affected relation.",
-        "The final primary entry for docs/session-refresh.md tracks src/refresh-worker.ts as a durable implementation relation.",
-        "The behavioral retry contract is not rewritten merely because a new implementation file appeared; it remains exactly-once retry with second failure propagation.",
-        "After relation repair the old verification baseline is not trusted until verify is run again.",
-        "Final status reports the current session refresh spec fresh with no unresolved relation drift."
-      ]
-    },
-    {
-      "id": 5,
-      "prompt": "Maintenance scenario: initialize the supplied fixture as Git, commit docs/old-job-contract.md and src/job.ts, record that document as an active as-is primary spec, and verify it. Then perform `git mv docs/old-job-contract.md contracts/job-cancellation.md` without changing its behavior. Run Spec Wiki maintenance for the move. Preserve the contract's lifecycle/type/summary/implementation relation, and do not leave duplicate current entries.",
-      "expected_output": "The move is recognized as an old missing tracked source plus a new document candidate; the new path is recorded and verified before the old metadata is removed, leaving one fresh active primary spec at the new path.",
-      "files": [
-        "evals/files/maintenance/move/docs/old-job-contract.md",
-        "evals/files/maintenance/move/src/job.ts"
-      ],
-      "expectations": [
-        "Impact/change inspection recognizes the old tracked primary path as missing/moved and the new path as a document requiring classification.",
-        "contracts/job-cancellation.md becomes the active as-is primary entry with the src/job.ts relation preserved.",
-        "The new path is verified before or as part of completing the move workflow.",
-        "docs/old-job-contract.md metadata is removed only after the new source has been recorded.",
-        "Final state contains no duplicate current primary entry for the old path and validates cleanly."
-      ]
-    },
-    {
-      "id": 6,
-      "prompt": "Maintenance scenario: initialize Git and commit only src/capture.ts as the baseline. Keep incoming/capture.txt outside the baseline, then move it to notes/capture.txt as a new document in the current task. Run the Spec Wiki post-change maintenance checkpoint. The text file intentionally has a neutral filename, no headings, and no path hints; only its contents state the current idempotency contract. Do not discard it because of a zero/below-threshold heuristic score. Inspect implementation evidence to determine the durable relation.",
-      "expected_output": "The changed-document path is inspected regardless of score, semantically classified as a current primary spec, related to src/capture.ts, verified, rendered, and validated.",
-      "files": [
-        "evals/files/maintenance/low-signal/src/capture.ts",
-        "evals/files/maintenance/low-signal/incoming/capture.txt"
-      ],
-      "expectations": [
-        "The new notes/capture.txt is surfaced for classification even though its discovery score is zero or below the normal threshold.",
-        "The document is classified from its contents rather than its location/name and becomes an as-is active primary spec.",
-        "The primary entry tracks src/capture.ts and has a non-empty semantic summary/topic metadata.",
-        "The entry is verified only after inspecting the implementation evidence, then the wiki renders/validates cleanly."
-      ]
-    },
-    {
-      "id": 7,
-      "prompt": "Negative maintenance control: initialize Git and commit docs/auth-contract.md plus src/auth.ts. Record/verify the active auth spec. Then move incoming/telemetry-format.ts to src/telemetry-format.ts as the only new production file. Run the post-change checkpoint. The telemetry formatting helper is unrelated to authentication. Perform the mandatory uncovered-path semantic sweep, but do not invent a spec relation or modify the auth contract just to make coverage non-empty.",
-      "expected_output": "The new telemetry path is reported as uncovered, the semantic sweep explicitly concludes it does not affect the auth contract, no false relation/spec edit is introduced, and the existing auth spec remains valid/fresh.",
-      "files": [
-        "evals/files/maintenance/no-impact/docs/auth-contract.md",
-        "evals/files/maintenance/no-impact/src/auth.ts",
-        "evals/files/maintenance/no-impact/incoming/telemetry-format.ts"
-      ],
-      "expectations": [
-        "The workflow does not stop at an empty affected result; it semantically inspects the uncovered telemetry path.",
-        "No inferred relation from docs/auth-contract.md to src/telemetry-format.ts is added.",
-        "The auth spec's behavioral claims are not modified.",
-        "The final report records a semantic no-impact decision rather than pretending every changed path must belong to a spec.",
-        "The existing auth spec remains fresh and state validates cleanly."
-      ]
-    }
-  ]
-}

package/skills/spec-wiki/evals/files/bootstrap/architecture/rfc-007.md

@@ -1,14 +0,0 @@
-# RFC 007 — Payment timeout contract
-
-## Goal
-
-Define the intended timeout contract for payment capture.
-
-## Behavior
-
-Capture requests should time out after 10 seconds and return a retryable timeout
-error without claiming that the payment failed at the provider.
-
-## Non-goals
-
-This document does not define provider reconciliation.

package/skills/spec-wiki/evals/files/bootstrap/docs/how-to-pay.md

@@ -1,4 +0,0 @@
-# How to run a payment test
-
-Run the development server, open the sandbox checkout page, enter the test card,
-and inspect the local logs. This page is an operator/developer guide.

package/skills/spec-wiki/evals/files/bootstrap/docs/overview.md

@@ -1,9 +0,0 @@
-# Payment docs index
-
-This catalog links the current payment documents:
-
-- [Requirements](../requirements/payment-behavior.md)
-- [Timeout RFC](../architecture/rfc-007.md)
-- [How-to](./how-to-pay.md)
-
-Use the linked primary documents for actual behavior.