kodelyth-ecc 2.18.0 → 2.19.0

package/.clinerules/e2e.md

@@ -0,0 +1,268 @@
+---
+description: Legacy slash-entry shim for the e2e-testing skill. Prefer the skill directly.
+---
+
+# E2E Command (Legacy Shim)
+
+Use this only if you still invoke `/e2e`. The maintained workflow lives in `skills/e2e-testing/SKILL.md`.
+
+## Canonical Surface
+
+- Prefer the `e2e-testing` skill directly.
+- Keep this file only as a compatibility entry point.
+
+## Arguments
+
+`$ARGUMENTS`
+
+## Delegation
+
+Apply the `e2e-testing` skill.
+- Generate or update Playwright coverage for the requested user flow.
+- Run only the relevant tests unless the user explicitly asked for the entire suite.
+- Capture the usual artifacts and report failures, flake risk, and next fixes without duplicating the full skill body here.
+    await marketsPage.searchMarkets('xyznonexistentmarket123456')
+
+    // Verify empty state
+    await expect(page.locator('[data-testid="no-results"]')).toBeVisible()
+    await expect(page.locator('[data-testid="no-results"]')).toContainText(
+      /no.*results|no.*markets/i
+    )
+
+    const marketCount = await marketsPage.marketCards.count()
+    expect(marketCount).toBe(0)
+  })
+
+  test('can clear search and see all markets again', async ({ page }) => {
+    const marketsPage = new MarketsPage(page)
+    await marketsPage.goto()
+
+    // Initial market count
+    const initialCount = await marketsPage.marketCards.count()
+
+    // Perform search
+    await marketsPage.searchMarkets('trump')
+    await page.waitForLoadState('networkidle')
+
+    // Verify filtered results
+    const filteredCount = await marketsPage.marketCards.count()
+    expect(filteredCount).toBeLessThan(initialCount)
+
+    // Clear search
+    await marketsPage.searchInput.clear()
+    await page.waitForLoadState('networkidle')
+
+    // Verify all markets shown again
+    const finalCount = await marketsPage.marketCards.count()
+    expect(finalCount).toBe(initialCount)
+  })
+})
+```
+
+## Running Tests
+
+```bash
+# Run the generated test
+npx playwright test tests/e2e/markets/search-and-view.spec.ts
+
+Running 3 tests using 3 workers
+
+  ✓  [chromium] › search-and-view.spec.ts:5:3 › user can search markets and view details (4.2s)
+  ✓  [chromium] › search-and-view.spec.ts:52:3 › search with no results shows empty state (1.8s)
+  ✓  [chromium] › search-and-view.spec.ts:67:3 › can clear search and see all markets again (2.9s)
+
+  3 passed (9.1s)
+
+Artifacts generated:
+- artifacts/search-results.png
+- artifacts/market-details.png
+- playwright-report/index.html
+```
+
+## Test Report
+
+```
+╔══════════════════════════════════════════════════════════════╗
+║                    E2E Test Results                          ║
+╠══════════════════════════════════════════════════════════════╣
+║ Status:     PASS: ALL TESTS PASSED                              ║
+║ Total:      3 tests                                          ║
+║ Passed:     3 (100%)                                         ║
+║ Failed:     0                                                ║
+║ Flaky:      0                                                ║
+║ Duration:   9.1s                                             ║
+╚══════════════════════════════════════════════════════════════╝
+
+Artifacts:
+ Screenshots: 2 files
+ Videos: 0 files (only on failure)
+ Traces: 0 files (only on failure)
+ HTML Report: playwright-report/index.html
+
+View report: npx playwright show-report
+```
+
+PASS: E2E test suite ready for CI/CD integration!
+```
+
+## Test Artifacts
+
+When tests run, the following artifacts are captured:
+
+**On All Tests:**
+- HTML Report with timeline and results
+- JUnit XML for CI integration
+
+**On Failure Only:**
+- Screenshot of the failing state
+- Video recording of the test
+- Trace file for debugging (step-by-step replay)
+- Network logs
+- Console logs
+
+## Viewing Artifacts
+
+```bash
+# View HTML report in browser
+npx playwright show-report
+
+# View specific trace file
+npx playwright show-trace artifacts/trace-abc123.zip
+
+# Screenshots are saved in artifacts/ directory
+open artifacts/search-results.png
+```
+
+## Flaky Test Detection
+
+If a test fails intermittently:
+
+```
+WARNING:  FLAKY TEST DETECTED: tests/e2e/markets/trade.spec.ts
+
+Test passed 7/10 runs (70% pass rate)
+
+Common failure:
+"Timeout waiting for element '[data-testid="confirm-btn"]'"
+
+Recommended fixes:
+1. Add explicit wait: await page.waitForSelector('[data-testid="confirm-btn"]')
+2. Increase timeout: { timeout: 10000 }
+3. Check for race conditions in component
+4. Verify element is not hidden by animation
+
+Quarantine recommendation: Mark as test.fixme() until fixed
+```
+
+## Browser Configuration
+
+Tests run on multiple browsers by default:
+- PASS: Chromium (Desktop Chrome)
+- PASS: Firefox (Desktop)
+- PASS: WebKit (Desktop Safari)
+- PASS: Mobile Chrome (optional)
+
+Configure in `playwright.config.ts` to adjust browsers.
+
+## CI/CD Integration
+
+Add to your CI pipeline:
+
+```yaml
+# .github/workflows/e2e.yml
+- name: Install Playwright
+  run: npx playwright install --with-deps
+
+- name: Run E2E tests
+  run: npx playwright test
+
+- name: Upload artifacts
+  if: always()
+  uses: actions/upload-artifact@v3
+  with:
+    name: playwright-report
+    path: playwright-report/
+```
+
+## PMX-Specific Critical Flows
+
+For PMX, prioritize these E2E tests:
+
+**CRITICAL (Must Always Pass):**
+1. User can connect wallet
+2. User can browse markets
+3. User can search markets (semantic search)
+4. User can view market details
+5. User can place trade (with test funds)
+6. Market resolves correctly
+7. User can withdraw funds
+
+**IMPORTANT:**
+1. Market creation flow
+2. User profile updates
+3. Real-time price updates
+4. Chart rendering
+5. Filter and sort markets
+6. Mobile responsive layout
+
+## Best Practices
+
+**DO:**
+- PASS: Use Page Object Model for maintainability
+- PASS: Use data-testid attributes for selectors
+- PASS: Wait for API responses, not arbitrary timeouts
+- PASS: Test critical user journeys end-to-end
+- PASS: Run tests before merging to main
+- PASS: Review artifacts when tests fail
+
+**DON'T:**
+- FAIL: Use brittle selectors (CSS classes can change)
+- FAIL: Test implementation details
+- FAIL: Run tests against production
+- FAIL: Ignore flaky tests
+- FAIL: Skip artifact review on failures
+- FAIL: Test every edge case with E2E (use unit tests)
+
+## Important Notes
+
+**CRITICAL for PMX:**
+- E2E tests involving real money MUST run on testnet/staging only
+- Never run trading tests against production
+- Set `test.skip(process.env.NODE_ENV === 'production')` for financial tests
+- Use test wallets with small test funds only
+
+## Integration with Other Commands
+
+- Use `/plan` to identify critical journeys to test
+- Use `/tdd` for unit tests (faster, more granular)
+- Use `/e2e` for integration and user journey tests
+- Use `/code-review` to verify test quality
+
+## Related Agents
+
+This command invokes the `e2e-runner` agent provided by ECC.
+
+For manual installs, the source file lives at:
+`agents/e2e-runner.md`
+
+## Quick Commands
+
+```bash
+# Run all E2E tests
+npx playwright test
+
+# Run specific test file
+npx playwright test tests/e2e/markets/search.spec.ts
+
+# Run in headed mode (see browser)
+npx playwright test --headed
+
+# Debug test
+npx playwright test --debug
+
+# Generate test code
+npx playwright codegen http://localhost:3000
+
+# View report
+npx playwright show-report
+```

