Registro de riesgo de permisos en Claude Code: decide antes de que el agente actúe

Por qué merece su propio artefacto

Este artículo construye un registro de riesgo de permisos para equipos que pasan del uso individual de Claude Code a reglas compartidas de aprobación. El fallo común es simple: el equipo discute permisos después de que el agente ya editó, desplegó o pidió un comando riesgoso. Un workflow con Claude Code no termina con una respuesta segura. Debe dejar un artefacto que otra persona pueda revisar. En este caso el artefacto es un registro pequeño con acción, decisión por defecto, prueba y owner.

Trata el artefacto como contrato entre prompt, línea de comandos y página pública. Debe mostrar qué leyó Claude Code, qué cambió, qué comando probó el resultado y qué ruta de ingresos verá después el lector. Por eso conecta con harness engineering, getting started y permissions.

El loop operativo

Ejecuta el loop en cinco pasadas: definir la acción, elegir la prueba, dejar que Claude Code haga el trabajo mínimo útil, verificar la salida y registrar la siguiente acción de ingresos. Aquí la prueba útil no es solo que el código corra. Mira aprobaciones, comandos denegados, rollback notes, prueba de deploy e intención de consulta. Con esos campos visibles puedes mejorar sin adivinar.

1. El mapeo read-only del repo puede permitirse si la nota final lista qué se leyó.

2. Las ediciones de contenido pueden permitirse si diff review, build y URL pública son obligatorios.

3. Secrets, billing, datos de clientes y force push siguen con aprobación del owner aunque el agente sea preciso.

Starter para copiar

permission_risk_register:
  - action: "read repository files"
    default: "allow"
    proof: "list files read in the final note"
  - action: "edit content files"
    default: "allow after diff review"
    proof: "build passes and URL matches the slug"
  - action: "deploy production"
    default: "ask first"
    proof: "build log, deploy URL, rollback note"
  - action: "touch secrets or billing"
    default: "never without owner approval"
    proof: "human approval id"

Tres ejemplos reales

Ejemplo 1. El mapeo read-only del repo puede permitirse si la nota final lista qué se leyó.

Ejemplo 2. Las ediciones de contenido pueden permitirse si diff review, build y URL pública son obligatorios.

Ejemplo 3. Secrets, billing, datos de clientes y force push siguen con aprobación del owner aunque el agente sea preciso.

Checklist de auto-revisión

Antes de convertir este workflow en hábito, revisa el artículo como si fuera una nota de release. El primer control es el alcance: el lector debe saber cuándo usar un registro de riesgo de permisos y cuándo basta un checklist más pequeño. El segundo control es la prueba: cada recomendación debe apuntar a un comando, una URL, un diff o una métrica. El tercer control es el routing: el PDF gratuito, la guía de Gumroad y la consultoría no deben competir, sino responder a distintos niveles de urgencia.

Añade una regla pequeña de ownership. Una persona es dueña del artefacto, otra de la verificación y otra del siguiente experimento de CTA. En un flujo individual pueden ser la misma persona, pero los roles deben quedar escritos. Eso evita que Claude Code mezcle publicación, medición y venta en una sola tarea borrosa. También permite que la siguiente ejecución continúe desde un punto concreto.

La pregunta práctica es: ¿qué haría este artículo más fácil de verificar mañana por la mañana? Si la respuesta es una captura, guárdala. Si es un prompt más fuerte, súbelo al prompt pack. Si es un límite más claro, añádelo a las notas de setup. un registro pequeño con acción, decisión por defecto, prueba y owner solo sirve cuando sobrevive a la siguiente sesión.

Fallos comunes

El primer fallo es tratar las páginas vistas como único score. El segundo es aprobar cambios sin comando de prueba. El tercero es enviar a todos los lectores al mismo producto pagado aunque un PDF gratuito o una consulta encaje mejor. Escribe la regla de routing antes de tocar el CTA.

Ruta de ingresos

Rutea por cuello de botella. Si falta fluidez de comandos, manda al PDF gratuito o al cheatsheet gratuito en Gumroad. Si repiten el mismo trabajo cada semana, usa 50 Prompt Templates o Setup Guide. Si el problema es rollout, riesgo o diseño de ingresos, usa consultoría. En este artículo, Setup Guide da la base de policy y la consultoría ayuda cuando producción o ingresos dependen de aprobaciones.

Métricas de verificación

Después de publicar, no basta HTTP 200. Confirma h1, canonical, hero image, inicio del cuerpo, enlaces CTA, mobile layout e idioma. Luego mira aprobaciones, comandos denegados, rollback notes, prueba de deploy e intención de consulta. Si la métrica no se mueve, revisa el CTA cerca del primer ejemplo concreto antes de reescribir todo.