chrislacey89/execute

Ejecutar

Ejecuta una unidad de trabajo completa: planifícala, constrúyela, verifica los resultados reales, confírmala.

Posición de Invocación

Esta es una habilidad primaria del pipeline que se utiliza después de que /prd-to-issues ha producido una porción concreta, o cuando el usuario ya tiene una tarea de implementación claramente delimitada.

Usa /execute cuando el trabajo esté listo para construir, verificar y confirmar.

Usa /execute en modo HITL cuando la porción todavía necesita juicio activo del usuario, supervisión o decisiones de aceptación durante la implementación. Usa /execute en modo AFK solo cuando la siguiente porción ya sea duradera en GitHub, esté desbloqueada y sea legible desde su issue, mapa de límites y cualquier artefacto de investigación vinculado (archivo de archivo o issue de spike) o contexto de docs/solutions/.

Legible para un lector que no tenga nada de eso — que es lo que es una iteración AFK. La verificación de completitud de contexto de /prd-to-issues §4 es la puerta detrás de esa condición: requiere que cada porción AFK lleve un bloque ### Context, o declaraciones explícitas de vacío, antes de que se registre la issue. Una porción marcada como AFK sin dicho bloque nunca fue verificada contra esta condición, solo se asumió que la cumplía. Trata eso como una razón para ejecutar la porción en modo HITL, o para enviarla de vuelta a través de /prd-to-issues, en lugar de como una formalidad que se pasa por alto.

Consulta Paso 0: Requisitos previos a continuación para las compuertas obligatorias de detección automática de Ralph y marcador TDD.

No lo utilices para reemplazar /shape, /research o /write-a-prd cuando el problema o la forma aún no estén resueltos. No lo utilices como sustituto de /pre-merge una vez que la implementación esté completa y lista para revisión.

Flujo de trabajo

0. Requisitos previos

Compuerta de aislamiento de rama. Antes de cualquier trabajo de implementación, asegúrate de estar trabajando en una rama limpia creada para esta tarea específica — no en una rama de características sobrante de trabajo anterior.

Aislamiento ya proporcionado — detente (verifica esto primero, antes de las reglas numeradas). Algunos entornos entregan a la sesión un worktree + rama aislado y dedicado antes de que se ejecute /execute — los espacios de trabajo de Conductor, GitHub Codespaces, devcontainers y hosts similares aprovisionan cada uno "un espacio de trabajo = una rama, bifurcada automáticamente desde la base", con scripts de configuración ya ejecutados. Cuando ese es el caso, el pipeline no posee el aprovisionamiento: crear un worktree aquí lo anidaría dentro del del host, y la rama del host (nombrada para el espacio de trabajo, no para la tarea) no está "obsoleta". Lee la señal del entorno y cede el worktree a quien ya lo posee (Norman — lee el significante del mundo en lugar de llevar una suposición mental de que el pipeline siempre aprovisiona; Meadows — un actor por stock, por lo que el pipeline difiere en lugar de agregar un administrador competidor).

Resuelve el modo de aprovisionamiento desde .claude/settings.json worktree.provisioning — "host" | "pipeline" | "auto", por defecto "auto" cuando la clave está ausente (reflejando el precedente existente de research.storage):

• host — el aislamiento es propiedad del host. Detente incondicionalmente.
• pipeline — el pipeline aprovisiona. Omite esta detención y ejecuta la compuerta numerada a continuación.
• auto (predeterminado) — detente si cualquiera de las señales se activa:
  • una variable de entorno del host describe este árbol — el bloque a continuación imprime host_owned=yes. Este es el discriminador primario más económico: el único mecanismo de detección del pipeline es Bash, y estas variables son visibles en el shell del agente. La presencia por sí sola no es suficiente: CONDUCTOR_WORKSPACE_PATH es heredada por cualquier shell iniciado bajo Conductor y puede nombrar un espacio de trabajo de un repositorio diferente, por lo que cuenta solo cuando contiene el toplevel actual. (No detectes a través de un directorio .conductor en el cwd — Conductor lo mantiene bajo $CONDUCTOR_ROOT_PATH, no en el espacio de trabajo).
  • el árbol de trabajo actual no es el árbol de trabajo principal del repositorio — git rev-parse --show-toplevel difiere de la primera ruta en git worktree list --porcelain.

