b089c2ef18
Boilerplate completo para construir soluciones agénticas sobre IBM watsonx Orchestrate (ADK 2.x) con una capa web encima. Destilado de cotemar-poc-n1 y dun-casos-prueba. Incluye: - 11 docs (best practices, architecture patterns, ADK cheatsheet, observability, tool authoring, deployment, RUNBOOK, DEPLOY_TO_NEW_WOX, known-issues con 16 errores reales y fix, eval strategy, INDEX) - 13 templates WxO (orchestrator/specialist/single-meta agents, 3 connections, KB + runbook, observable_tool decorator, coercion helpers, Python tools, OpenAPI spec, backend filter endpoint, webhook validator HMAC, MCP connection) - 6 scripts (deploy idempotente con fallback ADK, undeploy, reset, check-adk-version, new-specialist scaffold, eval-agents runner) - 4 eval pieces (linter de best practices, runner, smoke-test, direct backend probe) + scenario templates - 8 subagentes Claude (.claude/agents/) — wxo-architect, wxo-agent-author, wxo-tool-author, runbook-author, mock-builder, backend-tool-builder, eval-author, web-layer-builder - Skill bundle fit-wxo-bootstrap/ (SKILL.md + 3 templates) listo para copiar a ~/.claude/skills/ - Web layer default FastAPI+HTMX con vista timeline observable + endpoint receptor de trazas - Docker compose Coolify-ready (healthcheck wget -qO-, sin labels Traefik, network split internal:true) - CI Gitea workflow con lint + smoke Best practices enforced por evals/lint_wxo_yaml.py: - A1: máx 10 tools por agente - A3: orchestrator sin tools de remediación - A6: agente sin propósito (react sin tools ni KB) - T1: @observable_tool obligatorio, no @tool directo - T3: _compat shim inline en tools.py - D1: docker-compose sin wget --spider - I-005: OpenAPI con description per-operation - I-009: sin labels Traefik manuales Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
36 lines
1.3 KiB
Plaintext
36 lines
1.3 KiB
Plaintext
# Runbook XX — REPLACE título
|
|
|
|
## Trigger
|
|
- REPLACE cuándo aplica este runbook (input específico, evento específico)
|
|
- REPLACE condición secundaria si aplica
|
|
|
|
## Precondiciones
|
|
- REPLACE qué tiene que ser verdad antes de ejecutar
|
|
- REPLACE permisos / accesos necesarios
|
|
- REPLACE datos que el agente debe haber recolectado
|
|
|
|
## Pasos
|
|
1. REPLACE primer paso, verbo imperativo. "Consultar lookup_user(username)".
|
|
2. REPLACE segundo paso. "Si user.active=false → reportar fallo (ver Fallo §1)".
|
|
3. REPLACE tercer paso. "Ejecutar reset_password(username)".
|
|
4. REPLACE cuarto paso. "Crear ticket(...)".
|
|
|
|
## Éxito
|
|
- REPLACE qué confirma que el procedimiento salió bien
|
|
- REPLACE qué campos del ticket final deben estar presentes
|
|
- REPLACE qué responder al usuario / al orchestrator
|
|
|
|
## Fallo
|
|
- §1 REPLACE caso de fallo 1 → qué hacer (típicamente: reportar al orchestrator con reason="...")
|
|
- §2 REPLACE caso de fallo 2
|
|
- §3 REPLACE timeout / error de sistema externo
|
|
|
|
## Escalamiento
|
|
- REPLACE cuándo escalar (siempre, o solo en ciertos casos)
|
|
- REPLACE a qué grupo / persona
|
|
- REPLACE qué información incluir en el ticket de escalación
|
|
|
|
## Notas
|
|
- REPLACE consideraciones especiales, datos sensibles, restricciones legales/compliance
|
|
- REPLACE cambios recientes / versión del runbook
|