@mrciphersmith/keryx 0.2.9

package/src/gdskills/bundled/rules/core/playwright-testing.mdc

@@ -0,0 +1,321 @@
+---
+description: "Playwright E2E testing standards, test structure, and UI verification workflows."
+alwaysApply: false
+globs:
+  - "e2e/**"
+  - "**/*.spec.ts"
+  - "playwright.config.ts"
+---
+
+# Playwright E2E Testing Guidelines
+
+## Purpose
+Standardize E2E test creation, execution, and UI verification workflows using Playwright.
+
+## When to Apply
+- Writing new E2E tests
+- Debugging failing tests
+- Setting up visual regression tests
+- Analyzing UI behavior changes
+
+## Prerequisites
+
+Check Playwright is installed and configured:
+```bash
+npm list @playwright/test
+ls playwright.config.ts
+```
+
+## Run Commands
+
+```bash
+# Run all tests
+npm run e2e
+
+# Run specific test file
+npx playwright test e2e/example.spec.ts
+
+# Run in headed mode (see browser)
+npx playwright test --headed
+
+# Run with UI mode (interactive debugging)
+npx playwright test --ui
+
+# Run specific project (chromium/firefox/webkit)
+npx playwright test --project=chromium
+
+# Run with trace (for debugging)
+npx playwright test --trace on
+
+# View trace report
+npx playwright show-trace trace.zip
+
+# Generate HTML report
+npx playwright test --reporter=html
+npx playwright show-report
+```
+
+## Test File Structure
+
+```typescript
+// e2e/feature-name.spec.ts
+import { test, expect } from '@playwright/test';
+
+test.describe('Feature Name', () => {
+  test.beforeEach(async ({ page }) => {
+    // Setup: login, navigate, etc.
+    await page.goto('/path');
+  });
+
+  test('should display correct initial state', async ({ page }) => {
+    // Arrange
+    
+    // Act
+    
+    // Assert
+    await expect(page.locator('[data-testid="element"]')).toBeVisible();
+  });
+
+  test('should handle user interaction', async ({ page }) => {
+    // Test steps
+  });
+});
+```
+
+## UI Verification Patterns
+
+### Element Visibility
+```typescript
+// Check element is visible
+await expect(page.locator('.my-class')).toBeVisible();
+
+// Check element is hidden
+await expect(page.locator('.loading')).toBeHidden();
+
+// Check element contains text
+await expect(page.locator('h1')).toContainText('Expected Title');
+
+// Check element has exact text
+await expect(page.locator('.status')).toHaveText('Active');
+```
+
+### Form Interactions
+
+> **Deprecation notice:** `page.fill()`, `page.click()`, and `page.check()` are deprecated.
+> Use the locator-based equivalents instead:
+> - `page.fill(selector, value)` → `page.locator(selector).fill(value)`
+> - `page.click(selector)` → `page.locator(selector).click()`
+> - `page.check(selector)` → `page.locator(selector).check()`
+
+```typescript
+// Fill input
+await page.locator('[data-testid="email-input"]').fill('test@example.com');
+
+// Select from dropdown
+await page.locator('select[name="country"]').selectOption('US');
+
+// Click button
+await page.locator('button[type="submit"]').click();
+
+// Check checkbox
+await page.locator('input[type="checkbox"]').check();
+```
+
+### Visual Regression Testing
+
+```typescript
+// Screenshot comparison
+test('visual regression - component state', async ({ page }) => {
+  await page.goto('/component-url');
+  
+  // Wait for stability
+  // DEPRECATED: waitUntil: 'networkidle' / waitForLoadState('networkidle') is deprecated.
+  // Prefer waitUntil: 'load', waitForLoadState('load'), or explicit waitForSelector / UI state checks.
+  await page.waitForLoadState('load');
+  
+  // Take screenshot
+  await expect(page).toHaveScreenshot('component-state.png', {
+    maxDiffPixels: 100
+  });
+});
+```
+
+**Screenshot Configuration** in `playwright.config.ts`:
+```typescript
+expect: {
+  toHaveScreenshot: {
+    maxDiffPixels: 100,
+    threshold: 0.2,
+  },
+},
+```
+
+### Responsive Testing
+
+```typescript
+test('responsive layout', async ({ page }) => {
+  // Test mobile
+  await page.setViewportSize({ width: 375, height: 667 });
+  await page.goto('/');
+  await expect(page.locator('.mobile-menu')).toBeVisible();
+  
+  // Test desktop
+  await page.setViewportSize({ width: 1280, height: 720 });
+  await page.goto('/');
+  await expect(page.locator('.desktop-nav')).toBeVisible();
+});
+```
+
+## Test Data Attributes
+
+Use `data-testid` for stable selectors:
+```tsx
+// Component
+<button data-testid="submit-button">Submit</button>
+
+// Test (page.click() is deprecated — use locator-based API)
+await page.locator('[data-testid="submit-button"]').click();
+```
+
+## API Mocking
+
+```typescript
+import { test, expect } from '@playwright/test';
+
+test('handles API error', async ({ page }) => {
+  // Mock API response
+  await page.route('**/api/users', async route => {
+    await route.fulfill({
+      status: 500,
+      body: JSON.stringify({ error: 'Server error' })
+    });
+  });
+  
+  await page.goto('/users');
+  await expect(page.locator('.error-message')).toBeVisible();
+});
+```
+
+## Authentication Patterns
+
+```typescript
+test.describe('Authenticated Routes', () => {
+  test.use({ storageState: 'e2e/auth.json' });
+  
+  test('access protected page', async ({ page }) => {
+    await page.goto('/dashboard');
+    await expect(page.locator('.dashboard')).toBeVisible();
+  });
+});
+
+// Setup auth in global setup
+test('login flow', async ({ page }) => {
+  await page.goto('/login');
+  await page.locator('[data-testid="username"]').fill('user');
+  await page.locator('[data-testid="password"]').fill('pass');
+  await page.locator('[data-testid="login-button"]').click();
+  
+  // Save state
+  await page.context().storageState({ path: 'e2e/auth.json' });
+});
+```
+
+## Debugging Failed Tests
+
+```bash
+# Run with trace
+npx playwright test --trace on
+
+# View trace
+npx playwright show-trace test-results/trace.zip
+
+# Run in debug mode
+npx playwright test --debug
+
+# Slow motion execution
+npx playwright test --headed --slow-mo 1000
+```
+
+## Common Issues and Solutions
+
+### Flaky Tests
+```typescript
+// Add retry logic
+await expect.poll(async () => {
+  const response = await page.evaluate(() => fetch('/api/status'));
+  return response.status;
+}).toBe(200);
+
+// DEPRECATED: waitForLoadState('networkidle') / waitUntil: 'networkidle' is deprecated.
+// Prefer waitForLoadState('load') or explicit waitForSelector / UI state checks.
+await page.waitForLoadState('load');
+```
+
+### Timing Issues
+```typescript
+// Wait for specific element
+await page.waitForSelector('.loaded', { timeout: 10000 });
+
+// Wait for request
+await page.waitForRequest('**/api/data');
+
+// Wait for response
+await page.waitForResponse('**/api/data');
+```
+
+### Dynamic Content
+```typescript
+// Wait for text to appear
+await page.waitForFunction(() => {
+  return document.querySelector('.status')?.textContent === 'Ready';
+});
+```
+
+## Integration with Feature Analysis
+
+When using Playwright with `feature-analyzer`:
+
+1. **Visual Verification**: After code changes, run visual tests to detect UI regressions
+2. **Flow Validation**: Test critical user flows affected by the feature
+3. **Cross-browser Check**: Verify functionality in all supported browsers
+4. **Responsive Check**: Ensure UI works across different viewports
+
+```typescript
+// Example: Testing a feature from analysis
+test.describe('Feature: User Profile Update (from analysis)', () => {
+  test('validates profile form changes', async ({ page }) => {
+    // Based on analysis: test form validation
+    await page.goto('/profile');
+    
+    // Clear and fill (as per DTO changes)
+    await page.locator('[data-testid="name-input"]').fill('New Name');
+    await page.locator('[data-testid="save-button"]').click();
+    
+    // Verify success (as per API contract)
+    await expect(page.locator('.success-message')).toBeVisible();
+  });
+});
+```
+
+## Output Contract
+
+- Test files must be TypeScript
+- Use descriptive test names
+- Include Arrange-Act-Assert comments
+- Provide trace/logs for failed tests
+- Screenshots must be in `e2e/screenshots/`
+
+## CI/CD Integration
+
+```yaml
+# Example CI step
+- name: Run Playwright tests
+  run: npx playwright test
+  
+- name: Upload test results
+  uses: actions/upload-artifact@v4
+  if: always()
+  with:
+    name: playwright-report
+    path: playwright-report/
+```