# host-signal: does a host env var describe THIS tree, not just this shell?
host_owned=no
top=$(cd "$(git rev-parse --show-toplevel)" && pwd -P)
if [ -n "${CONDUCTOR_WORKSPACE_PATH:-}" ]; then
  ws=$(cd "$CONDUCTOR_WORKSPACE_PATH" 2>/dev/null && pwd -P) || ws=
  if [ -n "$ws" ]; then
    case "$top/" in "$ws"/*) host_owned=yes ;; esac
  fi
fi
if [ -n "${CODESPACES:-}" ] || [ -n "${REMOTE_CONTAINERS:-}" ]; then host_owned=yes; fi
echo "host_owned=$host_owned"

CODESPACES y REMOTE_CONTAINERS no llevan una ruta para comparar y se leen por presencia; están limitados al contenedor, por lo que un shell que los ve está dentro del contenedor cuyos repositorios describen. El mismo bloque aparece en /closeout, /lfg e /init-pipeline, byte-idéntico, fijado por scripts/test-host-signal-containment.sh en el propio repositorio del paquete.

Al detenerse: omite la creación del worktree y EnterWorktree, y trabaja en el lugar en la rama actual. Las reglas numeradas a continuación ya están satisfechas — en particular la regla 3 no aplica (una rama aprovisionada por el host no es ni base ni nombrada para la tarea, pero no está obsoleta; no anides un worktree y no te detengas). El host ya ha sembrado la configuración y dependencias ignoradas por git, por lo que la mayor parte de la "Lista de verificación de configuración del worktree" es solo informativa — verifica .env.local/deps si un comando falla, pero no vuelvas a aprovisionar. Su elemento de hooks de git es la excepción y aún aplica. Los hosts aprovisionan archivos rastreados más dependencias; los hooks de git viven en .git/hooks, que es por worktree y no rastreado, por lo que un espacio de trabajo aprovisionado por el host característicamente no tiene ninguno. Verifica ese elemento incluso cuando te detengas. Continúa a la compuerta de forma de issue.

Esta detención es deliberadamente asimétrica con la verificación de desmontaje de /closeout. El flujo de entrada solo necesita responder "¿ya estoy aislado?" — la detección genérica (toplevel ≠ primario) y la pista de variable de entorno resuelven cada una eso. La pregunta del flujo de salida — "¿quién es dueño del desmontaje?" — es más estricta y no puede confiar solo en la heurística genérica, porque un worktree creado por el pipeline también satisface toplevel ≠ primario; /closeout depende de la configuración explícita o solo de la variable de entorno del host.

1. Verifica la rama actual: git branch --show-current
2. Si la rama actual es la rama base (por ejemplo, main, prod, master), crea una nueva rama de características para esta tarea.
3. Si la rama actual es una rama de características diferente (no la rama base y no una rama nombrada para esta tarea), estás en una rama obsoleta de trabajo anterior. No confirmes trabajo nuevo aquí. Excepción: si la rama actual es una rama de porción hermana nombrada en la declaración Consumes from #N de esta tarea, estás intencionalmente a punto de bifurcarte desde ella para una porción de PR apilado — continúa. Excepción (aprovisionada por el host): si la verificación de detención anterior se activó, esta rama es la rama de espacio de trabajo aislada del host — no está obsoleta; trabaja en el lugar.

Para crear una rama aislada, utiliza uno de estos enfoques (en orden de preferencia):

• Worktrunk (si wt está disponible): wt switch --create <nombre-de-rama> — crea un nuevo worktree + rama desde la base apropiada y cambia a él, proporcionando un aislamiento completo del sistema de archivos. Usa la habilidad /worktrunk para obtener orientación.
• Git simple: git checkout <base> && git checkout -b <nombre-de-rama> — crea una nueva rama desde la base apropiada en el directorio de trabajo actual.

La base apropiada es la rama base del propio repositorio por defecto — lo que bash "$SC" base-ref --name imprima, con SC establecido en references/sidecar.sh de esta habilidad. No asumas main. Para una porción con una dependencia Consumes from #N sin fusionar que produce símbolos que esta porción importa, bifurca desde la rama de esa porción hermana en su lugar para que el PR apilado pueda apuntar al PR de la hermana (Hammant Trunk-Based Development Cap. 13: múltiples PRs por historia; el PR de la hermana aún debe fusionarse con la rama base del repositorio dentro de 2 días).

Deriva el nombre de la rama de la tarea: por ejemplo, issue-5-landing-page, landing-page o el slug de la issue. No reutilices nombres de rama de trabajo anterior.

Ingresa al worktree como una sesión (cuando hayas creado un worktree). Crear el worktree no es lo mismo que la sesión ejecutándose dentro de él — wt switch --create restablece el cwd del shell de vuelta a la raíz del proyecto después de cada comando, por lo que sin un paso adicional la sesión permanece anclada en el checkout original y el cwd informado miente sobre dónde está ocurriendo el trabajo. Después de crear el worktree, ingresa a él con la herramienta EnterWorktree para que el directorio de trabajo de la sesión sea genuinamente el worktree:

• Llama a EnterWorktree { path: <ruta-absoluta-del-worktree> }. La ruta ya debe aparecer en git worktree list para este repositorio (lo hará, porque acabas de crearlo). Esto cambia persistentemente la sesión al worktree.
• Mantén el paso de creación exactamente como arriba — wt switch --create / git worktree add ejecuta los hooks pre-start de worktrunk que siembran .env.local y dependencias. EnterWorktree solo cambia el cwd; no ejecuta esos hooks. Crea primero (para sembrar env/deps), luego ingresa.
• Esto pone el conocimiento en el mundo, no en la cabeza: el cwd dice la verdad sobre dónde aterrizan las ediciones y confirmaciones (un operador que observa puede verlo), y no hay un prefijo cd por comando que olvidar — eliminando la clase de desliz donde un comando sin prefijo escribe en el árbol equivocado.
• La opción Git simple (git checkout -b, sin worktree) crea la rama en el checkout actual — no hay worktree al que ingresar, por lo que omite EnterWorktree y trabaja en el lugar.

Alternativa AFK / sin cabeza. Si EnterWorktree no está disponible (ejecuciones sin cabeza, AFK Ralph, cron), recurre a la disciplina de prefijo cwd: el cwd del shell se restablece a la raíz del proyecto después de cada comando de Bash, por lo que prefija cada llamada de Bash en esta sesión con cd <ruta-absoluta-del-worktree> &&. Usa esto solo cuando la herramienta del arnés no esté genuinamente disponible — es la solución alternativa antigua, conservada para entornos sin el mecanismo nativo.

El desmontaje de este worktree es propiedad de /closeout al final del pipeline — después de que el PR se fusione, /closeout reancla el shell al checkout base, elimina el worktree y poda la rama fusionada. /execute es el lado de entrada del ciclo de vida del worktree; /closeout es el de salida. La limpieza del Paso 6 a continuación elimina solo los marcadores .tdd-* — deliberadamente no elimina el worktree.

Después de crear el worktree, configúralo. Un nuevo worktree hereda archivos rastreados pero no los ignorados por git (.env.local, dependencias por worktree, cachés de compilación). Dos caminos:

Preferido — configurar una vez a través de hooks de worktrunk (.config/wt.toml en el proyecto):

[pre-start]
copy = "wt step copy-ignored"
install = "pnpm install"

Los hooks pre-start son bloqueantes — el worktree no se reporta como listo hasta que terminan. Usa pre-start (no post-start) para ambos, porque post-start se ejecuta en segundo plano y los comandos posteriores que necesiten .env.local o node_modules competirán con el hook. Consulta /worktrunk para la receta completa. Una vez por proyecto.

Alternativa — configuración manual para git worktree add simple (sin worktrunk):

• cp <repo-fuente>/.env.local <worktree>/.env.local (y cualquier otra configuración ignorada por git que el proyecto use).
• Ejecuta el comando de instalación del proyecto (pnpm install, npm ci, pip install -r requirements.txt, etc.) desde el worktree.

Lista de verificación de configuración del worktree (HACER-CONFIRMAR — realiza cada paso, luego verifica antes de proceder). Aplica independientemente de cómo se creó el worktree:

• Configuración ignorada por git copiada — .env.local (y cualquier otro .env.*, *.local o configuración ignorada específica del proyecto) existe en el worktree
• Dependencias instaladas — el comando de instalación (pnpm install, npm ci, etc.) se ejecutó sin errores en el worktree
• La sesión está dentro del worktree — pwd reporta la ruta del worktree porque ingresaste a él a través de EnterWorktree { path } (no la raíz del proyecto). En la alternativa AFK/sin cabeza solamente, este elemento significa que el prefijo cd <ruta-absoluta-del-worktree> && se está aplicando a cada llamada de Bash
• Ámbito de $CLAUDE_PROJECT_DIR correcto — si el proyecto referencia esta variable de entorno en scripts, verifica que se resuelva a la ruta del worktree, no al repositorio primario
• Los hooks de git locales están instalados y su administrador está en PATH — ls "$(git rev-parse --git-dir)/hooks/" | grep -v '\.sample$' lista algo, y el administrador que el repositorio declara (lefthook, husky, pre-commit, …) se resuelve. Los hooks viven en .git/hooks, que es por worktree y no rastreado, por lo que un worktree nuevo no hereda ninguno de ellos — y la falla es silenciosa en la peor dirección: cada confirmación tiene éxito, y cada garantía que el repositorio documenta en el momento de la confirmación simplemente no se ejecutó. Si el administrador está ausente, instálalo (lefthook install) o registra en las notas de revisión del Paso 6 que las compuertas locales estaban inactivas para esta rama, para que nadie interprete una ejecución local exitosa como la compuerta de fusión
• Marcador de clasificación ausente — .claude/.tdd-active, .claude/.tdd-skipped y .claude/.lfg-active no existen en el worktree (pizarra limpia; el Paso 3 crea uno)
• Banderas de bloqueo posteriores a la revisión ausentes — .claude/.review-stamped y .claude/.fix-findings-active no existen. Ambos pertenecen a la rama anterior de la revisión: /pre-merge Fase 4 escribe el primero, /fix-findings escribe el segundo, y /closeout y /fix-findings respectivamente los eliminan al final de esa rama. Un .review-stamped filtrado rechaza cada escritura de implementación en esta porción antes de que comience; un .fix-findings-active filtrado mantiene el bloqueo abierto para toda la porción, que es la dirección silenciosa. Elimina cualquiera que encuentres — estás al inicio de una rama que no ha tenido ninguna revisión, por lo que ninguno puede describir esta

Compuerta de forma de issue y bloqueo. Si la tarea es una issue de GitHub, confirma que es una porción ejecutable antes de implementarla: no es un PRD no descompuesto, no está bloqueada y no está siendo cerrada por un PR abierto de otra persona. Una lectura de GraphQL responde a las tres, y el bloque decide — no juzgues ninguna de ellas a simple vista:

N=<n>
VERDICT_JQ='
def lines: split("\n")[];
[inputs][0] | if (.errors // [] | length) > 0 then "unknown" else
.data.repository.issue as $i
| if $i == null or $i.number != $n or (($i.title // "") == "")
     or ($i.bo