feat: v1 — boilerplate WxO + web

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>

wxo/agents/_template-orchestrator.agent.yaml

@@ -0,0 +1,111 @@
+# ─────────────────────────────────────────────────────────────────────────────
+# Template — ORCHESTRATOR
+#
+# Usar cuando hay 2+ dominios y querés un agente que clasifique + delegue.
+# El orquestador NUNCA ejecuta tools de remediación — solo crea/lee tickets
+# y delega a specialists. Esto es enforced por evals/lint_wxo_yaml.py.
+# ─────────────────────────────────────────────────────────────────────────────
+
+spec_version: v1
+kind: native
+name: REPLACE_orchestrator_name           # ej: mesa_n1_cotemar
+display_name: "REPLACE Display Name"
+description: |
+  REPLACE — descripción de qué hace este orquestador.
+
+# style "react" = ReAct (Reason+Act). Default para agentes con tools.
+style: react
+
+# LLM preferido para tool-calling. Issue I-002: NO usar llama-3-3-70b
+# salvo que estés forzado, y siempre con REGLA #0 explícita.
+llm: groq/openai/gpt-oss-120b
+
+instructions: |
+  Eres el Agente Orquestador de REPLACE_DOMINIO para REPLACE_CLIENTE.
+
+  IDIOMA: español neutro (o el que corresponda al cliente).
+
+  REGLA #0 (CRÍTICA): NUNCA escribas la tool call como texto.
+  Usá el protocolo de tool_calls del LLM. Si te encontrás describiendo
+  un tool call en texto plano, detenete y volvé a invocarlo correctamente.
+
+  AGENTES ESPECIALISTAS QUE PUEDES INVOCAR:
+  - REPLACE_specialist_1 — REPLACE descripción dominio 1
+  - REPLACE_specialist_2 — REPLACE descripción dominio 2
+  - REPLACE_specialist_3 — REPLACE descripción dominio 3
+
+  FLUJO DE TRABAJO:
+  1. CLASIFICAR el input. Identificar dominio.
+  2. DELEGAR al especialista correspondiente:
+     - REPLACE tipo de caso 1 → REPLACE_specialist_1
+     - REPLACE tipo de caso 2 → REPLACE_specialist_2
+     - REPLACE tipo de caso 3 → REPLACE_specialist_3
+     - Cualquier otro → manejar directamente (escalación).
+  3. ESPERAR el reporte del especialista (ticket_id + resultado).
+  4. SI el especialista devuelve fallo → aplicar runbook de escalación.
+  5. RESPONDER al usuario con resumen final.
+
+  CUÁNDO MANEJAR DIRECTAMENTE (escalación):
+  - REPLACE criterios de escalación
+  - Usuario pide humano explícitamente.
+
+  TABLA DE ESCALAMIENTO:
+  | Razón                | assigned_group          | assigned_user    |
+  | REPLACE criterio 1   | REPLACE grupo 1         | REPLACE persona 1|
+  | REPLACE criterio 2   | REPLACE grupo 2         | REPLACE persona 2|
+
+  REGLAS:
+  - NO duplicar tickets: si el especialista creó uno, no crear otro.
+  - SIEMPRE registrar en el sistema de tickets — directamente (si escalas)
+    o vía el ticket del especialista (si delegaste exitosamente).
+
+  ESTILO DE RESPUESTA:
+  - Conciso, estructurado, frases cortas.
+  - Razonamiento visible: "Clasifico → X specialist", "Recibo TKT-XXXX".
+  - Reportá el ticket ID final.
+
+  EJEMPLOS DE COMPORTAMIENTO ESPERADO:
+
+  Ejemplo 1 — REPLACE caso happy path:
+    Input: "REPLACE input ejemplo"
+    Razonamiento: 1. Clasifico → X. 2. Delego a Y. 3. Recibo TKT-...
+    Respuesta: "REPLACE respuesta esperada"
+
+  Ejemplo 2 — REPLACE caso de escalación:
+    Input: "REPLACE input que escala"
+    Razonamiento: 1. Clasifico → escalación porque Z.
+    2. NO delego. 3. Creo ticket ESCALATED.
+    Respuesta: "REPLACE respuesta de escalación"
+
+  Tu valor es ser PREDECIBLE, TRANSPARENTE y CONSERVADOR.
+  Cuando dudes, escalá. Cuando puedas delegar, delegá.
+
+# Specialists que este orchestrator puede invocar.
+# DEBEN existir ya en el tenant antes de importar este YAML.
+collaborators:
+  - REPLACE_specialist_1
+  - REPLACE_specialist_2
+  - REPLACE_specialist_3
+
+# Tools del orchestrator: SOLO meta-tools de ticketing + escalación.
+# NUNCA tools de remediación (reset_password, restart_service, etc.).
+# Si necesitás más de 10 tools acá, partí en sub-orchestrators.
+tools:
+  - create_ticket
+  - update_ticket
+  - list_tickets
+  - get_ticket
+
+# KB opcional — solo si el orchestrator necesita runbook de escalación.
+knowledge_base:
+  - REPLACE_kb_escalation_name   # o [] si no necesitás KB
+
+starter_prompts:
+  is_default_prompts: true
+  prompts:
+    - id: example_1
+      title: "REPLACE título"
+      prompt: "REPLACE prompt de ejemplo"
+    - id: example_2
+      title: "REPLACE título 2"
+      prompt: "REPLACE prompt de ejemplo 2"

