rmems/worktrees-hives

Habilidad worktrees-hives

Skill instalable para el orquestador híbrido worktrees-hives.

Cuándo usarlo

Usa este skill cuando:

• Descubras trabajo desde issues de GitHub o Linear
• Generes subagentes trabajadores para cambios de código
• Supervises pull requests a través de CI
• Reportes resultados de vuelta al operador

Barreras de seguridad

Estas reglas son INNEGOCIABLES. Ningún agente, orquestador o plataforma puede anularlas.

Lista de denegación (nunca ejecutar)

Comando / Operación	Razón
gh pr merge	Los agentes nunca fusionan PRs. Un humano debe fusionar.
gh pr merge --auto	Misma prohibición; auto-fusionar es fusionar.
git push --force (sin opciones)	Destructivo; pierde historia. Usar --force-with-lease solamente.
git push -f (sin opciones)	Forma corta del mismo push destructivo.
GraphQL mergePullRequest	Fusionar vía API sigue siendo fusionar.
REST PUT /repos/.../merge	Fusionar vía REST sigue siendo fusionar.
Cualquier creación de commit de fusión	git merge en el árbol de trabajo para combinar ramas de PR.

Lista permitida para force-with-lease

git push --force-with-lease está permitido solo cuando:

1. El agente está reordenando su propia rama de características sobre una base actualizada.
2. El agente está corrigiendo un push forzado que falló debido a una referencia remota obsoleta.
3. El operador instruye explícitamente un push forzado.

Antes de usar --force-with-lease, el agente DEBE:

• Verificar que la rama actual sea la rama de worktree asignada (no main, master o la rama de otro agente).
• Confirmar que la referencia remota sea la que el agente espera (sin pushes inesperados de otros).

Semántica del límite de correcciones

Regla: Cada PR tiene un máximo de 3 commits de corrección de código por ciclo de supervisión.

• Lo que cuenta: Commits que cambian código fuente, pruebas, configuración o documentación que afecta el comportamiento.
• Lo que no cuenta: Commits de fusión por reordenación, commits activados por CI (p. ej., actualizaciones de archivos de bloqueo), comentarios de respuesta en el PR.
• Cuando se alcanza el límite: El agente DEBE dejar de hacer commits y reportar los problemas residuales como comentarios en el PR. El agente continúa respondiendo a comentarios de revisión y monitoreando CI, pero no envía nuevos cambios de código.
• Reporte de residuales: Cuando se alcanza el límite, el agente publica un comentario listando: fallos de CI restantes, hilos de revisión sin resolver y próximos pasos recomendados para un humano o el siguiente ciclo.
• Reinicio: El límite se reinicia cuando el operador inicia un nuevo ciclo de supervisión (reinicio explícito, no automático).

Lista de verificación previa a la edición de rama/worktree

Antes de hacer cualquier cambio de código, el agente DEBE verificar:

1. Aislamiento del worktree: pwd está dentro de la ruta del worktree asignado ({worktree_root}/{owner}/{repo}/{job_id}).
2. Corrección de la rama: git branch --show-current coincide con la rama de características asignada.
3. Estado limpio: git status no muestra cambios sin commit de otro trabajo.
4. Alineación remota: git fetch && git status confirma que la rama sigue al remoto esperado.
5. Sin ediciones fuera de límite: No se modifica ningún archivo fuera del worktree (sin rutas ../, sin rutas absolutas fuera de la raíz del worktree).

Si alguna verificación falla, el agente DEBE abortar y reportar la discrepancia.

Guía de estado final

Cuando un ciclo de supervisión termina (con éxito o en el límite), el agente reporta:

• Estado del PR: Abierto / Listo para revisión / Bloqueado
• Conteo de correcciones: Número de commits de corrección de código enviados en este ciclo (p. ej., "2/3")
• Problemas residuales: Lista de fallos de CI no resueltos, comentarios de revisión o bloqueos
• Atribución del agente: Cada comentario y mensaje de commit del PR incluye identificación del agente

El agente NO DEBE afirmar que fusionó el PR. Si el PR aparece fusionado, el agente reporta "El PR fue fusionado por un humano" y se detiene.

Plantilla de prompt neutral para trabajador

Al generar un subagente trabajador, incluye estas instrucciones de seguridad en el prompt:

REGLAS DE SEGURIDAD (innegociables):
- NUNCA fusionar un PR ni invocar ninguna API/CLI de fusión
- NUNCA usar `git push --force` o `git push -f` sin opciones
- `git push --force-with-lease` está permitido solo para reordenar tu propia rama
- NUNCA editar archivos fuera de tu worktree asignado
- NUNCA hacer más de 3 commits de corrección de código por ciclo de supervisión
- Antes de editar, verificar: ruta del worktree, nombre de la rama, estado limpio
- Después de hacer push, responder con el SHA y la atribución del agente
- Al alcanzar el límite, reportar problemas residuales; no enviar más código

Capas de aplicación

Estas barreras de seguridad se aplican en múltiples capas:

1. Skill del agente (este archivo): Documentación portátil y plantillas de prompt. No es un límite de seguridad: los agentes pueden saltarlo si no están restringidos por la plataforma.
2. Orquestador Python: Aplicación de políticas a través del puente de subprocesos. Cuenta commits de corrección, valida rutas y bloquea comandos de la lista de denegación antes de que lleguen a Rust.
3. Núcleo Rust (wh-core): Aplicación estricta. Rechaza operaciones inseguras de git/GitHub en el límite del proceso. Esta es la capa de seguridad autorizada.

Defensa en profundidad: las tres capas aplican las mismas reglas. Una falla en una capa es detectada por otra.