From f61407fc50bbbdc2543b96b40cb62f4b1516449d Mon Sep 17 00:00:00 2001 From: Farda Karimov Date: Sun, 19 Jul 2026 18:27:00 +0200 Subject: [PATCH] docs: remove stale translated docs for retired commands MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 11 commands (tdd, eval, verify, e2e, docs, claw, context-budget, devfleet, orchestrate, prompt-optimize, rules-distill) were retired to legacy-command-shims/ in favor of skills, but their translated per-command doc pages were still committed under docs/{ja-JP,zh-CN,zh-TW,ko-KR,pt-BR,es,tr}/commands/. Removed the 47 stale files (count differs per locale — not all locales had all 11 translated). docs/ja-JP/commands/README.md also listed 4 of them directly; updated those bullets to point at the replacement skills instead. --- docs/es/commands/e2e.md | 336 ---------------------- docs/es/commands/eval.md | 120 -------- docs/es/commands/orchestrate.md | 231 --------------- docs/es/commands/tdd.md | 328 ---------------------- docs/es/commands/verify.md | 59 ---- docs/ja-JP/commands/README.md | 17 +- docs/ja-JP/commands/claw.md | 51 ---- docs/ja-JP/commands/context-budget.md | 29 -- docs/ja-JP/commands/devfleet.md | 93 ------ docs/ja-JP/commands/docs.md | 32 --- docs/ja-JP/commands/e2e.md | 370 ------------------------ docs/ja-JP/commands/eval.md | 120 -------- docs/ja-JP/commands/orchestrate.md | 172 ------------ docs/ja-JP/commands/prompt-optimize.md | 37 --- docs/ja-JP/commands/rules-distill.md | 11 - docs/ja-JP/commands/tdd.md | 326 --------------------- docs/ja-JP/commands/verify.md | 59 ---- docs/ko-KR/commands/e2e.md | 334 ---------------------- docs/ko-KR/commands/eval.md | 120 -------- docs/ko-KR/commands/orchestrate.md | 172 ------------ docs/ko-KR/commands/tdd.md | 326 --------------------- docs/ko-KR/commands/verify.md | 63 ----- docs/pt-BR/commands/e2e.md | 365 ------------------------ docs/pt-BR/commands/eval.md | 120 -------- docs/pt-BR/commands/orchestrate.md | 230 --------------- docs/pt-BR/commands/tdd.md | 328 ---------------------- docs/pt-BR/commands/verify.md | 59 ---- docs/tr/commands/e2e.md | 365 ------------------------ docs/tr/commands/eval.md | 120 -------- docs/tr/commands/orchestrate.md | 231 --------------- docs/tr/commands/tdd.md | 328 ---------------------- docs/tr/commands/verify.md | 59 ---- docs/zh-CN/commands/claw.md | 51 ---- docs/zh-CN/commands/context-budget.md | 29 -- docs/zh-CN/commands/devfleet.md | 93 ------ docs/zh-CN/commands/docs.md | 32 --- docs/zh-CN/commands/e2e.md | 374 ------------------------- docs/zh-CN/commands/eval.md | 122 -------- docs/zh-CN/commands/orchestrate.md | 242 ---------------- docs/zh-CN/commands/prompt-optimize.md | 37 --- docs/zh-CN/commands/rules-distill.md | 11 - docs/zh-CN/commands/tdd.md | 330 ---------------------- docs/zh-CN/commands/verify.md | 60 ---- docs/zh-TW/commands/e2e.md | 115 -------- docs/zh-TW/commands/eval.md | 120 -------- docs/zh-TW/commands/orchestrate.md | 140 --------- docs/zh-TW/commands/tdd.md | 100 ------- docs/zh-TW/commands/verify.md | 59 ---- 48 files changed, 9 insertions(+), 7517 deletions(-) delete mode 100644 docs/es/commands/e2e.md delete mode 100644 docs/es/commands/eval.md delete mode 100644 docs/es/commands/orchestrate.md delete mode 100644 docs/es/commands/tdd.md delete mode 100644 docs/es/commands/verify.md delete mode 100644 docs/ja-JP/commands/claw.md delete mode 100644 docs/ja-JP/commands/context-budget.md delete mode 100644 docs/ja-JP/commands/devfleet.md delete mode 100644 docs/ja-JP/commands/docs.md delete mode 100644 docs/ja-JP/commands/e2e.md delete mode 100644 docs/ja-JP/commands/eval.md delete mode 100644 docs/ja-JP/commands/orchestrate.md delete mode 100644 docs/ja-JP/commands/prompt-optimize.md delete mode 100644 docs/ja-JP/commands/rules-distill.md delete mode 100644 docs/ja-JP/commands/tdd.md delete mode 100644 docs/ja-JP/commands/verify.md delete mode 100644 docs/ko-KR/commands/e2e.md delete mode 100644 docs/ko-KR/commands/eval.md delete mode 100644 docs/ko-KR/commands/orchestrate.md delete mode 100644 docs/ko-KR/commands/tdd.md delete mode 100644 docs/ko-KR/commands/verify.md delete mode 100644 docs/pt-BR/commands/e2e.md delete mode 100644 docs/pt-BR/commands/eval.md delete mode 100644 docs/pt-BR/commands/orchestrate.md delete mode 100644 docs/pt-BR/commands/tdd.md delete mode 100644 docs/pt-BR/commands/verify.md delete mode 100644 docs/tr/commands/e2e.md delete mode 100644 docs/tr/commands/eval.md delete mode 100644 docs/tr/commands/orchestrate.md delete mode 100644 docs/tr/commands/tdd.md delete mode 100644 docs/tr/commands/verify.md delete mode 100644 docs/zh-CN/commands/claw.md delete mode 100644 docs/zh-CN/commands/context-budget.md delete mode 100644 docs/zh-CN/commands/devfleet.md delete mode 100644 docs/zh-CN/commands/docs.md delete mode 100644 docs/zh-CN/commands/e2e.md delete mode 100644 docs/zh-CN/commands/eval.md delete mode 100644 docs/zh-CN/commands/orchestrate.md delete mode 100644 docs/zh-CN/commands/prompt-optimize.md delete mode 100644 docs/zh-CN/commands/rules-distill.md delete mode 100644 docs/zh-CN/commands/tdd.md delete mode 100644 docs/zh-CN/commands/verify.md delete mode 100644 docs/zh-TW/commands/e2e.md delete mode 100644 docs/zh-TW/commands/eval.md delete mode 100644 docs/zh-TW/commands/orchestrate.md delete mode 100644 docs/zh-TW/commands/tdd.md delete mode 100644 docs/zh-TW/commands/verify.md diff --git a/docs/es/commands/e2e.md b/docs/es/commands/e2e.md deleted file mode 100644 index aaff8db29e..0000000000 --- a/docs/es/commands/e2e.md +++ /dev/null @@ -1,336 +0,0 @@ ---- -description: Crear y ejecutar pruebas end-to-end con Playwright. Genera flujos de prueba, ejecuta los tests, captura capturas de pantalla/videos/trazas y sube artefactos. ---- - -# Comando E2E - -Este comando invoca al agente **e2e-runner** para crear, mantener y ejecutar pruebas end-to-end usando Playwright. - -## Qué Hace Este Comando - -1. **Crear Flujos de Prueba** - Generar pruebas Playwright para flujos de usuario -2. **Ejecutar Pruebas E2E** - Ejecutar los tests en múltiples navegadores -3. **Capturar Artefactos** - Capturas de pantalla, videos y trazas en caso de error -4. **Subir Resultados** - Reportes HTML y JUnit XML -5. **Identificar Pruebas Inestables** - Poner en cuarentena tests no deterministas - -## Cuándo Usarlo - -Usa el comando `/e2e` cuando: -- Pruebes flujos de usuario críticos (login, transacciones, pagos) -- Verifiques que flujos de múltiples pasos funcionen de extremo a extremo -- Pruebes interacciones de UI y navegación -- Valides la integración entre frontend y backend -- Te prepares para despliegue a producción - -## Cómo Funciona - -El agente e2e-runner: - -1. **Analizará el flujo de usuario** e identificará los escenarios de prueba -2. **Generará la prueba Playwright** usando el patrón Page Object Model -3. **Ejecutará las pruebas** (Chrome, Firefox, Safari) -4. **Capturará los fallos** con capturas de pantalla, videos y trazas -5. **Generará un reporte** con los resultados y artefactos -6. **Identificará pruebas inestables** y sugerirá correcciones - -## Ejemplo de Uso - -``` -Usuario: /e2e Probar el flujo de búsqueda y visualización de mercados - -Agente (e2e-runner): -# Creación de Prueba E2E: Flujo de Búsqueda y Visualización de Mercados - -## Escenario de Prueba Identificado - -**Flujo de Usuario:** Búsqueda de Mercados → Ver Resultados → Click en Mercado → Ver Detalles - -**Cobertura de Prueba:** -1. Ir a la página de mercados -2. Realizar búsqueda semántica -3. Validar resultados de búsqueda -4. Click en el primer resultado -5. Validar que carga la página de detalles del mercado -6. Validar que el gráfico se renderiza - -## Código de Prueba Generado - -```typescript -// tests/e2e/markets/search-and-view.spec.ts -import { test, expect } from '@playwright/test' -import { MarketsPage } from '../../pages/MarketsPage' -import { MarketDetailsPage } from '../../pages/MarketDetailsPage' - -test.describe('Market Search and View Flow', () => { - test('el usuario puede buscar mercados y ver detalles', async ({ page }) => { - // 1. Ir a la página de mercados - const marketsPage = new MarketsPage(page) - await marketsPage.goto() - - // Validar que la página cargó - await expect(page).toHaveTitle(/Markets/) - await expect(page.locator('h1')).toContainText('Markets') - - // 2. Realizar búsqueda semántica - await marketsPage.searchMarkets('election') - - // Esperar respuesta de la API - await page.waitForResponse(resp => - resp.url().includes('/api/markets/search') && resp.status() === 200 - ) - - // 3. Validar resultados de búsqueda - const marketCards = marketsPage.marketCards - await expect(marketCards.first()).toBeVisible() - const resultCount = await marketCards.count() - expect(resultCount).toBeGreaterThan(0) - - // Tomar captura de pantalla de los resultados - await page.screenshot({ path: 'artifacts/search-results.png' }) - - // 4. Click en el primer resultado - const firstMarketTitle = await marketCards.first().textContent() - await marketCards.first().click() - - // 5. Validar que carga la página de detalles del mercado - await expect(page).toHaveURL(/\/markets\/[a-z0-9-]+/) - - const detailsPage = new MarketDetailsPage(page) - await expect(detailsPage.marketName).toBeVisible() - await expect(detailsPage.marketDescription).toBeVisible() - - // 6. Validar que el gráfico se renderiza - await expect(detailsPage.priceChart).toBeVisible() - - // Verificar que el nombre del mercado coincide - const detailsTitle = await detailsPage.marketName.textContent() - expect(detailsTitle?.toLowerCase()).toContain( - firstMarketTitle?.toLowerCase().substring(0, 20) || '' - ) - - // Tomar captura de pantalla de los detalles del mercado - await page.screenshot({ path: 'artifacts/market-details.png' }) - }) - - test('búsqueda sin resultados debe mostrar estado vacío', async ({ page }) => { - const marketsPage = new MarketsPage(page) - await marketsPage.goto() - - // Buscar un mercado que no existe - await marketsPage.searchMarkets('xyznonexistentmarket123456') - - // Validar estado vacío - 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('puede limpiar la búsqueda y ver todos los mercados de nuevo', async ({ page }) => { - const marketsPage = new MarketsPage(page) - await marketsPage.goto() - - // Cantidad inicial de mercados - const initialCount = await marketsPage.marketCards.count() - - // Realizar búsqueda - await marketsPage.searchMarkets('trump') - await page.waitForLoadState('networkidle') - - // Validar resultados filtrados - const filteredCount = await marketsPage.marketCards.count() - expect(filteredCount).toBeLessThan(initialCount) - - // Limpiar búsqueda - await marketsPage.searchInput.clear() - await page.waitForLoadState('networkidle') - - // Validar que se muestran todos los mercados de nuevo - const finalCount = await marketsPage.marketCards.count() - expect(finalCount).toBe(initialCount) - }) -}) -``` - -## Ejecutar las Pruebas - -```bash -# Ejecutar la prueba generada -npx playwright test tests/e2e/markets/search-and-view.spec.ts - -Corriendo 3 pruebas usando 3 workers - - ✓ [chromium] › search-and-view.spec.ts:5:3 › el usuario puede buscar mercados y ver detalles (4.2s) - ✓ [chromium] › search-and-view.spec.ts:52:3 › búsqueda sin resultados muestra estado vacío (1.8s) - ✓ [chromium] › search-and-view.spec.ts:67:3 › puede limpiar búsqueda y ver todos los mercados (2.9s) - - 3 passed (9.1s) - -Artefactos generados: -- artifacts/search-results.png -- artifacts/market-details.png -- playwright-report/index.html -``` - -## Reporte de Pruebas - -``` -╔══════════════════════════════════════════════════════════════╗ -║ Resultados de Pruebas E2E ║ -╠══════════════════════════════════════════════════════════════╣ -║ Estado: PASS: TODAS LAS PRUEBAS PASARON ║ -║ Total: 3 pruebas ║ -║ Pasaron: 3 (100%) ║ -║ Fallaron: 0 ║ -║ Inestables: 0 ║ -║ Duración: 9.1s ║ -╚══════════════════════════════════════════════════════════════╝ - -Artefactos: - Capturas de pantalla: 2 archivos - Videos: 0 archivos (solo en fallo) - Trazas: 0 archivos (solo en fallo) - Reporte HTML: playwright-report/index.html - -Ver reporte: npx playwright show-report -``` - -PASS: ¡Suite de pruebas E2E lista para integración CI/CD! -``` - -## Artefactos de Prueba - -Cuando las pruebas se ejecutan, se capturan estos artefactos: - -**En Todas las Pruebas:** -- Reporte HTML con cronología y resultados -- JUnit XML para integración CI - -**Solo en Caso de Fallo:** -- Captura de pantalla del estado fallido -- Grabación de video de la prueba -- Archivo de traza para depuración (reproducción paso a paso) -- Logs de red -- Logs de consola - -## Ver Artefactos - -```bash -# Ver reporte HTML en el navegador -npx playwright show-report - -# Ver archivo de traza específico -npx playwright show-trace artifacts/trace-abc123.zip - -# Las capturas de pantalla se guardan en el directorio artifacts/ -open artifacts/search-results.png -``` - -## Detección de Pruebas Inestables - -Si una prueba falla de forma intermitente: - -``` -ADVERTENCIA: PRUEBA INESTABLE DETECTADA: tests/e2e/markets/trade.spec.ts - -La prueba pasó 7 de 10 ejecuciones (70% de tasa de éxito) - -Fallo más frecuente: -"Timeout esperando elemento '[data-testid="confirm-btn"]'" - -Correcciones sugeridas: -1. Agregar espera explícita: await page.waitForSelector('[data-testid="confirm-btn"]') -2. Aumentar timeout: { timeout: 10000 } -3. Verificar condiciones de carrera en el componente -4. Validar que el elemento no está oculto por animación - -Sugerencia de cuarentena: Marcar como test.fixme() hasta que se corrija -``` - -## Configuración de Navegadores - -Las pruebas se ejecutan en múltiples navegadores por defecto: -- PASS: Chromium (Desktop Chrome) -- PASS: Firefox (Desktop) -- PASS: WebKit (Desktop Safari) -- PASS: Mobile Chrome (opcional) - -Configura `playwright.config.ts` para ajustar los navegadores. - -## Integración CI/CD - -Agregar a tu pipeline CI: - -```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/ -``` - -## Buenas Prácticas - -**HAZ:** -- PASS: Usa Page Object Model para mantenibilidad -- PASS: Usa atributos data-testid para los selectores -- PASS: Espera respuestas de API, no timeouts arbitrarios -- PASS: Prueba los flujos de usuario críticos de extremo a extremo -- PASS: Ejecuta las pruebas antes de hacer merge a main -- PASS: Inspecciona los artefactos cuando las pruebas fallen - -**NO HAGAS:** -- FAIL: No uses selectores frágiles (las clases CSS pueden cambiar) -- FAIL: No pruebes detalles de implementación -- FAIL: No ejecutes pruebas contra producción -- FAIL: No ignores pruebas inestables -- FAIL: No omitas la inspección de artefactos en fallos -- FAIL: No pruebes todos los casos límite con E2E (usa pruebas unitarias) - -## Comandos Rápidos - -```bash -# Ejecutar todas las pruebas E2E -npx playwright test - -# Ejecutar archivo de prueba específico -npx playwright test tests/e2e/markets/search.spec.ts - -# Ejecutar en modo headed (ver el navegador) -npx playwright test --headed - -# Depurar prueba -npx playwright test --debug - -# Generar código de prueba -npx playwright codegen http://localhost:3000 - -# Ver reporte -npx playwright show-report -``` - -## Agentes Relacionados - -Este comando invoca al agente `e2e-runner` proporcionado por ECC. - -Para instalaciones manuales, el archivo fuente se encuentra en: -`agents/e2e-runner.md` - -## Integración con Otros Comandos - -- Usa `/plan` para identificar los flujos críticos a probar -- Usa `/tdd` para pruebas unitarias (más rápidas, más detalladas) -- Usa `/e2e` para pruebas de integración y flujos de usuario -- Usa `/code-review` para validar la calidad de las pruebas diff --git a/docs/es/commands/eval.md b/docs/es/commands/eval.md deleted file mode 100644 index 4096b95cc9..0000000000 --- a/docs/es/commands/eval.md +++ /dev/null @@ -1,120 +0,0 @@ -# Comando Eval - -Gestionar el flujo de trabajo de desarrollo orientado a evals. - -## Uso - -`/eval [define|check|report|list] [nombre-feature]` - -## Definir Eval - -`/eval define nombre-feature` - -Crear una nueva definición de eval: - -1. Crear `.claude/evals/nombre-feature.md` con la plantilla: - -```markdown -## EVAL: nombre-feature -Created: $(date) - -### Capability Evals -- [ ] [Descripción de Capability 1] -- [ ] [Descripción de Capability 2] - -### Regression Evals -- [ ] [El comportamiento existente 1 sigue funcionando] -- [ ] [El comportamiento existente 2 sigue funcionando] - -### Success Criteria -- pass@3 > 90% para capability evals -- pass^3 = 100% para regression evals -``` - -2. Pedir al usuario que complete los criterios específicos - -## Verificar Eval - -`/eval check nombre-feature` - -Ejecutar los evals para una feature: - -1. Leer la definición de eval desde `.claude/evals/nombre-feature.md` -2. Para cada capability eval: - - Intentar verificar el criterio - - Registrar PASS/FAIL - - Guardar el intento en `.claude/evals/nombre-feature.log` -3. Para cada regression eval: - - Ejecutar las pruebas relevantes - - Comparar con la línea base - - Registrar PASS/FAIL -4. Reportar el estado actual: - -``` -EVAL CHECK: nombre-feature -======================== -Capability: X/Y pasando -Regression: X/Y pasando -Estado: EN PROGRESO / LISTO -``` - -## Reporte de Eval - -`/eval report nombre-feature` - -Generar reporte exhaustivo de eval: - -``` -EVAL REPORT: nombre-feature -========================= -Generated: $(date) - -CAPABILITY EVALS ----------------- -[eval-1]: PASS (pass@1) -[eval-2]: PASS (pass@2) - requirió reintento -[eval-3]: FAIL - ver notas - -REGRESSION EVALS ----------------- -[test-1]: PASS -[test-2]: PASS -[test-3]: PASS - -METRICS -------- -Capability pass@1: 67% -Capability pass@3: 100% -Regression pass^3: 100% - -NOTES ------ -[Cualquier problema, caso límite u observación] - -RECOMMENDATION --------------- -[SHIP / NEEDS WORK / BLOCKED] -``` - -## Listar Evals - -`/eval list` - -Mostrar todas las definiciones de eval: - -``` -EVAL DEFINITIONS -================ -feature-auth [3/5 pasando] EN PROGRESO -feature-search [5/5 pasando] LISTO -feature-export [0/4 pasando] NO INICIADO -``` - -## Argumentos - -$ARGUMENTS: -- `define ` - Crear nueva definición de eval -- `check ` - Ejecutar y verificar evals -- `report ` - Generar reporte completo -- `list` - Mostrar todos los evals -- `clean` - Eliminar logs de evals antiguos (mantiene las últimas 10 ejecuciones) diff --git a/docs/es/commands/orchestrate.md b/docs/es/commands/orchestrate.md deleted file mode 100644 index 0d8e2bde7d..0000000000 --- a/docs/es/commands/orchestrate.md +++ /dev/null @@ -1,231 +0,0 @@ ---- -description: Guía de orquestación secuencial y tmux/worktree para flujos de trabajo multi-agente. ---- - -# Comando Orchestrate - -Flujo de trabajo secuencial de agentes para tareas complejas. - -## Uso - -`/orchestrate [tipo-workflow] [descripción-de-tarea]` - -## Tipos de Workflow - -### feature -Flujo de trabajo completo de implementación de feature: -``` -planner -> tdd-guide -> code-reviewer -> security-reviewer -``` - -### bugfix -Flujo de trabajo de investigación y corrección de bugs: -``` -planner -> tdd-guide -> code-reviewer -``` - -### refactor -Flujo de trabajo de refactoring seguro: -``` -architect -> code-reviewer -> tdd-guide -``` - -### security -Revisión enfocada en seguridad: -``` -security-reviewer -> code-reviewer -> architect -``` - -## Patrón de Ejecución - -Para cada agente en el flujo de trabajo: - -1. **Invocar el agente** con el contexto del agente anterior -2. **Recopilar la salida** como documento de handoff estructurado -3. **Pasarlo al siguiente agente** en la cadena -4. **Consolidar los resultados** en el reporte final - -## Formato del Documento de Handoff - -Entre agentes, crear el documento de handoff: - -```markdown -## HANDOFF: [agente-anterior] -> [agente-siguiente] - -### Context -[Resumen de lo que se hizo] - -### Findings -[Descubrimientos o decisiones clave] - -### Files Modified -[Lista de archivos tocados] - -### Open Questions -[Elementos sin resolver para el siguiente agente] - -### Recommendations -[Próximos pasos recomendados] -``` - -## Ejemplo: Flujo de Trabajo Feature - -``` -/orchestrate feature "Agregar autenticación de usuarios" -``` - -Ejecuta: - -1. **Agente Planner** - - Analiza los requisitos - - Crea un plan de implementación - - Identifica dependencias - - Salida: `HANDOFF: planner -> tdd-guide` - -2. **Agente TDD Guide** - - Lee el handoff del planner - - Escribe las pruebas primero - - Implementa para que las pruebas pasen - - Salida: `HANDOFF: tdd-guide -> code-reviewer` - -3. **Agente Code Reviewer** - - Revisa la implementación - - Verifica problemas - - Sugiere mejoras - - Salida: `HANDOFF: code-reviewer -> security-reviewer` - -4. **Agente Security Reviewer** - - Auditoría de seguridad - - Verificación de vulnerabilidades - - Aprobación final - - Salida: Reporte Final - -## Formato del Reporte Final - -``` -ORCHESTRATION REPORT -==================== -Workflow: feature -Task: Agregar autenticación de usuarios -Agents: planner -> tdd-guide -> code-reviewer -> security-reviewer - -SUMMARY -------- -[Resumen en un párrafo] - -AGENT OUTPUTS -------------- -Planner: [resumen] -TDD Guide: [resumen] -Code Reviewer: [resumen] -Security Reviewer: [resumen] - -FILES CHANGED -------------- -[Lista de todos los archivos modificados] - -TEST RESULTS ------------- -[Resumen de pruebas pasadas/fallidas] - -SECURITY STATUS ---------------- -[Hallazgos de seguridad] - -RECOMMENDATION --------------- -[SHIP / NEEDS WORK / BLOCKED] -``` - -## Ejecución Paralela - -Para verificaciones independientes, ejecutar agentes en paralelo: - -```markdown -### Fase Paralela -Ejecutar simultáneamente: -- code-reviewer (calidad) -- security-reviewer (seguridad) -- architect (diseño) - -### Combinar Resultados -Combinar las salidas en un único reporte -``` - -Para workers externos en tmux pane con git worktrees separados, usar `node scripts/orchestrate-worktrees.js plan.json --execute`. El patrón de orquestación integrado permanece en proceso; el helper sirve para sesiones de larga duración o cross-harness. - -Cuando los workers necesiten ver archivos locales no rastreados o sucios del checkout principal, agregar `seedPaths` al archivo de plan. ECC superpone solo esas rutas seleccionadas en cada worktree de worker después de `git worktree add`; esto muestra scripts, planes o documentos locales en progreso mientras mantiene el branch aislado. - -```json -{ - "sessionName": "workflow-e2e", - "seedPaths": [ - "scripts/orchestrate-worktrees.js", - "scripts/lib/tmux-worktree-orchestrator.js", - ".claude/plan/workflow-e2e-test.json" - ], - "workers": [ - { "name": "docs", "task": "Actualizar documentación de orquestación." } - ] -} -``` - -Para exportar un snapshot del plano de control de una sesión tmux/worktree activa, ejecutar: - -```bash -node scripts/orchestration-status.js .claude/plan/workflow-visual-proof.json -``` - -El snapshot contiene actividad de sesión, metadatos de pane de tmux, estados de workers, objetivos, seed overlays y resúmenes de handoff recientes en formato JSON. - -## Handoff al Centro de Control del Operador - -Cuando el flujo de trabajo se extiende a múltiples sesiones, worktrees o panes de tmux, agregar un bloque de plano de control al handoff final: - -```markdown -CONTROL PLANE -------------- -Sessions: -- ID o alias de sesión activa -- branch + ruta de worktree para cada worker activo -- nombre del pane de tmux o sesión detached donde aplique - -Diffs: -- resumen de git status -- git diff --stat de archivos tocados -- notas de riesgo de merge/conflictos - -Approvals: -- aprobaciones de usuario pendientes -- pasos bloqueados esperando aprobación - -Telemetry: -- timestamp de última actividad o señal de idle -- deriva estimada de tokens o costos -- eventos de política reportados por hooks o revisores -``` - -Esto mantiene al planner, implementador, revisor y workers del loop comprensibles desde la superficie del operador. - -## Argumentos - -$ARGUMENTS: -- `feature ` - Flujo de trabajo completo de feature -- `bugfix ` - Flujo de trabajo de corrección de bug -- `refactor ` - Flujo de trabajo de refactoring -- `security ` - Flujo de trabajo de revisión de seguridad -- `custom ` - Secuencia de agentes personalizada - -## Ejemplo de Workflow Personalizado - -``` -/orchestrate custom "architect,tdd-guide,code-reviewer" "Rediseñar la capa de caché" -``` - -## Consejos - -1. **Comenzar con planner para features complejas** -2. **Siempre incluir code-reviewer antes del merge** -3. **Usar security-reviewer para auth/pagos/PII** -4. **Mantener los handoffs concisos** - enfocarse en lo que el siguiente agente necesita -5. **Ejecutar validación entre agentes si es necesario** diff --git a/docs/es/commands/tdd.md b/docs/es/commands/tdd.md deleted file mode 100644 index 6c4ff1a456..0000000000 --- a/docs/es/commands/tdd.md +++ /dev/null @@ -1,328 +0,0 @@ ---- -description: Aplicar el flujo de trabajo de desarrollo guiado por pruebas (TDD). Diseña interfaces, crea las pruebas PRIMERO, luego implementa el código mínimo. Garantiza 80%+ de cobertura de código. ---- - -# Comando TDD - -Este comando invoca al agente **tdd-guide** para aplicar la metodología de desarrollo guiado por pruebas. - -## Qué Hace Este Comando - -1. **Diseñar Interfaces** - Definir primero los tipos/interfaces -2. **Crear Pruebas Primero** - Escribir pruebas que fallan (RED) -3. **Implementar Código Mínimo** - Escribir el código justo para que pasen (GREEN) -4. **Refactorizar** - Mejorar el código mientras las pruebas siguen en verde (REFACTOR) -5. **Verificar Cobertura** - Garantizar 80%+ de cobertura de pruebas - -## Cuándo Usarlo - -Usa el comando `/tdd` cuando: -- Implementes nuevas features -- Agregues nuevas funciones/componentes -- Corrijas bugs (primero escribe la prueba que reproduce el bug) -- Refactorices código existente -- Construyas lógica de negocio crítica - -## Cómo Funciona - -El agente tdd-guide: - -1. **Definirá las interfaces** para entradas/salidas -2. **Escribirá pruebas que FALLARÁN** (porque el código aún no existe) -3. **Ejecutará las pruebas** y verificará que fallen por la razón correcta -4. **Escribirá la implementación mínima** para que las pruebas pasen -5. **Ejecutará las pruebas** y verificará que pasen -6. **Refactorizará el código** mientras las pruebas siguen en verde -7. **Verificará la cobertura** y agregará más pruebas si está por debajo del 80% - -## El Ciclo TDD - -``` -ROJO → VERDE → REFACTORIZAR → REPETIR - -ROJO: Escribir una prueba que falla -VERDE: Escribir el código mínimo para que pase -REFACTORIZAR: Mejorar el código, las pruebas siguen pasando -REPETIR: Siguiente feature/escenario -``` - -## Ejemplo de Uso - -``` -Usuario: /tdd Necesito una función para calcular el puntaje de liquidez de un mercado - -Agente (tdd-guide): -# Sesión TDD: Calculadora de Puntaje de Liquidez de Mercado - -## Paso 1: Definir Interface (SCAFFOLD) - -```typescript -// lib/liquidity.ts -export interface MarketData { - totalVolume: number - bidAskSpread: number - activeTraders: number - lastTradeTime: Date -} - -export function calculateLiquidityScore(market: MarketData): number { - // TODO: Implementación - throw new Error('Not implemented') -} -``` - -## Paso 2: Escribir Prueba que Falla (ROJO) - -```typescript -// lib/liquidity.test.ts -import { calculateLiquidityScore } from './liquidity' - -describe('calculateLiquidityScore', () => { - it('debe retornar puntaje alto para mercado líquido', () => { - const market = { - totalVolume: 100000, - bidAskSpread: 0.01, - activeTraders: 500, - lastTradeTime: new Date() - } - - const score = calculateLiquidityScore(market) - - expect(score).toBeGreaterThan(80) - expect(score).toBeLessThanOrEqual(100) - }) - - it('debe retornar puntaje bajo para mercado poco líquido', () => { - const market = { - totalVolume: 100, - bidAskSpread: 0.5, - activeTraders: 2, - lastTradeTime: new Date(Date.now() - 86400000) // hace 1 día - } - - const score = calculateLiquidityScore(market) - - expect(score).toBeLessThan(30) - expect(score).toBeGreaterThanOrEqual(0) - }) - - it('debe manejar caso límite: volumen cero', () => { - const market = { - totalVolume: 0, - bidAskSpread: 0, - activeTraders: 0, - lastTradeTime: new Date() - } - - const score = calculateLiquidityScore(market) - - expect(score).toBe(0) - }) -}) -``` - -## Paso 3: Ejecutar Pruebas - Verificar el Fallo - -```bash -npm test lib/liquidity.test.ts - -FAIL lib/liquidity.test.ts - ✕ debe retornar puntaje alto para mercado líquido (2 ms) - Error: Not implemented - -1 test failed, 0 passed -``` - -PASS: Las pruebas fallan como se esperaba. Listo para implementar. - -## Paso 4: Implementar Código Mínimo (VERDE) - -```typescript -// lib/liquidity.ts -export function calculateLiquidityScore(market: MarketData): number { - // Manejar caso límite de volumen cero - if (market.totalVolume === 0) { - return 0 - } - - // Calcular puntajes de componentes (escala 0-100) - const volumeScore = Math.min(market.totalVolume / 1000, 100) - const spreadScore = Math.max(100 - (market.bidAskSpread * 1000), 0) - const traderScore = Math.min(market.activeTraders / 10, 100) - - // Bonus por actividad reciente - const hoursSinceLastTrade = (Date.now() - market.lastTradeTime.getTime()) / (1000 * 60 * 60) - const recencyScore = Math.max(100 - (hoursSinceLastTrade * 10), 0) - - // Promedio ponderado - const score = ( - volumeScore * 0.4 + - spreadScore * 0.3 + - traderScore * 0.2 + - recencyScore * 0.1 - ) - - return Math.min(Math.max(score, 0), 100) // Limitar entre 0-100 -} -``` - -## Paso 5: Ejecutar Pruebas - Verificar el Éxito - -```bash -npm test lib/liquidity.test.ts - -PASS lib/liquidity.test.ts - ✓ debe retornar puntaje alto para mercado líquido (3 ms) - ✓ debe retornar puntaje bajo para mercado poco líquido (2 ms) - ✓ debe manejar caso límite: volumen cero (1 ms) - -3 tests passed -``` - -PASS: ¡Todas las pruebas pasan! - -## Paso 6: Refactorizar (MEJORAR) - -```typescript -// lib/liquidity.ts - Refactorizado con constantes y mejor legibilidad -const WEIGHTS = { - VOLUME: 0.4, - SPREAD: 0.3, - TRADERS: 0.2, - RECENCY: 0.1, -} as const - -const SCALE_FACTORS = { - VOLUME: 1000, - SPREAD: 1000, - TRADERS: 10, - RECENCY_PENALTY: 10, -} as const - -function clamp(value: number, min: number, max: number): number { - return Math.min(Math.max(value, min), max) -} - -export function calculateLiquidityScore(market: MarketData): number { - if (market.totalVolume === 0) return 0 - - const volumeScore = Math.min(market.totalVolume / SCALE_FACTORS.VOLUME, 100) - const spreadScore = clamp(100 - (market.bidAskSpread * SCALE_FACTORS.SPREAD), 0, 100) - const traderScore = Math.min(market.activeTraders / SCALE_FACTORS.TRADERS, 100) - - const hoursSinceLastTrade = (Date.now() - market.lastTradeTime.getTime()) / (1000 * 60 * 60) - const recencyScore = clamp(100 - (hoursSinceLastTrade * SCALE_FACTORS.RECENCY_PENALTY), 0, 100) - - const weightedScore = - volumeScore * WEIGHTS.VOLUME + - spreadScore * WEIGHTS.SPREAD + - traderScore * WEIGHTS.TRADERS + - recencyScore * WEIGHTS.RECENCY - - return clamp(weightedScore, 0, 100) -} -``` - -## Paso 7: Verificar que las Pruebas Siguen Pasando - -```bash -npm test lib/liquidity.test.ts - -PASS lib/liquidity.test.ts - ✓ debe retornar puntaje alto para mercado líquido (3 ms) - ✓ debe retornar puntaje bajo para mercado poco líquido (2 ms) - ✓ debe manejar caso límite: volumen cero (1 ms) - -3 tests passed -``` - -PASS: ¡Refactoring completo, las pruebas siguen pasando! - -## Paso 8: Verificar Cobertura - -```bash -npm test -- --coverage lib/liquidity.test.ts - -File | % Stmts | % Branch | % Funcs | % Lines ----------------|---------|----------|---------|-------- -liquidity.ts | 100 | 100 | 100 | 100 - -Coverage: 100% PASS (Objetivo: 80%) -``` - -PASS: ¡Sesión TDD completada! -``` - -## Buenas Prácticas de TDD - -**HAZ:** -- PASS: Escribe la prueba ANTES de cualquier implementación -- PASS: Ejecuta las pruebas y verifica que fallen antes de implementar -- PASS: Escribe el código mínimo para que las pruebas pasen -- PASS: Refactoriza después de que las pruebas estén en verde -- PASS: Agrega casos límite y escenarios de error -- PASS: Apunta a 80%+ de cobertura (100% para código crítico) - -**NO HAGAS:** -- FAIL: No escribas implementación antes de las pruebas -- FAIL: No omitas ejecutar las pruebas después de cada cambio -- FAIL: No escribas demasiado código de una vez -- FAIL: No ignores pruebas que fallan -- FAIL: No pruebes detalles de implementación (prueba el comportamiento) -- FAIL: No hagas mock de todo (prefiere pruebas de integración) - -## Tipos de Pruebas a Incluir - -**Pruebas Unitarias** (nivel de función): -- Escenarios de camino feliz -- Casos límite (vacío, null, valores máximos) -- Condiciones de error -- Valores límite - -**Pruebas de Integración** (nivel de componente): -- Endpoints de API -- Operaciones de base de datos -- Llamadas a servicios externos -- Componentes React con hooks - -**Pruebas E2E** (usar el comando `/e2e`): -- Flujos de usuario críticos -- Procesos de múltiples pasos -- Integración full stack - -## Requisitos de Cobertura - -- **Mínimo 80%** para todo el código -- **100% requerido**: - - Cálculos financieros - - Lógica de autenticación - - Código crítico de seguridad - - Lógica de negocio principal - -## Notas Importantes - -**OBLIGATORIO**: Las pruebas deben escribirse ANTES de la implementación. El ciclo TDD: - -1. **ROJO** - Escribir prueba que falla -2. **VERDE** - Implementar para que pase -3. **REFACTORIZAR** - Mejorar el código - -Nunca omitas la fase ROJO. Nunca escribas código antes de las pruebas. - -## Integración con Otros Comandos - -- Usa `/plan` primero para entender qué construir -- Usa `/tdd` para implementar con pruebas -- Usa `/build-fix` si surgen errores de build -- Usa `/code-review` para revisar la implementación -- Usa `/test-coverage` para verificar la cobertura - -## Agentes Relacionados - -Este comando invoca al agente `tdd-guide` proporcionado por ECC. - -La skill relacionada `tdd-workflow` también viene incluida con ECC. - -Para instalaciones manuales, los archivos fuente se encuentran en: -- `agents/tdd-guide.md` -- `skills/tdd-workflow/SKILL.md` diff --git a/docs/es/commands/verify.md b/docs/es/commands/verify.md deleted file mode 100644 index e9b6e4e640..0000000000 --- a/docs/es/commands/verify.md +++ /dev/null @@ -1,59 +0,0 @@ -# Comando Verify - -Ejecutar verificación exhaustiva sobre el estado actual del código base. - -## Instrucciones - -Ejecutar la verificación exactamente en este orden: - -1. **Verificación de Build** - - Ejecutar el comando de build para este proyecto - - Si falla, reportar los errores y DETENER - -2. **Verificación de Tipos** - - Ejecutar TypeScript/verificador de tipos - - Reportar todos los errores con archivo:línea - -3. **Verificación de Lint** - - Ejecutar el linter - - Reportar advertencias y errores - -4. **Suite de Pruebas** - - Ejecutar todas las pruebas - - Reportar cantidad de pasadas/fallidas - - Reportar porcentaje de cobertura - -5. **Auditoría de console.log** - - Buscar console.log en los archivos fuente - - Reportar las ubicaciones - -6. **Estado de Git** - - Mostrar cambios no confirmados - - Mostrar archivos modificados desde el último commit - -## Salida - -Generar un reporte de verificación resumido: - -``` -VERIFICACIÓN: [PASÓ/FALLÓ] - -Build: [OK/FALLÓ] -Tipos: [OK/X errores] -Lint: [OK/X problemas] -Pruebas: [X/Y pasaron, Z% cobertura] -Secretos: [OK/X encontrados] -Logs: [OK/X console.log] - -Listo para PR: [SÍ/NO] -``` - -Si hay algún problema crítico, listarlos con sugerencias de corrección. - -## Argumentos - -$ARGUMENTS puede ser: -- `quick` - Solo build + tipos -- `full` - Todas las verificaciones (por defecto) -- `pre-commit` - Verificaciones relevantes para commits -- `pre-pr` - Escaneo de seguridad más verificaciones completas diff --git a/docs/ja-JP/commands/README.md b/docs/ja-JP/commands/README.md index 2a4a3de5a1..c0e655da6a 100644 --- a/docs/ja-JP/commands/README.md +++ b/docs/ja-JP/commands/README.md @@ -15,10 +15,11 @@ - `/go-review` - Go コードをレビュー ### テスト & 検証 -- `/tdd` - テスト駆動開発ワークフロー -- `/e2e` - E2E テストを実行 +- `/go-test`, `/kotlin-test`, `/rust-test`, `/cpp-test`, `/flutter-test`, `/react-test` - 言語別 TDD ワークフロー - `/test-coverage` - テストカバレッジを確認 -- `/verify` - 実装を検証 +- （`/tdd` は廃止 → `tdd-workflow` スキルを使用） +- （`/e2e` は廃止 → `e2e-testing` スキルを使用） +- （`/verify` は廃止 → `verification-loop` スキルを使用） ### 計画 & 実装 - `/plan` - 機能実装計画を作成 @@ -33,7 +34,7 @@ - `/checkpoint` - 実装チェックポイント - `/evolve` - 機能を進化 - `/learn` - プロジェクトについて学ぶ -- `/orchestrate` - ワークフロー調整 +- （`/orchestrate` は廃止 → `dmux-workflows` / `autonomous-agent-harness` スキルを使用） - `/pm2` - PM2 デプロイメント管理 - `/setup-pm` - PM2 を設定 - `/sessions` - セッション管理 @@ -49,7 +50,7 @@ Claude Code でコマンドを実行： ```bash /plan -/tdd +/test-coverage /code-review /build-fix ``` @@ -65,14 +66,14 @@ Claude：実行 → `/plan` コマンド ### 開発ワークフロー 1. `/plan` - 実装計画を作成 -2. `/tdd` - テストを書いて機能を実装 +2. `tdd-workflow` スキル - テストを書いて機能を実装 3. `/code-review` - コード品質をレビュー 4. `/build-fix` - ビルドエラーを修正 -5. `/e2e` - E2E テストを実行 +5. `e2e-testing` スキル - E2E テストを実行 6. `/update-docs` - ドキュメントを更新 ### デバッグワークフロー -1. `/verify` - 実装を検証 +1. `verification-loop` スキル - 実装を検証 2. `/code-review` - 品質をチェック 3. `/build-fix` - エラーを修正 4. `/test-coverage` - カバレッジを確認 diff --git a/docs/ja-JP/commands/claw.md b/docs/ja-JP/commands/claw.md deleted file mode 100644 index 8e47ad1b3f..0000000000 --- a/docs/ja-JP/commands/claw.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -description: NanoClaw v2 を起動します — モデルルーティング、スキルホットロード、ブランチ、圧縮、エクスポート、メトリクス機能を備えた ECC の永続的でゼロ依存の REPL。 ---- - -# Claw コマンド - -永続的な Markdown 履歴と操作コントロールを備えた、インタラクティブな AI エージェントセッションを起動します。 - -## 使用方法 - -```bash -node scripts/claw.js -``` - -または npm 経由： - -```bash -npm run claw -``` - -## 環境変数 - -| 変数 | デフォルト値 | 説明 | -|----------|---------|-------------| -| `CLAW_SESSION` | `default` | セッション名（英数字 + ハイフン） | -| `CLAW_SKILLS` | *(空)* | 起動時に読み込むスキルのカンマ区切りリスト | -| `CLAW_MODEL` | `sonnet` | セッションのデフォルトモデル | - -## REPL コマンド - -```text -/help ヘルプを表示 -/clear 現在のセッション履歴をクリア -/history 会話履歴全体を表示 -/sessions 保存済みセッションを一覧表示 -/model [name] モデルを表示/設定 -/load スキルをコンテキストにホットロード -/branch 現在のセッションをブランチ -/search セッションをまたいでクエリを検索 -/compact 古いラウンドを圧縮し、最近のコンテキストを保持 -/export [path] セッションをエクスポート -/metrics セッションメトリクスを表示 -exit 終了 -``` - -## 説明 - -* NanoClaw はゼロ依存を維持します。 -* セッションは `~/.claude/claw/.md` に保存されます。 -* 圧縮は最近のラウンドを保持し、圧縮ヘッダーを書き込みます。 -* エクスポートは Markdown、JSON ラウンド、プレーンテキストに対応しています。 diff --git a/docs/ja-JP/commands/context-budget.md b/docs/ja-JP/commands/context-budget.md deleted file mode 100644 index 763e24c22f..0000000000 --- a/docs/ja-JP/commands/context-budget.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -description: エージェント、スキル、MCP サーバー、ルールにわたるコンテキストウィンドウの使用状況を分析し、最適化の機会を探ります。トークンオーバーヘッドの削減とパフォーマンス警告の回避に役立ちます。 ---- - -# コンテキストバジェット最適化ツール - -Claude Code の設定におけるコンテキストウィンドウの消費量を分析し、トークンオーバーヘッドを削減するための実用的な推奨事項を提供します。 - -## 使用方法 - -``` -/context-budget [--verbose] -``` - -* デフォルト：サマリーと主要な推奨事項を提供 -* `--verbose`：コンポーネントごとの完全な内訳を提供 - -$ARGUMENTS - -## 操作手順 - -**context-budget** スキル（`skills/context-budget/SKILL.md`）を実行し、以下を入力します： - -1. `$ARGUMENTS` に `--verbose` フラグが存在する場合、そのフラグを渡す -2. ユーザーが別途指定しない限り、200K コンテキストウィンドウ（Claude Sonnet のデフォルト）を仮定する -3. スキルの4フェーズに従う：インベントリ → 分類 → 問題検出 → レポート -4. フォーマット済みのコンテキストバジェットレポートをユーザーに出力する - -すべてのスキャンロジック、トークン推定、問題検出、レポートフォーマットはスキルが担当します。 diff --git a/docs/ja-JP/commands/devfleet.md b/docs/ja-JP/commands/devfleet.md deleted file mode 100644 index 1eb1d966a1..0000000000 --- a/docs/ja-JP/commands/devfleet.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -description: Claude DevFleet を使って並列 Claude Code エージェントをオーケストレーションします — 自然言語でプロジェクトを計画し、隔離されたワークツリーにエージェントをディスパッチし、進捗を監視し、構造化レポートを読み取ります。 ---- - -# DevFleet — マルチエージェントオーケストレーション - -Claude DevFleet を使って並列の Claude Code エージェントをオーケストレーションします。各エージェントは隔離された git worktree 内で動作し、完全なツールチェーンを備えています。 - -DevFleet MCP サーバーが必要です：`claude mcp add devfleet --transport http http://localhost:18801/mcp` - -## フロー - -``` -ユーザーがプロジェクトを説明 - → plan_project(prompt) → タスク DAG と依存関係 - → 計画を表示し、承認を取得 - → dispatch_mission(M1) → エージェントがワークスペースで生成 - → M1 完了 → 自動マージ → M2 が自動ディスパッチ（M1 に依存） - → M2 完了 → 自動マージ - → get_report(M2) → ファイル変更、完了内容、エラー、次のステップ - → ユーザーにサマリーをレポート -``` - -## ワークフロー - -1. **ユーザーの説明に基づいてプロジェクトを計画する**： - -``` -mcp__devfleet__plan_project(prompt="<ユーザーの説明>") -``` - -これはチェーン状のタスクを含むプロジェクトを返します。ユーザーに以下を表示します： - -* プロジェクト名と ID -* 各タスク：タイトル、タイプ、依存関係 -* 依存関係 DAG（どのタスクがどのタスクをブロックしているか） - -2. **ディスパッチ前にユーザーの承認を待つ**。計画を明確に表示します。 - -3. **最初のタスクをディスパッチする**（`depends_on` が空のタスク）： - -``` -mcp__devfleet__dispatch_mission(mission_id="") -``` - -残りのタスクは依存関係が完了すると自動的にディスパッチされます（`plan_project` が `auto_dispatch=true` でタスクを作成するため）。`create_mission` を使ってタスクを手動作成する場合は、この動作を有効にするために `auto_dispatch=true` を明示的に設定する必要があります。 - -4. **進捗を監視する** — 実行中の内容を確認： - -``` -mcp__devfleet__get_dashboard() -``` - -または特定のタスクを確認： - -``` -mcp__devfleet__get_mission_status(mission_id="") -``` - -長時間実行するタスクには、`wait_for_mission` ではなく `get_mission_status` によるポーリングを優先し、ユーザーが進捗の更新を確認できるようにします。 - -5. **完了した各タスクのレポートを読む**： - -``` -mcp__devfleet__get_report(mission_id="") -``` - -終了状態に達した各タスクに対してこのツールを呼び出します。レポートには files\_changed、what\_done、what\_open、what\_tested、what\_untested、next\_steps、errors\_encountered が含まれます。 - -## 利用可能なすべてのツール - -| ツール | 用途 | -|------|---------| -| `plan_project(prompt)` | AI が説明を `auto_dispatch=true` のチェーン状タスクに分解する | -| `create_project(name, path?, description?)` | プロジェクトを手動作成し、`project_id` を返す | -| `create_mission(project_id, title, prompt, depends_on?, auto_dispatch?)` | タスクを追加する。`depends_on` はタスク ID 文字列のリスト | -| `dispatch_mission(mission_id, model?, max_turns?)` | エージェントを起動する | -| `cancel_mission(mission_id)` | 実行中のエージェントを停止する | -| `wait_for_mission(mission_id, timeout_seconds?)` | 完了までブロックする（長いタスクにはポーリングを優先） | -| `get_mission_status(mission_id)` | ノンブロッキングで進捗を確認する | -| `get_report(mission_id)` | 構造化レポートを読む | -| `get_dashboard()` | システム概要 | -| `list_projects()` | プロジェクトを参照する | -| `list_missions(project_id, status?)` | タスクを一覧表示する | - -## ガイドライン - -* ユーザーが明示的に「始めてください」と言わない限り、ディスパッチ前に必ず計画を確認する -* ステータスをレポートする際はタスクのタイトルと ID を含める -* タスクが失敗した場合、再試行前にそのレポートを読んでエラーを把握する -* エージェントの同時実行数は設定可能（デフォルト：3）。超過したタスクはキューに入れられ、スロットが空くと自動的にディスパッチされる。スロットの可用性は `get_dashboard()` で確認する -* 依存関係は DAG を形成する — 循環依存は絶対に作成しない -* 各エージェントは完了時に自動的に worktree をマージする。マージ競合が発生した場合、変更は手動解決のために worktree ブランチに保持される diff --git a/docs/ja-JP/commands/docs.md b/docs/ja-JP/commands/docs.md deleted file mode 100644 index eff495027f..0000000000 --- a/docs/ja-JP/commands/docs.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -description: Context7 を使ってライブラリやトピックの最新ドキュメントを検索します。 ---- - -# /docs - -## 目的 - -ライブラリ、フレームワーク、または API の最新ドキュメントを検索し、関連するコードスニペットを含む要約された回答を返します。Context7 MCP（resolve-library-id と query-docs）を使用するため、回答はトレーニングデータではなく最新のドキュメントを反映しています。 - -## 使い方 - -``` -/docs [library name] [question] -``` - -複数の単語からなる引数には、単一のトークンとして解析されるよう引用符を使用してください。例：`/docs "Next.js" "How do I configure middleware?"` - -ライブラリまたは質問が省略された場合、ユーザーに入力を求めます： - -1. ライブラリまたは製品名（例：Next.js、Prisma、Supabase）。 -2. 具体的な質問またはタスク（例：「ミドルウェアの設定方法は？」、「認証方法」）。 - -## ワークフロー - -1. **ライブラリ ID を解決する** — Context7 ツール `resolve-library-id` をライブラリ名とユーザーの質問とともに呼び出し、Context7 互換のライブラリ ID（例：`/vercel/next.js`）を取得する。 -2. **ドキュメントをクエリする** — そのライブラリ ID とユーザーの質問を使って `query-docs` を呼び出す。 -3. **要約する** — 簡潔な回答を返し、取得したドキュメントから抽出した関連コード例を含める。ライブラリ（関連する場合はバージョンも含めて）に言及する。 - -## 出力 - -ユーザーは、最新のドキュメントに基づいた簡潔で正確な回答と、役立つコードスニペットを受け取ります。Context7 が利用できない場合は、その旨を説明し、トレーニングデータに基づいて回答しますが、ドキュメントが古い可能性があることを注記します。 diff --git a/docs/ja-JP/commands/e2e.md b/docs/ja-JP/commands/e2e.md deleted file mode 100644 index 1b728fa150..0000000000 --- a/docs/ja-JP/commands/e2e.md +++ /dev/null @@ -1,370 +0,0 @@ ---- -description: Playwright を使用してエンドツーエンドテストを生成して実行します。テストジャーニーを作成し、テストを実行し、スクリーンショット/ビデオ/トレースをキャプチャし、アーティファクトをアップロードします。 ---- - -# E2E コマンド - -このコマンドは **e2e-runner** エージェントを呼び出して、Playwright を使用してエンドツーエンドテストを生成、保守、実行します。 - -## このコマンドの機能 - -1. **テストジャーニー生成** - ユーザーフローの Playwright テストを作成 -2. **E2E テスト実行** - 複数ブラウザ間でテストを実行 -3. **アーティファクトキャプチャ** - 失敗時のスクリーンショット、ビデオ、トレース -4. **結果アップロード** - HTML レポートと JUnit XML -5. **不安定なテスト識別** - 不安定なテストを分離 - -## いつ使用しますするか - -以下の場合に `/e2e` を使用します： - -* 重要なユーザージャーニーをテスト（ログイン、取引、支払い） -* マルチステップフローがエンドツーエンドで機能することを検証 -* UI インタラクションとナビゲーションをテスト -* フロントエンドとバックエンド間の統合を検証 -* 本番環境デプロイメント向けの準備 - -## 動作方法 - -e2e-runner エージェントは： - -1. **ユーザーフローを分析**してテストシナリオを特定 -2. **ページオブジェクトモデルパターンを使用して Playwright テストを生成** -3. **複数ブラウザ間（Chrome、Firefox、Safari）でテストを実行** -4. **失敗をキャプチャ**（スクリーンショット、ビデオ、トレース含む） -5. **結果とアーティファクトを含むレポートを生成** -6. **不安定なテストを特定**して修正を推奨 - -## 使用します示例 - -```` -User: /e2e マーケット検索と表示フローをテスト - -Agent (e2e-runner): -# E2Eテスト生成: マーケット検索と表示フロー - -## 特定されたテストシナリオ - -**ユーザージャーニー:** マーケット検索 → 結果表示 → マーケットクリック → 詳細表示 - -**テストカバレッジ:** -1. マーケットページに遷移 -2. セマンティック検索を実行 -3. 検索結果を検証 -4. 最初の結果をクリック -5. マーケット詳細ページの読み込みを検証 -6. チャートの描画を検証 - -## 生成されたテストコード - -```typescript -// tests/e2e/markets/search-and-view.spec.ts -import { test, expect } from '@playwright/test' -import { MarketsPage } from '../../pages/MarketsPage' -import { MarketDetailsPage } from '../../pages/MarketDetailsPage' - -test.describe('Market Search and View Flow', () => { - test('user can search markets and view details', async ({ page }) => { - // 1. Navigate to markets page - const marketsPage = new MarketsPage(page) - await marketsPage.goto() - - // Verify page loaded - await expect(page).toHaveTitle(/Markets/) - await expect(page.locator('h1')).toContainText('Markets') - - // 2. Perform semantic search - await marketsPage.searchMarkets('election') - - // Wait for API response - await page.waitForResponse(resp => - resp.url().includes('/api/markets/search') && resp.status() === 200 - ) - - // 3. Verify search results - const marketCards = marketsPage.marketCards - await expect(marketCards.first()).toBeVisible() - const resultCount = await marketCards.count() - expect(resultCount).toBeGreaterThan(0) - - // Take screenshot of search results - await page.screenshot({ path: 'artifacts/search-results.png' }) - - // 4. Click on first result - const firstMarketTitle = await marketCards.first().textContent() - await marketCards.first().click() - - // 5. Verify market details page loads - await expect(page).toHaveURL(/\/markets\/[a-z0-9-]+/) - - const detailsPage = new MarketDetailsPage(page) - await expect(detailsPage.marketName).toBeVisible() - await expect(detailsPage.marketDescription).toBeVisible() - - // 6. Verify chart renders - await expect(detailsPage.priceChart).toBeVisible() - - // Verify market name matches - const detailsTitle = await detailsPage.marketName.textContent() - expect(detailsTitle?.toLowerCase()).toContain( - firstMarketTitle?.toLowerCase().substring(0, 20) || '' - ) - - // Take screenshot of market details - await page.screenshot({ path: 'artifacts/market-details.png' }) - }) - - test('search with no results shows empty state', async ({ page }) => { - const marketsPage = new MarketsPage(page) - await marketsPage.goto() - - // Search for non-existent market - 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) - }) -}) -```` - -## テスト実行 - -```bash -# 生成されたテストを実行 -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 -``` - -## テストレポート - -``` -╔══════════════════════════════════════════════════════════════╗ -║ E2Eテスト結果 ║ -╠══════════════════════════════════════════════════════════════╣ -║ ステータス: PASS: 全テスト合格 ║ -║ 合計: 3テスト ║ -║ 合格: 3 (100%) ║ -║ 失敗: 0 ║ -║ 不安定: 0 ║ -║ 所要時間: 9.1s ║ -╚══════════════════════════════════════════════════════════════╝ - -アーティファクト: - スクリーンショット: 2ファイル - ビデオ: 0ファイル (失敗時のみ) - トレース: 0ファイル (失敗時のみ) - HTMLレポート: playwright-report/index.html - -レポート表示: npx playwright show-report -``` - -PASS: E2E テストスイートは CI/CD 統合の準備ができました！ - -```` - -## テストアーティファクト - -テスト実行時、以下のアーティファクトがキャプチャされます: - -**全テスト共通:** -- タイムラインと結果を含むHTMLレポート -- CI統合用のJUnit XML - -**失敗時のみ:** -- 失敗状態のスクリーンショット -- テストのビデオ録画 -- デバッグ用トレースファイル (ステップバイステップ再生) -- ネットワークログ -- コンソールログ - -## アーティファクトの確認 - -```bash -# ブラウザでHTMLレポートを表示 -npx playwright show-report - -# 特定のトレースファイルを表示 -npx playwright show-trace artifacts/trace-abc123.zip - -# スクリーンショットはartifacts/ディレクトリに保存 -open artifacts/search-results.png -```` - -## 不安定なテスト検出 - -テストが断続的に失敗する場合： - -``` -WARNING: FLAKY TEST DETECTED: tests/e2e/markets/trade.spec.ts - -テストは10回中7回合格 (合格率70%) - -よくある失敗: -"Timeout waiting for element '[data-testid="confirm-btn"]'" - -推奨修正: -1. 明示的な待機を追加: await page.waitForSelector('[data-testid="confirm-btn"]') -2. タイムアウトを増加: { timeout: 10000 } -3. コンポーネントの競合状態を確認 -4. 要素がアニメーションで隠れていないか確認 - -隔離推奨: 修正されるまでtest.fixme()としてマーク -``` - -## ブラウザ設定 - -デフォルトでは、テストは複数のブラウザで実行されます： - -* PASS: Chromium（デスクトップ Chrome） -* PASS: Firefox（デスクトップ） -* PASS: WebKit（デスクトップ Safari） -* PASS: Mobile Chrome（オプション） - -`playwright.config.ts` で設定してブラウザを調整します。 - -## CI/CD 統合 - -CI パイプラインに追加： - -```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 固有の重要フロー - -PMX の場合、以下の E2E テストを優先： - -**重大（常に成功する必要）：** - -1. ユーザーがウォレットを接続できる -2. ユーザーが市場をブラウズできる -3. ユーザーが市場を検索できる（セマンティック検索） -4. ユーザーが市場の詳細を表示できる -5. ユーザーが取引注文を配置できる（テスト資金使用します） -6. 市場が正しく決済される -7. ユーザーが資金を引き出せる - -**重要：** - -1. 市場作成フロー -2. ユーザープロフィール更新 -3. リアルタイム価格更新 -4. チャートレンダリング -5. 市場のフィルタリングとソート -6. モバイルレスポンシブレイアウト - -## ベストプラクティス - -**すべき事：** - -* PASS: 保守性を高めるためページオブジェクトモデルを使用します -* PASS: セレクタとして data-testid 属性を使用します -* PASS: 任意のタイムアウトではなく API レスポンスを待機 -* PASS: 重要なユーザージャーニーのエンドツーエンドテスト -* PASS: main にマージする前にテストを実行 -* PASS: テスト失敗時にアーティファクトをレビュー - -**すべきでない事：** - -* FAIL: 不安定なセレクタを使用します（CSS クラスは変わる可能性） -* FAIL: 実装の詳細をテスト -* FAIL: 本番環境に対してテストを実行 -* FAIL: 不安定なテストを無視 -* FAIL: 失敗時にアーティファクトレビューをスキップ -* FAIL: E2E テストですべてのエッジケースをテスト（単体テストを使用します） - -## 重要な注意事項 - -**PMX にとって重大：** - -* 実際の資金に関わる E2E テストは**テストネット/ステージング環境でのみ実行**する必要があります -* 本番環境に対して取引テストを実行しないでください -* 金融テストに `test.skip(process.env.NODE_ENV === 'production')` を設定 -* 少量のテスト資金を持つテストウォレットのみを使用します - -## 他のコマンドとの統合 - -* `/plan` を使用してテストする重要なジャーニーを特定 -* `/tdd` を単体テストに使用します（より速く、より細粒度） -* `/e2e` を統合とユーザージャーニーテストに使用します -* `/code-review` を使用してテスト品質を検証 - -## 関連エージェント - -このコマンドは `~/.claude/agents/e2e-runner.md` の `e2e-runner` エージェントを呼び出します。 - -## 快速命令 - -```bash -# 全E2Eテストを実行 -npx playwright test - -# 特定のテストファイルを実行 -npx playwright test tests/e2e/markets/search.spec.ts - -# ヘッドモードで実行 (ブラウザ表示) -npx playwright test --headed - -# テストをデバッグ -npx playwright test --debug - -# テストコードを生成 -npx playwright codegen http://localhost:3000 - -# レポートを表示 -npx playwright show-report -``` diff --git a/docs/ja-JP/commands/eval.md b/docs/ja-JP/commands/eval.md deleted file mode 100644 index 5a85be85fc..0000000000 --- a/docs/ja-JP/commands/eval.md +++ /dev/null @@ -1,120 +0,0 @@ -# Evalコマンド - -評価駆動開発ワークフローを管理します。 - -## 使用方法 - -`/eval [define|check|report|list] [機能名]` - -## Evalの定義 - -`/eval define 機能名` - -新しい評価定義を作成します。 - -1. テンプレートを使用して `.claude/evals/機能名.md` を作成: - -```markdown -## EVAL: 機能名 -作成日: $(date) - -### 機能評価 -- [ ] [機能1の説明] -- [ ] [機能2の説明] - -### 回帰評価 -- [ ] [既存の動作1が正常に動作する] -- [ ] [既存の動作2が正常に動作する] - -### 成功基準 -- 機能評価: pass@3 > 90% -- 回帰評価: pass^3 = 100% -``` - -2. ユーザーに具体的な基準を記入するよう促す - -## Evalのチェック - -`/eval check 機能名` - -機能の評価を実行します。 - -1. `.claude/evals/機能名.md` から評価定義を読み込む -2. 各機能評価について: - - 基準の検証を試行 - - PASS/FAILを記録 - - `.claude/evals/機能名.log` に試行を記録 -3. 各回帰評価について: - - 関連するテストを実行 - - ベースラインと比較 - - PASS/FAILを記録 -4. 現在のステータスを報告: - -``` -EVAL CHECK: 機能名 -======================== -機能評価: X/Y 合格 -回帰評価: X/Y 合格 -ステータス: 進行中 / 準備完了 -``` - -## Evalの報告 - -`/eval report 機能名` - -包括的な評価レポートを生成します。 - -``` -EVAL REPORT: 機能名 -========================= -生成日時: $(date) - -機能評価 ----------------- -[eval-1]: PASS (pass@1) -[eval-2]: PASS (pass@2) - 再試行が必要でした -[eval-3]: FAIL - 備考を参照 - -回帰評価 ----------------- -[test-1]: PASS -[test-2]: PASS -[test-3]: PASS - -メトリクス -------- -機能評価 pass@1: 67% -機能評価 pass@3: 100% -回帰評価 pass^3: 100% - -備考 ------ -[問題、エッジケース、または観察事項] - -推奨事項 --------------- -[リリース可 / 要修正 / ブロック中] -``` - -## Evalのリスト表示 - -`/eval list` - -すべての評価定義を表示します。 - -``` -EVAL 定義一覧 -================ -feature-auth [3/5 合格] 進行中 -feature-search [5/5 合格] 準備完了 -feature-export [0/4 合格] 未着手 -``` - -## 引数 - -$ARGUMENTS: -- `define <名前>` - 新しい評価定義を作成 -- `check <名前>` - 評価を実行してチェック -- `report <名前>` - 完全なレポートを生成 -- `list` - すべての評価を表示 -- `clean` - 古い評価ログを削除（最新10件を保持） diff --git a/docs/ja-JP/commands/orchestrate.md b/docs/ja-JP/commands/orchestrate.md deleted file mode 100644 index b06fa04901..0000000000 --- a/docs/ja-JP/commands/orchestrate.md +++ /dev/null @@ -1,172 +0,0 @@ -# Orchestrateコマンド - -複雑なタスクのための連続的なエージェントワークフロー。 - -## 使用方法 - -`/orchestrate [ワークフロータイプ] [タスク説明]` - -## ワークフロータイプ - -### feature -完全な機能実装ワークフロー: -``` -planner -> tdd-guide -> code-reviewer -> security-reviewer -``` - -### bugfix -バグ調査と修正ワークフロー: -``` -explorer -> tdd-guide -> code-reviewer -``` - -### refactor -安全なリファクタリングワークフロー: -``` -architect -> code-reviewer -> tdd-guide -``` - -### security -セキュリティ重視のレビュー: -``` -security-reviewer -> code-reviewer -> architect -``` - -## 実行パターン - -ワークフロー内の各エージェントに対して: - -1. 前のエージェントからのコンテキストで**エージェントを呼び出す** -2. 出力を構造化されたハンドオフドキュメントとして**収集** -3. チェーン内の**次のエージェントに渡す** -4. 結果を最終レポートに**集約** - -## ハンドオフドキュメント形式 - -エージェント間でハンドオフドキュメントを作成します: - -```markdown -## HANDOFF: [前のエージェント] -> [次のエージェント] - -### コンテキスト -[実行された内容の要約] - -### 発見事項 -[重要な発見または決定] - -### 変更されたファイル -[変更されたファイルのリスト] - -### 未解決の質問 -[次のエージェントのための未解決項目] - -### 推奨事項 -[推奨される次のステップ] -``` - -## 例: 機能ワークフロー - -``` -/orchestrate feature "Add user authentication" -``` - -以下を実行します: - -1. **Plannerエージェント** - - 要件を分析 - - 実装計画を作成 - - 依存関係を特定 - - 出力: `HANDOFF: planner -> tdd-guide` - -2. **TDD Guideエージェント** - - プランナーのハンドオフを読み込む - - 最初にテストを記述 - - テストに合格するように実装 - - 出力: `HANDOFF: tdd-guide -> code-reviewer` - -3. **Code Reviewerエージェント** - - 実装をレビュー - - 問題をチェック - - 改善を提案 - - 出力: `HANDOFF: code-reviewer -> security-reviewer` - -4. **Security Reviewerエージェント** - - セキュリティ監査 - - 脆弱性チェック - - 最終承認 - - 出力: 最終レポート - -## 最終レポート形式 - -``` -オーケストレーションレポート -==================== -ワークフロー: feature -タスク: ユーザー認証の追加 -エージェント: planner -> tdd-guide -> code-reviewer -> security-reviewer - -サマリー -------- -[1段落の要約] - -エージェント出力 -------------- -Planner: [要約] -TDD Guide: [要約] -Code Reviewer: [要約] -Security Reviewer: [要約] - -変更ファイル -------------- -[変更されたすべてのファイルをリスト] - -テスト結果 ------------- -[テスト合格/不合格の要約] - -セキュリティステータス ---------------- -[セキュリティの発見事項] - -推奨事項 --------------- -[リリース可 / 要修正 / ブロック中] -``` - -## 並行実行 - -独立したチェックの場合、エージェントを並行実行します: - -```markdown -### 並行フェーズ -同時に実行: -- code-reviewer (品質) -- security-reviewer (セキュリティ) -- architect (設計) - -### 結果のマージ -出力を単一のレポートに結合 -``` - -## 引数 - -$ARGUMENTS: -- `feature <説明>` - 完全な機能ワークフロー -- `bugfix <説明>` - バグ修正ワークフロー -- `refactor <説明>` - リファクタリングワークフロー -- `security <説明>` - セキュリティレビューワークフロー -- `custom <エージェント> <説明>` - カスタムエージェントシーケンス - -## カスタムワークフローの例 - -``` -/orchestrate custom "architect,tdd-guide,code-reviewer" "Redesign caching layer" -``` - -## ヒント - -1. 複雑な機能には**plannerから始める** -2. マージ前に**常にcode-reviewerを含める** -3. 認証/決済/個人情報には**security-reviewerを使用** -4. **ハンドオフを簡潔に保つ** - 次のエージェントが必要とするものに焦点を当てる -5. 必要に応じて**エージェント間で検証を実行** diff --git a/docs/ja-JP/commands/prompt-optimize.md b/docs/ja-JP/commands/prompt-optimize.md deleted file mode 100644 index 88ee704cb1..0000000000 --- a/docs/ja-JP/commands/prompt-optimize.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -description: ドラフトプロンプトを分析し、ECC が強化された最適化済みバージョンを出力します。貼り付けてすぐに実行できる状態で出力されます。タスクは実行しません — コンサルティング分析のみを出力します。 ---- - -# /prompt-optimize - -以下のプロンプトを分析し、ECC レバレッジを最大化するよう最適化します。 - -## あなたのタスク - -ユーザーの入力に **prompt-optimizer** スキルを適用します。6フェーズの分析プロセスに従ってください： - -0. **プロジェクト検出** — CLAUDE.md を読み取り、プロジェクトファイル（package.json、go.mod、pyproject.toml など）から技術スタックを検出する -1. **意図検出** — タスクタイプを分類する（新機能、バグ修正、リファクタリング、調査、テスト、レビュー、ドキュメント、インフラ、設計） -2. **スコープ評価** — 複雑さを評価する（シンプル / 低 / 中 / 高 / エピック）、コードベースが検出された場合はそのサイズをシグナルとして使用する -3. **ECC コンポーネントマッチング** — 特定のスキル、コマンド、エージェント、モデル階層にマッピングする -4. **不足コンテキスト検出** — 情報のギャップを特定する。3つ以上の重要な項目が不足している場合は、生成前にユーザーに確認を求める -5. **ワークフローとモデル** — ライフサイクルフェーズを決定し、モデル階層を推奨し、複雑さが高/エピックの場合は複数のプロンプトに分割する - -## 出力要件 - -* 診断結果、推奨 ECC コンポーネント、prompt-optimizer スキルの出力フォーマットを使用した最適化済みプロンプトを提示する -* **完全版**（詳細）と**クイック版**（コンパクト、意図タイプによって変化）を提供する -* ユーザーの入力と同じ言語で回答する -* 最適化済みプロンプトは完全で、新しいセッションにコピー＆ペーストしてそのまま使用できる状態でなければならない -* 調整オプションまたは明確な次のアクション（別途実行リクエストを開始するため）を提供するフッターで締めくくる - -## 重要 - -ユーザーのタスクを実行しないでください。分析結果と最適化済みプロンプトのみを出力してください。 -ユーザーが直接実行を求めた場合は、`/prompt-optimize` はコンサルティング的な出力のみを生成することを説明し、通常のタスクリクエストを開始するよう伝えてください。 - -注意：`blueprint` は**スキル**であり、スラッシュコマンドではありません。「ブループリントスキルを使用する」と書き、`/...` コマンドとして表現しないでください。 - -## ユーザー入力 - -$ARGUMENTS diff --git a/docs/ja-JP/commands/rules-distill.md b/docs/ja-JP/commands/rules-distill.md deleted file mode 100644 index 415889331c..0000000000 --- a/docs/ja-JP/commands/rules-distill.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: "スキルをスキャンして横断的な原則を抽出し、ルールとして蒸留する" ---- - -# /rules-distill — スキルから原則をルールとして蒸留する - -インストール済みのスキルをスキャンし、横断的な原則を抽出して、ルールとして蒸留します。 - -## フロー - -`rules-distill` スキルで定義された完全なワークフローに従います。 diff --git a/docs/ja-JP/commands/tdd.md b/docs/ja-JP/commands/tdd.md deleted file mode 100644 index 96a61c301e..0000000000 --- a/docs/ja-JP/commands/tdd.md +++ /dev/null @@ -1,326 +0,0 @@ ---- -description: テスト駆動開発ワークフローを強制します。インターフェースをスキャフォールドし、最初にテストを生成し、次にテストに合格するための最小限のコードを実装します。80%以上のカバレッジを保証します。 ---- - -# TDDコマンド - -このコマンドは**tdd-guide**エージェントを呼び出し、テスト駆動開発の手法を強制します。 - -## このコマンドの機能 - -1. **インターフェースのスキャフォールド** - まず型/インターフェースを定義 -2. **最初にテストを生成** - 失敗するテストを書く(RED) -3. **最小限のコードを実装** - テストに合格するだけのコードを書く(GREEN) -4. **リファクタリング** - テストを緑色に保ちながらコードを改善(REFACTOR) -5. **カバレッジの検証** - 80%以上のテストカバレッジを保証 - -## 使用するタイミング - -以下の場合に`/tdd`を使用します: -- 新機能の実装時 -- 新しい関数/コンポーネントの追加時 -- バグ修正時(最初にバグを再現するテストを書く) -- 既存コードのリファクタリング時 -- 重要なビジネスロジックの構築時 - -## 動作方法 - -tdd-guideエージェントは以下を実行します: - -1. **インターフェースを定義**入力/出力の型を決定 -2. **失敗するテストを書く**(コードがまだ存在しないため) -3. **テストを実行**し、正しい理由で失敗することを確認 -4. **最小限の実装を書く**テストに合格させる -5. **テストを実行**し、合格することを確認 -6. **リファクタリング**テストを緑色に保ちながらコードを改善 -7. **カバレッジを確認**80%未満の場合はテストを追加 - -## TDDサイクル - -``` -RED → GREEN → REFACTOR → REPEAT - -RED: 失敗するテストを書く -GREEN: 合格するための最小限のコードを書く -REFACTOR: コードを改善し、テストを合格状態に保つ -REPEAT: 次の機能/シナリオへ -``` - -## 使用例 - -``` -User: /tdd マーケット流動性スコアを計算する関数が必要です - -Agent (tdd-guide): -# TDDセッション: マーケット流動性スコア計算機 - -## ステップ1: インターフェースの定義(SCAFFOLD) - -```typescript -// lib/liquidity.ts -export interface MarketData { - totalVolume: number - bidAskSpread: number - activeTraders: number - lastTradeTime: Date -} - -export function calculateLiquidityScore(market: MarketData): number { - // TODO: Implementation - throw new Error('Not implemented') -} -``` - -## ステップ2: 失敗するテストを書く(RED) - -```typescript -// lib/liquidity.test.ts -import { calculateLiquidityScore } from './liquidity' - -describe('calculateLiquidityScore', () => { - it('should return high score for liquid market', () => { - const market = { - totalVolume: 100000, - bidAskSpread: 0.01, - activeTraders: 500, - lastTradeTime: new Date() - } - - const score = calculateLiquidityScore(market) - - expect(score).toBeGreaterThan(80) - expect(score).toBeLessThanOrEqual(100) - }) - - it('should return low score for illiquid market', () => { - const market = { - totalVolume: 100, - bidAskSpread: 0.5, - activeTraders: 2, - lastTradeTime: new Date(Date.now() - 86400000) // 1 day ago - } - - const score = calculateLiquidityScore(market) - - expect(score).toBeLessThan(30) - expect(score).toBeGreaterThanOrEqual(0) - }) - - it('should handle edge case: zero volume', () => { - const market = { - totalVolume: 0, - bidAskSpread: 0, - activeTraders: 0, - lastTradeTime: new Date() - } - - const score = calculateLiquidityScore(market) - - expect(score).toBe(0) - }) -}) -``` - -## ステップ3: テストを実行 - 失敗を確認 - -```bash -npm test lib/liquidity.test.ts - -FAIL lib/liquidity.test.ts - ✕ should return high score for liquid market (2 ms) - Error: Not implemented - -1 test failed, 0 passed -``` - -PASS: テストは期待通りに失敗しました。実装の準備ができました。 - -## ステップ4: 最小限のコードを実装(GREEN) - -```typescript -// lib/liquidity.ts -export function calculateLiquidityScore(market: MarketData): number { - // Handle zero volume edge case - if (market.totalVolume === 0) { - return 0 - } - - // Calculate component scores (0-100 scale) - const volumeScore = Math.min(market.totalVolume / 1000, 100) - const spreadScore = Math.max(100 - (market.bidAskSpread * 1000), 0) - const traderScore = Math.min(market.activeTraders / 10, 100) - - // Recent activity bonus - const hoursSinceLastTrade = (Date.now() - market.lastTradeTime.getTime()) / (1000 * 60 * 60) - const recencyScore = Math.max(100 - (hoursSinceLastTrade * 10), 0) - - // Weighted average - const score = ( - volumeScore * 0.4 + - spreadScore * 0.3 + - traderScore * 0.2 + - recencyScore * 0.1 - ) - - return Math.min(Math.max(score, 0), 100) // Clamp to 0-100 -} -``` - -## ステップ5: テストを実行 - 合格を確認 - -```bash -npm test lib/liquidity.test.ts - -PASS lib/liquidity.test.ts - ✓ should return high score for liquid market (3 ms) - ✓ should return low score for illiquid market (2 ms) - ✓ should handle edge case: zero volume (1 ms) - -3 tests passed -``` - -PASS: すべてのテストが合格しました! - -## ステップ6: リファクタリング(IMPROVE) - -```typescript -// lib/liquidity.ts - 定数と可読性を向上させてリファクタリング -const WEIGHTS = { - VOLUME: 0.4, - SPREAD: 0.3, - TRADERS: 0.2, - RECENCY: 0.1, -} as const - -const SCALE_FACTORS = { - VOLUME: 1000, - SPREAD: 1000, - TRADERS: 10, - RECENCY_PENALTY: 10, -} as const - -function clamp(value: number, min: number, max: number): number { - return Math.min(Math.max(value, min), max) -} - -export function calculateLiquidityScore(market: MarketData): number { - if (market.totalVolume === 0) return 0 - - const volumeScore = Math.min(market.totalVolume / SCALE_FACTORS.VOLUME, 100) - const spreadScore = clamp(100 - (market.bidAskSpread * SCALE_FACTORS.SPREAD), 0, 100) - const traderScore = Math.min(market.activeTraders / SCALE_FACTORS.TRADERS, 100) - - const hoursSinceLastTrade = (Date.now() - market.lastTradeTime.getTime()) / (1000 * 60 * 60) - const recencyScore = clamp(100 - (hoursSinceLastTrade * SCALE_FACTORS.RECENCY_PENALTY), 0, 100) - - const weightedScore = - volumeScore * WEIGHTS.VOLUME + - spreadScore * WEIGHTS.SPREAD + - traderScore * WEIGHTS.TRADERS + - recencyScore * WEIGHTS.RECENCY - - return clamp(weightedScore, 0, 100) -} -``` - -## ステップ7: テストがまだ合格することを確認 - -```bash -npm test lib/liquidity.test.ts - -PASS lib/liquidity.test.ts - ✓ should return high score for liquid market (3 ms) - ✓ should return low score for illiquid market (2 ms) - ✓ should handle edge case: zero volume (1 ms) - -3 tests passed -``` - -PASS: リファクタリング完了、テストはまだ合格しています! - -## ステップ8: カバレッジの確認 - -```bash -npm test -- --coverage lib/liquidity.test.ts - -File | % Stmts | % Branch | % Funcs | % Lines ----------------|---------|----------|---------|-------- -liquidity.ts | 100 | 100 | 100 | 100 - -Coverage: 100% PASS: (Target: 80%) -``` - -PASS: TDDセッション完了! -``` - -## TDDベストプラクティス - -**すべきこと:** -- PASS: 実装の前にまずテストを書く -- PASS: テストを実行し、実装前に失敗することを確認 -- PASS: テストに合格するための最小限のコードを書く -- PASS: テストが緑色になってからのみリファクタリング -- PASS: エッジケースとエラーシナリオを追加 -- PASS: 80%以上のカバレッジを目指す(重要なコードは100%) - -**してはいけないこと:** -- FAIL: テストの前に実装を書く -- FAIL: 各変更後のテスト実行をスキップ -- FAIL: 一度に多くのコードを書く -- FAIL: 失敗するテストを無視 -- FAIL: 実装の詳細をテスト(動作をテスト) -- FAIL: すべてをモック化(統合テストを優先) - -## 含めるべきテストタイプ - -**単体テスト**(関数レベル): -- ハッピーパスシナリオ -- エッジケース(空、null、最大値) -- エラー条件 -- 境界値 - -**統合テスト**(コンポーネントレベル): -- APIエンドポイント -- データベース操作 -- 外部サービス呼び出し -- hooksを使用したReactコンポーネント - -**E2Eテスト**(`/e2e`コマンドを使用): -- 重要なユーザーフロー -- 複数ステップのプロセス -- フルスタック統合 - -## カバレッジ要件 - -- **すべてのコードに80%以上** -- **以下には100%必須**: - - 財務計算 - - 認証ロジック - - セキュリティクリティカルなコード - - コアビジネスロジック - -## 重要事項 - -**必須**: テストは実装の前に書く必要があります。TDDサイクルは: - -1. **RED** - 失敗するテストを書く -2. **GREEN** - 合格する実装を書く -3. **REFACTOR** - コードを改善 - -REDフェーズをスキップしてはいけません。テストの前にコードを書いてはいけません。 - -## 他のコマンドとの統合 - -- まず`/plan`を使用して何を構築するかを理解 -- `/tdd`を使用してテスト付きで実装 -- `/build-and-fix`をビルドエラー発生時に使用 -- `/code-review`で実装をレビュー -- `/test-coverage`でカバレッジを検証 - -## 関連エージェント - -このコマンドは以下の場所にある`tdd-guide`エージェントを呼び出します: -`~/.claude/agents/tdd-guide.md` - -また、以下の場所にある`tdd-workflow`スキルを参照できます: -`~/.claude/skills/tdd-workflow/` diff --git a/docs/ja-JP/commands/verify.md b/docs/ja-JP/commands/verify.md deleted file mode 100644 index 89e9297c6a..0000000000 --- a/docs/ja-JP/commands/verify.md +++ /dev/null @@ -1,59 +0,0 @@ -# 検証コマンド - -現在のコードベースの状態に対して包括的な検証を実行します。 - -## 手順 - -この正確な順序で検証を実行してください: - -1. **ビルドチェック** - - このプロジェクトのビルドコマンドを実行 - - 失敗した場合、エラーを報告して**停止** - -2. **型チェック** - - TypeScript/型チェッカーを実行 - - すべてのエラーをファイル:行番号とともに報告 - -3. **Lintチェック** - - Linterを実行 - - 警告とエラーを報告 - -4. **テストスイート** - - すべてのテストを実行 - - 合格/不合格の数を報告 - - カバレッジのパーセンテージを報告 - -5. **Console.log監査** - - ソースファイルでconsole.logを検索 - - 場所を報告 - -6. **Git状態** - - コミットされていない変更を表示 - - 最後のコミット以降に変更されたファイルを表示 - -## 出力 - -簡潔な検証レポートを生成します: - -``` -検証結果: [PASS/FAIL] - -ビルド: [OK/FAIL] -型: [OK/Xエラー] -Lint: [OK/X件の問題] -テスト: [X/Y合格, Z%カバレッジ] -シークレット: [OK/X件発見] -ログ: [OK/X件のconsole.log] - -PR準備完了: [YES/NO] -``` - -重大な問題がある場合は、修正案とともにリストアップします。 - -## 引数 - -$ARGUMENTS は以下のいずれか: -- `quick` - ビルド + 型チェックのみ -- `full` - すべてのチェック（デフォルト） -- `pre-commit` - コミットに関連するチェック -- `pre-pr` - 完全なチェック + セキュリティスキャン diff --git a/docs/ko-KR/commands/e2e.md b/docs/ko-KR/commands/e2e.md deleted file mode 100644 index e12588ed0f..0000000000 --- a/docs/ko-KR/commands/e2e.md +++ /dev/null @@ -1,334 +0,0 @@ ---- -description: Playwright로 E2E 테스트를 생성하고 실행합니다. 테스트 여정을 만들고, 테스트를 실행하며, 스크린샷/비디오/트레이스를 캡처하고, 아티팩트를 업로드합니다. ---- - -# E2E 커맨드 - -이 커맨드는 **e2e-runner** 에이전트를 호출하여 Playwright를 사용한 E2E 테스트를 생성, 유지, 실행합니다. - -## 이 커맨드가 하는 것 - -1. **테스트 여정 생성** - 사용자 흐름에 대한 Playwright 테스트 생성 -2. **E2E 테스트 실행** - 여러 브라우저에서 테스트 실행 -3. **아티팩트 캡처** - 실패 시 스크린샷, 비디오, 트레이스 -4. **결과 업로드** - HTML 보고서 및 JUnit XML -5. **불안정한 테스트 식별** - 불안정한 테스트를 격리 - -## 사용 시점 - -`/e2e`를 사용해야 할 때: -- 핵심 사용자 여정 테스트 (로그인, 거래, 결제) -- 다단계 흐름이 E2E로 작동하는지 검증 -- UI 인터랙션 및 네비게이션 테스트 -- 프론트엔드와 백엔드 간 통합 검증 -- 프로덕션 배포 준비 - -## 작동 방식 - -e2e-runner 에이전트가 수행하는 작업: - -1. **사용자 흐름 분석** 및 테스트 시나리오 식별 -2. Page Object Model 패턴을 사용한 **Playwright 테스트 생성** -3. 여러 브라우저(Chrome, Firefox, Safari)에서 **테스트 실행** -4. 스크린샷, 비디오, 트레이스로 **실패 캡처** -5. 결과와 아티팩트로 **보고서 생성** -6. **불안정한 테스트 식별** 및 수정 권장 - -## 사용 예시 - -```` -User: /e2e 마켓 검색 및 조회 흐름 테스트 - -Agent (e2e-runner): -# E2E 테스트 생성: 마켓 검색 및 조회 흐름 - -## 식별된 테스트 시나리오 - -**사용자 여정:** 마켓 검색 → 결과 확인 → 마켓 클릭 → 상세 정보 확인 - -**테스트 범위:** -1. 마켓 페이지로 이동 -2. 시맨틱 검색 수행 -3. 검색 결과 확인 -4. 첫 번째 결과 클릭 -5. 마켓 상세 페이지 로드 확인 -6. 차트 렌더링 확인 - -## 생성된 테스트 코드 - -```typescript -// tests/e2e/markets/search-and-view.spec.ts -import { test, expect } from '@playwright/test' -import { MarketsPage } from '../../pages/MarketsPage' -import { MarketDetailsPage } from '../../pages/MarketDetailsPage' - -test.describe('Market Search and View Flow', () => { - test('user can search markets and view details', async ({ page }) => { - // 1. 마켓 페이지로 이동 - const marketsPage = new MarketsPage(page) - await marketsPage.goto() - - // 페이지 로드 확인 - await expect(page).toHaveTitle(/Markets/) - await expect(page.locator('h1')).toContainText('Markets') - - // 2. 시맨틱 검색 수행 - await marketsPage.searchMarkets('election') - - // API 응답 대기 - await page.waitForResponse(resp => - resp.url().includes('/api/markets/search') && resp.status() === 200 - ) - - // 3. 검색 결과 확인 - const marketCards = marketsPage.marketCards - await expect(marketCards.first()).toBeVisible() - const resultCount = await marketCards.count() - expect(resultCount).toBeGreaterThan(0) - - // 검색 결과 스크린샷 촬영 - await page.screenshot({ path: 'artifacts/search-results.png' }) - - // 4. 첫 번째 결과 클릭 - const firstMarketTitle = await marketCards.first().textContent() - await marketCards.first().click() - - // 5. 마켓 상세 페이지 로드 확인 - await expect(page).toHaveURL(/\/markets\/[a-z0-9-]+/) - - const detailsPage = new MarketDetailsPage(page) - await expect(detailsPage.marketName).toBeVisible() - await expect(detailsPage.marketDescription).toBeVisible() - - // 6. 차트 렌더링 확인 - await expect(detailsPage.priceChart).toBeVisible() - - // 마켓 이름 일치 확인 - const detailsTitle = await detailsPage.marketName.textContent() - expect(detailsTitle?.toLowerCase()).toContain( - firstMarketTitle?.toLowerCase().substring(0, 20) || '' - ) - - // 마켓 상세 스크린샷 촬영 - await page.screenshot({ path: 'artifacts/market-details.png' }) - }) - - test('search with no results shows empty state', async ({ page }) => { - const marketsPage = new MarketsPage(page) - await marketsPage.goto() - - // 존재하지 않는 마켓 검색 - await marketsPage.searchMarkets('xyznonexistentmarket123456') - - // 빈 상태 확인 - 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() - - // 초기 마켓 수 - const initialCount = await marketsPage.marketCards.count() - - // 검색 수행 - await marketsPage.searchMarkets('trump') - await page.waitForLoadState('networkidle') - - // 필터링된 결과 확인 - const filteredCount = await marketsPage.marketCards.count() - expect(filteredCount).toBeLessThan(initialCount) - - // 검색 초기화 - await marketsPage.searchInput.clear() - await page.waitForLoadState('networkidle') - - // 모든 마켓이 다시 표시되는지 확인 - const finalCount = await marketsPage.marketCards.count() - expect(finalCount).toBe(initialCount) - }) -}) -``` - -## 테스트 실행 - -```bash -# 생성된 테스트 실행 -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/search-results.png -- artifacts/market-details.png -- playwright-report/index.html -``` - -## 테스트 보고서 - -``` -╔══════════════════════════════════════════════════════════════╗ -║ E2E 테스트 결과 ║ -╠══════════════════════════════════════════════════════════════╣ -║ 상태: PASS: 모든 테스트 통과 ║ -║ 전체: 3개 테스트 ║ -║ 통과: 3 (100%) ║ -║ 실패: 0 ║ -║ 불안정: 0 ║ -║ 소요시간: 9.1s ║ -╚══════════════════════════════════════════════════════════════╝ - -아티팩트: - 스크린샷: 2개 파일 - 비디오: 0개 파일 (실패 시에만) - 트레이스: 0개 파일 (실패 시에만) - HTML 보고서: playwright-report/index.html - -보고서 확인: npx playwright show-report -``` - -PASS: CI/CD 통합 준비가 완료된 E2E 테스트 모음! -```` - -## 테스트 아티팩트 - -테스트 실행 시 다음 아티팩트가 캡처됩니다: - -**모든 테스트:** -- 타임라인과 결과가 포함된 HTML 보고서 -- CI 통합을 위한 JUnit XML - -**실패 시에만:** -- 실패 상태의 스크린샷 -- 테스트의 비디오 녹화 -- 디버깅을 위한 트레이스 파일 (단계별 재생) -- 네트워크 로그 -- 콘솔 로그 - -## 아티팩트 확인 - -```bash -# 브라우저에서 HTML 보고서 확인 -npx playwright show-report - -# 특정 트레이스 파일 확인 -npx playwright show-trace artifacts/trace-abc123.zip - -# 스크린샷은 artifacts/ 디렉토리에 저장됨 -open artifacts/search-results.png -``` - -## 불안정한 테스트 감지 - -테스트가 간헐적으로 실패하는 경우: - -``` -WARNING: 불안정한 테스트 감지됨: tests/e2e/markets/trade.spec.ts - -테스트가 10회 중 7회 통과 (70% 통과율) - -일반적인 실패 원인: -"요소 '[data-testid="confirm-btn"]'을 대기하는 중 타임아웃" - -권장 수정 사항: -1. 명시적 대기 추가: await page.waitForSelector('[data-testid="confirm-btn"]') -2. 타임아웃 증가: { timeout: 10000 } -3. 컴포넌트의 레이스 컨디션 확인 -4. 애니메이션에 의해 요소가 숨겨져 있지 않은지 확인 - -격리 권장: 수정될 때까지 test.fixme()로 표시 -``` - -## 브라우저 구성 - -기본적으로 여러 브라우저에서 테스트가 실행됩니다: -- Chromium (데스크톱 Chrome) -- Firefox (데스크톱) -- WebKit (데스크톱 Safari) -- Mobile Chrome (선택 사항) - -`playwright.config.ts`에서 브라우저를 조정할 수 있습니다. - -## CI/CD 통합 - -CI 파이프라인에 추가: - -```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/ -``` - -## 모범 사례 - -**해야 할 것:** -- Page Object Model을 사용하여 유지보수성 향상 -- data-testid 속성을 셀렉터로 사용 -- 임의의 타임아웃 대신 API 응답을 대기 -- 핵심 사용자 여정을 E2E로 테스트 -- main에 merge하기 전에 테스트 실행 -- 테스트 실패 시 아티팩트 검토 - -**하지 말아야 할 것:** -- 취약한 셀렉터 사용 (CSS 클래스는 변경될 수 있음) -- 구현 세부사항 테스트 -- 프로덕션에 대해 테스트 실행 -- 불안정한 테스트 무시 -- 실패 시 아티팩트 검토 생략 -- E2E로 모든 엣지 케이스 테스트 (단위 테스트 사용) - -## 다른 커맨드와의 연동 - -- `/plan`을 사용하여 테스트할 핵심 여정 식별 -- `/tdd`를 사용하여 단위 테스트 (더 빠르고 세밀함) -- `/e2e`를 사용하여 통합 및 사용자 여정 테스트 -- `/code-review`를 사용하여 테스트 품질 검증 - -## 관련 에이전트 - -이 커맨드는 `e2e-runner` 에이전트를 호출합니다: -`~/.claude/agents/e2e-runner.md` - -## 빠른 커맨드 - -```bash -# 모든 E2E 테스트 실행 -npx playwright test - -# 특정 테스트 파일 실행 -npx playwright test tests/e2e/markets/search.spec.ts - -# headed 모드로 실행 (브라우저 표시) -npx playwright test --headed - -# 테스트 디버그 -npx playwright test --debug - -# 테스트 코드 생성 -npx playwright codegen http://localhost:3000 - -# 보고서 확인 -npx playwright show-report -``` diff --git a/docs/ko-KR/commands/eval.md b/docs/ko-KR/commands/eval.md deleted file mode 100644 index ddf3869dc2..0000000000 --- a/docs/ko-KR/commands/eval.md +++ /dev/null @@ -1,120 +0,0 @@ -# Eval 커맨드 - -평가 기반 개발 워크플로우를 관리합니다. - -## 사용법 - -`/eval [define|check|report|list|clean] [feature-name]` - -## 평가 정의 - -`/eval define feature-name` - -새로운 평가 정의를 생성합니다: - -1. `.claude/evals/feature-name.md`에 템플릿을 생성합니다: - -```markdown -## EVAL: feature-name -Created: $(date) - -### Capability Evals -- [ ] [기능 1에 대한 설명] -- [ ] [기능 2에 대한 설명] - -### Regression Evals -- [ ] [기존 동작 1이 여전히 작동함] -- [ ] [기존 동작 2이 여전히 작동함] - -### Success Criteria -- capability eval에 대해 pass@3 > 90% -- regression eval에 대해 pass^3 = 100% -``` - -2. 사용자에게 구체적인 기준을 입력하도록 안내합니다 - -## 평가 확인 - -`/eval check feature-name` - -기능에 대한 평가를 실행합니다: - -1. `.claude/evals/feature-name.md`에서 평가 정의를 읽습니다 -2. 각 capability eval에 대해: - - 기준 검증을 시도합니다 - - PASS/FAIL을 기록합니다 - - `.claude/evals/feature-name.log`에 시도를 기록합니다 -3. 각 regression eval에 대해: - - 관련 테스트를 실행합니다 - - 기준선과 비교합니다 - - PASS/FAIL을 기록합니다 -4. 현재 상태를 보고합니다: - -``` -EVAL CHECK: feature-name -======================== -Capability: X/Y passing -Regression: X/Y passing -Status: IN PROGRESS / READY -``` - -## 평가 보고 - -`/eval report feature-name` - -포괄적인 평가 보고서를 생성합니다: - -``` -EVAL REPORT: feature-name -========================= -Generated: $(date) - -CAPABILITY EVALS ----------------- -[eval-1]: PASS (pass@1) -[eval-2]: PASS (pass@2) - 재시도 필요했음 -[eval-3]: FAIL - 비고 참조 - -REGRESSION EVALS ----------------- -[test-1]: PASS -[test-2]: PASS -[test-3]: PASS - -METRICS -------- -Capability pass@1: 67% -Capability pass@3: 100% -Regression pass^3: 100% - -NOTES ------ -[이슈, 엣지 케이스 또는 관찰 사항] - -RECOMMENDATION --------------- -[SHIP / NEEDS WORK / BLOCKED] -``` - -## 평가 목록 - -`/eval list` - -모든 평가 정의를 표시합니다: - -``` -EVAL DEFINITIONS -================ -feature-auth [3/5 passing] IN PROGRESS -feature-search [5/5 passing] READY -feature-export [0/4 passing] NOT STARTED -``` - -## 인자 - -$ARGUMENTS: -- `define ` - 새 평가 정의 생성 -- `check ` - 평가 실행 및 확인 -- `report ` - 전체 보고서 생성 -- `list` - 모든 평가 표시 -- `clean` - 오래된 평가 로그 제거 (최근 10회 실행 유지) diff --git a/docs/ko-KR/commands/orchestrate.md b/docs/ko-KR/commands/orchestrate.md deleted file mode 100644 index a9845ea378..0000000000 --- a/docs/ko-KR/commands/orchestrate.md +++ /dev/null @@ -1,172 +0,0 @@ -# Orchestrate 커맨드 - -복잡한 작업을 위한 순차적 에이전트 워크플로우입니다. - -## 사용법 - -`/orchestrate [workflow-type] [task-description]` - -## 워크플로우 유형 - -### feature -전체 기능 구현 워크플로우: -``` -planner -> tdd-guide -> code-reviewer -> security-reviewer -``` - -### bugfix -버그 조사 및 수정 워크플로우: -``` -planner -> tdd-guide -> code-reviewer -``` - -### refactor -안전한 리팩토링 워크플로우: -``` -architect -> code-reviewer -> tdd-guide -``` - -### security -보안 중심 리뷰: -``` -security-reviewer -> code-reviewer -> architect -``` - -## 실행 패턴 - -워크플로우의 각 에이전트에 대해: - -1. 이전 에이전트의 컨텍스트로 **에이전트 호출** -2. 구조화된 핸드오프 문서로 **출력 수집** -3. 체인의 **다음 에이전트에 전달** -4. **결과를 종합**하여 최종 보고서 작성 - -## 핸드오프 문서 형식 - -에이전트 간에 핸드오프 문서를 생성합니다: - -```markdown -## HANDOFF: [이전-에이전트] -> [다음-에이전트] - -### Context -[수행된 작업 요약] - -### Findings -[주요 발견 사항 또는 결정 사항] - -### Files Modified -[수정된 파일 목록] - -### Open Questions -[다음 에이전트를 위한 미해결 항목] - -### Recommendations -[제안하는 다음 단계] -``` - -## 예시: Feature 워크플로우 - -``` -/orchestrate feature "Add user authentication" -``` - -실행 순서: - -1. **Planner 에이전트** - - 요구사항 분석 - - 구현 계획 작성 - - 의존성 식별 - - 출력: `HANDOFF: planner -> tdd-guide` - -2. **TDD Guide 에이전트** - - planner 핸드오프 읽기 - - 테스트 먼저 작성 - - 테스트를 통과하도록 구현 - - 출력: `HANDOFF: tdd-guide -> code-reviewer` - -3. **Code Reviewer 에이전트** - - 구현 리뷰 - - 이슈 확인 - - 개선사항 제안 - - 출력: `HANDOFF: code-reviewer -> security-reviewer` - -4. **Security Reviewer 에이전트** - - 보안 감사 - - 취약점 점검 - - 최종 승인 - - 출력: 최종 보고서 - -## 최종 보고서 형식 - -``` -ORCHESTRATION REPORT -==================== -Workflow: feature -Task: Add user authentication -Agents: planner -> tdd-guide -> code-reviewer -> security-reviewer - -SUMMARY -------- -[한 단락 요약] - -AGENT OUTPUTS -------------- -Planner: [요약] -TDD Guide: [요약] -Code Reviewer: [요약] -Security Reviewer: [요약] - -FILES CHANGED -------------- -[수정된 모든 파일 목록] - -TEST RESULTS ------------- -[테스트 통과/실패 요약] - -SECURITY STATUS ---------------- -[보안 발견 사항] - -RECOMMENDATION --------------- -[SHIP / NEEDS WORK / BLOCKED] -``` - -## 병렬 실행 - -독립적인 검사에 대해서는 에이전트를 병렬로 실행합니다: - -```markdown -### Parallel Phase -동시에 실행: -- code-reviewer (품질) -- security-reviewer (보안) -- architect (설계) - -### Merge Results -출력을 단일 보고서로 통합 -``` - -## 인자 - -$ARGUMENTS: -- `feature ` - 전체 기능 워크플로우 -- `bugfix ` - 버그 수정 워크플로우 -- `refactor ` - 리팩토링 워크플로우 -- `security ` - 보안 리뷰 워크플로우 -- `custom ` - 사용자 정의 에이전트 순서 - -## 사용자 정의 워크플로우 예시 - -``` -/orchestrate custom "architect,tdd-guide,code-reviewer" "Redesign caching layer" -``` - -## 팁 - -1. 복잡한 기능에는 **planner부터 시작**하세요 -2. merge 전에는 **항상 code-reviewer를 포함**하세요 -3. 인증/결제/개인정보 처리에는 **security-reviewer를 사용**하세요 -4. **핸드오프는 간결하게** 유지하세요 - 다음 에이전트에 필요한 것에 집중 -5. 필요한 경우 에이전트 사이에 **검증을 실행**하세요 diff --git a/docs/ko-KR/commands/tdd.md b/docs/ko-KR/commands/tdd.md deleted file mode 100644 index 5dc1ba8013..0000000000 --- a/docs/ko-KR/commands/tdd.md +++ /dev/null @@ -1,326 +0,0 @@ ---- -description: 테스트 주도 개발 워크플로우 강제. 인터페이스를 스캐폴딩하고, 테스트를 먼저 생성한 후 통과할 최소한의 코드를 구현합니다. 80% 이상 커버리지를 보장합니다. ---- - -# TDD 커맨드 - -이 커맨드는 **tdd-guide** 에이전트를 호출하여 테스트 주도 개발 방법론을 강제합니다. - -## 이 커맨드가 하는 것 - -1. **인터페이스 스캐폴딩** - 타입/인터페이스를 먼저 정의 -2. **테스트 먼저 생성** - 실패하는 테스트 작성 (RED) -3. **최소한의 코드 구현** - 통과하기에 충분한 코드만 작성 (GREEN) -4. **리팩토링** - 테스트를 통과시키면서 코드 개선 (REFACTOR) -5. **커버리지 확인** - 80% 이상 테스트 커버리지 보장 - -## 사용 시점 - -`/tdd`를 사용해야 할 때: -- 새 기능 구현 -- 새 함수/컴포넌트 추가 -- 버그 수정 (버그를 재현하는 테스트를 먼저 작성) -- 기존 코드 리팩토링 -- 핵심 비즈니스 로직 구현 - -## 작동 방식 - -tdd-guide 에이전트가 수행하는 작업: - -1. 입출력에 대한 **인터페이스 정의** -2. (코드가 아직 존재하지 않으므로) **실패하는 테스트 작성** -3. 올바른 이유로 실패하는지 **테스트 실행** 및 확인 -4. 테스트를 통과하도록 **최소한의 구현 작성** -5. 통과하는지 **테스트 실행** 및 확인 -6. 테스트를 통과시키면서 코드 **리팩토링** -7. **커버리지 확인** 및 80% 미만이면 테스트 추가 - -## TDD 사이클 - -``` -RED → GREEN → REFACTOR → REPEAT - -RED: 실패하는 테스트 작성 -GREEN: 통과할 최소한의 코드 작성 -REFACTOR: 코드 개선, 테스트 계속 통과 유지 -REPEAT: 다음 기능/시나리오 -``` - -## 사용 예시 - -```` -User: /tdd 마켓 유동성 점수를 계산하는 함수가 필요합니다 - -Agent (tdd-guide): -# TDD 세션: 마켓 유동성 점수 계산기 - -## 1단계: 인터페이스 정의 (SCAFFOLD) - -```typescript -// lib/liquidity.ts -export interface MarketData { - totalVolume: number - bidAskSpread: number - activeTraders: number - lastTradeTime: Date -} - -export function calculateLiquidityScore(market: MarketData): number { - // TODO: 구현 - throw new Error('Not implemented') -} -``` - -## 2단계: 실패하는 테스트 작성 (RED) - -```typescript -// lib/liquidity.test.ts -import { calculateLiquidityScore } from './liquidity' - -describe('calculateLiquidityScore', () => { - it('should return high score for liquid market', () => { - const market = { - totalVolume: 100000, - bidAskSpread: 0.01, - activeTraders: 500, - lastTradeTime: new Date() - } - - const score = calculateLiquidityScore(market) - - expect(score).toBeGreaterThan(80) - expect(score).toBeLessThanOrEqual(100) - }) - - it('should return low score for illiquid market', () => { - const market = { - totalVolume: 100, - bidAskSpread: 0.5, - activeTraders: 2, - lastTradeTime: new Date(Date.now() - 86400000) // 1일 전 - } - - const score = calculateLiquidityScore(market) - - expect(score).toBeLessThan(30) - expect(score).toBeGreaterThanOrEqual(0) - }) - - it('should handle edge case: zero volume', () => { - const market = { - totalVolume: 0, - bidAskSpread: 0, - activeTraders: 0, - lastTradeTime: new Date() - } - - const score = calculateLiquidityScore(market) - - expect(score).toBe(0) - }) -}) -``` - -## 3단계: 테스트 실행 - 실패 확인 - -```bash -npm test lib/liquidity.test.ts - -FAIL lib/liquidity.test.ts - ✕ should return high score for liquid market (2 ms) - Error: Not implemented - -1 test failed, 0 passed -``` - -PASS: 예상대로 테스트 실패. 구현 준비 완료. - -## 4단계: 최소한의 코드 구현 (GREEN) - -```typescript -// lib/liquidity.ts -export function calculateLiquidityScore(market: MarketData): number { - // 거래량 0인 엣지 케이스 처리 - if (market.totalVolume === 0) { - return 0 - } - - // 구성 요소별 점수 계산 (0-100 스케일) - const volumeScore = Math.min(market.totalVolume / 1000, 100) - const spreadScore = Math.max(100 - (market.bidAskSpread * 1000), 0) - const traderScore = Math.min(market.activeTraders / 10, 100) - - // 최근 활동 보너스 - const hoursSinceLastTrade = (Date.now() - market.lastTradeTime.getTime()) / (1000 * 60 * 60) - const recencyScore = Math.max(100 - (hoursSinceLastTrade * 10), 0) - - // 가중 평균 - const score = ( - volumeScore * 0.4 + - spreadScore * 0.3 + - traderScore * 0.2 + - recencyScore * 0.1 - ) - - return Math.min(Math.max(score, 0), 100) // 0-100으로 클램핑 -} -``` - -## 5단계: 테스트 실행 - 통과 확인 - -```bash -npm test lib/liquidity.test.ts - -PASS lib/liquidity.test.ts - ✓ should return high score for liquid market (3 ms) - ✓ should return low score for illiquid market (2 ms) - ✓ should handle edge case: zero volume (1 ms) - -3 tests passed -``` - -PASS: 모든 테스트 통과! - -## 6단계: 리팩토링 (IMPROVE) - -```typescript -// lib/liquidity.ts - 상수와 가독성 향상을 위한 리팩토링 -const WEIGHTS = { - VOLUME: 0.4, - SPREAD: 0.3, - TRADERS: 0.2, - RECENCY: 0.1, -} as const - -const SCALE_FACTORS = { - VOLUME: 1000, - SPREAD: 1000, - TRADERS: 10, - RECENCY_PENALTY: 10, -} as const - -function clamp(value: number, min: number, max: number): number { - return Math.min(Math.max(value, min), max) -} - -export function calculateLiquidityScore(market: MarketData): number { - if (market.totalVolume === 0) return 0 - - const volumeScore = Math.min(market.totalVolume / SCALE_FACTORS.VOLUME, 100) - const spreadScore = clamp(100 - (market.bidAskSpread * SCALE_FACTORS.SPREAD), 0, 100) - const traderScore = Math.min(market.activeTraders / SCALE_FACTORS.TRADERS, 100) - - const hoursSinceLastTrade = (Date.now() - market.lastTradeTime.getTime()) / (1000 * 60 * 60) - const recencyScore = clamp(100 - (hoursSinceLastTrade * SCALE_FACTORS.RECENCY_PENALTY), 0, 100) - - const weightedScore = - volumeScore * WEIGHTS.VOLUME + - spreadScore * WEIGHTS.SPREAD + - traderScore * WEIGHTS.TRADERS + - recencyScore * WEIGHTS.RECENCY - - return clamp(weightedScore, 0, 100) -} -``` - -## 7단계: 테스트가 여전히 통과하는지 확인 - -```bash -npm test lib/liquidity.test.ts - -PASS lib/liquidity.test.ts - ✓ should return high score for liquid market (3 ms) - ✓ should return low score for illiquid market (2 ms) - ✓ should handle edge case: zero volume (1 ms) - -3 tests passed -``` - -PASS: 리팩토링 완료, 테스트 여전히 통과! - -## 8단계: 커버리지 확인 - -```bash -npm test -- --coverage lib/liquidity.test.ts - -File | % Stmts | % Branch | % Funcs | % Lines ----------------|---------|----------|---------|-------- -liquidity.ts | 100 | 100 | 100 | 100 - -Coverage: 100% PASS: (목표: 80%) -``` - -PASS: TDD 세션 완료! -```` - -## TDD 모범 사례 - -**해야 할 것:** -- 구현 전에 테스트를 먼저 작성 -- 구현 전에 테스트를 실행하여 실패하는지 확인 -- 테스트를 통과하기 위한 최소한의 코드 작성 -- 테스트가 통과한 후에만 리팩토링 -- 엣지 케이스와 에러 시나리오 추가 -- 80% 이상 커버리지 목표 (핵심 코드는 100%) - -**하지 말아야 할 것:** -- 테스트 전에 구현 작성 -- 각 변경 후 테스트 실행 건너뛰기 -- 한 번에 너무 많은 코드 작성 -- 실패하는 테스트 무시 -- 구현 세부사항 테스트 (동작을 테스트) -- 모든 것을 mock (통합 테스트 선호) - -## 포함할 테스트 유형 - -**단위 테스트** (함수 수준): -- 정상 경로 시나리오 -- 엣지 케이스 (빈 값, null, 최대값) -- 에러 조건 -- 경계값 - -**통합 테스트** (컴포넌트 수준): -- API 엔드포인트 -- 데이터베이스 작업 -- 외부 서비스 호출 -- hooks가 포함된 React 컴포넌트 - -**E2E 테스트** (`/e2e` 커맨드 사용): -- 핵심 사용자 흐름 -- 다단계 프로세스 -- 풀 스택 통합 - -## 커버리지 요구사항 - -- **80% 최소** - 모든 코드에 대해 -- **100% 필수** - 다음 항목에 대해: - - 금융 계산 - - 인증 로직 - - 보안에 중요한 코드 - - 핵심 비즈니스 로직 - -## 중요 사항 - -**필수**: 테스트는 반드시 구현 전에 작성해야 합니다. TDD 사이클은 다음과 같습니다: - -1. **RED** - 실패하는 테스트 작성 -2. **GREEN** - 통과하도록 구현 -3. **REFACTOR** - 코드 개선 - -절대 RED 단계를 건너뛰지 마세요. 절대 테스트 전에 코드를 작성하지 마세요. - -## 다른 커맨드와의 연동 - -- `/plan`을 먼저 사용하여 무엇을 만들지 이해 -- `/tdd`를 사용하여 테스트와 함께 구현 -- `/build-fix`를 사용하여 빌드 에러 발생 시 수정 -- `/code-review`를 사용하여 구현 리뷰 -- `/test-coverage`를 사용하여 커버리지 검증 - -## 관련 에이전트 - -이 커맨드는 `tdd-guide` 에이전트를 호출합니다: -`~/.claude/agents/tdd-guide.md` - -그리고 `tdd-workflow` 스킬을 참조할 수 있습니다: -`~/.claude/skills/tdd-workflow/` diff --git a/docs/ko-KR/commands/verify.md b/docs/ko-KR/commands/verify.md deleted file mode 100644 index 3c973a3e76..0000000000 --- a/docs/ko-KR/commands/verify.md +++ /dev/null @@ -1,63 +0,0 @@ -# 검증 커맨드 - -현재 코드베이스 상태에 대한 포괄적인 검증을 실행합니다. - -## 지시사항 - -정확히 이 순서로 검증을 실행하세요: - -1. **Build 검사** - - 이 프로젝트의 build 커맨드 실행 - - 실패 시 에러를 보고하고 중단 - -2. **타입 검사** - - TypeScript/타입 체커 실행 - - 모든 에러를 파일:줄번호로 보고 - -3. **Lint 검사** - - 린터 실행 - - 경고와 에러 보고 - -4. **테스트 실행** - - 모든 테스트 실행 - - 통과/실패 수 보고 - - 커버리지 비율 보고 - -5. **시크릿 스캔** - - 소스 파일에서 API 키, 토큰, 비밀값 패턴 검색 - - 발견 위치 보고 - -6. **Console.log 감사** - - 소스 파일에서 console.log 검색 - - 위치 보고 - -7. **Git 상태** - - 커밋되지 않은 변경사항 표시 - - 마지막 커밋 이후 수정된 파일 표시 - -## 출력 - -간결한 검증 보고서를 생성합니다: - -``` -VERIFICATION: [PASS/FAIL] - -Build: [OK/FAIL] -Types: [OK/X errors] -Lint: [OK/X issues] -Tests: [X/Y passed, Z% coverage] -Secrets: [OK/X found] -Logs: [OK/X console.logs] - -Ready for PR: [YES/NO] -``` - -치명적 이슈가 있으면 수정 제안과 함께 목록화합니다. - -## 인자 - -$ARGUMENTS: -- `quick` - build + 타입만 -- `full` - 모든 검사 (기본값) -- `pre-commit` - 커밋에 관련된 검사 -- `pre-pr` - 전체 검사 + 보안 스캔 diff --git a/docs/pt-BR/commands/e2e.md b/docs/pt-BR/commands/e2e.md deleted file mode 100644 index c6cdd19d7e..0000000000 --- a/docs/pt-BR/commands/e2e.md +++ /dev/null @@ -1,365 +0,0 @@ ---- -description: Gere e rode testes end-to-end com Playwright. Cria jornadas de teste, executa testes, captura screenshots/videos/traces e faz upload de artefatos. ---- - -# Comando E2E - -Este comando invoca o agente **e2e-runner** para gerar, manter e executar testes end-to-end usando Playwright. - -## O Que Este Comando Faz - -1. **Gerar Jornadas de Teste** - Cria testes Playwright para fluxos de usuário -2. **Rodar Testes E2E** - Executa testes em múltiplos navegadores -3. **Capturar Artefatos** - Screenshots, vídeos, traces em falhas -4. **Upload de Resultados** - Relatórios HTML e JUnit XML -5. **Identificar Testes Flaky** - Coloca testes instáveis em quarentena - -## Quando Usar - -Use `/e2e` quando: -- Testar jornadas críticas de usuário (login, trading, pagamentos) -- Verificar fluxos multi-etapa de ponta a ponta -- Testar interações de UI e navegação -- Validar integração entre frontend e backend -- Preparar para deploy em produção - -## Como Funciona - -O agente e2e-runner vai: - -1. **Analisar o fluxo de usuário** e identificar cenários de teste -2. **Gerar teste Playwright** usando padrão Page Object Model -3. **Rodar testes** em múltiplos navegadores (Chrome, Firefox, Safari) -4. **Capturar falhas** com screenshots, vídeos e traces -5. **Gerar relatório** com resultados e artefatos -6. **Identificar testes flaky** e recomendar correções - -## Exemplo de Uso - -``` -User: /e2e Test the market search and view flow - -Agent (e2e-runner): -# E2E Test Generation: Market Search and View Flow - -## Test Scenario Identified - -**User Journey:** Market Search → View Results → Click Market → View Details - -**Test Coverage:** -1. Navigate to markets page -2. Perform semantic search -3. Verify search results -4. Click on first result -5. Verify market details page loads -6. Verify chart renders - -## Generated Test Code - -```typescript -// tests/e2e/markets/search-and-view.spec.ts -import { test, expect } from '@playwright/test' -import { MarketsPage } from '../../pages/MarketsPage' -import { MarketDetailsPage } from '../../pages/MarketDetailsPage' - -test.describe('Market Search and View Flow', () => { - test('user can search markets and view details', async ({ page }) => { - // 1. Navigate to markets page - const marketsPage = new MarketsPage(page) - await marketsPage.goto() - - // Verify page loaded - await expect(page).toHaveTitle(/Markets/) - await expect(page.locator('h1')).toContainText('Markets') - - // 2. Perform semantic search - await marketsPage.searchMarkets('election') - - // Wait for API response - await page.waitForResponse(resp => - resp.url().includes('/api/markets/search') && resp.status() === 200 - ) - - // 3. Verify search results - const marketCards = marketsPage.marketCards - await expect(marketCards.first()).toBeVisible() - const resultCount = await marketCards.count() - expect(resultCount).toBeGreaterThan(0) - - // Take screenshot of search results - await page.screenshot({ path: 'artifacts/search-results.png' }) - - // 4. Click on first result - const firstMarketTitle = await marketCards.first().textContent() - await marketCards.first().click() - - // 5. Verify market details page loads - await expect(page).toHaveURL(/\/markets\/[a-z0-9-]+/) - - const detailsPage = new MarketDetailsPage(page) - await expect(detailsPage.marketName).toBeVisible() - await expect(detailsPage.marketDescription).toBeVisible() - - // 6. Verify chart renders - await expect(detailsPage.priceChart).toBeVisible() - - // Verify market name matches - const detailsTitle = await detailsPage.marketName.textContent() - expect(detailsTitle?.toLowerCase()).toContain( - firstMarketTitle?.toLowerCase().substring(0, 20) || '' - ) - - // Take screenshot of market details - await page.screenshot({ path: 'artifacts/market-details.png' }) - }) - - test('search with no results shows empty state', async ({ page }) => { - const marketsPage = new MarketsPage(page) - await marketsPage.goto() - - // Search for non-existent market - 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) - }) -}) -``` - -## Rodando os Testes - -```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 -``` - -## Relatório de Teste - -``` -╔══════════════════════════════════════════════════════════════╗ -║ 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! -``` - -## Artefatos de Teste - -Quando os testes rodam, os seguintes artefatos são capturados: - -**Em Todos os Testes:** -- Relatório HTML com timeline e resultados -- JUnit XML para integração com CI - -**Somente em Falha:** -- Screenshot do estado de falha -- Gravação em vídeo do teste -- Arquivo de trace para debug (replay passo a passo) -- Logs de rede -- Logs de console - -## Visualizando Artefatos - -```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 -``` - -## Detecção de Teste Flaky - -Se um teste falhar de forma intermitente: - -``` -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 -``` - -## Configuração de Navegador - -Os testes rodam em múltiplos navegadores por padrão: -- PASS: Chromium (Desktop Chrome) -- PASS: Firefox (Desktop) -- PASS: WebKit (Desktop Safari) -- PASS: Mobile Chrome (optional) - -Configure em `playwright.config.ts` para ajustar navegadores. - -## Integração CI/CD - -Adicione ao seu pipeline de CI: - -```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/ -``` - -## Fluxos Críticos Específicos do PMX - -Para PMX, priorize estes testes E2E: - -**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 - -## Boas Práticas - -**DO:** -- PASS: Use Page Object Model para manutenção -- PASS: Use atributos data-testid para seletores -- PASS: Aguarde respostas de API, não timeouts arbitrários -- PASS: Teste jornadas críticas de usuário end-to-end -- PASS: Rode testes antes de mergear em main -- PASS: Revise artefatos quando testes falharem - -**DON'T:** -- FAIL: Use seletores frágeis (classes CSS podem mudar) -- FAIL: Teste detalhes de implementação -- FAIL: Rode testes contra produção -- FAIL: Ignore testes flaky -- FAIL: Pule revisão de artefatos em falhas -- FAIL: Teste todo edge case com E2E (use testes unitários) - -## Notas Importantes - -**CRITICAL para PMX:** -- Testes E2E envolvendo dinheiro real DEVEM rodar apenas em testnet/staging -- Nunca rode testes de trading em produção -- Defina `test.skip(process.env.NODE_ENV === 'production')` para testes financeiros -- Use carteiras de teste com fundos de teste pequenos apenas - -## Integração com Outros Comandos - -- Use `/plan` para identificar jornadas críticas a testar -- Use `/tdd` para testes unitários (mais rápidos e granulares) -- Use `/e2e` para integração e jornadas de usuário -- Use `/code-review` para verificar qualidade dos testes - -## Agentes Relacionados - -Este comando invoca o agente `e2e-runner` fornecido pelo ECC. - -Para instalações manuais, o arquivo fonte fica em: -`agents/e2e-runner.md` - -## Comandos Rápidos - -```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 -``` diff --git a/docs/pt-BR/commands/eval.md b/docs/pt-BR/commands/eval.md deleted file mode 100644 index 780f82a00b..0000000000 --- a/docs/pt-BR/commands/eval.md +++ /dev/null @@ -1,120 +0,0 @@ -# Comando Eval - -Gerencie o fluxo de desenvolvimento orientado por evals. - -## Uso - -`/eval [define|check|report|list] [feature-name]` - -## Definir Evals - -`/eval define feature-name` - -Crie uma nova definição de eval: - -1. Crie `.claude/evals/feature-name.md` com o template: - -```markdown -## EVAL: feature-name -Created: $(date) - -### Evals de Capacidade -- [ ] [Descrição da capacidade 1] -- [ ] [Descrição da capacidade 2] - -### Evals de Regressão -- [ ] [Comportamento existente 1 ainda funciona] -- [ ] [Comportamento existente 2 ainda funciona] - -### Critérios de Sucesso -- pass@3 > 90% para evals de capacidade -- pass^3 = 100% para evals de regressão -``` - -2. Peça ao usuário para preencher os critérios específicos - -## Verificar Evals - -`/eval check feature-name` - -Rode evals para uma feature: - -1. Leia a definição de eval em `.claude/evals/feature-name.md` -2. Para cada eval de capability: - - Tente verificar o critério - - Registre PASS/FAIL - - Salve tentativa em `.claude/evals/feature-name.log` -3. Para cada eval de regressão: - - Rode os testes relevantes - - Compare com baseline - - Registre PASS/FAIL -4. Reporte status atual: - -``` -EVAL CHECK: feature-name -======================== -Capability: X/Y passing -Regression: X/Y passing -Status: IN PROGRESS / READY -``` - -## Relatório de Evals - -`/eval report feature-name` - -Gere relatório completo de eval: - -``` -EVAL REPORT: feature-name -========================= -Generated: $(date) - -CAPABILITY EVALS ----------------- -[eval-1]: PASS (pass@1) -[eval-2]: PASS (pass@2) - required retry -[eval-3]: FAIL - see notes - -REGRESSION EVALS ----------------- -[test-1]: PASS -[test-2]: PASS -[test-3]: PASS - -METRICS -------- -Capability pass@1: 67% -Capability pass@3: 100% -Regression pass^3: 100% - -NOTES ------ -[Any issues, edge cases, or observations] - -RECOMMENDATION --------------- -[SHIP / NEEDS WORK / BLOCKED] -``` - -## Listar Evals - -`/eval list` - -Mostre todas as definições de eval: - -``` -EVAL DEFINITIONS -================ -feature-auth [3/5 passing] IN PROGRESS -feature-search [5/5 passing] READY -feature-export [0/4 passing] NOT STARTED -``` - -## Argumentos - -$ARGUMENTS: -- `define ` - Criar nova definição de eval -- `check ` - Rodar e verificar evals -- `report ` - Gerar relatório completo -- `list` - Mostrar todos os evals -- `clean` - Remover logs antigos de eval (mantém as últimas 10 execuções) diff --git a/docs/pt-BR/commands/orchestrate.md b/docs/pt-BR/commands/orchestrate.md deleted file mode 100644 index 0c41410fcb..0000000000 --- a/docs/pt-BR/commands/orchestrate.md +++ /dev/null @@ -1,230 +0,0 @@ ---- -description: Orientação de orquestração sequencial e tmux/worktree para fluxos multiagente. ---- - -# Comando Orchestrate - -Fluxo sequencial de agentes para tarefas complexas. - -## Uso - -`/orchestrate [workflow-type] [task-description]` - -## Tipos de Workflow - -### feature -Workflow completo de implementação de feature: -``` -planner -> tdd-guide -> code-reviewer -> security-reviewer -``` - -### bugfix -Workflow de investigação e correção de bug: -``` -planner -> tdd-guide -> code-reviewer -``` - -### refactor -Workflow de refatoração segura: -``` -architect -> code-reviewer -> tdd-guide -``` - -### security -Revisão focada em segurança: -``` -security-reviewer -> code-reviewer -> architect -``` - -## Padrão de Execução - -Para cada agente no workflow: - -1. **Invoque o agente** com contexto do agente anterior -2. **Colete saída** como documento estruturado de handoff -3. **Passe para o próximo agente** na cadeia -4. **Agregue resultados** em um relatório final - -## Formato do Documento de Handoff - -Entre agentes, crie um documento de handoff: - -```markdown -## HANDOFF: [previous-agent] -> [next-agent] - -### Context -[Summary of what was done] - -### Findings -[Key discoveries or decisions] - -### Files Modified -[List of files touched] - -### Open Questions -[Unresolved items for next agent] - -### Recommendations -[Suggested next steps] -``` - -## Exemplo: Workflow de Feature - -``` -/orchestrate feature "Add user authentication" -``` - -Executa: - -1. **Planner Agent** - - Analisa requisitos - - Cria plano de implementação - - Identifica dependências - - Saída: `HANDOFF: planner -> tdd-guide` - -2. **TDD Guide Agent** - - Lê handoff do planner - - Escreve testes primeiro - - Implementa para passar testes - - Saída: `HANDOFF: tdd-guide -> code-reviewer` - -3. **Code Reviewer Agent** - - Revisa implementação - - Verifica problemas - - Sugere melhorias - - Saída: `HANDOFF: code-reviewer -> security-reviewer` - -4. **Security Reviewer Agent** - - Auditoria de segurança - - Verificação de vulnerabilidades - - Aprovação final - - Saída: Relatório Final - -## Formato do Relatório Final - -``` -ORCHESTRATION REPORT -==================== -Workflow: feature -Task: Add user authentication -Agents: planner -> tdd-guide -> code-reviewer -> security-reviewer - -SUMMARY -------- -[One paragraph summary] - -AGENT OUTPUTS -------------- -Planner: [summary] -TDD Guide: [summary] -Code Reviewer: [summary] -Security Reviewer: [summary] - -FILES CHANGED -------------- -[List all files modified] - -TEST RESULTS ------------- -[Test pass/fail summary] - -SECURITY STATUS ---------------- -[Security findings] - -RECOMMENDATION --------------- -[SHIP / NEEDS WORK / BLOCKED] -``` - -## Execução Paralela - -Para verificações independentes, rode agentes em paralelo: - -```markdown -### Fase Paralela -Executar simultaneamente: -- code-reviewer (qualidade) -- security-reviewer (segurança) -- architect (design) - -### Mesclar Resultados -Combinar saídas em um único relatório - -Para workers externos em tmux panes com git worktrees separados, use `node scripts/orchestrate-worktrees.js plan.json --execute`. O padrão embutido de orquestração permanece no processo atual; o helper é para sessões longas ou cross-harness. - -Quando os workers precisarem enxergar arquivos locais sujos ou não rastreados do checkout principal, adicione `seedPaths` ao arquivo de plano. O ECC faz overlay apenas desses caminhos selecionados em cada worktree do worker após `git worktree add`, mantendo o branch isolado e ainda expondo scripts, planos ou docs em andamento. - -```json -{ - "sessionName": "workflow-e2e", - "seedPaths": [ - "scripts/orchestrate-worktrees.js", - "scripts/lib/tmux-worktree-orchestrator.js", - ".claude/plan/workflow-e2e-test.json" - ], - "workers": [ - { "name": "docs", "task": "Update orchestration docs." } - ] -} -``` - -Para exportar um snapshot do control plane para uma sessão tmux/worktree ao vivo, rode: - -```bash -node scripts/orchestration-status.js .claude/plan/workflow-visual-proof.json -``` - -O snapshot inclui atividade da sessão, metadados de pane do tmux, estado dos workers, objetivos, overlays semeados e resumos recentes de handoff em formato JSON. - -## Handoff de Command Center do Operador - -Quando o workflow atravessar múltiplas sessões, worktrees ou panes tmux, acrescente um bloco de control plane ao handoff final: - -```markdown -CONTROL PLANE -------------- -Sessions: -- active session ID or alias -- branch + worktree path for each active worker -- tmux pane or detached session name when applicable - -Diffs: -- git status summary -- git diff --stat for touched files -- merge/conflict risk notes - -Approvals: -- pending user approvals -- blocked steps awaiting confirmation - -Telemetry: -- last activity timestamp or idle signal -- estimated token or cost drift -- policy events raised by hooks or reviewers -``` - -Isso mantém planner, implementador, revisor e loop workers legíveis pela superfície de operação. - -## Argumentos - -$ARGUMENTS: -- `feature ` - Workflow completo de feature -- `bugfix ` - Workflow de correção de bug -- `refactor ` - Workflow de refatoração -- `security ` - Workflow de revisão de segurança -- `custom ` - Sequência customizada de agentes - -## Exemplo de Workflow Customizado - -``` -/orchestrate custom "architect,tdd-guide,code-reviewer" "Redesign caching layer" -``` - -## Dicas - -1. **Comece com planner** para features complexas -2. **Sempre inclua code-reviewer** antes do merge -3. **Use security-reviewer** para auth/pagamento/PII -4. **Mantenha handoffs concisos** - foque no que o próximo agente precisa -5. **Rode verificação** entre agentes quando necessário diff --git a/docs/pt-BR/commands/tdd.md b/docs/pt-BR/commands/tdd.md deleted file mode 100644 index 1cd4677856..0000000000 --- a/docs/pt-BR/commands/tdd.md +++ /dev/null @@ -1,328 +0,0 @@ ---- -description: Impõe fluxo de desenvolvimento orientado a testes. Estruture interfaces, gere testes PRIMEIRO e depois implemente código mínimo para passar. Garanta cobertura de 80%+. ---- - -# Comando TDD - -Este comando invoca o agente **tdd-guide** para impor a metodologia de desenvolvimento orientado a testes. - -## O Que Este Comando Faz - -1. **Estruturar Interfaces** - Definir tipos/interfaces primeiro -2. **Gerar Testes Primeiro** - Escrever testes que falham (RED) -3. **Implementar Código Mínimo** - Escrever apenas o suficiente para passar (GREEN) -4. **Refatorar** - Melhorar o código mantendo testes verdes (REFACTOR) -5. **Verificar Cobertura** - Garantir cobertura de testes de 80%+ - -## Quando Usar - -Use `/tdd` quando: -- Implementar novas features -- Adicionar novas funções/componentes -- Corrigir bugs (escrever primeiro teste que reproduz o bug) -- Refatorar código existente -- Construir lógica de negócio crítica - -## Como Funciona - -O agente tdd-guide vai: - -1. **Definir interfaces** para entradas/saídas -2. **Escrever testes que vão FALHAR** (porque o código ainda não existe) -3. **Rodar testes** e verificar que falham pelo motivo correto -4. **Escrever implementação mínima** para fazer testes passarem -5. **Rodar testes** e verificar que passam -6. **Refatorar** código mantendo testes verdes -7. **Checar cobertura** e adicionar mais testes se estiver abaixo de 80% - -## Ciclo TDD - -``` -RED → GREEN → REFACTOR → REPEAT - -RED: Write a failing test -GREEN: Write minimal code to pass -REFACTOR: Improve code, keep tests passing -REPEAT: Next feature/scenario -``` - -## Exemplo de Uso - -``` -Usuário: /tdd Preciso de uma função para calcular a pontuação de liquidez do mercado - -Agent (tdd-guide): -# Sessão TDD: Calculadora de Pontuação de Liquidez de Mercado - -## Etapa 1: Definir Interface (SCAFFOLD) - -```typescript -// lib/liquidity.ts -export interface MarketData { - totalVolume: number - bidAskSpread: number - activeTraders: number - lastTradeTime: Date -} - -export function calculateLiquidityScore(market: MarketData): number { - // TODO: Implementation - throw new Error('Not implemented') -} -``` - -## Etapa 2: Escreva o teste com falha (VERMELHO) - -```typescript -// lib/liquidity.test.ts -import { calculateLiquidityScore } from './liquidity' - -describe('calculateLiquidityScore', () => { - it('should return high score for liquid market', () => { - const market = { - totalVolume: 100000, - bidAskSpread: 0.01, - activeTraders: 500, - lastTradeTime: new Date() - } - - const score = calculateLiquidityScore(market) - - expect(score).toBeGreaterThan(80) - expect(score).toBeLessThanOrEqual(100) - }) - - it('should return low score for illiquid market', () => { - const market = { - totalVolume: 100, - bidAskSpread: 0.5, - activeTraders: 2, - lastTradeTime: new Date(Date.now() - 86400000) // 1 day ago - } - - const score = calculateLiquidityScore(market) - - expect(score).toBeLessThan(30) - expect(score).toBeGreaterThanOrEqual(0) - }) - - it('should handle edge case: zero volume', () => { - const market = { - totalVolume: 0, - bidAskSpread: 0, - activeTraders: 0, - lastTradeTime: new Date() - } - - const score = calculateLiquidityScore(market) - - expect(score).toBe(0) - }) -}) -``` - -## Etapa 3: Executar testes - Verificar FALHA - -```bash -npm test lib/liquidity.test.ts - -FAIL lib/liquidity.test.ts - ✕ should return high score for liquid market (2 ms) - Error: Not implemented - -1 test failed, 0 passed -``` - -PASS: Os testes falharam conforme o esperado. Pronto para implementação. - -## Etapa 4: Implementar o código mínimo (VERDE) - -```typescript -// lib/liquidity.ts -export function calculateLiquidityScore(market: MarketData): number { - // Handle zero volume edge case - if (market.totalVolume === 0) { - return 0 - } - - // Calculate component scores (0-100 scale) - const volumeScore = Math.min(market.totalVolume / 1000, 100) - const spreadScore = Math.max(100 - (market.bidAskSpread * 1000), 0) - const traderScore = Math.min(market.activeTraders / 10, 100) - - // Recent activity bonus - const hoursSinceLastTrade = (Date.now() - market.lastTradeTime.getTime()) / (1000 * 60 * 60) - const recencyScore = Math.max(100 - (hoursSinceLastTrade * 10), 0) - - // Weighted average - const score = ( - volumeScore * 0.4 + - spreadScore * 0.3 + - traderScore * 0.2 + - recencyScore * 0.1 - ) - - return Math.min(Math.max(score, 0), 100) // Clamp to 0-100 -} -``` - -## Etapa 5: Executar testes - Verificar se foi aprovado - -```bash -npm test lib/liquidity.test.ts - -PASS lib/liquidity.test.ts - ✓ should return high score for liquid market (3 ms) - ✓ should return low score for illiquid market (2 ms) - ✓ should handle edge case: zero volume (1 ms) - -3 tests passed -``` - -PASS: Todos os testes passando - -## Etapa 6: Refatorar (MELHORAR) - -```typescript -// lib/liquidity.ts - Refatorado com constantes e melhor legibilidade. -const WEIGHTS = { - VOLUME: 0.4, - SPREAD: 0.3, - TRADERS: 0.2, - RECENCY: 0.1, -} as const - -const SCALE_FACTORS = { - VOLUME: 1000, - SPREAD: 1000, - TRADERS: 10, - RECENCY_PENALTY: 10, -} as const - -function clamp(value: number, min: number, max: number): number { - return Math.min(Math.max(value, min), max) -} - -export function calculateLiquidityScore(market: MarketData): number { - if (market.totalVolume === 0) return 0 - - const volumeScore = Math.min(market.totalVolume / SCALE_FACTORS.VOLUME, 100) - const spreadScore = clamp(100 - (market.bidAskSpread * SCALE_FACTORS.SPREAD), 0, 100) - const traderScore = Math.min(market.activeTraders / SCALE_FACTORS.TRADERS, 100) - - const hoursSinceLastTrade = (Date.now() - market.lastTradeTime.getTime()) / (1000 * 60 * 60) - const recencyScore = clamp(100 - (hoursSinceLastTrade * SCALE_FACTORS.RECENCY_PENALTY), 0, 100) - - const weightedScore = - volumeScore * WEIGHTS.VOLUME + - spreadScore * WEIGHTS.SPREAD + - traderScore * WEIGHTS.TRADERS + - recencyScore * WEIGHTS.RECENCY - - return clamp(weightedScore, 0, 100) -} -``` - -## Etapa 7: Verificar se os testes ainda são aprovados - -```bash -npm test lib/liquidity.test.ts - -PASS lib/liquidity.test.ts - ✓ should return high score for liquid market (3 ms) - ✓ should return low score for illiquid market (2 ms) - ✓ should handle edge case: zero volume (1 ms) - -3 tests passed -``` - -PASS: Refatoração concluída, testes ainda passando! - -## Etapa 8: Verificar a cobertura - -```bash -npm test -- --coverage lib/liquidity.test.ts - -File | % Stmts | % Branch | % Funcs | % Lines ----------------|---------|----------|---------|-------- -liquidity.ts | 100 | 100 | 100 | 100 - -Coverage: 100% PASS: (Target: 80%) -``` - -PASS: TDD sessão completa! -``` - -## Boas Práticas de TDD - -**Fazer:** -- PASS: Escreva o teste PRIMEIRO, antes da implementação -- PASS: Rode testes e confirme que FALHAM antes de implementar -- PASS: Escreva código mínimo para fazer passar -- PASS: Refatore só depois que os testes estiverem verdes -- PASS: Adicione casos de borda e cenários de erro -- PASS: Mire 80%+ de cobertura (100% para código crítico) - -**Não fazer:** -- FAIL: Escrever implementação antes de testes -- FAIL: Pular execução de testes após cada mudança -- FAIL: Escrever código demais de uma vez -- FAIL: Ignorar testes falhando -- FAIL: Testar detalhes de implementação (teste comportamento) -- FAIL: Fazer mock de tudo (prefira testes de integração) - -## Tipos de Teste a Incluir - -**Testes Unitários** (nível de função): -- Cenários happy path -- Casos de borda (vazio, null, valores máximos) -- Condições de erro -- Valores de fronteira - -**Testes de Integração** (nível de componente): -- Endpoints de API -- Operações de banco de dados -- Chamadas a serviços externos -- Componentes React com hooks - -**Testes E2E** (use comando `/e2e`): -- Fluxos críticos de usuário -- Processos multi-etapa -- Integração full stack - -## Requisitos de Cobertura - -- **Mínimo de 80%** para todo o código -- **100% obrigatório** para: - - Cálculos financeiros - - Lógica de autenticação - - Código crítico de segurança - - Lógica de negócio central - -## Notas Importantes - -**MANDATÓRIO**: Os testes devem ser escritos ANTES da implementação. O ciclo TDD é: - -1. **RED** - Escrever teste que falha -2. **GREEN** - Implementar para passar -3. **REFACTOR** - Melhorar código - -Nunca pule a fase RED. Nunca escreva código antes dos testes. - -## Integração com Outros Comandos - -- Use `/plan` primeiro para entender o que construir -- Use `/tdd` para implementar com testes -- Use `/build-fix` se ocorrerem erros de build -- Use `/code-review` para revisar implementação -- Use `/test-coverage` para verificar cobertura - -## Agentes Relacionados - -Este comando invoca o agente `tdd-guide` fornecido pelo ECC. - -A skill relacionada `tdd-workflow` também é distribuída com o ECC. - -Para instalações manuais, os arquivos fonte ficam em: -- `agents/tdd-guide.md` -- `skills/tdd-workflow/SKILL.md` diff --git a/docs/pt-BR/commands/verify.md b/docs/pt-BR/commands/verify.md deleted file mode 100644 index 5916a529b3..0000000000 --- a/docs/pt-BR/commands/verify.md +++ /dev/null @@ -1,59 +0,0 @@ -# Comando Verification - -Rode verificação abrangente no estado atual do codebase. - -## Instruções - -Execute a verificação nesta ordem exata: - -1. **Build Check** - - Rode o comando de build deste projeto - - Se falhar, reporte erros e PARE - -2. **Type Check** - - Rode o TypeScript/type checker - - Reporte todos os erros com file:line - -3. **Lint Check** - - Rode o linter - - Reporte warnings e errors - -4. **Test Suite** - - Rode todos os testes - - Reporte contagem de pass/fail - - Reporte percentual de cobertura - -5. **Console.log Audit** - - Procure por console.log em arquivos de código-fonte - - Reporte localizações - -6. **Git Status** - - Mostre mudanças não commitadas - - Mostre arquivos modificados desde o último commit - -## Saída - -Produza um relatório conciso de verificação: - -``` -VERIFICATION: [PASS/FAIL] - -Build: [OK/FAIL] -Types: [OK/X errors] -Lint: [OK/X issues] -Tests: [X/Y passed, Z% coverage] -Secrets: [OK/X found] -Logs: [OK/X console.logs] - -Ready for PR: [YES/NO] -``` - -Se houver problemas críticos, liste-os com sugestões de correção. - -## Argumentos - -$ARGUMENTS podem ser: -- `quick` - Apenas build + types -- `full` - Todas as checagens (padrão) -- `pre-commit` - Checagens relevantes para commits -- `pre-pr` - Checagens completas mais security scan diff --git a/docs/tr/commands/e2e.md b/docs/tr/commands/e2e.md deleted file mode 100644 index 3212e492d8..0000000000 --- a/docs/tr/commands/e2e.md +++ /dev/null @@ -1,365 +0,0 @@ ---- -description: Playwright ile end-to-end testler oluştur ve çalıştır. Test yolculukları oluşturur, testleri çalıştırır, ekran görüntüleri/videolar/izlemeler yakalar ve artifact'ları yükler. ---- - -# E2E Komutu - -Bu komut, Playwright kullanarak end-to-end testleri oluşturmak, sürdürmek ve yürütmek için **e2e-runner** agent'ını çağırır. - -## Bu Komut Ne Yapar - -1. **Test Yolculukları Oluştur** - Kullanıcı akışları için Playwright testleri oluştur -2. **E2E Testlerini Çalıştır** - Testleri tarayıcılar arasında yürüt -3. **Artifact'ları Yakala** - Hatalarda ekran görüntüleri, videolar, izlemeler -4. **Sonuçları Yükle** - HTML raporları ve JUnit XML -5. **Dengesiz Testleri Tanımla** - Kararsız testleri karantinaya al - -## Ne Zaman Kullanılır - -`/e2e` komutunu şu durumlarda kullanın: -- Kritik kullanıcı yolculuklarını test ederken (giriş, ticaret, ödemeler) -- Çok adımlı akışların uçtan uca çalıştığını doğrularken -- UI etkileşimlerini ve navigasyonu test ederken -- Frontend ve backend arasındaki entegrasyonu doğrularken -- Üretime dağıtım için hazırlanırken - -## Nasıl Çalışır - -e2e-runner agent'ı şunları yapacaktır: - -1. **Kullanıcı akışını analiz edecek** ve test senaryolarını tanımlayacak -2. Page Object Model deseni kullanarak **Playwright testi oluşturacak** -3. **Testleri çalıştıracak** (Chrome, Firefox, Safari) -4. Ekran görüntüleri, videolar ve izlemelerle **hataları yakalayacak** -5. Sonuçlar ve artifact'larla **rapor oluşturacak** -6. **Dengesiz testleri tanımlayacak** ve düzeltme önerilerinde bulunacak - -## Örnek Kullanım - -``` -Kullanıcı: /e2e Piyasa arama ve görüntüleme akışını test et - -Agent (e2e-runner): -# E2E Test Oluşturma: Piyasa Arama ve Görüntüleme Akışı - -## Tanımlanan Test Senaryosu - -**Kullanıcı Yolculuğu:** Piyasa Arama → Sonuçları Görüntüle → Piyasaya Tıkla → Detayları Görüntüle - -**Test Kapsamı:** -1. Piyasalar sayfasına git -2. Semantik arama yap -3. Arama sonuçlarını doğrula -4. İlk sonuca tıkla -5. Piyasa detay sayfasının yüklendiğini doğrula -6. Grafiğin render olduğunu doğrula - -## Oluşturulan Test Kodu - -```typescript -// tests/e2e/markets/search-and-view.spec.ts -import { test, expect } from '@playwright/test' -import { MarketsPage } from '../../pages/MarketsPage' -import { MarketDetailsPage } from '../../pages/MarketDetailsPage' - -test.describe('Market Search and View Flow', () => { - test('kullanıcı piyasaları arayabilir ve detayları görüntüleyebilir', async ({ page }) => { - // 1. Piyasalar sayfasına git - const marketsPage = new MarketsPage(page) - await marketsPage.goto() - - // Sayfanın yüklendiğini doğrula - await expect(page).toHaveTitle(/Markets/) - await expect(page.locator('h1')).toContainText('Markets') - - // 2. Semantik arama yap - await marketsPage.searchMarkets('election') - - // API yanıtını bekle - await page.waitForResponse(resp => - resp.url().includes('/api/markets/search') && resp.status() === 200 - ) - - // 3. Arama sonuçlarını doğrula - const marketCards = marketsPage.marketCards - await expect(marketCards.first()).toBeVisible() - const resultCount = await marketCards.count() - expect(resultCount).toBeGreaterThan(0) - - // Arama sonuçlarının ekran görüntüsünü al - await page.screenshot({ path: 'artifacts/search-results.png' }) - - // 4. İlk sonuca tıkla - const firstMarketTitle = await marketCards.first().textContent() - await marketCards.first().click() - - // 5. Piyasa detay sayfasının yüklendiğini doğrula - await expect(page).toHaveURL(/\/markets\/[a-z0-9-]+/) - - const detailsPage = new MarketDetailsPage(page) - await expect(detailsPage.marketName).toBeVisible() - await expect(detailsPage.marketDescription).toBeVisible() - - // 6. Grafiğin render olduğunu doğrula - await expect(detailsPage.priceChart).toBeVisible() - - // Piyasa adının eşleştiğini doğrula - const detailsTitle = await detailsPage.marketName.textContent() - expect(detailsTitle?.toLowerCase()).toContain( - firstMarketTitle?.toLowerCase().substring(0, 20) || '' - ) - - // Piyasa detaylarının ekran görüntüsünü al - await page.screenshot({ path: 'artifacts/market-details.png' }) - }) - - test('sonuç olmayan arama boş durumu göstermeli', async ({ page }) => { - const marketsPage = new MarketsPage(page) - await marketsPage.goto() - - // Var olmayan piyasayı ara - await marketsPage.searchMarkets('xyznonexistentmarket123456') - - // Boş durumu doğrula - 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('aramayı temizleyebilir ve tüm piyasaları tekrar görebilir', async ({ page }) => { - const marketsPage = new MarketsPage(page) - await marketsPage.goto() - - // İlk piyasa sayısı - const initialCount = await marketsPage.marketCards.count() - - // Arama yap - await marketsPage.searchMarkets('trump') - await page.waitForLoadState('networkidle') - - // Filtrelenmiş sonuçları doğrula - const filteredCount = await marketsPage.marketCards.count() - expect(filteredCount).toBeLessThan(initialCount) - - // Aramayı temizle - await marketsPage.searchInput.clear() - await page.waitForLoadState('networkidle') - - // Tüm piyasaların tekrar gösterildiğini doğrula - const finalCount = await marketsPage.marketCards.count() - expect(finalCount).toBe(initialCount) - }) -}) -``` - -## Testleri Çalıştırma - -```bash -# Oluşturulan testi çalıştır -npx playwright test tests/e2e/markets/search-and-view.spec.ts - -3 worker kullanarak 3 test çalıştırılıyor - - ✓ [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) - -Oluşturulan artifact'lar: -- artifacts/search-results.png -- artifacts/market-details.png -- playwright-report/index.html -``` - -## Test Raporu - -``` -╔══════════════════════════════════════════════════════════════╗ -║ E2E Test Sonuçları ║ -╠══════════════════════════════════════════════════════════════╣ -║ Durum: PASS: TÜM TESTLER GEÇTİ ║ -║ Toplam: 3 test ║ -║ Geçti: 3 (%100) ║ -║ Başarısız: 0 ║ -║ Dengesiz: 0 ║ -║ Süre: 9.1s ║ -╚══════════════════════════════════════════════════════════════╝ - -Artifact'lar: - Ekran Görüntüleri: 2 dosya - Videolar: 0 dosya (sadece hatada) - İzlemeler: 0 dosya (sadece hatada) - HTML Rapor: playwright-report/index.html - -Raporu görüntüle: npx playwright show-report -``` - -PASS: E2E test paketi CI/CD entegrasyonuna hazır! -``` - -## Test Artifact'ları - -Testler çalıştığında, şu artifact'lar yakalanır: - -**Tüm Testlerde:** -- Zaman çizelgesi ve sonuçlarla HTML Rapor -- CI entegrasyonu için JUnit XML - -**Sadece Hatada:** -- Başarısız durumun ekran görüntüsü -- Testin video kaydı -- Hata ayıklama için izleme dosyası (adım adım tekrar) -- Network logları -- Console logları - -## Artifact'ları Görüntüleme - -```bash -# HTML raporunu tarayıcıda görüntüle -npx playwright show-report - -# Belirli izleme dosyasını görüntüle -npx playwright show-trace artifacts/trace-abc123.zip - -# Ekran görüntüleri artifacts/ dizinine kaydedilir -open artifacts/search-results.png -``` - -## Dengesiz Test Tespiti - -Bir test aralıklı olarak başarısız olursa: - -``` -WARNING: DENGESİZ TEST TESPİT EDİLDİ: tests/e2e/markets/trade.spec.ts - -Test 10 çalıştırmadan 7'sinde geçti (%70 geçme oranı) - -Yaygın başarısızlık: -"'[data-testid="confirm-btn"]' elementi için timeout" - -Önerilen düzeltmeler: -1. Açık bekleme ekle: await page.waitForSelector('[data-testid="confirm-btn"]') -2. Timeout'u artır: { timeout: 10000 } -3. Component'te yarış koşullarını kontrol et -4. Elementin animasyon tarafından gizlenmediğini doğrula - -Karantina önerisi: Düzeltilene kadar test.fixme() olarak işaretle -``` - -## Tarayıcı Yapılandırması - -Testler varsayılan olarak birden fazla tarayıcıda çalışır: -- PASS: Chromium (Desktop Chrome) -- PASS: Firefox (Desktop) -- PASS: WebKit (Desktop Safari) -- PASS: Mobile Chrome (opsiyonel) - -Tarayıcıları ayarlamak için `playwright.config.ts`'yi yapılandırın. - -## CI/CD Entegrasyonu - -CI pipeline'ınıza ekleyin: - -```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'e Özgü Kritik Akışlar - -PMX için bu E2E testlerine öncelik verin: - -**KRİTİK (Her Zaman Geçmeli):** -1. Kullanıcı cüzdan bağlayabilir -2. Kullanıcı piyasalara göz atabilir -3. Kullanıcı piyasa arayabilir (semantik arama) -4. Kullanıcı piyasa detaylarını görüntüleyebilir -5. Kullanıcı işlem yapabilir (test fonlarıyla) -6. Piyasa doğru çözülür -7. Kullanıcı fon çekebilir - -**ÖNEMLİ:** -1. Piyasa oluşturma akışı -2. Kullanıcı profil güncellemeleri -3. Gerçek zamanlı fiyat güncellemeleri -4. Grafik render'ı -5. Piyasaları filtreleme ve sıralama -6. Mobil responsive layout - -## En İyi Uygulamalar - -**YAPIN:** -- PASS: Sürdürülebilirlik için Page Object Model kullanın -- PASS: Selector'lar için data-testid nitelikleri kullanın -- PASS: Rastgele timeout'lar değil, API yanıtlarını bekleyin -- PASS: Kritik kullanıcı yolculuklarını uçtan uca test edin -- PASS: Main'e merge etmeden önce testleri çalıştırın -- PASS: Testler başarısız olduğunda artifact'ları inceleyin - -**YAPMAYIN:** -- FAIL: Kırılgan selector'lar kullanmayın (CSS sınıfları değişebilir) -- FAIL: Uygulama detaylarını test etmeyin -- FAIL: Production'a karşı testler çalıştırmayın -- FAIL: Dengesiz testleri görmezden gelmeyin -- FAIL: Başarısızlıklarda artifact incelemesini atlamayın -- FAIL: Her edge case'i E2E ile test etmeyin (unit testler kullanın) - -## Önemli Notlar - -**PMX için KRİTİK:** -- Gerçek para içeren E2E testleri SADECE testnet/staging'de çalışmalıdır -- Asla production'a karşı ticaret testleri çalıştırmayın -- Finansal testler için `test.skip(process.env.NODE_ENV === 'production')` ayarlayın -- Sadece küçük test fonlarıyla test cüzdanları kullanın - -## Diğer Komutlarla Entegrasyon - -- Test edilecek kritik yolculukları tanımlamak için `/plan` kullanın -- Unit testler için `/tdd` kullanın (daha hızlı, daha ayrıntılı) -- Entegrasyon ve kullanıcı yolculuk testleri için `/e2e` kullanın -- Test kalitesini doğrulamak için `/code-review` kullanın - -## İlgili Agent'lar - -Bu komut, ECC tarafından sağlanan `e2e-runner` agent'ını çağırır. - -Manuel kurulumlar için, kaynak dosya şurada bulunur: -`agents/e2e-runner.md` - -## Hızlı Komutlar - -```bash -# Tüm E2E testlerini çalıştır -npx playwright test - -# Belirli test dosyasını çalıştır -npx playwright test tests/e2e/markets/search.spec.ts - -# Headed modda çalıştır (tarayıcıyı gör) -npx playwright test --headed - -# Testi debug et -npx playwright test --debug - -# Test kodu oluştur -npx playwright codegen http://localhost:3000 - -# Raporu görüntüle -npx playwright show-report -``` diff --git a/docs/tr/commands/eval.md b/docs/tr/commands/eval.md deleted file mode 100644 index cf74da2d81..0000000000 --- a/docs/tr/commands/eval.md +++ /dev/null @@ -1,120 +0,0 @@ -# Eval Komutu - -Eval-odaklı geliştirme iş akışını yönet. - -## Kullanım - -`/eval [define|check|report|list] [feature-name]` - -## Eval Tanımla - -`/eval define feature-name` - -Yeni bir eval tanımı oluştur: - -1. Şablonla `.claude/evals/feature-name.md` oluştur: - -```markdown -## EVAL: feature-name -Created: $(date) - -### Capability Evals -- [ ] [Capability 1 açıklaması] -- [ ] [Capability 2 açıklaması] - -### Regression Evals -- [ ] [Mevcut davranış 1 hala çalışıyor] -- [ ] [Mevcut davranış 2 hala çalışıyor] - -### Success Criteria -- pass@3 > 90% for capability evals -- pass^3 = 100% for regression evals -``` - -2. Kullanıcıdan belirli kriterleri doldurmasını iste - -## Eval Kontrol Et - -`/eval check feature-name` - -Bir özellik için eval'ları çalıştır: - -1. `.claude/evals/feature-name.md` dosyasından eval tanımını oku -2. Her capability eval için: - - Kriteri doğrulamayı dene - - PASS/FAIL kaydet - - Denemeyi `.claude/evals/feature-name.log` dosyasına kaydet -3. Her regression eval için: - - İlgili test'leri çalıştır - - Baseline ile karşılaştır - - PASS/FAIL kaydet -4. Mevcut durumu raporla: - -``` -EVAL CHECK: feature-name -======================== -Capability: X/Y passing -Regression: X/Y passing -Status: IN PROGRESS / READY -``` - -## Eval Raporu - -`/eval report feature-name` - -Kapsamlı eval raporu oluştur: - -``` -EVAL REPORT: feature-name -========================= -Generated: $(date) - -CAPABILITY EVALS ----------------- -[eval-1]: PASS (pass@1) -[eval-2]: PASS (pass@2) - required retry -[eval-3]: FAIL - see notes - -REGRESSION EVALS ----------------- -[test-1]: PASS -[test-2]: PASS -[test-3]: PASS - -METRICS -------- -Capability pass@1: 67% -Capability pass@3: 100% -Regression pass^3: 100% - -NOTES ------ -[Herhangi bir sorun, edge case veya gözlem] - -RECOMMENDATION --------------- -[SHIP / NEEDS WORK / BLOCKED] -``` - -## Eval'ları Listele - -`/eval list` - -Tüm eval tanımlarını göster: - -``` -EVAL DEFINITIONS -================ -feature-auth [3/5 passing] IN PROGRESS -feature-search [5/5 passing] READY -feature-export [0/4 passing] NOT STARTED -``` - -## Argümanlar - -$ARGUMENTS: -- `define ` - Yeni eval tanımı oluştur -- `check ` - Eval'ları çalıştır ve kontrol et -- `report ` - Tam rapor oluştur -- `list` - Tüm eval'ları göster -- `clean` - Eski eval loglarını kaldır (son 10 çalıştırmayı tutar) diff --git a/docs/tr/commands/orchestrate.md b/docs/tr/commands/orchestrate.md deleted file mode 100644 index 08c956501b..0000000000 --- a/docs/tr/commands/orchestrate.md +++ /dev/null @@ -1,231 +0,0 @@ ---- -description: Multi-agent iş akışları için sıralı ve tmux/worktree orkestrasyon rehberi. ---- - -# Orchestrate Komutu - -Karmaşık görevler için sıralı agent iş akışı. - -## Kullanım - -`/orchestrate [workflow-type] [task-description]` - -## Workflow Tipleri - -### feature -Tam özellik implementasyon iş akışı: -``` -planner -> tdd-guide -> code-reviewer -> security-reviewer -``` - -### bugfix -Bug araştırma ve düzeltme iş akışı: -``` -planner -> tdd-guide -> code-reviewer -``` - -### refactor -Güvenli refactoring iş akışı: -``` -architect -> code-reviewer -> tdd-guide -``` - -### security -Güvenlik odaklı review: -``` -security-reviewer -> code-reviewer -> architect -``` - -## Execution Pattern - -İş akışındaki her agent için: - -1. **Agent'ı çağır** önceki agent'tan gelen context ile -2. **Çıktıyı topla** yapılandırılmış handoff dokümanı olarak -3. **Sonraki agent'a geçir** zincirde -4. **Sonuçları topla** nihai rapora - -## Handoff Doküman Formatı - -Agent'lar arasında, handoff dokümanı oluştur: - -```markdown -## HANDOFF: [previous-agent] -> [next-agent] - -### Context -[Yapılanların özeti] - -### Findings -[Anahtar keşifler veya kararlar] - -### Files Modified -[Dokunulan dosyaların listesi] - -### Open Questions -[Sonraki agent için çözülmemiş öğeler] - -### Recommendations -[Önerilen sonraki adımlar] -``` - -## Örnek: Feature Workflow - -``` -/orchestrate feature "Add user authentication" -``` - -Çalıştırır: - -1. **Planner Agent** - - Requirement'ları analiz eder - - Implementation planı oluşturur - - Bağımlılıkları tanımlar - - Çıktı: `HANDOFF: planner -> tdd-guide` - -2. **TDD Guide Agent** - - Planner handoff'unu okur - - Önce test'leri yazar - - Test'leri geçirmek için implement eder - - Çıktı: `HANDOFF: tdd-guide -> code-reviewer` - -3. **Code Reviewer Agent** - - Implementation'ı gözden geçirir - - Sorunları kontrol eder - - İyileştirmeler önerir - - Çıktı: `HANDOFF: code-reviewer -> security-reviewer` - -4. **Security Reviewer Agent** - - Güvenlik denetimi - - Güvenlik açığı kontrolü - - Nihai onay - - Çıktı: Final Report - -## Nihai Rapor Formatı - -``` -ORCHESTRATION REPORT -==================== -Workflow: feature -Task: Add user authentication -Agents: planner -> tdd-guide -> code-reviewer -> security-reviewer - -SUMMARY -------- -[Bir paragraf özet] - -AGENT OUTPUTS -------------- -Planner: [özet] -TDD Guide: [özet] -Code Reviewer: [özet] -Security Reviewer: [özet] - -FILES CHANGED -------------- -[Değiştirilen tüm dosyaların listesi] - -TEST RESULTS ------------- -[Test geçti/başarısız özeti] - -SECURITY STATUS ---------------- -[Güvenlik bulguları] - -RECOMMENDATION --------------- -[SHIP / NEEDS WORK / BLOCKED] -``` - -## Parallel Execution - -Bağımsız kontroller için, agent'ları parallel çalıştır: - -```markdown -### Parallel Phase -Eş zamanlı çalıştır: -- code-reviewer (kalite) -- security-reviewer (güvenlik) -- architect (tasarım) - -### Merge Results -Çıktıları tek rapora birleştir -``` - -Ayrı git worktree'leri olan harici tmux-pane worker'ları için, `node scripts/orchestrate-worktrees.js plan.json --execute` kullan. Built-in orkestrasyon pattern'i in-process kalır; helper uzun süren veya cross-harness session'lar için. - -Worker'ların ana checkout'tan kirli veya izlenmeyen yerel dosyaları görmesi gerektiğinde, plan dosyasına `seedPaths` ekle. ECC sadece seçilen bu yolları `git worktree add`'den sonra her worker worktree'sine overlay eder; bu branch'ı izole tutarken devam eden yerel script'leri, planları veya dokümanları gösterir. - -```json -{ - "sessionName": "workflow-e2e", - "seedPaths": [ - "scripts/orchestrate-worktrees.js", - "scripts/lib/tmux-worktree-orchestrator.js", - ".claude/plan/workflow-e2e-test.json" - ], - "workers": [ - { "name": "docs", "task": "Orkestrasyon dokümanlarını güncelle." } - ] -} -``` - -Canlı bir tmux/worktree session için kontrol düzlemi snapshot'ı dışa aktarmak için şunu çalıştır: - -```bash -node scripts/orchestration-status.js .claude/plan/workflow-visual-proof.json -``` - -Snapshot session aktivitesi, tmux pane metadata'sı, worker state'leri, hedefleri, seed overlay'leri ve son handoff özetlerini JSON formatında içerir. - -## Operatör Command-Center Handoff - -İş akışı birden fazla session, worktree veya tmux pane'e yayıldığında, nihai handoff'a bir kontrol düzlemi bloğu ekle: - -```markdown -CONTROL PLANE -------------- -Sessions: -- aktif session ID veya alias -- her aktif worker için branch + worktree yolu -- uygulanabilir durumlarda tmux pane veya detached session adı - -Diffs: -- git status özeti -- dokunulan dosyalar için git diff --stat -- merge/çakışma risk notları - -Approvals: -- bekleyen kullanıcı onayları -- onay bekleyen bloke adımlar - -Telemetry: -- son aktivite timestamp'i veya idle sinyali -- tahmini token veya cost drift -- hook'lar veya reviewer'lar tarafından bildirilen policy olayları -``` - -Bu planner, implementer, reviewer ve loop worker'larını operatör yüzeyinden anlaşılır tutar. - -## Argümanlar - -$ARGUMENTS: -- `feature ` - Tam özellik iş akışı -- `bugfix ` - Bug düzeltme iş akışı -- `refactor ` - Refactoring iş akışı -- `security ` - Güvenlik review iş akışı -- `custom ` - Özel agent dizisi - -## Özel Workflow Örneği - -``` -/orchestrate custom "architect,tdd-guide,code-reviewer" "Caching katmanını yeniden tasarla" -``` - -## İpuçları - -1. **Karmaşık özellikler için planner ile başla** -2. **Merge'den önce her zaman code-reviewer dahil et** -3. **Auth/ödeme/PII için security-reviewer kullan** -4. **Handoff'ları kısa tut** - sonraki agent'ın ihtiyaç duyduğu şeye odaklan -5. **Gerekirse agent'lar arasında doğrulama çalıştır** diff --git a/docs/tr/commands/tdd.md b/docs/tr/commands/tdd.md deleted file mode 100644 index caad51ad83..0000000000 --- a/docs/tr/commands/tdd.md +++ /dev/null @@ -1,328 +0,0 @@ ---- -description: Test odaklı geliştirme (TDD) iş akışını zorlar. Interface'leri tasarla, ÖNCE testleri oluştur, sonra minimal kodu uygula. %80+ kod kapsama oranı sağla. ---- - -# TDD Komutu - -Bu komut, test odaklı geliştirme metodolojisini zorlamak için **tdd-guide** agent'ını çağırır. - -## Bu Komut Ne Yapar - -1. **Interface'leri Tasarla** - Önce tip/interface'leri tanımla -2. **Önce Testleri Oluştur** - Başarısız testler yaz (RED) -3. **Minimal Kod Uygula** - Geçmek için yeterli kodu yaz (GREEN) -4. **Refactor Et** - Testleri yeşil tutarken kodu iyileştir (REFACTOR) -5. **Kapsama Oranını Doğrula** - %80+ test kapsama oranı sağla - -## Ne Zaman Kullanılır - -`/tdd` komutunu şu durumlarda kullanın: -- Yeni özellikler uygularken -- Yeni fonksiyonlar/componentler eklerken -- Hataları düzeltirken (önce hatayı tekrar eden test yaz) -- Mevcut kodu refactor ederken -- Kritik iş mantığı oluştururken - -## Nasıl Çalışır - -tdd-guide agent'ı şunları yapacaktır: - -1. Giriş/çıkışlar için **interface'leri tanımla** -2. **BAŞARISIZ olacak testleri yaz** (çünkü kod henüz yok) -3. **Testleri çalıştır** ve doğru sebepten başarısız olduklarını doğrula -4. Testleri geçirmek için **minimal uygulama yaz** -5. **Testleri çalıştır** ve geçtiklerini doğrula -6. Testleri yeşil tutarken kodu **refactor et** -7. **Kapsama oranını kontrol et** ve %80'in altındaysa daha fazla test ekle - -## TDD Döngüsü - -``` -RED → GREEN → REFACTOR → TEKRARLA - -RED: Başarısız bir test yaz -GREEN: Geçmek için minimal kod yaz -REFACTOR: Kodu iyileştir, testleri geçmeye devam et -TEKRARLA: Bir sonraki özellik/senaryo -``` - -## Örnek Kullanım - -``` -Kullanıcı: /tdd Piyasa likidite skorunu hesaplamak için bir fonksiyona ihtiyacım var - -Agent (tdd-guide): -# TDD Oturumu: Piyasa Likidite Skoru Hesaplayıcı - -## Adım 1: Interface Tanımla (SCAFFOLD) - -```typescript -// lib/liquidity.ts -export interface MarketData { - totalVolume: number - bidAskSpread: number - activeTraders: number - lastTradeTime: Date -} - -export function calculateLiquidityScore(market: MarketData): number { - // TODO: Uygulama - throw new Error('Not implemented') -} -``` - -## Adım 2: Başarısız Test Yaz (RED) - -```typescript -// lib/liquidity.test.ts -import { calculateLiquidityScore } from './liquidity' - -describe('calculateLiquidityScore', () => { - it('likit piyasa için yüksek skor döndürmeli', () => { - const market = { - totalVolume: 100000, - bidAskSpread: 0.01, - activeTraders: 500, - lastTradeTime: new Date() - } - - const score = calculateLiquidityScore(market) - - expect(score).toBeGreaterThan(80) - expect(score).toBeLessThanOrEqual(100) - }) - - it('az likit piyasa için düşük skor döndürmeli', () => { - const market = { - totalVolume: 100, - bidAskSpread: 0.5, - activeTraders: 2, - lastTradeTime: new Date(Date.now() - 86400000) // 1 gün önce - } - - const score = calculateLiquidityScore(market) - - expect(score).toBeLessThan(30) - expect(score).toBeGreaterThanOrEqual(0) - }) - - it('edge case\'i idare etmeli: sıfır hacim', () => { - const market = { - totalVolume: 0, - bidAskSpread: 0, - activeTraders: 0, - lastTradeTime: new Date() - } - - const score = calculateLiquidityScore(market) - - expect(score).toBe(0) - }) -}) -``` - -## Adım 3: Testleri Çalıştır - Başarısızlığı Doğrula - -```bash -npm test lib/liquidity.test.ts - -FAIL lib/liquidity.test.ts - ✕ should return high score for liquid market (2 ms) - Error: Not implemented - -1 test failed, 0 passed -``` - -PASS: Testler beklendiği gibi başarısız. Uygulamaya hazır. - -## Adım 4: Minimal Kod Uygula (GREEN) - -```typescript -// lib/liquidity.ts -export function calculateLiquidityScore(market: MarketData): number { - // Sıfır hacim edge case'ini idare et - if (market.totalVolume === 0) { - return 0 - } - - // Bileşen skorlarını hesapla (0-100 ölçeği) - const volumeScore = Math.min(market.totalVolume / 1000, 100) - const spreadScore = Math.max(100 - (market.bidAskSpread * 1000), 0) - const traderScore = Math.min(market.activeTraders / 10, 100) - - // Son aktivite bonusu - const hoursSinceLastTrade = (Date.now() - market.lastTradeTime.getTime()) / (1000 * 60 * 60) - const recencyScore = Math.max(100 - (hoursSinceLastTrade * 10), 0) - - // Ağırlıklı ortalama - const score = ( - volumeScore * 0.4 + - spreadScore * 0.3 + - traderScore * 0.2 + - recencyScore * 0.1 - ) - - return Math.min(Math.max(score, 0), 100) // 0-100 arası sınırla -} -``` - -## Adım 5: Testleri Çalıştır - Başarıyı Doğrula - -```bash -npm test lib/liquidity.test.ts - -PASS lib/liquidity.test.ts - ✓ should return high score for liquid market (3 ms) - ✓ should return low score for illiquid market (2 ms) - ✓ should handle edge case: zero volume (1 ms) - -3 tests passed -``` - -PASS: Tüm testler geçiyor! - -## Adım 6: Refactor Et (IYILEŞTIR) - -```typescript -// lib/liquidity.ts - Sabitler ve daha iyi okunabilirlik ile refactor edildi -const WEIGHTS = { - VOLUME: 0.4, - SPREAD: 0.3, - TRADERS: 0.2, - RECENCY: 0.1, -} as const - -const SCALE_FACTORS = { - VOLUME: 1000, - SPREAD: 1000, - TRADERS: 10, - RECENCY_PENALTY: 10, -} as const - -function clamp(value: number, min: number, max: number): number { - return Math.min(Math.max(value, min), max) -} - -export function calculateLiquidityScore(market: MarketData): number { - if (market.totalVolume === 0) return 0 - - const volumeScore = Math.min(market.totalVolume / SCALE_FACTORS.VOLUME, 100) - const spreadScore = clamp(100 - (market.bidAskSpread * SCALE_FACTORS.SPREAD), 0, 100) - const traderScore = Math.min(market.activeTraders / SCALE_FACTORS.TRADERS, 100) - - const hoursSinceLastTrade = (Date.now() - market.lastTradeTime.getTime()) / (1000 * 60 * 60) - const recencyScore = clamp(100 - (hoursSinceLastTrade * SCALE_FACTORS.RECENCY_PENALTY), 0, 100) - - const weightedScore = - volumeScore * WEIGHTS.VOLUME + - spreadScore * WEIGHTS.SPREAD + - traderScore * WEIGHTS.TRADERS + - recencyScore * WEIGHTS.RECENCY - - return clamp(weightedScore, 0, 100) -} -``` - -## Adım 7: Testlerin Hala Geçtiğini Doğrula - -```bash -npm test lib/liquidity.test.ts - -PASS lib/liquidity.test.ts - ✓ should return high score for liquid market (3 ms) - ✓ should return low score for illiquid market (2 ms) - ✓ should handle edge case: zero volume (1 ms) - -3 tests passed -``` - -PASS: Refactoring tamamlandı, testler hala geçiyor! - -## Adım 8: Kapsama Oranını Kontrol Et - -```bash -npm test -- --coverage lib/liquidity.test.ts - -File | % Stmts | % Branch | % Funcs | % Lines ----------------|---------|----------|---------|-------- -liquidity.ts | 100 | 100 | 100 | 100 - -Coverage: 100% PASS: (Hedef: 80%) -``` - -PASS: TDD oturumu tamamlandı! -``` - -## TDD En İyi Uygulamaları - -**YAPIN:** -- PASS: Herhangi bir uygulamadan ÖNCE testi yazın -- PASS: Testleri çalıştırın ve uygulamadan önce başarısız olduklarını doğrulayın -- PASS: Testleri geçirmek için minimal kod yazın -- PASS: Testler yeşil olduktan sonra refactor edin -- PASS: Edge case'leri ve hata senaryolarını ekleyin -- PASS: %80+ kapsama hedefleyin (kritik kod için %100) - -**YAPMAYIN:** -- FAIL: Testlerden önce uygulama yazmayın -- FAIL: Her değişiklikten sonra testleri çalıştırmayı atlamayın -- FAIL: Aynı anda çok fazla kod yazmayın -- FAIL: Başarısız testleri görmezden gelmeyin -- FAIL: Uygulama detaylarını test etmeyin (davranışı test edin) -- FAIL: Her şeyi mock'lamayın (integration testleri tercih edin) - -## Dahil Edilecek Test Türleri - -**Unit Tests** (Fonksiyon seviyesi): -- Happy path senaryoları -- Edge case'ler (boş, null, maksimum değerler) -- Hata koşulları -- Sınır değerleri - -**Integration Tests** (Component seviyesi): -- API endpoint'leri -- Database operasyonları -- Dış servis çağrıları -- Hook'lu React componentleri - -**E2E Tests** (`/e2e` komutunu kullanın): -- Kritik kullanıcı akışları -- Çok adımlı süreçler -- Full stack entegrasyon - -## Kapsama Gereksinimleri - -- **Minimum %80** tüm kod için -- **%100 gerekli**: - - Finansal hesaplamalar - - Kimlik doğrulama mantığı - - Güvenlik açısından kritik kod - - Temel iş mantığı - -## Önemli Notlar - -**ZORUNLU**: Testler uygulamadan ÖNCE yazılmalıdır. TDD döngüsü: - -1. **RED** - Başarısız test yaz -2. **GREEN** - Geçmek için uygula -3. **REFACTOR** - Kodu iyileştir - -RED aşamasını asla atlamayın. Testlerden önce asla kod yazmayın. - -## Diğer Komutlarla Entegrasyon - -- Ne inşa edileceğini anlamak için önce `/plan` kullanın -- Testlerle uygulamak için `/tdd` kullanın -- Build hataları oluşursa `/build-fix` kullanın -- Uygulamayı gözden geçirmek için `/code-review` kullanın -- Kapsama oranını doğrulamak için `/test-coverage` kullanın - -## İlgili Agent'lar - -Bu komut, ECC tarafından sağlanan `tdd-guide` agent'ını çağırır. - -İlgili `tdd-workflow` skill'i de ECC ile birlikte gelir. - -Manuel kurulumlar için, kaynak dosyalar şurada bulunur: -- `agents/tdd-guide.md` -- `skills/tdd-workflow/SKILL.md` diff --git a/docs/tr/commands/verify.md b/docs/tr/commands/verify.md deleted file mode 100644 index ccd4514695..0000000000 --- a/docs/tr/commands/verify.md +++ /dev/null @@ -1,59 +0,0 @@ -# Verification Komutu - -Mevcut kod tabanı durumu üzerinde kapsamlı doğrulama çalıştır. - -## Talimatlar - -Doğrulamayı tam olarak bu sırayla yürüt: - -1. **Build Kontrolü** - - Bu proje için build komutunu çalıştır - - Başarısız olursa, hataları raporla ve DUR - -2. **Tip Kontrolü** - - TypeScript/tip denetleyicisini çalıştır - - Tüm hataları dosya:satır ile raporla - -3. **Lint Kontrolü** - - Linter'ı çalıştır - - Uyarıları ve hataları raporla - -4. **Test Paketi** - - Tüm testleri çalıştır - - Geçti/başarısız sayısını raporla - - Kapsama yüzdesini raporla - -5. **Console.log Denetimi** - - Kaynak dosyalarda console.log ara - - Konumları raporla - -6. **Git Durumu** - - Commit edilmemiş değişiklikleri göster - - Son commit'ten beri değiştirilen dosyaları göster - -## Çıktı - -Özet bir doğrulama raporu üret: - -``` -DOĞRULAMA: [GEÇTİ/BAŞARISIZ] - -Build: [TAMAM/BAŞARISIZ] -Tipler: [TAMAM/X hata] -Lint: [TAMAM/X sorun] -Testler: [X/Y geçti, Z% kapsama] -Gizli: [TAMAM/X bulundu] -Loglar: [TAMAM/X console.log] - -PR için Hazır: [EVET/HAYIR] -``` - -Herhangi bir kritik sorun varsa, düzeltme önerileriyle listele. - -## Argümanlar - -$ARGUMENTS şunlar olabilir: -- `quick` - Sadece build + tipler -- `full` - Tüm kontroller (varsayılan) -- `pre-commit` - Commit'ler için ilgili kontroller -- `pre-pr` - Güvenlik taraması artı tam kontroller diff --git a/docs/zh-CN/commands/claw.md b/docs/zh-CN/commands/claw.md deleted file mode 100644 index bf7fcff5bf..0000000000 --- a/docs/zh-CN/commands/claw.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -description: 启动 NanoClaw v2 — ECC 的持久、零依赖 REPL，具备模型路由、技能热加载、分支、压缩、导出和指标功能。 ---- - -# Claw 命令 - -启动一个具有持久化 Markdown 历史记录和操作控制的交互式 AI 代理会话。 - -## 使用方法 - -```bash -node scripts/claw.js -``` - -或通过 npm： - -```bash -npm run claw -``` - -## 环境变量 - -| 变量 | 默认值 | 描述 | -|----------|---------|-------------| -| `CLAW_SESSION` | `default` | 会话名称（字母数字 + 连字符） | -| `CLAW_SKILLS` | *(空)* | 启动时加载的以逗号分隔的技能列表 | -| `CLAW_MODEL` | `sonnet` | 会话的默认模型 | - -## REPL 命令 - -```text -/help 显示帮助信息 -/clear 清除当前会话历史 -/history 打印完整对话历史 -/sessions 列出已保存的会话 -/model [name] 显示/设置模型 -/load 热加载技能到上下文 -/branch 分支当前会话 -/search 跨会话搜索查询 -/compact 压缩旧轮次，保留近期上下文 -/export [path] 导出会话 -/metrics 显示会话指标 -exit 退出 -``` - -## 说明 - -* NanoClaw 保持零依赖。 -* 会话存储在 `~/.claude/claw/.md`。 -* 压缩会保留最近的回合并写入压缩头。 -* 导出支持 Markdown、JSON 回合和纯文本。 diff --git a/docs/zh-CN/commands/context-budget.md b/docs/zh-CN/commands/context-budget.md deleted file mode 100644 index 4c12929928..0000000000 --- a/docs/zh-CN/commands/context-budget.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -description: 分析跨代理、技能、MCP服务器和规则的上下文窗口使用情况，以寻找优化机会。有助于减少令牌开销并避免性能警告。 ---- - -# 上下文预算优化器 - -分析您的 Claude Code 设置中的上下文窗口消耗，并提供可操作的建议以减少令牌开销。 - -## 使用方法 - -``` -/context-budget [--verbose] -``` - -* 默认：提供摘要及主要建议 -* `--verbose`：按组件提供完整细分 - -$ARGUMENTS - -## 操作步骤 - -运行 **context-budget** 技能（`skills/context-budget/SKILL.md`），并输入以下内容： - -1. 如果 `$ARGUMENTS` 中存在 `--verbose` 标志，则传递该标志 -2. 除非用户另行指定，否则假设为 200K 上下文窗口（Claude Sonnet 默认值） -3. 遵循技能的四个阶段：清单 → 分类 → 检测问题 → 报告 -4. 向用户输出格式化的上下文预算报告 - -该技能负责所有扫描逻辑、令牌估算、问题检测和报告格式化。 diff --git a/docs/zh-CN/commands/devfleet.md b/docs/zh-CN/commands/devfleet.md deleted file mode 100644 index cf355d7b0d..0000000000 --- a/docs/zh-CN/commands/devfleet.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -description: 通过Claude DevFleet协调并行Claude Code代理——从自然语言规划项目，在隔离的工作树中调度代理，监控进度，并读取结构化报告。 ---- - -# DevFleet — 多智能体编排 - -通过 Claude DevFleet 编排并行的 Claude Code 智能体。每个智能体在隔离的 git worktree 中运行，并配备完整的工具链。 - -需要 DevFleet MCP 服务器：`claude mcp add devfleet --transport http http://localhost:18801/mcp` - -## 流程 - -``` -用户描述项目 - → plan_project(prompt) → 任务DAG与依赖关系 - → 展示计划，获取批准 - → dispatch_mission(M1) → 代理在工作区中生成 - → M1完成 → 自动合并 → M2自动调度（依赖于M1） - → M2完成 → 自动合并 - → get_report(M2) → 文件变更、完成内容、错误、后续步骤 - → 向用户报告总结 -``` - -## 工作流 - -1. **根据用户描述规划项目**： - -``` -mcp__devfleet__plan_project(prompt="<用户描述>") -``` - -这将返回一个包含链式任务的项目。向用户展示： - -* 项目名称和 ID -* 每个任务：标题、类型、依赖项 -* 依赖关系 DAG（哪些任务阻塞了哪些任务） - -2. **在派发前等待用户批准**。清晰展示计划。 - -3. **派发第一个任务**（`depends_on` 为空的任务）： - -``` -mcp__devfleet__dispatch_mission(mission_id="") -``` - -剩余的任务会在其依赖项完成时自动派发（因为 `plan_project` 创建它们时使用了 `auto_dispatch=true`）。当使用 `create_mission` 手动创建任务时，您必须显式设置 `auto_dispatch=true` 才能启用此行为。 - -4. **监控进度** — 检查正在运行的内容： - -``` -mcp__devfleet__get_dashboard() -``` - -或检查特定任务： - -``` -mcp__devfleet__get_mission_status(mission_id="") -``` - -对于长时间运行的任务，优先使用 `get_mission_status` 轮询，而不是 `wait_for_mission`，以便用户能看到进度更新。 - -5. **读取每个已完成任务的报告**： - -``` -mcp__devfleet__get_report(mission_id="") -``` - -对每个达到终止状态的任务调用此工具。报告包含：files\_changed, what\_done, what\_open, what\_tested, what\_untested, next\_steps, errors\_encountered。 - -## 所有可用工具 - -| 工具 | 用途 | -|------|---------| -| `plan_project(prompt)` | AI 将描述分解为具有 `auto_dispatch=true` 的链式任务 | -| `create_project(name, path?, description?)` | 手动创建项目，返回 `project_id` | -| `create_mission(project_id, title, prompt, depends_on?, auto_dispatch?)` | 添加任务。`depends_on` 是任务 ID 字符串列表。 | -| `dispatch_mission(mission_id, model?, max_turns?)` | 启动一个智能体 | -| `cancel_mission(mission_id)` | 停止一个正在运行的智能体 | -| `wait_for_mission(mission_id, timeout_seconds?)` | 阻塞直到完成（对于长任务，优先使用轮询） | -| `get_mission_status(mission_id)` | 非阻塞地检查进度 | -| `get_report(mission_id)` | 读取结构化报告 | -| `get_dashboard()` | 系统概览 | -| `list_projects()` | 浏览项目 | -| `list_missions(project_id, status?)` | 列出任务 | - -## 指南 - -* 除非用户明确说"开始吧"，否则派发前始终确认计划 -* 报告状态时包含任务标题和 ID -* 如果任务失败，在重试前先读取其报告以了解错误 -* 智能体并发数是可配置的（默认：3）。超额的任务会排队，并在有空闲槽位时自动派发。检查 `get_dashboard()` 以了解槽位可用性。 -* 依赖关系形成一个 DAG — 切勿创建循环依赖 -* 每个智能体在完成时自动合并其 worktree。如果发生合并冲突，更改将保留在 worktree 分支上，以供手动解决。 diff --git a/docs/zh-CN/commands/docs.md b/docs/zh-CN/commands/docs.md deleted file mode 100644 index 566bac4075..0000000000 --- a/docs/zh-CN/commands/docs.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -description: 通过 Context7 查找库或主题的当前文档。 ---- - -# /docs - -## 目的 - -查找库、框架或 API 的最新文档，并返回包含相关代码片段的摘要答案。使用 Context7 MCP（resolve-library-id 和 query-docs），因此答案反映的是当前文档，而非训练数据。 - -## 用法 - -``` -/docs [library name] [question] -``` - -对于多单词参数，使用引号以便它们被解析为单个标记。示例：`/docs "Next.js" "How do I configure middleware?"` - -如果省略了库或问题，则提示用户输入： - -1. 库或产品名称（例如 Next.js、Prisma、Supabase）。 -2. 具体问题或任务（例如“如何设置中间件？”、“认证方法”）。 - -## 工作流程 - -1. **解析库 ID** — 调用 Context7 工具 `resolve-library-id`，传入库名称和用户问题，以获取 Context7 兼容的库 ID（例如 `/vercel/next.js`）。 -2. **查询文档** — 使用该库 ID 和用户问题调用 `query-docs`。 -3. **总结** — 返回简洁的答案，并包含从获取的文档中提取的相关代码示例。提及库（如果相关，包括版本）。 - -## 输出 - -用户收到一个简短、准确的答案，该答案基于当前文档，并附带任何有帮助的代码片段。如果 Context7 不可用，则说明情况，并根据训练数据回答问题，并注明文档可能已过时。 diff --git a/docs/zh-CN/commands/e2e.md b/docs/zh-CN/commands/e2e.md deleted file mode 100644 index e6ce7f8630..0000000000 --- a/docs/zh-CN/commands/e2e.md +++ /dev/null @@ -1,374 +0,0 @@ ---- -description: 使用 Playwright 生成并运行端到端测试。创建测试旅程、运行测试、捕获截图/视频/跟踪，并上传工件。 ---- - -# E2E 命令 - -此命令调用 **e2e-runner** 代理来使用 Playwright 生成、维护和执行端到端测试。 - -## 此命令的作用 - -1. **生成测试旅程** - 为用户流程创建 Playwright 测试 -2. **运行 E2E 测试** - 跨浏览器执行测试 -3. **捕获工件** - 失败时的截图、视频、跟踪 -4. **上传结果** - HTML 报告和 JUnit XML -5. **识别不稳定测试** - 隔离不稳定的测试 - -## 何时使用 - -在以下情况使用 `/e2e`： - -* 测试关键用户旅程（登录、交易、支付） -* 验证多步骤流程端到端工作 -* 测试 UI 交互和导航 -* 验证前端和后端之间的集成 -* 为生产部署做准备 - -## 工作原理 - -e2e-runner 代理将： - -1. **分析用户流程**并识别测试场景 -2. **使用页面对象模型模式生成 Playwright 测试** -3. **跨多个浏览器（Chrome、Firefox、Safari）运行测试** -4. **捕获失败**，包括截图、视频和跟踪 -5. **生成包含结果和工件的报告** -6. **识别不稳定测试**并推荐修复方法 - -## 使用示例 - -```` -用户：/e2e 测试市场搜索和查看流程 - -代理（e2e-runner）： -# E2E 测试生成：市场搜索和查看流程 - -## 已识别测试场景 - -**用户旅程：** 市场搜索 → 查看结果 → 点击市场 → 查看详情 - -**测试覆盖范围：** -1. 导航至市场页面 -2. 执行语义搜索 -3. 验证搜索结果 -4. 点击第一个结果 -5. 验证市场详情页面加载 -6. 验证图表渲染 - -## 生成的测试代码 - -```typescript -// tests/e2e/markets/search-and-view.spec.ts -import { test, expect } from '@playwright/test' -import { MarketsPage } from '../../pages/MarketsPage' -import { MarketDetailsPage } from '../../pages/MarketDetailsPage' - -test.describe('Market Search and View Flow', () => { - test('user can search markets and view details', async ({ page }) => { - // 1. Navigate to markets page - const marketsPage = new MarketsPage(page) - await marketsPage.goto() - - // Verify page loaded - await expect(page).toHaveTitle(/Markets/) - await expect(page.locator('h1')).toContainText('Markets') - - // 2. Perform semantic search - await marketsPage.searchMarkets('election') - - // Wait for API response - await page.waitForResponse(resp => - resp.url().includes('/api/markets/search') && resp.status() === 200 - ) - - // 3. Verify search results - const marketCards = marketsPage.marketCards - await expect(marketCards.first()).toBeVisible() - const resultCount = await marketCards.count() - expect(resultCount).toBeGreaterThan(0) - - // Take screenshot of search results - await page.screenshot({ path: 'artifacts/search-results.png' }) - - // 4. Click on first result - const firstMarketTitle = await marketCards.first().textContent() - await marketCards.first().click() - - // 5. Verify market details page loads - await expect(page).toHaveURL(/\/markets\/[a-z0-9-]+/) - - const detailsPage = new MarketDetailsPage(page) - await expect(detailsPage.marketName).toBeVisible() - await expect(detailsPage.marketDescription).toBeVisible() - - // 6. Verify chart renders - await expect(detailsPage.priceChart).toBeVisible() - - // Verify market name matches - const detailsTitle = await detailsPage.marketName.textContent() - expect(detailsTitle?.toLowerCase()).toContain( - firstMarketTitle?.toLowerCase().substring(0, 20) || '' - ) - - // Take screenshot of market details - await page.screenshot({ path: 'artifacts/market-details.png' }) - }) - - test('search with no results shows empty state', async ({ page }) => { - const marketsPage = new MarketsPage(page) - await marketsPage.goto() - - // Search for non-existent market - 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) - }) -}) - -```` - -## 运行测试 - -```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 -``` - -## 测试报告 - -``` -╔══════════════════════════════════════════════════════════════╗ -║ E2E 测试结果 ║ -╠══════════════════════════════════════════════════════════════╣ -║ 状态： PASS: 所有测试通过 ║ -║ 总计： 3 项测试 ║ -║ 通过： 3 (100%) ║ -║ 失败： 0 ║ -║ 不稳定： 0 ║ -║ 耗时： 9.1s ║ -╚══════════════════════════════════════════════════════════════╝ - -产物： - 截图： 2 个文件 - 视频： 0 个文件（仅在失败时生成） - 追踪文件： 0 个文件（仅在失败时生成） - HTML 报告： playwright-report/index.html - -查看报告： npx playwright show-report -``` - -PASS: E2E 测试套件已准备好进行 CI/CD 集成！ - -```` -## 测试产物 - -当测试运行时，会捕获以下产物： - -**所有测试：** -- 包含时间线和结果的 HTML 报告 -- 用于 CI 集成的 JUnit XML 文件 - -**仅在失败时：** -- 失败状态的截图 -- 测试的视频录制 -- 用于调试的追踪文件（逐步重放） -- 网络日志 -- 控制台日志 - -## 查看产物 - -```bash -# 在浏览器中查看 HTML 报告 -npx playwright show-report - -# 查看特定的追踪文件 -npx playwright show-trace artifacts/trace-abc123.zip - -# 截图保存在 artifacts/ 目录中 -open artifacts/search-results.png - -```` - -## 不稳定测试检测 - -如果测试间歇性失败： - -``` -WARNING: FLAKY TEST DETECTED: tests/e2e/markets/trade.spec.ts - -测试通过了 7/10 次运行 (70% 通过率) - -常见失败原因: -"等待元素 '[data-testid="confirm-btn"]' 超时" - -推荐修复方法: -1. 添加显式等待: await page.waitForSelector('[data-testid="confirm-btn"]') -2. 增加超时时间: { timeout: 10000 } -3. 检查组件中的竞争条件 -4. 确认元素未被动画遮挡 - -隔离建议: 在修复前标记为 test.fixme() -``` - -## 浏览器配置 - -默认情况下，测试在多个浏览器上运行： - -* PASS: Chromium（桌面版 Chrome） -* PASS: Firefox（桌面版） -* PASS: WebKit（桌面版 Safari） -* PASS: 移动版 Chrome（可选） - -在 `playwright.config.ts` 中配置以调整浏览器。 - -## CI/CD 集成 - -添加到您的 CI 流水线： - -```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 特定的关键流程 - -对于 PMX，请优先考虑以下 E2E 测试： - -**关键（必须始终通过）：** - -1. 用户可以连接钱包 -2. 用户可以浏览市场 -3. 用户可以搜索市场（语义搜索） -4. 用户可以查看市场详情 -5. 用户可以下交易单（使用测试资金） -6. 市场正确结算 -7. 用户可以提取资金 - -**重要：** - -1. 市场创建流程 -2. 用户资料更新 -3. 实时价格更新 -4. 图表渲染 -5. 过滤和排序市场 -6. 移动端响应式布局 - -## 最佳实践 - -**应该：** - -* PASS: 使用页面对象模型以提高可维护性 -* PASS: 使用 data-testid 属性作为选择器 -* PASS: 等待 API 响应，而不是使用任意超时 -* PASS: 测试关键用户旅程的端到端 -* PASS: 在合并到主分支前运行测试 -* PASS: 在测试失败时审查工件 - -**不应该：** - -* FAIL: 使用不稳定的选择器（CSS 类可能会改变） -* FAIL: 测试实现细节 -* FAIL: 针对生产环境运行测试 -* FAIL: 忽略不稳定测试 -* FAIL: 在失败时跳过工件审查 -* FAIL: 使用 E2E 测试每个边缘情况（使用单元测试） - -## 重要注意事项 - -**对 PMX 至关重要：** - -* 涉及真实资金的 E2E 测试**必须**仅在测试网/暂存环境中运行 -* 切勿针对生产环境运行交易测试 -* 为金融测试设置 `test.skip(process.env.NODE_ENV === 'production')` -* 仅使用带有少量测试资金的测试钱包 - -## 与其他命令的集成 - -* 使用 `/plan` 来识别要测试的关键旅程 -* 使用 `/tdd` 进行单元测试（更快、更细粒度） -* 使用 `/e2e` 进行集成和用户旅程测试 -* 使用 `/code-review` 来验证测试质量 - -## 相关代理 - -此命令调用由 ECC 提供的 `e2e-runner` 代理。 - -对于手动安装，源文件位于： -`agents/e2e-runner.md` - -## 快速命令 - -```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 -``` diff --git a/docs/zh-CN/commands/eval.md b/docs/zh-CN/commands/eval.md deleted file mode 100644 index 9c1ec0d472..0000000000 --- a/docs/zh-CN/commands/eval.md +++ /dev/null @@ -1,122 +0,0 @@ -# Eval 命令 - -管理基于评估的开发工作流。 - -## 用法 - -`/eval [define|check|report|list] [feature-name]` - -## 定义评估 - -`/eval define feature-name` - -创建新的评估定义： - -1. 使用模板创建 `.claude/evals/feature-name.md`： - -```markdown -## EVAL: 功能名称 -创建于: $(date) - -### 能力评估 -- [ ] [能力 1 的描述] -- [ ] [能力 2 的描述] - -### 回归评估 -- [ ] [现有行为 1 仍然有效] -- [ ] [现有行为 2 仍然有效] - -### 成功标准 -- 能力评估的 pass@3 > 90% -- 回归评估的 pass^3 = 100% - -``` - -2. 提示用户填写具体标准 - -## 检查评估 - -`/eval check feature-name` - -为功能运行评估： - -1. 从 `.claude/evals/feature-name.md` 读取评估定义 -2. 对于每个能力评估： - * 尝试验证标准 - * 记录 通过/失败 - * 在 `.claude/evals/feature-name.log` 中记录尝试 -3. 对于每个回归评估： - * 运行相关测试 - * 与基线比较 - * 记录 通过/失败 -4. 报告当前状态： - -``` -EVAL CHECK: feature-name -======================== -功能：X/Y 通过 -回归测试：X/Y 通过 -状态：进行中 / 就绪 -``` - -## 报告评估 - -`/eval report feature-name` - -生成全面的评估报告： - -``` -EVAL REPORT: feature-name -========================= -生成时间: $(date) - -能力评估 ----------------- -[eval-1]: 通过 (pass@1) -[eval-2]: 通过 (pass@2) - 需要重试 -[eval-3]: 失败 - 参见备注 - -回归测试 ----------------- -[test-1]: 通过 -[test-2]: 通过 -[test-3]: 通过 - -指标 -------- -能力 pass@1: 67% -能力 pass@3: 100% -回归 pass^3: 100% - -备注 ------ -[任何问题、边界情况或观察结果] - -建议 --------------- -[SHIP / NEEDS WORK / BLOCKED] -``` - -## 列出评估 - -`/eval list` - -显示所有评估定义： - -``` -功能模块定义 -================ -feature-auth [3/5 通过] 进行中 -feature-search [5/5 通过] 就绪 -feature-export [0/4 通过] 未开始 -``` - -## 参数 - -$ARGUMENTS: - -* `define ` - 创建新的评估定义 -* `check ` - 运行并检查评估 -* `report ` - 生成完整报告 -* `list` - 显示所有评估 -* `clean` - 删除旧的评估日志（保留最近 10 次运行） diff --git a/docs/zh-CN/commands/orchestrate.md b/docs/zh-CN/commands/orchestrate.md deleted file mode 100644 index e13d033161..0000000000 --- a/docs/zh-CN/commands/orchestrate.md +++ /dev/null @@ -1,242 +0,0 @@ ---- -description: 针对多智能体工作流程的顺序和tmux/worktree编排指南。 ---- - -# 编排命令 - -用于复杂任务的顺序代理工作流。 - -## 使用 - -`/orchestrate [workflow-type] [task-description]` - -## 工作流类型 - -### feature - -完整功能实现工作流： - -``` -规划者 -> 测试驱动开发指南 -> 代码审查员 -> 安全审查员 -``` - -### bugfix - -错误调查与修复工作流： - -``` -planner -> tdd-guide -> code-reviewer -``` - -### refactor - -安全重构工作流： - -``` -架构师 -> 代码审查员 -> 测试驱动开发指南 -``` - -### security - -安全审查工作流： - -``` -security-reviewer -> code-reviewer -> architect -``` - -## 执行模式 - -针对工作流中的每个代理： - -1. 使用来自上一个代理的上下文**调用代理** -2. 将输出收集为结构化的交接文档 -3. 将文档**传递给链中的下一个代理** -4. 将结果**汇总**到最终报告中 - -## 交接文档格式 - -在代理之间，创建交接文档： - -```markdown -## 交接：[前一位代理人] -> [下一位代理人] - -### 背景 -[已完成工作的总结] - -### 发现 -[关键发现或决定] - -### 已修改的文件 -[已触及的文件列表] - -### 待解决的问题 -[留给下一位代理人的未决事项] - -### 建议 -[建议的后续步骤] - -``` - -## 示例：功能工作流 - -``` -/orchestrate feature "Add user authentication" -``` - -执行： - -1. **规划代理** - * 分析需求 - * 创建实施计划 - * 识别依赖项 - * 输出：`HANDOFF: planner -> tdd-guide` - -2. **TDD 指导代理** - * 读取规划交接文档 - * 先编写测试 - * 实施代码以通过测试 - * 输出：`HANDOFF: tdd-guide -> code-reviewer` - -3. **代码审查代理** - * 审查实现 - * 检查问题 - * 提出改进建议 - * 输出：`HANDOFF: code-reviewer -> security-reviewer` - -4. **安全审查代理** - * 安全审计 - * 漏洞检查 - * 最终批准 - * 输出：最终报告 - -## 最终报告格式 - -``` -编排报告 -==================== -工作流：功能 -任务：添加用户认证 -智能体：规划者 -> TDD指南 -> 代码审查员 -> 安全审查员 - -概要 -------- -[一段总结] - -智能体输出 -------------- -规划者：[总结] -TDD指南：[总结] -代码审查员：[总结] -安全审查员：[总结] - -已更改文件 -------------- -[列出所有修改的文件] - -测试结果 ------------- -[测试通过/失败总结] - -安全状态 ---------------- -[安全发现] - -建议 --------------- -[可发布 / 需要改进 / 已阻止] -``` - -## 并行执行 - -对于独立的检查，并行运行代理： - -```markdown -### 并行阶段 -同时运行： -- code-reviewer（质量） -- security-reviewer（安全） -- architect（设计） - -### 合并结果 -将输出合并为单一报告 - -``` - -对于使用独立 git worktree 的外部 tmux-pane 工作器，请使用 `node scripts/orchestrate-worktrees.js plan.json --execute`。内置的编排模式保持进程内运行；此辅助工具适用于长时间运行或跨测试框架的会话。 - -当工作器需要查看主检出目录中的脏文件或未跟踪的本地文件时，请在计划文件中添加 `seedPaths`。ECC 仅在 `git worktree add` 之后，将那些选定的路径覆盖到每个工作器的工作树中，这既能保持分支隔离，又能暴露正在处理的本地脚本、计划或文档。 - -```json -{ - "sessionName": "workflow-e2e", - "seedPaths": [ - "scripts/orchestrate-worktrees.js", - "scripts/lib/tmux-worktree-orchestrator.js", - ".claude/plan/workflow-e2e-test.json" - ], - "workers": [ - { "name": "docs", "task": "Update orchestration docs." } - ] -} -``` - -要导出实时 tmux/worktree 会话的控制平面快照，请运行： - -```bash -node scripts/orchestration-status.js .claude/plan/workflow-visual-proof.json -``` - -快照包含会话活动、tmux 窗格元数据、工作器状态、目标、已播种的覆盖层以及最近的交接摘要，均以 JSON 格式保存。 - -## 操作员指挥中心交接 - -当工作流跨越多个会话、工作树或 tmux 窗格时，请在最终交接内容中附加一个控制平面块： - -```markdown -控制平面 -------------- -会话： -- 活动会话 ID 或别名 -- 每个活动工作线程的分支 + 工作树路径 -- 适用时的 tmux 窗格或分离会话名称 - -差异： -- git 状态摘要 -- 已修改文件的 git diff --stat -- 合并/冲突风险说明 - -审批： -- 待处理的用户审批 -- 等待确认的受阻步骤 - -遥测： -- 最后活动时间戳或空闲信号 -- 预估的令牌或成本漂移 -- 由钩子或审查器引发的策略事件 -``` - -这使得规划者、实施者、审查者和循环工作器在操作员界面上保持清晰可辨。 - -## 参数 - -$ARGUMENTS: - -* `feature ` - 完整功能工作流 -* `bugfix ` - 错误修复工作流 -* `refactor ` - 重构工作流 -* `security ` - 安全审查工作流 -* `custom ` - 自定义代理序列 - -## 自定义工作流示例 - -``` -/orchestrate 自定义 "architect,tdd-guide,code-reviewer" "重新设计缓存层" -``` - -## 提示 - -1. **从规划代理开始**处理复杂功能 -2. **始终在合并前包含代码审查代理** -3. 处理认证/支付/个人身份信息时**使用安全审查代理** -4. **保持交接文档简洁** - 关注下一个代理需要什么 -5. 如有需要，**在代理之间运行验证** diff --git a/docs/zh-CN/commands/prompt-optimize.md b/docs/zh-CN/commands/prompt-optimize.md deleted file mode 100644 index a6809aea33..0000000000 --- a/docs/zh-CN/commands/prompt-optimize.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -description: 分析一个草稿提示，输出一个经过优化、富含ECC的版本，准备粘贴并运行。不执行任务——仅输出咨询分析。 ---- - -# /prompt-optimize - -分析并优化以下提示语，以实现最大化的ECC杠杆效应。 - -## 你的任务 - -对下方用户的输入应用 **prompt-optimizer** 技能。遵循6阶段分析流程： - -0. **项目检测** — 读取 CLAUDE.md，从项目文件（package.json, go.mod, pyproject.toml 等）检测技术栈 -1. **意图检测** — 对任务类型进行分类（新功能、错误修复、重构、研究、测试、评审、文档、基础设施、设计） -2. **范围评估** — 评估复杂度（简单 / 低 / 中 / 高 / 史诗级），如果检测到代码库，则使用其大小作为信号 -3. **ECC组件匹配** — 映射到特定的技能、命令、代理和模型层级 -4. **缺失上下文检测** — 识别信息缺口。如果缺少3个以上关键项，请在生成前请用户澄清 -5. **工作流与模型** — 确定生命周期阶段，推荐模型层级，如果复杂度为高/史诗级，则将其拆分为多个提示语 - -## 输出要求 - -* 呈现诊断结果、推荐的ECC组件以及使用 prompt-optimizer 技能中输出格式的优化后提示语 -* 提供 **完整版本**（详细）和 **快速版本**（紧凑，根据意图类型变化） -* 使用与用户输入相同的语言进行回复 -* 优化后的提示语必须完整且可复制粘贴到新会话中直接使用 -* 以提供调整选项或明确下一步操作（用于启动单独的执行请求）的页脚结束 - -## 关键 - -请勿执行用户的任务。仅输出分析结果和优化后的提示语。 -如果用户要求直接执行，请说明 `/prompt-optimize` 仅产生咨询性输出，并告诉他们应启动一个常规的任务请求。 - -注意：`blueprint` 是一个**技能**，而非斜杠命令。请写作“使用蓝图技能”，而不是将其呈现为 `/...` 命令。 - -## 用户输入 - -$ARGUMENTS diff --git a/docs/zh-CN/commands/rules-distill.md b/docs/zh-CN/commands/rules-distill.md deleted file mode 100644 index 22ce171be9..0000000000 --- a/docs/zh-CN/commands/rules-distill.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: "扫描技能以提取跨领域原则并将其提炼为规则" ---- - -# /rules-distill — 从技能中提炼原则为规则 - -扫描已安装的技能，提取跨领域原则，并将其提炼为规则。 - -## 流程 - -遵循 `rules-distill` 技能中定义的完整工作流程。 diff --git a/docs/zh-CN/commands/tdd.md b/docs/zh-CN/commands/tdd.md deleted file mode 100644 index fb86731bb2..0000000000 --- a/docs/zh-CN/commands/tdd.md +++ /dev/null @@ -1,330 +0,0 @@ ---- -description: 强制执行测试驱动开发工作流。首先搭建接口，生成测试，然后实现最小化代码以通过测试。确保 80%+ 覆盖率。 ---- - -# TDD 命令 - -此命令调用 **tdd-guide** 代理来强制执行测试驱动开发方法。 - -## 此命令的作用 - -1. **搭建接口** - 首先定义类型/接口 -2. **首先生成测试** - 编写失败的测试（红） -3. **实现最小化代码** - 编写刚好足够的代码以通过测试（绿） -4. **重构** - 改进代码，同时保持测试通过（重构） -5. **验证覆盖率** - 确保 80%+ 的测试覆盖率 - -## 何时使用 - -在以下情况下使用 `/tdd`： - -* 实现新功能时 -* 添加新函数/组件时 -* 修复错误时（首先编写重现错误的测试） -* 重构现有代码时 -* 构建关键业务逻辑时 - -## 工作原理 - -tdd-guide 代理将： - -1. 为输入/输出**定义接口** -2. **编写将会失败的测试**（因为代码尚不存在） -3. **运行测试**并验证它们因正确的原因而失败 -4. **编写最小化实现**以使测试通过 -5. **运行测试**并验证它们通过 -6. **重构**代码，同时保持测试通过 -7. **检查覆盖率**，如果低于 80% 则添加更多测试 - -## TDD 循环 - -``` -RED → GREEN → REFACTOR → REPEAT - -RED: 编写一个失败测试 -GREEN: 编写通过测试的最简代码 -REFACTOR: 改进代码，保持测试通过 -REPEAT: 开始下一个功能/场景 -``` - -## 使用示例 - -```` -User: /tdd I need a function to calculate market liquidity score - -Agent (tdd-guide): -# TDD Session: Market Liquidity Score Calculator - -## Step 1: Define Interface (SCAFFOLD) - -```typescript -// lib/liquidity.ts -export interface MarketData { - totalVolume: number - bidAskSpread: number - activeTraders: number - lastTradeTime: Date -} - -export function calculateLiquidityScore(market: MarketData): number { - // TODO: Implementation - throw new Error('Not implemented') -} -```` - -## 步骤 2：编写失败的测试（红） - -```typescript -// lib/liquidity.test.ts -import { calculateLiquidityScore } from './liquidity' - -describe('calculateLiquidityScore', () => { - it('should return high score for liquid market', () => { - const market = { - totalVolume: 100000, - bidAskSpread: 0.01, - activeTraders: 500, - lastTradeTime: new Date() - } - - const score = calculateLiquidityScore(market) - - expect(score).toBeGreaterThan(80) - expect(score).toBeLessThanOrEqual(100) - }) - - it('should return low score for illiquid market', () => { - const market = { - totalVolume: 100, - bidAskSpread: 0.5, - activeTraders: 2, - lastTradeTime: new Date(Date.now() - 86400000) // 1 day ago - } - - const score = calculateLiquidityScore(market) - - expect(score).toBeLessThan(30) - expect(score).toBeGreaterThanOrEqual(0) - }) - - it('should handle edge case: zero volume', () => { - const market = { - totalVolume: 0, - bidAskSpread: 0, - activeTraders: 0, - lastTradeTime: new Date() - } - - const score = calculateLiquidityScore(market) - - expect(score).toBe(0) - }) -}) -``` - -## 步骤 3：运行测试 - 验证失败 - -```bash -npm test lib/liquidity.test.ts - -FAIL lib/liquidity.test.ts - ✕ should return high score for liquid market (2 ms) - Error: Not implemented - -1 test failed, 0 passed -``` - -PASS: 测试按预期失败。准备实施。 - -## 步骤 4：实现最小化代码（绿） - -```typescript -// lib/liquidity.ts -export function calculateLiquidityScore(market: MarketData): number { - // Handle zero volume edge case - if (market.totalVolume === 0) { - return 0 - } - - // Calculate component scores (0-100 scale) - const volumeScore = Math.min(market.totalVolume / 1000, 100) - const spreadScore = Math.max(100 - (market.bidAskSpread * 1000), 0) - const traderScore = Math.min(market.activeTraders / 10, 100) - - // Recent activity bonus - const hoursSinceLastTrade = (Date.now() - market.lastTradeTime.getTime()) / (1000 * 60 * 60) - const recencyScore = Math.max(100 - (hoursSinceLastTrade * 10), 0) - - // Weighted average - const score = ( - volumeScore * 0.4 + - spreadScore * 0.3 + - traderScore * 0.2 + - recencyScore * 0.1 - ) - - return Math.min(Math.max(score, 0), 100) // Clamp to 0-100 -} -``` - -## 步骤 5：运行测试 - 验证通过 - -```bash -npm test lib/liquidity.test.ts - -PASS lib/liquidity.test.ts - ✓ should return high score for liquid market (3 ms) - ✓ should return low score for illiquid market (2 ms) - ✓ should handle edge case: zero volume (1 ms) - -3 tests passed -``` - -PASS: 所有测试通过！ - -## 步骤 6：重构（改进） - -```typescript -// lib/liquidity.ts - Refactored with constants and better readability -const WEIGHTS = { - VOLUME: 0.4, - SPREAD: 0.3, - TRADERS: 0.2, - RECENCY: 0.1, -} as const - -const SCALE_FACTORS = { - VOLUME: 1000, - SPREAD: 1000, - TRADERS: 10, - RECENCY_PENALTY: 10, -} as const - -function clamp(value: number, min: number, max: number): number { - return Math.min(Math.max(value, min), max) -} - -export function calculateLiquidityScore(market: MarketData): number { - if (market.totalVolume === 0) return 0 - - const volumeScore = Math.min(market.totalVolume / SCALE_FACTORS.VOLUME, 100) - const spreadScore = clamp(100 - (market.bidAskSpread * SCALE_FACTORS.SPREAD), 0, 100) - const traderScore = Math.min(market.activeTraders / SCALE_FACTORS.TRADERS, 100) - - const hoursSinceLastTrade = (Date.now() - market.lastTradeTime.getTime()) / (1000 * 60 * 60) - const recencyScore = clamp(100 - (hoursSinceLastTrade * SCALE_FACTORS.RECENCY_PENALTY), 0, 100) - - const weightedScore = - volumeScore * WEIGHTS.VOLUME + - spreadScore * WEIGHTS.SPREAD + - traderScore * WEIGHTS.TRADERS + - recencyScore * WEIGHTS.RECENCY - - return clamp(weightedScore, 0, 100) -} -``` - -## 步骤 7：验证测试仍然通过 - -```bash -npm test lib/liquidity.test.ts - -PASS lib/liquidity.test.ts - ✓ should return high score for liquid market (3 ms) - ✓ should return low score for illiquid market (2 ms) - ✓ should handle edge case: zero volume (1 ms) - -3 tests passed -``` - -PASS: 重构完成，测试仍然通过！ - -## 步骤 8：检查覆盖率 - -```bash -npm test -- --coverage lib/liquidity.test.ts - -File | % Stmts | % Branch | % Funcs | % Lines ----------------|---------|----------|---------|-------- -liquidity.ts | 100 | 100 | 100 | 100 - -Coverage: 100% PASS: (Target: 80%) -``` - -PASS: TDD 会话完成！ - -``` -## TDD 最佳实践 - -**应做：** -- PASS: 先写测试，再写实现 -- PASS: 运行测试并确认失败，再实现功能 -- PASS: 编写最少代码使测试通过 -- PASS: 仅在测试通过后进行重构 -- PASS: 添加边界情况和错误场景 -- PASS: 目标覆盖率 80% 以上（关键代码 100%） - -**不应做：** -- FAIL: 先写实现再写测试 -- FAIL: 每次更改后跳过运行测试 -- FAIL: 一次性编写过多代码 -- FAIL: 忽略失败的测试 -- FAIL: 测试实现细节（应测试行为） -- FAIL: 过度模拟（优先使用集成测试） - -## 应包含的测试类型 - -**单元测试**（函数级别）： -- 正常路径场景 -- 边界情况（空值、null、最大值） -- 错误条件 -- 边界值 - -**集成测试**（组件级别）： -- API 端点 -- 数据库操作 -- 外部服务调用 -- 包含钩子的 React 组件 - -**端到端测试**（使用 `/e2e` 命令）： -- 关键用户流程 -- 多步骤流程 -- 全栈集成 - -## 覆盖率要求 - -- 所有代码**最低 80%** -- **必须达到 100%** 的代码： - - 财务计算 - - 认证逻辑 - - 安全关键代码 - - 核心业务逻辑 - -## 重要说明 - -**强制要求**：测试必须在实现之前编写。TDD 循环是： - -1. **红** - 编写失败的测试 -2. **绿** - 实现功能使测试通过 -3. **重构** - 改进代码 - -切勿跳过红阶段。切勿在测试之前编写代码。 - -## 与其他命令的集成 - -- 首先使用 `/plan` 来了解要构建什么 -- 使用 `/tdd` 进行带测试的实现 -- 如果出现构建错误，请使用 `/build-fix` -- 使用 `/code-review` 审查实现 -- 使用 `/test-coverage` 验证覆盖率 - -## 相关代理 - -此命令调用由 ECC 提供的 `tdd-guide` 代理。 - -相关的 `tdd-workflow` 技能也随 ECC 捆绑提供。 - -对于手动安装，源文件位于： -- `agents/tdd-guide.md` -- `skills/tdd-workflow/SKILL.md` -``` diff --git a/docs/zh-CN/commands/verify.md b/docs/zh-CN/commands/verify.md deleted file mode 100644 index 89e8c25432..0000000000 --- a/docs/zh-CN/commands/verify.md +++ /dev/null @@ -1,60 +0,0 @@ -# 验证命令 - -对当前代码库状态执行全面验证。 - -## 说明 - -请严格按照以下顺序执行验证： - -1. **构建检查** - * 运行此项目的构建命令 - * 如果失败，报告错误并**停止** - -2. **类型检查** - * 运行 TypeScript/类型检查器 - * 报告所有错误，包含文件:行号 - -3. **代码检查** - * 运行代码检查器 - * 报告警告和错误 - -4. **测试套件** - * 运行所有测试 - * 报告通过/失败数量 - * 报告覆盖率百分比 - -5. **Console.log 审计** - * 在源文件中搜索 console.log - * 报告位置 - -6. **Git 状态** - * 显示未提交的更改 - * 显示自上次提交以来修改的文件 - -## 输出 - -生成一份简洁的验证报告： - -``` -验证： [通过/失败] - -构建： [成功/失败] -类型： [成功/X 错误] -代码检查： [成功/X 问题] -测试： [X/Y 通过，Z% 覆盖率] -密钥检查： [成功/X 发现] -日志： [成功/X console.logs] - -准备提交 PR： [是/否] -``` - -如果存在任何关键问题，列出它们并提供修复建议。 - -## 参数 - -$ARGUMENTS 可以是： - -* `quick` - 仅构建 + 类型检查 -* `full` - 所有检查（默认） -* `pre-commit` - 与提交相关的检查 -* `pre-pr` - 完整检查加安全扫描 diff --git a/docs/zh-TW/commands/e2e.md b/docs/zh-TW/commands/e2e.md deleted file mode 100644 index 315e727a16..0000000000 --- a/docs/zh-TW/commands/e2e.md +++ /dev/null @@ -1,115 +0,0 @@ ---- -description: Generate and run end-to-end tests with Playwright. Creates test journeys, runs tests, captures screenshots/videos/traces, and uploads artifacts. ---- - -# E2E 指令 - -此指令呼叫 **e2e-runner** Agent 來產生、維護和執行使用 Playwright 的端對端測試。 - -## 此指令的功能 - -1. **產生測試旅程** - 為使用者流程建立 Playwright 測試 -2. **執行 E2E 測試** - 跨瀏覽器執行測試 -3. **擷取產出物** - 失敗時的截圖、影片、追蹤 -4. **上傳結果** - HTML 報告和 JUnit XML -5. **識別不穩定測試** - 隔離不穩定的測試 - -## 何時使用 - -在以下情況使用 `/e2e`： -- 測試關鍵使用者旅程（登入、交易、支付） -- 驗證多步驟流程端對端運作 -- 測試 UI 互動和導航 -- 驗證前端和後端的整合 -- 為生產環境部署做準備 - -## 運作方式 - -e2e-runner Agent 會： - -1. **分析使用者流程**並識別測試情境 -2. **產生 Playwright 測試**使用 Page Object Model 模式 -3. **跨多個瀏覽器執行測試**（Chrome、Firefox、Safari） -4. **擷取失敗**的截圖、影片和追蹤 -5. **產生報告**包含結果和產出物 -6. **識別不穩定測試**並建議修復 - -## 測試產出物 - -測試執行時，會擷取以下產出物： - -**所有測試：** -- HTML 報告包含時間線和結果 -- JUnit XML 用於 CI 整合 - -**僅在失敗時：** -- 失敗狀態的截圖 -- 測試的影片錄製 -- 追蹤檔案用於除錯（逐步重播） -- 網路日誌 -- Console 日誌 - -## 檢視產出物 - -```bash -# 在瀏覽器檢視 HTML 報告 -npx playwright show-report - -# 檢視特定追蹤檔案 -npx playwright show-trace artifacts/trace-abc123.zip - -# 截圖儲存在 artifacts/ 目錄 -open artifacts/search-results.png -``` - -## 最佳實務 - -**應該做：** -- PASS: 使用 Page Object Model 以利維護 -- PASS: 使用 data-testid 屬性作為選擇器 -- PASS: 等待 API 回應，不要用任意逾時 -- PASS: 測試關鍵使用者旅程端對端 -- PASS: 合併到主分支前執行測試 -- PASS: 測試失敗時審查產出物 - -**不應該做：** -- FAIL: 使用脆弱的選擇器（CSS class 可能改變） -- FAIL: 測試實作細節 -- FAIL: 對生產環境執行測試 -- FAIL: 忽略不穩定的測試 -- FAIL: 失敗時跳過產出物審查 -- FAIL: 用 E2E 測試每個邊界情況（使用單元測試） - -## 快速指令 - -```bash -# 執行所有 E2E 測試 -npx playwright test - -# 執行特定測試檔案 -npx playwright test tests/e2e/markets/search.spec.ts - -# 以可視模式執行（看到瀏覽器） -npx playwright test --headed - -# 除錯測試 -npx playwright test --debug - -# 產生測試程式碼 -npx playwright codegen http://localhost:3000 - -# 檢視報告 -npx playwright show-report -``` - -## 與其他指令的整合 - -- 使用 `/plan` 識別要測試的關鍵旅程 -- 使用 `/tdd` 進行單元測試（更快、更細粒度） -- 使用 `/e2e` 進行整合和使用者旅程測試 -- 使用 `/code-review` 驗證測試品質 - -## 相關 Agent - -此指令呼叫位於以下位置的 `e2e-runner` Agent： -`~/.claude/agents/e2e-runner.md` diff --git a/docs/zh-TW/commands/eval.md b/docs/zh-TW/commands/eval.md deleted file mode 100644 index 0948d2574a..0000000000 --- a/docs/zh-TW/commands/eval.md +++ /dev/null @@ -1,120 +0,0 @@ -# Eval 指令 - -管理評估驅動開發工作流程。 - -## 使用方式 - -`/eval [define|check|report|list] [feature-name]` - -## 定義 Evals - -`/eval define feature-name` - -建立新的 eval 定義： - -1. 使用範本建立 `.claude/evals/feature-name.md`： - -```markdown -## EVAL: feature-name -建立日期：$(date) - -### 能力 Evals -- [ ] [能力 1 的描述] -- [ ] [能力 2 的描述] - -### 回歸 Evals -- [ ] [現有行為 1 仍然有效] -- [ ] [現有行為 2 仍然有效] - -### 成功標準 -- 能力 evals 的 pass@3 > 90% -- 回歸 evals 的 pass^3 = 100% -``` - -2. 提示使用者填入具體標準 - -## 檢查 Evals - -`/eval check feature-name` - -執行功能的 evals： - -1. 從 `.claude/evals/feature-name.md` 讀取 eval 定義 -2. 對每個能力 eval： - - 嘗試驗證標準 - - 記錄通過/失敗 - - 記錄嘗試到 `.claude/evals/feature-name.log` -3. 對每個回歸 eval： - - 執行相關測試 - - 與基準比較 - - 記錄通過/失敗 -4. 報告目前狀態： - -``` -EVAL 檢查：feature-name -======================== -能力：X/Y 通過 -回歸：X/Y 通過 -狀態：進行中 / 就緒 -``` - -## 報告 Evals - -`/eval report feature-name` - -產生全面的 eval 報告： - -``` -EVAL 報告：feature-name -========================= -產生日期：$(date) - -能力 EVALS ----------------- -[eval-1]：通過（pass@1） -[eval-2]：通過（pass@2）- 需要重試 -[eval-3]：失敗 - 參見備註 - -回歸 EVALS ----------------- -[test-1]：通過 -[test-2]：通過 -[test-3]：通過 - -指標 -------- -能力 pass@1：67% -能力 pass@3：100% -回歸 pass^3：100% - -備註 ------ -[任何問題、邊界情況或觀察] - -建議 --------------- -[發布 / 需要改進 / 阻擋] -``` - -## 列出 Evals - -`/eval list` - -顯示所有 eval 定義： - -``` -EVAL 定義 -================ -feature-auth [3/5 通過] 進行中 -feature-search [5/5 通過] 就緒 -feature-export [0/4 通過] 未開始 -``` - -## 參數 - -$ARGUMENTS: -- `define ` - 建立新的 eval 定義 -- `check ` - 執行並檢查 evals -- `report ` - 產生完整報告 -- `list` - 顯示所有 evals -- `clean` - 移除舊的 eval 日誌（保留最後 10 次執行） diff --git a/docs/zh-TW/commands/orchestrate.md b/docs/zh-TW/commands/orchestrate.md deleted file mode 100644 index f4ddb9fc29..0000000000 --- a/docs/zh-TW/commands/orchestrate.md +++ /dev/null @@ -1,140 +0,0 @@ -# Orchestrate 指令 - -複雜任務的循序 Agent 工作流程。 - -## 使用方式 - -`/orchestrate [workflow-type] [task-description]` - -## 工作流程類型 - -### feature -完整的功能實作工作流程： -``` -planner -> tdd-guide -> code-reviewer -> security-reviewer -``` - -### bugfix -Bug 調查和修復工作流程： -``` -planner -> tdd-guide -> code-reviewer -``` - -### refactor -安全重構工作流程： -``` -architect -> code-reviewer -> tdd-guide -``` - -### security -以安全性為焦點的審查： -``` -security-reviewer -> code-reviewer -> architect -``` - -## 執行模式 - -對工作流程中的每個 Agent： - -1. **呼叫 Agent**，帶入前一個 Agent 的上下文 -2. **收集輸出**作為結構化交接文件 -3. **傳遞給下一個 Agent** -4. **彙整結果**為最終報告 - -## 交接文件格式 - -Agent 之間，建立交接文件： - -```markdown -## 交接：[前一個 Agent] -> [下一個 Agent] - -### 上下文 -[完成事項的摘要] - -### 發現 -[關鍵發現或決策] - -### 修改的檔案 -[觸及的檔案列表] - -### 開放問題 -[下一個 Agent 的未解決項目] - -### 建議 -[建議的後續步驟] -``` - -## 最終報告格式 - -``` -協調報告 -==================== -工作流程：feature -任務：新增使用者驗證 -Agents：planner -> tdd-guide -> code-reviewer -> security-reviewer - -摘要 -------- -[一段摘要] - -AGENT 輸出 -------------- -Planner：[摘要] -TDD Guide：[摘要] -Code Reviewer：[摘要] -Security Reviewer：[摘要] - -變更的檔案 -------------- -[列出所有修改的檔案] - -測試結果 ------------- -[測試通過/失敗摘要] - -安全性狀態 ---------------- -[安全性發現] - -建議 --------------- -[發布 / 需要改進 / 阻擋] -``` - -## 平行執行 - -對於獨立的檢查，平行執行 Agents： - -```markdown -### 平行階段 -同時執行： -- code-reviewer（品質） -- security-reviewer（安全性） -- architect（設計） - -### 合併結果 -將輸出合併為單一報告 -``` - -## 參數 - -$ARGUMENTS: -- `feature ` - 完整功能工作流程 -- `bugfix ` - Bug 修復工作流程 -- `refactor ` - 重構工作流程 -- `security ` - 安全性審查工作流程 -- `custom ` - 自訂 Agent 序列 - -## 自訂工作流程範例 - -``` -/orchestrate custom "architect,tdd-guide,code-reviewer" "重新設計快取層" -``` - -## 提示 - -1. **複雜功能從 planner 開始** -2. **合併前總是包含 code-reviewer** -3. **對驗證/支付/PII 使用 security-reviewer** -4. **保持交接簡潔** - 專注於下一個 Agent 需要的內容 -5. **如有需要，在 Agents 之間執行 verification** diff --git a/docs/zh-TW/commands/tdd.md b/docs/zh-TW/commands/tdd.md deleted file mode 100644 index e10f2e3353..0000000000 --- a/docs/zh-TW/commands/tdd.md +++ /dev/null @@ -1,100 +0,0 @@ ---- -description: Enforce test-driven development workflow. Scaffold interfaces, generate tests FIRST, then implement minimal code to pass. Ensure 80%+ coverage. ---- - -# TDD 指令 - -此指令呼叫 **tdd-guide** Agent 來強制執行測試驅動開發方法論。 - -## 此指令的功能 - -1. **建立介面骨架** - 先定義類型/介面 -2. **先產生測試** - 撰寫失敗的測試（RED） -3. **實作最小程式碼** - 撰寫剛好足以通過的程式碼（GREEN） -4. **重構** - 在測試保持綠色的同時改進程式碼（REFACTOR） -5. **驗證覆蓋率** - 確保 80% 以上測試覆蓋率 - -## 何時使用 - -在以下情況使用 `/tdd`： -- 實作新功能 -- 新增新函式/元件 -- 修復 Bug（先撰寫重現 bug 的測試） -- 重構現有程式碼 -- 建構關鍵商業邏輯 - -## 運作方式 - -tdd-guide Agent 會： - -1. **定義介面**用於輸入/輸出 -2. **撰寫會失敗的測試**（因為程式碼還不存在） -3. **執行測試**並驗證它們因正確的原因失敗 -4. **撰寫最小實作**使測試通過 -5. **執行測試**並驗證它們通過 -6. **重構**程式碼，同時保持測試通過 -7. **檢查覆蓋率**，如果低於 80% 則新增更多測試 - -## TDD 循環 - -``` -RED → GREEN → REFACTOR → REPEAT - -RED: 撰寫失敗的測試 -GREEN: 撰寫最小程式碼使其通過 -REFACTOR: 改進程式碼，保持測試通過 -REPEAT: 下一個功能/情境 -``` - -## TDD 最佳實務 - -**應該做：** -- PASS: 在任何實作前先撰寫測試 -- PASS: 在實作前執行測試並驗證它們失敗 -- PASS: 撰寫最小程式碼使測試通過 -- PASS: 只在測試通過後才重構 -- PASS: 新增邊界情況和錯誤情境 -- PASS: 目標 80% 以上覆蓋率（關鍵程式碼 100%） - -**不應該做：** -- FAIL: 在測試之前撰寫實作 -- FAIL: 跳過每次變更後執行測試 -- FAIL: 一次撰寫太多程式碼 -- FAIL: 忽略失敗的測試 -- FAIL: 測試實作細節（測試行為） -- FAIL: Mock 所有東西（優先使用整合測試） - -## 覆蓋率要求 - -- **所有程式碼至少 80%** -- **以下類型需要 100%：** - - 財務計算 - - 驗證邏輯 - - 安全關鍵程式碼 - - 核心商業邏輯 - -## 重要提醒 - -**強制要求**：測試必須在實作之前撰寫。TDD 循環是： - -1. **RED** - 撰寫失敗的測試 -2. **GREEN** - 實作使其通過 -3. **REFACTOR** - 改進程式碼 - -絕不跳過 RED 階段。絕不在測試之前撰寫程式碼。 - -## 與其他指令的整合 - -- 先使用 `/plan` 理解要建構什麼 -- 使用 `/tdd` 帶著測試實作 -- 如果發生建置錯誤，使用 `/build-fix` -- 使用 `/code-review` 審查實作 -- 使用 `/test-coverage` 驗證覆蓋率 - -## 相關 Agent - -此指令呼叫位於以下位置的 `tdd-guide` Agent： -`~/.claude/agents/tdd-guide.md` - -並可參考位於以下位置的 `tdd-workflow` 技能： -`~/.claude/skills/tdd-workflow/` diff --git a/docs/zh-TW/commands/verify.md b/docs/zh-TW/commands/verify.md deleted file mode 100644 index 4f64662e53..0000000000 --- a/docs/zh-TW/commands/verify.md +++ /dev/null @@ -1,59 +0,0 @@ -# 驗證指令 - -對目前程式碼庫狀態執行全面驗證。 - -## 說明 - -按此確切順序執行驗證： - -1. **建置檢查** - - 執行此專案的建置指令 - - 如果失敗，報告錯誤並停止 - -2. **型別檢查** - - 執行 TypeScript/型別檢查器 - - 報告所有錯誤，包含 檔案:行號 - -3. **Lint 檢查** - - 執行 linter - - 報告警告和錯誤 - -4. **測試套件** - - 執行所有測試 - - 報告通過/失敗數量 - - 報告覆蓋率百分比 - -5. **Console.log 稽核** - - 在原始檔案中搜尋 console.log - - 報告位置 - -6. **Git 狀態** - - 顯示未提交的變更 - - 顯示上次提交後修改的檔案 - -## 輸出 - -產生簡潔的驗證報告： - -``` -驗證：[通過/失敗] - -建置： [OK/失敗] -型別： [OK/X 個錯誤] -Lint： [OK/X 個問題] -測試： [X/Y 通過，Z% 覆蓋率] -密鑰： [OK/找到 X 個] -日誌： [OK/X 個 console.logs] - -準備好建立 PR：[是/否] -``` - -如果有任何關鍵問題，列出它們並提供修復建議。 - -## 參數 - -$ARGUMENTS 可以是： -- `quick` - 只檢查建置 + 型別 -- `full` - 所有檢查（預設） -- `pre-commit` - 與提交相關的檢查 -- `pre-pr` - 完整檢查加上安全性掃描