formal-you/agent-skills-suite — Implementación de Tareas (Dev)

Dev — Implementación de Tareas

Implementa un paquete de tareas y entrégalo a QA. Este skill define el proceso y lleva sus propios límites de rol en references/role-boundaries.md. Si el repositorio adoptante define reglas para agentes (AGENTS.md, un directorio de reglas de rol o equivalente), léelas y síguelas cuando estén presentes; el skill nunca otorga acceso extra.

Úsalo cuando

• Una tarea bajo tasks/<task-id>/ tiene un 01-contract.md completado y eres el rol Dev.
• Necesitas implementar una porción vertical, ejecutar sus comandos DoD, registrar evidencia y entregar.
• Estás retrabajando una tarea después de que QA emitió REWORK_REQUIRED.

No lo uses cuando

• El contrato falta, está incompleto o en disputa — devuélvelo al Planificador.
• Se te pide planificar, dividir o revisar tareas, o verificar el trabajo de otro agente.
• El cambio solicitado está fuera de los touch_files del contrato — escala o divide la tarea.

Entradas

• tasks/<task-id>/01-contract.md — frontmatter YAML autoritativo, touch_files, dod, Sección 4 escenarios BDD (invariantes Given-When-Then) y ADRs heredados.
• Anclas de especificación referenciadas por el contrato.
• Comandos del proyecto para verificación de tipos y lint, la suite de pruebas existente y el objetivo de aceptación propiedad de QA declarado en dod.test_file.
• tasks/<task-id>/02-dev-workspace.md — el formulario en blanco que llenas.

Salidas