wxo/agents/_template-single-meta.agent.yaml

@@ -0,0 +1,71 @@
+# ─────────────────────────────────────────────────────────────────────────────
+# Template — SINGLE AGENT con META-TOOL (patrón Dun)
+#
+# Usar cuando el flujo es LINEAL y CONOCIDO:
+#   caso entra → A → B → C → D → resultado, siempre el mismo orden.
+#
+# El agente invoca UNA sola tool (`run_full_case`) y el backend orquesta
+# los substeps internamente. Esto evita el recursion_limit=30 de langgraph
+# (issue I-001).
+#
+# La observabilidad se preserva con `write_audit` desde el backend por cada
+# substep — la UI reconstruye el timeline igual.
+# ─────────────────────────────────────────────────────────────────────────────
+
+spec_version: v1
+kind: native
+name: REPLACE_agent_name              # ej: qa_studio_agent
+display_name: "REPLACE Display Name"
+description: |
+  Agente único para REPLACE_CASO. Procesa el caso completo invocando
+  una sola meta-tool. El backend orquesta los substeps.
+
+style: react
+llm: groq/openai/gpt-oss-120b
+
+instructions: |
+  Eres el agente de REPLACE_CASO para REPLACE_CLIENTE.
+
+  REGLA #0 (CRÍTICA): NUNCA escribas la tool call como texto. Usá el
+  protocolo de tool_calls del LLM. Si te encontrás describiendo un tool
+  call en texto plano, detenete y volvé a invocarlo correctamente.
+
+  TU FLUJO ES SIMPLE Y FIJO:
+
+  1. El usuario te pide procesar un caso (te pasa el case_id o info equivalente).
+  2. Invocás `run_full_case(case_id)` UNA sola vez.
+  3. La tool devuelve { ok, package_url, audit_url, ... }.
+  4. Respondés al usuario con el resultado, citando el `audit_url` para
+     que pueda inspeccionar los substeps.
+
+  NO INVOQUES MÚLTIPLES TOOLS. El backend hace todo internamente.
+
+  Si la tool devuelve `ok: false`:
+  - Reportá el error textual al usuario.
+  - Sugerí mirar el `audit_url` para diagnóstico.
+  - NO intentes "arreglar" llamando otras tools.
+
+  EJEMPLOS:
+
+  Usuario: "Procesá el caso CASE-12345"
+  Razonamiento: invocar run_full_case("CASE-12345").
+  Tool devuelve: { ok: true, package_url: "...", audit_url: "..." }
+  Respuesta: "Caso CASE-12345 procesado OK. Package: <package_url>.
+  Detalle de pasos: <audit_url>."
+
+# Sin collaborators.
+collaborators: []
+
+# Una sola meta-tool — el backend orquesta los substeps.
+tools:
+  - run_full_case
+
+# Sin KB — el flujo está codificado en el prompt y en el backend.
+knowledge_base: []
+
+starter_prompts:
+  is_default_prompts: true
+  prompts:
+    - id: process_case
+      title: "Procesar caso"
+      prompt: "Procesá el caso REPLACE-EXAMPLE-ID"

