Claude Code Harness Smoke Test: un bucle de prueba de 15 minutos antes de confiar en un agente

El primer trabajo serio con Claude Code no necesita una automatización enorme. Necesita una prueba pequeña. Define qué archivos puede leer, qué archivos puede editar, qué zonas no debe tocar y qué prueba cierra el trabajo.

La intención es práctica: una persona nueva quiere saber cuánto puede delegar en un agente. En un sitio con ingresos, la prueba incluye PDF gratis, Gumroad y consulta, no solo un build local correcto.

Lecturas relacionadas: Claude Code harness engineering, first repo audit checklist, permission safety ladder.

Por qué funciona este patrón

Un harness smoke test no demuestra que el modelo sea seguro siempre. Demuestra que el entorno tiene límites. Un cambio pequeño puede romper el formulario del PDF, el enlace de producto o el camino de consulta.

Quince minutos es lo bastante corto para repetirlo cada día. Primero pasa por lectura, edición limitada, build, URL pública y captura.

Flujo práctico

1. Escribe el objetivo en una frase y limita la edición a tres archivos o menos
2. Marca secretos, pagos, datos de clientes y despliegue como zonas bloqueadas
3. Elige antes de editar el comando de prueba, diff, URL pública y captura
4. En artículos y páginas, añade revisión de PDF gratis, Gumroad y consulta
5. Guarda la run card para que el siguiente trabajo empiece con evidencia

Situación	Movimiento seguro	Prueba
Artículo nuevo	Permitir solo cuerpo y frontmatter; layouts y API quedan en lectura	build y URL pública
Página de productos	Cambiar texto y orden de tarjetas; verificar cada URL de compra	enlaces de Gumroad
Adopción en equipo	Empezar solo lectura y luego permitir una edición de bajo riesgo	diff y captura

Prompt y código para copiar

Ejecuta un harness smoke test de 15 minutos para este repositorio. No hagas una edición amplia todavía. Devuelve objetivo, archivos editables, zonas bloqueadas, comandos de verificación, comprobaciones de URL pública y CTA de PDF gratis/Gumroad/consulta.

const runCard = {
  slug: "claude-code-harness-smoke-test-loop",
  goal: "publish one safe content change",
  allowedFiles: ["site/src/content/blog-en/example.mdx"],
  blockedAreas: [".env", "billing/", "cloudflare/"],
  proof: ["npm.cmd run build", "public URL screenshot"],
  ctas: ["free PDF", "Setup Guide", "consultation"]
};

function readyForAgent(card) {
  return card.allowedFiles.length > 0 &&
    card.blockedAreas.length > 0 &&
    card.proof.some((item) => item.includes("build")) &&
    card.ctas.length >= 3;
}

console.log(readyForAgent(runCard) ? "ready" : "tighten scope");

El código convierte una petición vaga en una run card. Puedes usar la misma forma en plantillas de PR, listas de publicación o notas previas a una consulta.

Tres ejemplos reales

Publicar un artículo Astro

Limita la edición a cuerpo, heroImage y CTA. Un build verde no basta si el h1 o la CTA de producción pertenecen a otra página.

Cambio pequeño de UI

Aunque solo cambie el texto de un botón, revisa salto de línea móvil y zona táctil. Si lleva a un producto, verifica también la URL.

Primera sesión de equipo

No empieces escribiendo código. Mapea README, permisos, pruebas y zonas bloqueadas. Ese artefacto sirve como agenda de consulta.

Fallos que conviene evitar

• Pedir que Claude Code mejore todo hace explotar el alcance.
• Parar en el build local oculta fallbacks de producción y CTA viejas.
• No revisar Gumroad puede enviar tráfico principiante a una oferta equivocada.

En varios idiomas, el slug puede coincidir mientras el cuerpo y la CTA siguen antiguos. Revisa la página pública.

Cómo conectar PDF gratis, Gumroad y consulta

Quien aún necesita fluidez de comandos debe empezar con el cheatsheet gratuito. Si el bloqueo es permisos, CLAUDE.md, hooks, MCP o CI, usa la Setup Guide.

Si repites prompts de revisión y depuración, usa 50 Prompt Templates. Para diseño de rollout en equipo, ve a consulta. Para comparar opciones, empieza en products.

Qué verificar antes y después de publicar

Antes de publicar revisa frontmatter, heroImage, enlaces internos y Gumroad. Después, en móvil, mira h1, inicio del cuerpo y zona CTA. Un 200 no basta si es fallback.

Métricas para observar después

Mira búsqueda, inicios de PDF, clics en Gumroad, visitas a productos y visitas a consulta. Si suben las PV sin clics de producto, la CTA no corresponde al momento del lector.

Revisión operativa de 30 minutos

Cuando el harness smoke test entra en trabajo real, la revisión más útil llega al día siguiente. Lee el registro y anota alcance permitido, archivos cambiados, comandos de prueba y páginas públicas vistas. No escribas solo “revisado”; deja el recibo exacto: h1 móvil, primer párrafo, zona CTA, enlace Gumroad y ruta de consulta.

Separa confianza del operador y comportamiento del lector. La primera confirma que no se tocaron zonas bloqueadas, que existe build, que la URL pública apunta al mismo slug y que las páginas traducidas no mantienen cuerpo en inglés. La segunda confirma que hay un paso natural: PDF gratis para comandos, Gumroad para un bloqueo repetible y consulta para diseño de flujo.

Convierte la revisión en una regla futura. No agregues diez reglas por cada problema. Agrega una: preguntar antes de tocar layout, hacer clic en cada URL de Gumroad en producción o capturar el inicio del cuerpo por idioma. Una regla pequeña que se cumple a diario vale más que una política larga.