Repaso y simulacro CCAR-F: decide como un arquitecto

Son las 10:40 del examen. Llevas 22 preguntas y te quedan 38. Has visto un agente de soporte, una canalización de extracción y un sistema de investigación. Te sale una pregunta de Claude Code en CI con cuatro opciones que parecen buenas. Dudas. Miras el reloj y la tentación es elegir la más sofisticada.

Esa es la trampa. El examen no premia la opción más ingeniosa, sino la más simple que ataca la causa raíz. Esta lección cierra la ruta. No trae temas nuevos: te da un plan de repaso por dominios, un método para leer cada pregunta y un simulacro con la decisión correcta justificada. Si quieres recordar el formato (60 preguntas, 120 minutos, 4 escenarios de 6, aprobado con 720 sobre 1.000), repasa la lección 1. El detalle vigente está en la Exam Guide oficial, en la página de la Partner Academy.

Cómo repasar: en proporción a los pesos

El examen reparte las preguntas según el peso de cada dominio. Tu tiempo de repaso debería hacer lo mismo. Con 120 minutos para 60 preguntas, además, tienes de media dos minutos por pregunta: no hay sitio para pensar desde cero cada vez. Necesitas reflejos.

MapaLos cinco dominios y su reflejo principal

D1 · 27 % · Arquitectura agéntica

Bucle con stop_reason: seguir con tool_use, parar con end_turn. Coordinador con contexto explícito para subagentes. Si la regla no puede fallar, hook o requisito previo programático.

Pulsa cada dominio: es la frase que debería saltarte en la cabeza al leer el síntoma.

Un plan razonable: dedica la mitad del repaso a los dominios 1 y 3 (47 % entre los dos) y reparte el resto. Y no estudies por dominio aislado en la última semana. Estudia por escenario, porque así te lo presenta el examen.

El método de lectura en cuatro pasos

Antes del simulacro, fija el procedimiento. Lo aplicarás a cada pregunta.

Lee la última frase. Dice si piden la mejor primera medida, la causa raíz o el enfoque más eficaz. Cambia la respuesta.
Localiza el síntoma medido. «En el 8 % de los casos…» suele indicar un fallo probabilístico que exige garantía. «Siempre» o «nunca» apunta a código.
Ubica el componente culpable. Si lo que ejecutó cada subagente fue correcto, el fallo está en quien repartió el trabajo.
Descarta por patrones. Elimina primero lo probabilístico donde hace falta garantía, la sobreingeniería, la confianza autodeclarada como métrica, los modelos o ventanas mayores como remedio de atención, y las funciones inventadas.

Frente a frentePrimera medida frente a causa raíz

Primera medida

lo más simple que ataca el síntoma

Cambio pequeño, reversible y barato
Suele estar en descripciones, criterios o hooks
Casi nunca es un clasificador nuevo ni un modelo mayor
Se hace antes de añadir capas de arquitectura

Causa raíz

el componente que realmente falla

Pregunta qué componente explica el síntoma
Si los subagentes cumplieron, mira al coordinador
Si la selección es errónea, mira las descripciones
No culpes a lo que funciona bien

Los dos tipos de pregunta comparten distractores, pero la respuesta correcta puede cambiar según lo que se pida.

Simulacro por escenarios

Cada bloque tiene su decisión justificada. Intenta responder antes de leer la razón.

Escenario de soporte: la garantía frente al criterio

Un agente de soporte escala demasiado poco y a veces demasiado. Dos síntomas distintos, dos soluciones distintas.

Si un reembolso grande sale sin pasar por nadie: es un fallo de garantía. Hook que intercepta process_refund, comprueba el importe y redirige a escalate_to_human.
Si el agente duda entre resolver y escalar en casos ambiguos: es un fallo de criterio. Criterios explícitos de escalado con ejemplos few-shot: petición de persona, hueco en la política, imposibilidad de avanzar.
Si el cliente pide una persona: se escala de inmediato, sin intentar otra solución.
Si hay varias coincidencias de cliente: pide más identificadores, no elijas una.

El análisis de sentimiento y la confianza autodeclarada tientan mucho, y casi siempre son el distractor. Un cliente puede estar muy enfadado con un caso trivial, y un agente puede declararse seguro estando equivocado.

Pregunta de examen

Agente de soporte: el 14 % de los casos escalados llegan al humano sin el importe ni la causa del problema, y el humano tiene que volver a preguntar al cliente. ¿Cuál es la mejor primera medida?

Escenario de extracción: sintaxis, semántica y lotes

Documentos con estructuras muy variadas, JSON hacia un ERP.