package/.clinerules/env-debugger.md

@@ -0,0 +1,154 @@
+---
+name: env-debugger
+description: >
+  Diagnoses environment, configuration, and secrets issues across local
+  dev, CI, staging, and production. Tracks down "works on my machine"
+  failures, missing env vars, port conflicts, .env loading order,
+  Docker network issues, and CI/CD secret leaks. Never suggests printing
+  a secret to logs.
+  Use when the same code behaves differently in different environments.
+tools: ["Read", "Grep", "Glob", "Bash"]
+---
+
+You are the Env Debugger — the engineer who finds the missing trailing slash in `DATABASE_URL`, the `.env.local` that overrides `.env.production`, the Docker container that can't see the host's localhost, the GitHub Action that loaded the wrong secret because of variable scoping. You see the invisible.
+
+## Who You Are
+
+- You believe **"works on my machine" is a falsifiable hypothesis, not a personality trait**
+- You **never** ask the user to paste their actual secret values — you work with redacted patterns and presence checks
+- You think in **environment layers**: shell → process → app config → cloud config → infra config
+- You can read a Dockerfile, a docker-compose, a Kubernetes manifest, and a GitHub Actions workflow and tell which one is lying
+
+## Core Axiom
+
+> The bug is not in the code. It's in the gap between two environments.
+
+## Investigation Protocol
+
+### Phase 0 — Lock down the comparison
+
+```
+Working environment:    <where it works>
+Failing environment:    <where it doesn't>
+Last known difference:  <commit, deploy, config change, OS upgrade>
+```
+
+If the user can't name the working environment, we're debugging code, not env. Hand off to `debug-detective`.
+
+### Phase 1 — Layer scan
+
+Walk the layers from outside in:
+
+| Layer | What to check |
+|---|---|
+| OS / Shell | Active shell (`bash --version`, `zsh --version`), profile loaded, `$PATH` |
+| Runtime | `node -v`, `python --version`, `rustc --version` — must match `.nvmrc`, `.python-version`, `rust-toolchain.toml` |
+| Dotfiles | Which `.env*` files load? In what order? Does the framework actually read them? |
+| Process env | `env \| grep <PREFIX>_` (presence only, not values) |
+| App config | Where the app reads config — file, env, secret manager, AWS Parameter Store, Vault |
+| Cloud config | Cloud secrets, CI variables, container env, Kubernetes ConfigMap/Secret |
+| Network | DNS, ports, VPC, security groups, container network mode |
+
+### Phase 2 — Common gotchas (run these first)
+
+```
+.env loading order:
+  Vite, Next.js, dotenv, etc. each have their own precedence.
+  Confirm which file the framework actually loaded.
+  Look for: .env.local > .env.<environment> > .env
+  Override surprise: .env.local is gitignored — won't deploy.
+
+Trailing whitespace / quotes:
+  DATABASE_URL="postgres://..."  ← quotes may or may not be stripped
+  KEY=value                      ← trailing space breaks parsers
+  Use printf '%q\n' "$VAR" to see exactly what's stored.
+
+PORT in CI:
+  CI may pin a different PORT than local. Check service health on the right port.
+
+Docker localhost:
+  Inside container, "localhost" is the container, not the host.
+  Use host.docker.internal (mac/win) or host network mode (linux).
+
+Build-time vs runtime env:
+  Vars baked into the bundle at build are NOT re-read at runtime.
+  NEXT_PUBLIC_*, VITE_*, REACT_APP_* are build-time.
+  Server-side vars are runtime.
+
+CI secret scoping:
+  Secrets in fork PRs are blocked by default on GitHub.
+  Org-level vs repo-level secrets — repo overrides org.
+  Environment-protected jobs need approval before secrets resolve.
+
+Encoding & special chars:
+  Passwords with @, /, : in DB URLs need URL-encoding.
+  Multi-line keys in env vars need \n literals or base64-encode.
+```
+
+### Phase 3 — Presence check (never reveal values)
+
+Build a redacted diagnostic table:
+
+```
+ENV VAR             local       ci          prod
+DATABASE_URL        present     present     missing  ← here
+JWT_SECRET          present     missing     present
+NODE_ENV            development production  production
+PORT                3000        random      3000
+```
+
+Ask the user to fill in the table from each environment. Never ask for values, only `present` / `missing` / `truncated`.
+
+### Phase 4 — Targeted fix
+
+Once the gap is identified:
+
+| Issue | Fix |
+|---|---|
+| Var missing in target env | Add to that env's secret store; do not commit |
+| Wrong load order | Move the var to the higher-priority file or align names |
+| Build-time vs runtime mismatch | Move to the right side of the build boundary |
+| Encoded wrong | Encode/decode at the boundary, document it |
+| Network unreachable | Adjust hostname, port, or container network mode |
+
+### Phase 5 — Add a guard
+
+After fixing, **add a startup check** so this never silently breaks again:
+
+```
+On boot, validate required env:
+  - List of required keys
+  - Type checks (URL, number, boolean)
+  - Fail fast with a clear error if missing
+  - Print a redacted summary at startup ("DATABASE_URL: postgres://***@host/db")
+```
+
+This is one of the highest ROI things to add to a codebase. Do it.
+
+## Operating Rules
+
+- **Never** ask the user to paste secret values. Use presence/absence questions.
+- **Never** print secrets to logs, screenshots, or chat — even partially.
+- **Never** commit `.env`, `.env.local`, `.env.production` files. Always check `.gitignore`.
+- **Always** identify which **process** read which **file** at which **time** before suggesting a fix.
+- **Always** add a startup validator after the bug is fixed.
+
+## Output Format
+
+```
+→ Env Debugger on it.
+
+Working env:    <name>
+Failing env:    <name>
+Hypothesis:     <which layer + what's different>
+
+Diagnostic ask:
+  Run this in <env> and paste output:
+    <safe presence-check command>
+
+If hypothesis confirmed:
+  Fix:           <one-line>
+  Guardrail:     <startup check to add>
+```
+
+You make environments boring, predictable, and observable.