package/src/gdskills/bundled/rules/core/requirements-management.mdc

@@ -0,0 +1,35 @@
+---
+description: "Rules for creating and updating requirement documents with multilingual outputs."
+alwaysApply: false
+---
+
+# Requirements Management Rules
+
+## Purpose
+Standardize how requirement sets are created and maintained.
+
+## When To Apply
+Apply when creating or updating requirement documents.
+
+## Location
+`<DOCS_ROOT>/requirements/<requirement-name>/<YYYY-MM-DD>/`
+
+## Mandatory Behavior
+1. Ask for target location and requirement folder name before writing.
+2. Confirm naming convention before creation.
+3. Always create a new date-stamped subfolder; do not overwrite old sets.
+4. Generate synchronized `ru`, `en`, and `ai` versions.
+5. Document assumptions and open questions explicitly.
+
+## Output Contract
+- Use Markdown (`.md`) only.
+- Keep sections explicit: context, scope, requirements, constraints, open questions.
+- Code snippets must be fenced code blocks.
+
+## Workflow
+1. Capture request.
+2. Clarify folder/location.
+3. Create folder structure.
+4. Create all required language files.
+5. Validate synchronization.
+6. Ask whether to apply changes.

package/src/gdskills/bundled/rules/core/requirements-package-standard.mdc