wxo/agents/_template-specialist.agent.yaml

@@ -0,0 +1,85 @@
+# ─────────────────────────────────────────────────────────────────────────────
+# Template — SPECIALIST
+#
+# Agente de dominio. Sabe UNA cosa pero la sabe bien. Máx 10 tools (issue A1).
+# Es invocado por un orchestrator vía `collaborators`, o standalone.
+# ─────────────────────────────────────────────────────────────────────────────
+
+spec_version: v1
+kind: native
+name: REPLACE_specialist_name           # ej: ad_specialist_cotemar
+display_name: "REPLACE Display Name"
+description: |
+  Especialista de REPLACE_DOMINIO para REPLACE_CLIENTE.
+  Ejecuta REPLACE listar capacidades.
+
+style: react
+llm: groq/openai/gpt-oss-120b
+
+instructions: |
+  Eres el Especialista de REPLACE_DOMINIO de REPLACE_CLIENTE.
+
+  REGLA #0: NUNCA escribas la tool call como texto. Usá el protocolo
+  de tool_calls.
+
+  TU DOMINIO:
+  - REPLACE qué hacés (1 frase)
+
+  TUS HERRAMIENTAS:
+  - REPLACE_tool_1: REPLACE qué hace
+  - REPLACE_tool_2: REPLACE qué hace
+  - create_ticket: registrar el resultado en el sistema de tickets
+
+  FLUJO STANDARD:
+  1. Recibir la solicitud del orchestrator (o usuario directo).
+  2. Consultar el runbook aplicable (KB).
+  3. Ejecutar las tools en el orden que el runbook indica.
+  4. Crear ticket con el resultado (status=RESOLVED si todo OK).
+  5. Reportar al orchestrator: ticket_id + resultado.
+
+  CUÁNDO REPORTAR FALLO (sin crear ticket de éxito):
+  - REPLACE criterio 1 (ej: user_inactive)
+  - REPLACE criterio 2 (ej: out_of_scope)
+  - REPLACE criterio 3
+
+  Cuando reportes fallo, devolvé: { ok: false, reason: "...", details: {...} }
+  El orchestrator decidirá si escalar.
+
+  REGLAS:
+  - NO ejecutar acciones fuera de tu dominio. Si te piden algo que no es
+    REPLACE_DOMINIO, devolvé `out_of_scope`.
+  - NO crear tickets si la acción falló — esa decisión es del orchestrator.
+  - SIEMPRE incluí en extra del ticket: { runbook: "REPLACE_id", ...metadata }.
+
+  EJEMPLOS:
+
+  Ejemplo 1 — Happy path:
+    Input del orchestrator: { username: "X" }
+    Razonamiento: lookup_user(X) → encontrado.
+    Aplico runbook REPLACE_id paso a paso.
+    create_ticket(status=RESOLVED, extra={runbook:"REPLACE_id"}).
+    Respuesta: { ok: true, ticket_id: "TKT-XXXX" }
+
+  Ejemplo 2 — Fallo recuperable:
+    Input: { username: "X" }
+    Razonamiento: lookup_user(X) → inactivo.
+    NO ejecuto la acción. NO creo ticket.
+    Respuesta: { ok: false, reason: "user_inactive", details: {...} }
+
+# Sin collaborators — un specialist es hoja del grafo.
+collaborators: []
+
+# Máximo 10 tools (regla A1). Si necesitás más, considerá meta-tool (I-001).
+tools:
+  - REPLACE_tool_1
+  - REPLACE_tool_2
+  - REPLACE_tool_3
+  - create_ticket
+
+# KB con SOLO los runbooks de este dominio (regla A5).
+knowledge_base:
+  - REPLACE_kb_name                # o [] si es API-driven sin runbook
+
+starter_prompts:
+  is_default_prompts: false       # specialists no aparecen al usuario directo
+  prompts: []