Desarrollar un lector RSS desde cero con Spec Kit

Un proyecto nuevo significa que no hay comportamiento existente de la aplicación que preservar. No significa que no haya restricciones. Implementarás solo la gestión de suscripciones, no la recuperación remota de feeds ni un lector de producción.

Resumen del laboratorio

[!NOTE] El starter está intencionalmente incompleto; no sustituyas su contrato.

Conceptos · Primera tarea · Lista de evidencias · Restablecer

Objetivos de aprendizaje

• Separa gobernanza, requisitos de usuario, diseño técnico y ejecución.
• Usa la aclaración para resolver el comportamiento ante duplicados y entradas no válidas.
• Selecciona una pila frente al mismo contrato de aceptación.
• Valida una implementación generada con pruebas declaradas de antemano.

Antes de empezar

Completa la configuración de Spec Kit. Prepara 13-greenfield con la guía de la unidad de trabajo. Implementación predeterminada: módulos ES de Node 24, sin paquetes ni red. Se comparan TypeScript, .NET, Python y Go más abajo; ejecuta solo la pila elegida.

Conceptos y casos de uso

Escenario del ejercicio

Un lector selecciona suscripciones a feeds localmente. Puede añadir una URL HTTP(S) y listar suscripciones. Deben rechazarse los duplicados, las URL mal formadas y las credenciales incrustadas. La aplicación no debe recuperar la URL. Las URL bajo example.test son fixtures intencionales.

Tarea 1 - Revisar la intención de las partes interesadas y la línea base fallida

1. Lee StakeholderDocuments/ProjectGoals.md, AppFeatures.md y TechStack.md.

2. Inspecciona contract.test.mjs sin modificar sus aserciones.

3. Ejecuta:

   node --test --test-concurrency=1 contract.test.mjs
   

4. La función inacabada createStore debería fallar con el error documentado del ejercicio. Un error de sintaxis, una prueba ausente o la falta de Node no son el fallo esperado.

5. Registra RSS-1 a RSS-4 e identifica lo que queda deliberadamente fuera del contrato.

Tarea 2 - Inicializar y establecer principios

1. Registra el fixture intacto como una línea base local de Git.

2. Inicializa usando la disposición de skills documentada en la referencia de Spec Kit.

3. Invoca:

   /speckit-constitution Use StakeholderDocuments/ProjectGoals.md.
   Require local deterministic tests, no remote feed fetches or credentials,
   explicit errors, immutable returned records, and bounded changes.
   

4. Revisa .specify/memory/constitution.md. Los principios deben poder aplicarse.

5. No permitas que el flujo de la constitución implemente la aplicación ni reescriba las pruebas.

Tarea 3 - Especificar y aclarar

/speckit-specify Use StakeholderDocuments/AppFeatures.md.
Build only add/list subscription behavior. Assign stable IDs, reject normalized
duplicates, accept only HTTP(S) without userinfo, and never fetch a submitted URL.
Map requirements to the supplied acceptance tests.

Después usa /speckit-clarify para resolver estas preguntas:

• ¿Se normalizan los espacios en los extremos y los fragmentos de URL?
• ¿Los nombres de host de las URL no distinguen mayúsculas? ¿Qué ocurre con las mayúsculas de la ruta?
• ¿Las altas fallidas consumen IDs o modifican el estado?
• ¿Quien llama recibe copias modificables o registros internos activos?

El contrato proporcionado responde estas preguntas para la implementación predeterminada. Si una parte interesada cambia el contrato, registra la aprobación antes de modificar tanto la especificación como las pruebas.

Tarea 4 - Elegir una pila y planificar

Ejemplo para la vía predeterminada:

/speckit-plan Use Node 24 ES modules and the built-in test runner. Implement
subscriptions.mjs only. Use URL parsing, retain IDs and insertion order, return
copies, and add no dependencies, persistence, or HTTP calls.

Separa «pila diferente» de «requisitos diferentes». Una interfaz es opcional hasta que el contrato de dominio pase; necesita comprobaciones independientes de teclado y comportamiento de red.

Tarea 5 - Descomponer, implementar y converger

1. Ejecuta /speckit-tasks y después /speckit-analyze.
2. Asegúrate de que cada requisito RSS-1..4 tenga una tarea de implementación y una comprobación.
3. Ejecuta /speckit-implement para una parte revisada.
4. Vuelve a ejecutar tú mismo contract.test.mjs; inspecciona el diff completo.
5. Ejecuta /speckit-converge si está presente en la integración fijada. Verifica sus afirmaciones de forma independiente. Detente tras dos reparaciones sin éxito, no sigas en un ciclo ilimitado.
6. Haz deliberadamente que list() devuelva registros internos. Confirma que RSS-4 falle y después restaura el comportamiento correcto.

Verifica tu trabajo

• Se registran el resultado fallido inicial y el resultado final exitoso.
• Cada requisito RSS se vincula con especificación, plan, tarea y comprobación ejecutada.
• No se debilitó ninguna prueba para aceptar un comportamiento incorrecto.
• La validación de URL no realiza ninguna solicitud remota.
• Las adaptaciones a otras pilas se etiquetan como propuestas o ejecutadas.

Solución de problemas

Usa los nombres de skills generados, no comandos con puntos copiados de otra versión. No «repares» una prueba de URL no válida aceptando cadenas arbitrarias. Si el modelo añade una base de datos o un recuperador remoto, detente y vuelve a establecer los objetivos excluidos.

Práctica independiente

Implementa el mismo contrato en una segunda pila o añade la eliminación de suscripciones como una nueva especificación. Mantén una tabla de trazabilidad que muestre qué comprobaciones originales permanecen.

Restablecimiento

Guarda la evidencia de fallo y éxito. Restaura únicamente los cambios de implementación en la copia desechable o prepara una copia nueva. No ejecutes la inicialización de Specify en la raíz del contenido formativo.

Referencias oficiales

• Spec Kit v1.0.4
• Referencia de integraciones
• Flujo de la constitución
• Planificación de agentes