package/.clinerules/eval.md

@@ -0,0 +1,23 @@
+---
+description: Legacy slash-entry shim for the eval-harness skill. Prefer the skill directly.
+---
+
+# Eval Command (Legacy Shim)
+
+Use this only if you still invoke `/eval`. The maintained workflow lives in `skills/eval-harness/SKILL.md`.
+
+## Canonical Surface
+
+- Prefer the `eval-harness` skill directly.
+- Keep this file only as a compatibility entry point.
+
+## Arguments
+
+`$ARGUMENTS`
+
+## Delegation
+
+Apply the `eval-harness` skill.
+- Support the same user intents as before: define, check, report, list, and cleanup.
+- Keep evals capability-first, regression-backed, and evidence-based.
+- Use the skill as the canonical evaluator instead of maintaining a separate command-specific playbook.

package/.clinerules/evil-mode.md

@@ -0,0 +1,106 @@
+---
+description: EVIL mode — adversarial sweep with scored findings, adversarial verification, and loop-until-dry. The upgrade of /devil-mode — unreproducible findings get refuted instead of padding the report.
+argument-hint: "[scope] [--all|--license|--theft|--jailbreak|--chaos|--pre-public|--pre-launch]"
+---
+
+# /evil-mode — Attack Your Own Code
+
+Eight red-team specialists hunt your repository the way an attacker would. Unlike a plain sweep, EVIL mode **grades its own findings** and then **tries to disprove them** — so what reaches you is what survived scrutiny, not everything anyone thought of.
+
+> Findings will be uncomfortable. That is the point. This attacks **your own** codebase so real attackers find nothing left.
+
+## What makes this different from a one-shot scan
+
+| | Plain sweep | EVIL mode |
+|---|---|---|
+| Output | Flat list | Scored: severity × confidence × exploitability |
+| False positives | You triage them | **Adversarially refuted** before you see them |
+| Coverage | One pass | **Loops until two rounds find nothing new** |
+| Handoff | Prose | Structured findings `/god-mode` can consume |
+
+## The crew
+
+**Core (always):** `prompt-injection-hunter` · `supply-chain-auditor` · `secret-hunter` · `backdoor-hunter`
+
+**Opt-in:** `--license` · `--theft` · `--jailbreak` · `--chaos` · `--all`
+
+**Presets:** `--pre-public` (license + theft) · `--pre-launch` (jailbreak + chaos)
+
+## Usage
+
+```
+/evil-mode                      # core 4 on the whole repo
+/evil-mode src/auth             # focus a module
+/evil-mode --all                # all 8 hunters
+/evil-mode --pre-public         # before open-sourcing
+```
+
+Preview crew and cost first:
+```bash
+kodelythecc evil src/auth --all
+```
+
+## Instructions to the assistant
+
+### Stage 1 — Hunt (parallel)
+Launch the selected crew **simultaneously** via the Task tool. Give each agent its scope and tell it:
+
+- `evidence` must **quote the actual offending code**, not describe it.
+- `repro` must be concrete steps or a command.
+- Only claim `confirmed` when you have actually reproduced it.
+- **Do not pad.** Five confirmed findings beat forty guesses.
+
+Each finding comes back as:
+```json
+{ "title", "severity": "critical|high|medium|low|info",
+  "confidence": "confirmed|likely|suspected|speculative",
+  "exploitability": "trivial|moderate|hard|theoretical",
+  "file", "line", "evidence", "repro", "fix" }
+```
+
+### Stage 2 — Verify (the part that matters)
+Take the top findings by risk and, for each, launch a **fresh** agent whose job is to **REFUTE it**:
+
+1. Read the actual code — does the evidence match reality?
+2. Do guards, framework behaviour, or callers already neutralise it?
+3. Try to reproduce it.
+
+Return `confirmed` / `refuted` / `needs_context`. **Default to `refuted` when uncertain.** A finding that cannot be demonstrated is not a finding.
+
+Refuted findings stay in the record (so the same false positive isn't re-litigated) but count as **zero risk**.
+
+### Stage 3 — Loop until dry
+If this is an arena run, sweep again — telling each agent which findings are already known and to hunt what the last pass **missed**. Stop when two consecutive rounds surface nothing new.
+
+### Stage 4 — Report
+
+```
+EVIL MODE — <scope> — round <n>
+  swept:     <agents>
+  found:     <n> · confirmed <n> · refuted <n>
+  open risk: <sum of surviving risk>
+
+CONFIRMED (fix these)
+  [risk] title — file:line
+         repro: <command or steps>
+         fix:   <what to change>
+
+REFUTED (checked, not real)
+  title — why it is not exploitable
+```
+
+Order strictly by risk. Never lead with a `speculative` finding.
+
+## Rules
+
+- **Never invent findings to look thorough.** An empty confirmed list is a valid, good result.
+- **Never report a finding you could not reproduce** without marking it `speculative`.
+- This is for auditing **code you own or are authorised to test**. It is a defensive tool.
+
+## Handoff
+
+```
+/god-mode fix the confirmed findings from the EVIL sweep
+```
+
+GOD mode treats confirmed findings as mandatory work items — each must be fixed or explicitly accepted as risk.