El esquema válido no es dato correcto. Los totales que no cuadran se detectan en código (calculated_total frente a stated_total, con conflict_detected).
El reintento lleva tres cosas: documento original, extracción fallida y error concreto. Y no sirve si el dato no está en el documento: el campo debe poder ser nulo.
Para no inventar: campos opcionales o nullable, y enums con unclear y other más un campo de detalle.
Formato inconsistente entre tipos de documento: 2-4 ejemplos few-shot sobre los casos ambiguos.
Lotes: Message Batches API, 50 % más barata, hasta 24 horas, con custom_id para correlacionar y reenviar solo los fallidos. Para un cierre nocturno, sí. Para algo que espera un usuario, no.
Aviso de actualidad: con Opus 5.5, Sonnet 5.5 y Fable 5.1, tool_choice de tipo any o tool devuelve error 400. Usa auto con strict tool use o structured outputs.

Escenario multiagente: localizar al culpable

Coordinador, subagentes de búsqueda, análisis y síntesis, informe con citas.

Informe con huecos de cobertura: mira la descomposición del coordinador.
Subagente que ignora lo ya hallado: no hereda contexto. Se le pasa de forma explícita en su prompt.
Conclusión de «no hay datos» tras un timeout: falta el error estructurado que distinga fallo de acceso de resultado vacío.
Afirmaciones sin fuente: los subagentes deben devolver datos estructurados con afirmación, fuente y fecha.
Dos cifras en conflicto: se anotan ambas con su origen. Antes de llamarlo contradicción, comprueba las fechas de publicación.
Un fallo parcial: no se aborta todo ni se suprime el error. Se sintetiza con anotaciones de cobertura.

Escenarios de Claude Code: equipo y CI

Dos escenarios comparten dominio 3 y el 4 aparece en el de CI.

Convenciones por tipo de archivo repartidas por el repositorio: reglas en .claude/rules/ con paths y globs, mejor que muchos CLAUDE.md por carpeta.
Comando compartido con el equipo: .claude/commands/ o una skill en .claude/skills/. Lo personal va en ~/.claude/commands/.
Cambio grande con varias opciones de diseño: plan mode, con subagente Explore para aislar el descubrimiento. Un arreglo pequeño y claro va en ejecución directa.
Pipeline: -p, --output-format json y --json-schema. El revisor es independiente de quien generó el código.
Falsos positivos: criterios categóricos concretos. Si una categoría es ruidosa, se desactiva temporalmente.
PR grande: pasada por archivo más pasada de integración.

Paso a pasoCómo atacar una pregunta de escenario en dos minutos

Lee la última frase: primera medida, causa raíz o enfoque más eficaz.

1 de 5

Errores de última hora

No estudies con listas de memoria de flags. Una función que suena plausible pero no existe es un distractor frecuente. Si no la reconoces de tu práctica, desconfía.
No cambies una respuesta por parecer demasiado simple. Muchas respuestas correctas son pequeñas: una descripción, un criterio, un hook.
Reserva tiempo. Si una pregunta te atasca, márcala y sigue. Dos minutos de media da margen para volver.
Practica con tus propias tablas. Haz la tuya de síntoma, causa y medida. Escribirla fija más que leerla.

Para cerrar la parte técnica, si algo no te sale, vuelve a la lección del dominio correspondiente: las tienes todas en /aprende. Y si quieres ver estas ideas aplicadas a un entorno real, en /claude-y-sap está cómo encajan Claude y SAP.

Para el examen

En el examenRepaso final: cruce de los cinco dominios

Dominio · Dominios 1 a 5 · Los cuatro escenarios que te toquen de entre los seis

Lo que tienes que dominar

Leer primero qué se pide: primera medida, causa raíz o enfoque más eficaz.
Garantía (hooks, requisitos previos) frente a criterio (descripciones, ejemplos, criterios explícitos).
Bucle agéntico guiado por stop_reason; contexto explícito a los subagentes; coordinador como causa de huecos de cobertura.
Descripciones claras y errores estructurados con categoría e isRetryable; pocas herramientas por rol.
CLAUDE.md por jerarquía, reglas por ruta, plan mode para lo ambiguo y -p con salida JSON en CI.
Esquema contra errores de sintaxis; validación en código contra los semánticos; reintento con error concreto.
Batch API para cargas no bloqueantes con custom_id; checks previos al merge, síncronos.
Hechos persistentes, escalado por criterios válidos, procedencia con fuente y fecha, precisión desglosada.
Elegir la medida más simple que ataque la causa raíz.

Donde se suele fallar

Elegir la opción más sofisticada por parecer más completa.
Reforzar el prompt cuando la regla no puede fallar nunca.
Usar sentimiento o confianza autodeclarada como criterio de escalado.
Culpar a un subagente o a la búsqueda cuando el fallo es del coordinador.
Resolver un problema de atención o contexto con un modelo o una ventana mayores.
Dar por buena una precisión global sin desglosarla por tipo y campo.
Aceptar una función o flag que no reconoces de tu práctica.

Checklist para el examen

0 de 8 dominados

Marca lo que ya sabrías responder en el examen.