Segundo artículo de la serie de 6 partes sobre los escenarios del CCA-F — código fuente completo de cada escenario: aicert-labs.
El escenario, tal como está en el exam guide
Un equipo usa Claude Code para generación de código, refactoring, debugging y documentación, con slash commands personalizados y un CLAUDE.md, decidiendo entre plan mode y ejecución directa.
| Dominio | Peso | Dónde aparece en este escenario |
|---|---|---|
| Claude Code Configuration & Workflows | 20% | Convenciones de equipo en CLAUDE.md y tres slash commands personalizados, cada uno con un nivel de riesgo distinto |
| Context Management & Reliability | 15% | Un CLAUDE.md deliberadamente corto — uno largo y desactualizado ya es, en sí mismo, una falla de context management |
"Usa plan mode para cambios riesgosos" no es una decisión
Esa instrucción solo reformula el problema. ¿Qué es riesgoso? Sin definición, queda a criterio de quien esté ejecutando la sesión ese día, con el juicio que tenga a mano. Dos ingenieros del mismo equipo van a trazar la línea en lugares distintos, y ninguno está equivocado — nunca existió una definición compartida sobre la cual estar equivocado.
El CLAUDE.md de referencia en aicert-labs reemplaza la instrucción vaga por una tabla explícita: el radio de impacto de un archivo — único, módulo compartido, legado, schema — se mapea a un modo. No es dificultad, no es cómo el ingeniero siente el cambio. Es radio de impacto.
| El cambio toca... | Modo |
|---|---|
| Un único archivo, no importado en ningún otro lugar | Ejecución directa |
Un archivo importado por 3+ módulos, o src/shared/ | Plan mode obligatorio |
src/legacy/ | Plan mode obligatorio, el plan debe decir qué no se verificó |
| Schema de base de datos | Plan mode obligatorio, siempre |
Los comandos son la fiscalización, no la tabla
Una tabla en un archivo markdown sigue siendo solo una tabla que alguien tiene que recordar consultar. El proyecto de ejemplo la convierte en tres slash commands que llevan su propio nivel de riesgo:
/fix-buges ejecución directa, pero su propio cuerpo indica rechazar y redirigir a/refactor-safelysi el fix no está realmente confinado a un solo archivo./refactor-safelyrecibe la instrucción explícita: si no fue invocado en plan mode, detente y dile al usuario que vuelva a ejecutarlo en plan mode. No procede "con cuidado" — no procede./documentes ejecución directa pero tiene prohibido tocar lógica, para que un comando de documentación no se convierta silenciosamente en un refactor.
Para hacer la regla de radio de impacto concreta en lugar de hipotética, el ejemplo tiene src/shared/format-currency.ts genuinamente importado por tres archivos de rutas. Pídele a /refactor-safely que lo cambie, y lo primero que tiene que hacer — según sus propias instrucciones — es enumerar los tres importadores antes de proponer nada.
Dos capas independientes, no una sola
CLAUDE.md y los comandos actúan a nivel de prompt — moldean lo que Claude decide hacer. .claude/settings.json agrega una capa que no depende de que el modelo lea nada correctamente: un hook PostToolUse que ejecuta el linter después de cada edición, y una lista de negación de permisos que bloquea git push --force y rm -rf sin excepciones, sin importar lo que diga cualquier prompt. Es el mismo principio del process_refund del Escenario 1: poner la restricción donde no se puede argumentar en contra, no solo donde es probable que se siga.
Ejecútalo tú mismo
git clone https://github.com/AICERT-STUDY/aicert-labs
cd aicert-labs/cca-f/scenario-2-claude-code-workflows/example-project
npm install && npm test && npm run lint
Luego abre la carpeta en Claude Code y prueba /document src/shared/format-currency.ts, /fix-bug y /refactor-safely — el README tiene comandos exactos para probar, incluyendo uno que debería hacer que Claude enumere los tres importadores antes de tocar nada.
Pon a prueba tus conocimientos
1. ¿Por qué la tabla de radio de impacto del proyecto de ejemplo se basa en qué archivos toca un módulo, en lugar del tamaño o complejidad del cambio?
Respuesta: porque la complejidad es subjetiva e inconsistente entre ingenieros, mientras que "importado por 3+ módulos" es un hecho verificable con un grep.
Una regla que depende del juicio reintroduce exactamente la ambigüedad que la tabla existe para eliminar. Una regla basada en un hecho verificable produce la misma respuesta sin importar quién — o qué — la evalúe.
2. ¿Cuál es la diferencia funcional entre poner una regla en CLAUDE.md y aplicarla vía hooks y permissions de .claude/settings.json?
Respuesta: CLAUDE.md moldea lo que el modelo decide hacer; los hooks/permissions de settings.json se ejecutan independientemente de la decisión del modelo.
Una regla en CLAUDE.md solo se sostiene si el modelo la lee y la sigue correctamente en cada turno relevante. Un hook o una lista de negación de permisos se ejecuta de todas formas — es el mismo patrón de "la tool lo garantiza, no el prompt" que el resultado tipado needs_escalation del Escenario 1.
3. Las instrucciones de /fix-bug dicen que redirija a /refactor-safely bajo ciertas condiciones. ¿Por qué poner esa lógica dentro del comando en lugar de simplemente confiar en que el ingeniero elegirá el comando correcto?
Respuesta: porque el ingeniero que invoca el comando es exactamente quien podría juzgar mal el radio de impacto — el comando es una segunda verificación, no una redundante.
Si elegir el comando correcto fuera confiable por sí solo, la tabla de radio de impacto ni siquiera sería necesaria. La redirección es una red de seguridad para el caso que la tabla existe para prevenir.
4. ¿Por qué CLAUDE.md dice explícitamente mantenerlo corto, llamando a un archivo largo una "falla de Context Management"?
Respuesta: un CLAUDE.md largo compite por presupuesto de contexto con la tarea en sí, y el contenido rara vez relevante para una tarea dada desplaza contenido que sí lo es.
Esto se relaciona directamente con el dominio Context Management & Reliability: lo que entra en contexto persistente, siempre cargado, tiene que justificar su lugar en cada sesión, no solo una vez cuando se escribió.
5. El comentario en src/legacy/reconcile.ts dice que otros tres servicios dependen de su comportamiento de redondeo no documentado. ¿Qué riesgo relevante para el CCA-F aborda documentar eso en el propio archivo?
Respuesta: evita que el conocimiento tribal se pierda cuando la persona que lo sabía se va — y coloca la información exactamente donde un agente (o alguien nuevo) que toque ese archivo la va a leer realmente.
Las restricciones no documentadas que viven solo en la cabeza de una persona son un riesgo de confiabilidad en el momento en que esa persona no está disponible. Escribir la restricción en el punto de contacto es lo que la hace duradera.
Simulacro gratuito del CCA-F, cubriendo los 5 dominios: aicert.study/certifications/ccaf.