Añadir una función a un panel existente con Spec Kit

Un proyecto existente tiene comportamiento, consumidores, pruebas y convenciones. Una nueva función debe integrarse con esas restricciones en lugar de regenerar el proyecto.

Resumen del laboratorio

[!NOTE] Un actor de prueba de confianza es una costura, no autenticación de producción.

Conceptos · Primera tarea · Lista de evidencias · Restablecer

Objetivos de aprendizaje

• Caracteriza los endpoints y contratos de módulos existentes antes de inicializar la estructura.
• Especifica una función como un cambio acotado.
• Mantén la identidad separada de los campos proporcionados por el modelo o la solicitud.
• Verifica juntos el comportamiento antiguo y el nuevo.

Antes de empezar

Completa la preparación de Spec Kit. Prepara 14-brownfield usando la guía de la unidad de trabajo. Este módulo de panel incluido sustituye la importación obligatoria de un repositorio externo. No se necesitan LocalDB, cambios en cuentas de la nube, cargas binarias ni un repositorio público.

Conceptos y casos de uso

Escenario del ejercicio

El panel ya lista un proyecto de formación. Añade títulos e IDs de documentos limitados al actor actual del fixture. Las cargas reales de archivos, el análisis de malware, el almacenamiento externo y la autenticación real de usuarios son explícitamente trabajo separado.

Tarea 1 - Ejecutar los contratos antiguo y nuevo por separado

node --test --test-concurrency=1 baseline.test.mjs
node --test --test-concurrency=1 feature.test.mjs

1. Confirma que la línea base pase.
2. Confirma que las pruebas de la función fallen porque no está implementada.
3. Registra los mensajes y códigos de salida exactos.
4. Lee requirements.md; relaciona DOC-1..4 con las pruebas e identifica el conocimiento que falta.

Tarea 2 - Adoptar Spec Kit sin reemplazar la aplicación

1. Crea un commit de referencia en el proyecto desechable.
2. Inspecciona .github, .specify y los archivos del editor antes de specify init --here.
3. Revisa todos los cambios de la estructura inicial y conserva las instrucciones propias del proyecto.
4. Crea una constitución que preserve DOC-1 y prohíba modernizaciones ajenas al alcance.

No uses --force como sustituto de la resolución de conflictos.

Tarea 3 - Especificar el cambio y aclarar la propiedad

/speckit-specify Add document metadata to the existing dashboard in requirements.md.
Preserve health/projects exactly. Derive ownerId from a trusted actor supplied by
the application boundary, not from document input. Reject missing project/title,
overlong title, missing actor and owner spoofing. No file upload.

Usa /speckit-clarify para responder:

• ¿Quién establece el actor en producción?
• ¿Cuál es la longitud máxima del título?
• ¿Una adición fallida deja estado parcial?
• ¿Puede otro actor listar estos registros?

El actor inyectado del fixture es un punto de aislamiento para pruebas, no evidencia de autenticación de producción.

Tarea 4 - Planificar con puntos de control de compatibilidad

Usa /speckit-plan para exigir:

1. health y projects existentes sin cambios.
2. Nuevo almacenamiento y validación de metadatos limitados al módulo.
3. Listado limitado al propietario con copias defensivas.
4. Ejecución conjunta de pruebas de referencia y de la función.
5. Propagación explícita de errores, sin un propietario alternativo silencioso.

Para .NET, propón una adaptación con controlador y servicio autenticados; para TypeScript, añade tipos explícitos de entrada y salida. Ambas deben preservar DOC-1..4. No afirmes que esos adaptadores se ejecutaron salvo que implementes y ejecutes sus pruebas.

Tarea 5 - Implementar y evaluar el cambio

1. Ejecuta /speckit-tasks y /speckit-analyze.

2. Revisa las correspondencias con las pruebas antiguas y nuevas.

3. Implementa una parte y después ejecuta:

   node --test --test-concurrency=1 baseline.test.mjs feature.test.mjs
   

4. Inspecciona el diff completo, no solo el nuevo método.

5. Elimina temporalmente el filtrado por propietario. Confirma que la prueba entre actores falle y después restáuralo.

6. Usa /speckit-converge como ayuda para la revisión, no como evidencia de que se ejecutaron las pruebas.

Verifica tu trabajo

• Las pruebas antiguas siguen pasando junto con la nueva función.
• La propiedad procede del límite confiable.
• El actor incorrecto, el propietario suplantado y las entradas no válidas se rechazan o aíslan.
• La función no introduce cargas binarias ni nuevos servicios de red.
• El punto de control de compatibilidad está representado en la especificación, las tareas y las pruebas ejecutadas.

Solución de problemas

Si el código generado reescribe todo el panel, detente y compara con la línea base. Si las pruebas solo pasan individualmente, inspecciona el estado compartido. Si se lee una cadena «owner» desde la entrada del usuario, eso no es autorización.

Práctica independiente

Especifica una función separada de carga binaria con límites de tamaño, validación de contenido, propiedad del almacenamiento, gestión de malware y política de eliminación. Mantenla como ejercicio de diseño hasta que existan sus propios fixtures y pruebas.

Restablecimiento

Guarda la evidencia y después restaura únicamente dashboard.mjs en la copia desechable. Mantén intactos el contenido formativo y el material original; no elimines ramas ni cuentas compartidas.

Referencias oficiales

• Instalación y adopción de Spec Kit
• Integración de Spec Kit
• Autorización de ASP.NET Core