菜单
Evaluador outcome-based del cierre de fase. Reemplaza el checklist binario de flow-guardian por checks deterministas + juicio LLM cualitativo. Bloquea apex_set_phase si los outcomes reales no se cumplen.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | grader |
| description | Evaluador outcome-based del cierre de fase. Reemplaza el checklist binario de flow-guardian por checks deterministas + juicio LLM cualitativo. Bloquea apex_set_phase si los outcomes reales no se cumplen. |
Outcome-based, no checklist. Inspirado en el Self-Healing Agent Harness de CREAO y en /goal de Hermes — adaptado a la realidad operativa de APEX (1 usuario, ~10 sesiones/semana → juez único Sonnet 4.6, no panel).
Se ejecuta automáticamente:
apex_set_phase(N) (vía hook phase-gate.py).apex_grader_evaluate(phase)./apex:goal (Sprint 8.2).gather_evidence(project_root, phase)
│
▼
run_deterministic_checks(evidence)
│
├── git_initialized? (fase ≥ 5)
├── tests_present? (fase ≥ 6)
├── os_detected? (fase ≥ 1)
├── no_emojis_in_frontend? (fase ≥ 2 y hay frontend)
├── schema_contracts? (fase ≥ 7)
└── e2e_for_web_ui? (fase ≥ 8 y component_type incluye "web")
│
▼
¿Algún issue BLOQUEANTE? (no_git_init, mock_data, no_e2e_for_ui, emoji)
│
sí ──┴── no
│ │
▼ ▼
BLOCK Juicio LLM Sonnet 4.6 (si ANTHROPIC_API_KEY disponible)
│
▼
merge_verdicts(determinista, llm)
│
▼
Verdict final → context.db.add_verdict()
no_git_init, mock_data, no_e2e_for_ui, emoji_in_frontend.missing_tests, no_so_detection, no_schema_contract, no_cross_project_search.| Quality | Cuándo |
|---|---|
| 4 excellent | Outcome verificable + tests pasan + cero issues |
| 3 good | Determinista pasa, LLM neutral, sin avisos |
| 2 acceptable | Avisos no-bloqueantes |
| 1 poor | Bloqueo determinista o LLM detecta cáscara/mock |
from grader import gather_evidence, evaluate_deterministic, evaluate_full
# Modo rápido (sin LLM, sin red)
evidence = gather_evidence(".", phase=5,
component_types=["web"],
decisions_metadata={"detected_os": "Linux"})
verdict = evaluate_deterministic(evidence)
print(verdict.should_block, verdict.issues)
# Modo completo (con LLM si hay API key, sino cae a determinista)
verdict = evaluate_full(evidence, use_anthropic=True)
Desde el MCP:
apex_grader_evaluate(phase=8, mode="full")
Si Vicente sabe que el bloqueo es falso positivo:
apex_set_phase(N, force=True)
Esto registra automáticamente un apex_add_error con motivo del override.
El grader aprende de la frecuencia de overrides para ajustar umbrales.
El grader detecta señales objetivas (git, tests, schema, emojis, Playwright). Para el juicio cualitativo del outcome (¿está mock?, ¿falta contexto?, ¿es ambigua la salida?) sigue dependiendo del LLM. Por eso el prompt del juez es self-contained y la salida es JSON estricto.
| Lección | Issue code | Fase mínima |
|---|---|---|
| focusnow#1 (uname -s) | no_so_detection | 1 (aviso) |
| focusnow#2 (no emojis) | emoji_in_frontend | 2 (bloquea) |
| focusnow#3 (mock data) | mock_data (vía LLM) | 6/8 (bloquea) |
| focusnow#4 (git init) | no_git_init | 5 (bloquea) |
| tfg-tutor#5 (datos sin contrato) | no_schema_contract | 7 (aviso) |
_debug_log (Sprint 8.3, ya planificado).apex-doctor (Sprint 13).Prototipa lógica de negocio compleja como máquina de estados ejecutable (TUI Python con Textual). Mejor que prosa para validar transiciones, edge cases y reglas de negocio. Genera un .py corriendo + diagrama Mermaid commiteado a wiki/concepts/. Triggers ES/EN — prototipo, prototype, máquina de estados, state machine, valida transiciones, business logic complejo, "más de 5 reglas".
Bucle persistente con turn-budget. Mantiene un goal activo entre turnos, juez Sonnet 4.6 decide done|continue|degenerate tras cada turno. Adaptación de Hermes /goal con detección de degeneración.
Bucle de diagnóstico disciplinado para bugs difíciles y regresiones de rendimiento. Reproduce → minimiza → hipotetiza → instrumenta → corrige → test de regresión. Usar cuando el usuario dice "diagnose this" / "debug this", reporta un bug, dice que algo está roto/throwing/failing, o describe una regresión de rendimiento. Triggers ES/EN — diagnose, diagnostica, debug, "está roto", regresión, "no funciona".
Sesión de interrogatorio que confronta tu plan contra el modelo de dominio existente, afila la terminología y actualiza la documentación (CONTEXT.md, ADRs / wiki/decisions/) inline conforme las decisiones cristalizan. Usar cuando el usuario quiere estresar un plan contra el lenguaje del proyecto y las decisiones documentadas. Triggers ES/EN — grill, parrilla, interrogar, "afina mi plan", stress-test plan, challenge plan.
Encuentra oportunidades de profundización (deepening) en un codebase, informado por el lenguaje del dominio en CONTEXT.md y las decisiones en wiki/decisions/ o docs/adr/. Usar cuando el usuario quiere mejorar arquitectura, encontrar oportunidades de refactor, consolidar módulos fuertemente acoplados, o hacer un codebase más testeable y AI-navegable. Triggers ES/EN — improve architecture, "mejorar arquitectura", deepening, refactor, "demasiados módulos pequeños", "es difícil de testear".
Desarrollo guiado por tests con bucle red-green-refactor. Usar cuando el usuario quiere construir features o arreglar bugs usando TDD, menciona "red-green-refactor", quiere tests de integración, o pide desarrollo test-first. Triggers ES/EN — tdd, test-driven, "primero test", red-green-refactor, "tests integración".