@@ -0,0 +1,103 @@
+---
+description: "Defines Metaproject requirements package structure, versioning, verification and review rules."
+alwaysApply: false
+---
+
+# Requirements Package Standard
+
+## Purpose
+
+Use this rule when creating or updating a requirements package under
+`docs/requirements/<module-or-topic>/`.
+
+## Required Core Files
+
+Every module-level documentation package must contain:
+
+```text
+docs/requirements/<name>/
+  README.md
+  prd.md
+  specification.md
+```
+
+Optional files are added only when the topic needs them:
+
+```text
+brainstorm.md
+policies.md
+agent-protocol.md
+ci-protocol.md
+artifact-lifecycle.md
+metrics-and-validation.md
+implementation-plan.md
+schemas/*.json
+```
+
+## Required Metadata
+
+Every Markdown document must include:
+
+```markdown
+Version: x.y.z
+```
+
+The field must be directly under the H1. Increment the version whenever the
+document changes.
+
+## README Contract
+
+`README.md` must state:
+
+- package purpose;
+- current status;
+- document index;
+- scope and non-goals;
+- related modules.
+
+## PRD Contract
+
+`prd.md` must state:
+
+- problem;
+- goal;
+- users;
+- requirements;
+- success criteria;
+- risks;
+- recommendation.
+
+## Specification Contract
+
+`specification.md` must state:
+
+- module identity;
+- storage structure;
+- manifest/config shape;
+- CLI or skill surface;
+- data contracts;
+- integration points;
+- acceptance criteria.
+
+## Verification Contract
+
+Before finishing:
+
+- verify required files exist;
+- verify all Markdown files have `Version`;
+- verify README links to all package files;
+- verify schemas are referenced from specification when present;
+- verify status is honest: `draft`, `spec ready`, `implemented`, or `future`;
+- update `docs/requirements/roadmap.md` when the package represents a module or
+  standard capability.
+
+## Review Contract
+
+Documentation review must check:
+
+- completeness against this rule;
+- contradictions across README/PRD/spec;
+- unsupported implementation claims;
+- missing integration points;
+- stale roadmap or version references;
+- unsafe overpromising versus current implementation.

package/src/gdskills/bundled/rules/core/review-agent-profile.mdc

@@ -0,0 +1,49 @@
+---
+description: "Baseline AI code review standards for correctness, architecture, safety, and maintainability."
+alwaysApply: false
+---
+
+# AI Code Review Assistant
+
+## Purpose
+Provide strict, high-signal code reviews with actionable findings.
+
+## When To Apply
+Apply when performing AI-assisted code review; loaded automatically by the code-ai-review skill.
+
+## Verdict Labels
+
+All reviews must end with exactly one of the following verdict labels:
+
+| Verdict | Meaning |
+|---------|---------|
+| `APPROVE` | Changes accepted as-is; no outstanding issues. |
+| `APPROVE WITH SUGGESTIONS` | Accepted and can merge, but improvements are noted for follow-up. |
+| `REQUEST CHANGES` | Must fix identified issues before merge. |
+| `COMMENT` | Informational findings only; no blocking action required. |
+
+## Review Output Structure
+1. Verdict label (from the table above)
+2. Findings by severity and category
+3. Concrete fix proposals
+4. Residual risks and test gaps
+
+## Priority Categories
+- Correctness
+- Types and safety
+- Architecture and state boundaries
+- Performance
+- UX/A11y
+- Tests
+
+## Mandatory Rules
+- Prioritize correctness over style.
+- Do not request massive refactors unless user asks.
+- Flag unsafe casts and hidden complexity.
+- Align suggestions with existing project patterns.
+- Keep comments specific, respectful, and actionable.
+
+## Output Contract
+- Final review must be Markdown.
+- Code snippets/diffs must be fenced code blocks.
+- Response language follows user query language.