• Cambios de código solo para las rutas listadas en touch_files.
• Código que cumple con los invariantes BDD y los límites de complejidad ciclomática ($V(G) \le 10$ estándar, advertencia $11-15$ justificada en 02, crítico $> 15$ prohibido).
• Un 02-dev-workspace.md completado con metadatos, cambios reales, autoverificación y la tabla de Desviaciones de implementación (filas DEV-001, DEV-002, ... o una fila explícita "Ninguna").
• Exactamente un marcador de entrega: - [x] WAITING_FOR_QA, marcado solo cuando cada elemento de la DoD pasa.
• Sin ediciones en 01-contract.md, 03-qa-verification.md, 04-process.md ni tests/acceptance/**.

Flujo de trabajo

1. Confirmar alcance y contrato BDD. Lee el frontmatter de 01-contract.md y la Sección 4 de escenarios BDD. Verifica que task_id coincida con el nombre del directorio, y que touch_files, dod, adherence_adrs y los invariantes Given-When-Then estén definidos. Reporta elementos faltantes o contradictorios al Planificador.
2. Preparar el trabajo. Anota el commit base y cumple con las convenciones de rama/commit del proyecto. No reabras una tarea ya aceptada a menos que un revisor la reabra.
3. Implementar porción vertical bajo BDD y límites de complejidad. Cambia solo los archivos en touch_files. Implementa la lógica que cumple los invariantes Given-When-Then declarados en la Sección 4 y dod.edge_cases. Controla la complejidad ciclomática de funciones individuales ($V(G) \le 10$ estándar). Si la complejidad se acerca al límite de advertencia ($11-15$), aplica patrones de refactorización (Método Extraído, Estrategia / Tabla de Búsqueda, Cláusulas Guarda). Si $V(G) > 15$, refactoriza antes de continuar. No edites ni crees tests/acceptance/**.
4. Ejecutar DoD automatizable y autoverificación. Ejecuta dod.type_check y dod.lint, luego ejecuta las pruebas existentes del proyecto; considera cada elemento de dod.edge_cases. Realiza una autoverificación de complejidad ciclomática en todas las funciones tocadas. El objetivo de aceptación (dod.test_file) es propiedad de QA: ejecútalo solo si ya existe, nunca lo crees ni edites. Si aún no existe, regístralo en 02 y deja que QA lo ejecute durante la verificación. Captura comandos/resultados.
5. Llenar 02-dev-workspace.md. Registra la rama, el commit base/entrega, notas de diseño, una fila por cada archivo realmente cambiado, conteo neto de líneas, y marca cada elemento de autoverificación que sea verdadero. Incluye justificación arquitectónica explícita para cualquier función con complejidad de advertencia ($11 \le V(G) \le 15$). Deja los elementos sin marcar si no pasaron. Completa la tabla de Desviaciones de implementación: una fila por cada lugar donde el código difiere del contrato o especificación (DEV-001, DEV-002, ...; operación add | modify | remove; un ancla #sec-*), o escribe "Ninguna" en cada celda cuando no hubo desviaciones.
6. Entregar a QA. Solo cuando cada elemento de autoverificación pase y los límites de complejidad estén satisfechos, cambia - [ ] WAITING_FOR_QA a - [x] WAITING_FOR_QA. Esa única casilla marcada es el disparador de entrega. No edites 03 o 04.
7. En caso de rework. Lee los rastros de fallo de QA en 03-qa-verification.md, corrige solo dentro del contrato, vuelve a ejecutar la DoD, actualiza 02 para el nuevo intento y entrega nuevamente. Escala fallos repetidos en lugar de eludir el contrato.

Puerta de calidad (antes de declarar terminado)

• Cada ruta modificada está listada en 01-contract.md → touch_files.
• No se creó ni modificó ningún archivo fuera del radio de acción.
• La implementación respeta todos los escenarios BDD Given-When-Then y los invariantes de comportamiento.
• La verificación de tipos y el lint finalizan exitosamente; las pruebas existentes del proyecto pasan.
• La autoverificación de complejidad ciclomática pasa: todas las funciones cumplen $V(G) \le 10$ (o $11-15$ con justificación en 02); ninguna excede $V(G) > 15$.
• El objetivo de aceptación propiedad de QA (dod.test_file) está declarado; si aún no está creado, eso se registra para QA.
• Cada elemento de dod.edge_cases tiene una justificación de implementación/prueba.
• 02-dev-workspace.md está completo para este intento, incluida la tabla de Desviaciones de implementación (fila explícita "Ninguna" cuando no hubo desviaciones).
• Solo WAITING_FOR_QA está marcado; 03 y 04 no han sido tocados.

Manejo de fallos

• Contrato faltante o contradictorio: detente; informa el campo y pide al Planificador que lo corrija.
• Cambio fuera de alcance necesario: divide la tarea o escala; nunca edites fuera de touch_files.
• Comando DoD faltante o no ejecutable: repórtalo con el comando y el error; no ignores la verificación.
• DoD falla: corrige la implementación y vuelve a ejecutar. No marques la casilla de entrega mientras un cheque falle.
• Complejidad supera el umbral ($V(G) > 15$): refactoriza usando Método Extraído, Estrategia / Tabla de Búsqueda, Cláusulas Guarda o patrones de Estado antes de la entrega; nunca entregues complejidad crítica.
• Herramientas no disponibles: usa los comandos manuales del proyecto y registra evidencia en 02; el flujo de trabajo no debe depender de herramientas opcionales.

04-process.md y herramientas

04-process.md es una salida derivada. Después de marcar la casilla de entrega, si el repositorio cuenta con herramientas opcionales, estas añaden HANDOFF_QA_REQUESTED y actualizan macro_status/current_lock_holder. Nunca edites 04 manualmente; sin herramientas, confía en git/CI y la casilla marcada.

Después de QA_PASSED: propiedad de la escritura de vuelta a la especificación

La tabla de Desviaciones de implementación es el último entregable del Dev para la tarea. Después de que QA registra QA_PASSED, el skill converge es el dueño de la escritura de vuelta a la especificación: fusiona las desviaciones confirmadas en .specs/02-tech-spec.md, archiva el paquete de tarea y cierra la propuesta de cambio.

• El Dev nunca edita .specs/02-tech-spec.md y nunca archiva el paquete.
• Una desviación estructural (nuevo componente, límite cambiado, nueva decisión a nivel ADR) se escala al Planificador/spec-generator en lugar de convergerse silenciosamente.
• Si QA solicita rework, actualiza la tabla de desviaciones para el nuevo intento; no redactes prosa de especificación por adelantado.

Referencias

• references/dev-protocol.md — listas de verificación detalladas, verificación de alcance, límites de complejidad ciclomática de McCabe, patrones de refactorización, procedimiento de entrega y rework.
• Límites de rol: references/role-boundaries.md — alcance de escritura, alcance de solo lectura, invariantes y el modelo de cumplimiento honesto (incluido; no se necesitan archivos externos).
• Reglas del repositorio: lee AGENTS.md y cualquier archivo de reglas de rol cuando el proyecto adoptante las defina; pueden agregar requisitos pero no son necesarios para que este skill funcione.
• Formato del paquete de tarea: skill task-decomposition (hermano opcional; este skill solo consume sus artefactos).

Límites honestos

Este skill no otorga acceso de escritura y no puede hacer cumplir el aislamiento de roles. Donde el repositorio tenga CI (por ejemplo, una auditoría de roles basada en git) o protección de ramas, esa es la capa autoritativa. El contrato, no este documento, define el radio de acción permitido.