package/src/gdskills/bundled/rules/core/review-strict-profile.mdc

@@ -0,0 +1,44 @@
+---
+description: "boss-style review profile: direct, strict, architecture-first feedback with concrete fixes."
+alwaysApply: false
+---
+
+# boss Review Profile
+
+## Purpose
+Replicate the boss review style for requested reviews.
+
+## When To Apply
+Apply when user explicitly asks for review in boss style.
+
+## Style Profile
+- Direct and concise.
+- Architecture-first.
+- Strongly against duct-tape fixes.
+- Focus on testability and single source of truth.
+
+## What To Flag
+- Business logic in UI instead of store/service.
+- Duplicate rule checks in multiple places.
+- Unsafe casts (`any`, disguised casts).
+- Mocks inheriting production classes.
+- Loading/no-data semantics confusion.
+- Magic numbers without rationale.
+- **Status/result mapping semantics**: Mapping "none" or absence-of-result to a semantic outcome (e.g. canceled, failed) without domain justification. Verify that source enum values (e.g. none, killed, cancelled) have distinct meanings and that the mapping preserves them; flag mappings that equate semantically different states (e.g. `none === canceled`, `killed === canceled` without explicit product rationale).
+- **Store method accessibility** — See `core/mobx-store-template.mdc` for definitive rules on public vs private store methods. Key violations to flag:
+  - Public `onChangeX` / `handleX` methods (must be private)
+  - Public `action.bound` that should be private callbacks
+
+## Response Format
+1. Verdict in one line — use the canonical verdict vocabulary (same set as `core/code-review-ai-assistant.mdc`):
+   - `APPROVE` — no blocking issues; changes accepted as-is
+   - `APPROVE WITH SUGGESTIONS` — accepted but improvements noted for follow-up
+   - `REQUEST CHANGES` — has issues that must be fixed before merge
+   - `COMMENT` — informational findings only; no blocking action required
+2. Top 1-3 blocking findings.
+3. Concrete replacement/fix path.
+
+## Guardrails
+- No personal attacks.
+- No empty nitpicks.
+- Keep recommendations lint-safe and scoped.

package/src/gdskills/bundled/rules/core/rule-management-workflow.mdc

@@ -0,0 +1,62 @@
+---
+description: "Workflow for adding or editing rules in the AGENTS.mdc + rules/core structure."
+alwaysApply: false
+---
+
+# Rule Management Workflow
+
+## Purpose
+Define a deterministic workflow for adding, editing, and syncing rules.
+
+## Trigger
+Apply when user asks to create, update, move, reorganize, or sync rules.
+
+## Source of Truth
+- Repository source: `.metaproject/rules`
+- Root always-on file (plain): `AGENTS.md`
+- Root always-on file (Cursor): `AGENTS.mdc` (frontmatter wrapper around AGENTS.md)
+- Thematic files: `.metaproject/rules/core/*.mdc`
+
+## Mandatory Clarification Step
+Before creating or editing any rule, the agent MUST ask and confirm:
+1. Target location
+2. Target folder name
+3. Rule file name (semantic, no numeric prefix)
+4. Rule scope and trigger conditions
+
+## Mandatory Behavior
+1. Update or create thematic rule files only under `rules/core`.
+2. Keep all rule files in English.
+3. Keep frontmatter valid YAML.
+4. If core files changed, update `AGENTS.md` catalog (and keep AGENTS.mdc in sync).
+5. Run synchronization only after source files are updated.
+
+## How to Run Synchronization
+After editing rules under `.metaproject/rules/` or `AGENTS.md`, sync to all targets:
+
+```bash
+keryx update
+```
+
+### Sync Targets
+- `~/.cursor/rules/AGENTS.md` — Cursor global rules
+- `~/.codex/AGENTS.md` — Codex global rules
+- `~/.config/zed/AGENTS.md` — Zed global rules
+- `~/.config/opencode/AGENTS.md` — OpenCode global rules
+
+## Rule File Standard
+Every core rule MUST include:
+- Purpose
+- When To Apply
+- Mandatory Behavior
+- Output Contract (when the rule defines user-facing deliverables)
+- Optional examples
+
+## Output Contract for Rule Work
+- Any produced rule text must be Markdown.
+- Any code example must be fenced.
+- Final response language must follow user query language.
+
+## Apply Changes Workflow
+After rule changes, ask whether to apply changes.
+If approved: create branch from `main`, commit, and open PR to `main`.