Extra CRúbrica de evaluación — cómo saber si lo estás haciendo bien

Cómo usar esta rúbrica

Para cada entregable, lee los criterios y asígnate una puntuación:

• ✅ Cumplido — El criterio está claramente satisfecho
• ⚠️ Parcial — Está pero le falta profundidad o precisión
• ❌ No cumplido — Falta o está mal

Rúbrica M1 — Primera spec

Criterio 1: El bloque CONTEXTO describe el sistema real

• ✅ Bien: "Proyecto gowy.es — Next.js 14, Supabase. Página /subastas/page.tsx que muestra listado sin filtros"
• ⚠️ Parcial: "Es un proyecto web de subastas"
• ❌ Mal: Está vacío o dice "ya lo sé"

Criterio 2: El COMPORTAMIENTO ESPERADO describe acciones concretas

• ✅ Bien: "Al hacer click en 'Activas', el listado muestra solo subastas con estado=activa. Si no hay ninguna, muestra 'No hay subastas activas'"
• ⚠️ Parcial: "Que filtre por estado"
• ❌ Mal: "Que funcione bien" / "Que sea intuitivo"

Criterio 3: Las RESTRICCIONES son explícitas

• ✅ Bien: "No usar librerías externas. El filtrado es en cliente, sin nueva query. Usar el componente Button de /components/ui/"
• ⚠️ Parcial: "Que sea rápido y no use cosas raras"
• ❌ Mal: Bloque vacío

Criterio 4: Los CRITERIOS DE VALIDACIÓN son verificables

• ✅ Bien: "Dado click en 'Activas' → solo aparecen subastas con estado=activa / Dado 0 subastas activas → aparece texto 'No hay subastas activas'"
• ⚠️ Parcial: "Que los filtros funcionen"
• ❌ Mal: "Que se vea bien" / bloque vacío

Puntuación mínima para avanzar al M2: 3 criterios ✅, ninguno ❌

Rúbrica M2 — Spec completa de 9 bloques

Criterio 1: Título con verbo de acción

• ✅ Bien: "Implementar filtro por estado en listado de subastas"
• ⚠️ Parcial: "Filtro de subastas"
• ❌ Mal: "Subastas" / "Feature nueva"

Criterio 2: OBJETIVO diferenciado del comportamiento

• ✅ Bien: "Permitir al usuario reducir el ruido visual del listado y encontrar subastas de su interés más rápido"
• ⚠️ Parcial: "Para que el usuario pueda filtrar"
• ❌ Mal: Es una copia del COMPORTAMIENTO ESPERADO

Criterio 3: COMPORTAMIENTO cubre todos los estados

• ✅ Bien: Describe happy path + estado de error + estado vacío + estado de carga (si aplica)
• ⚠️ Parcial: Describe solo el happy path
• ❌ Mal: Una sola frase sin estados

Criterio 4: CASOS LÍMITE son situaciones no obvias

• ✅ Bien: "Si el usuario hace doble click en submit antes de recibir respuesta / Si llega con ?estado=INVALIDO en la URL"
• ⚠️ Parcial: "Si no hay datos" (es obvio, no es edge case)
• ❌ Mal: Bloque vacío o copiado de COMPORTAMIENTO

Criterio 5: CRITERIOS DE VALIDACIÓN siguen formato "Dado X → resultado Y"

• ✅ Bien: "Dado click en 'Activas' → listado muestra solo subastas con estado=activa / Dado 0 subastas activas → texto 'No hay subastas activas' visible"
• ⚠️ Parcial: "Los filtros funcionan correctamente"
• ❌ Mal: Subjetivos o no verificables

Criterio 6: FUERA DE ALCANCE delimita el trabajo

• ✅ Bien: "No incluye filtro por categoría (pendiente). No incluye persistencia del filtro en localStorage."
• ⚠️ Parcial: "No sé qué poner aquí"
• ❌ Mal: Bloque vacío

Puntuación mínima para avanzar al M3: 5 criterios ✅, ninguno ❌

Rúbrica M3 — Configuración del entorno

Criterio 1: CLAUDE.md describe el stack con tecnologías concretas

• ✅ Bien: "Next.js 14, App Router, TypeScript, Tailwind, Supabase (PostgreSQL), Vercel"
• ⚠️ Parcial: "Es un proyecto web moderno con base de datos"
• ❌ Mal: Stack no especificado

Criterio 2: CLAUDE.md menciona archivos o carpetas concretas

• ✅ Bien: "/app → páginas App Router / /lib → lógica de negocio / /types → TypeScript interfaces"
• ⚠️ Parcial: "Tiene una carpeta para componentes"
• ❌ Mal: No menciona estructura de carpetas

Criterio 3: CLAUDE.md tiene al menos 3 convenciones explícitas

• ✅ Bien: "kebab-case para archivos / PascalCase para componentes / comentarios en español / no usar any"
• ⚠️ Parcial: "Código limpio y ordenado"
• ❌ Mal: Sección vacía o genérica

Criterio 4: La estructura ai/ está creada con las subcarpetas correctas

• ✅ Bien: ai/specs/pendientes + en-progreso + completadas + ai/decisiones + ai/plantillas
• ⚠️ Parcial: Existe ai/ pero sin subcarpetas
• ❌ Mal: No existe ai/

Criterio 5: La spec del M2 está en ai/specs/en-progreso/

• ✅ Bien: Archivo con nombre descriptivo en la carpeta correcta
• ⚠️ Parcial: Está en ai/ pero sin subcarpeta correcta
• ❌ Mal: No está en el proyecto

Puntuación mínima para avanzar al M4: 4 criterios ✅, ninguno ❌

Rúbrica M4 — Ciclo completo

Criterio 1: La spec se entregó a la IA completa y antes de implementar

• ✅ Bien: El log documenta que se entregó la spec y se esperó confirmación antes de implementar
• ⚠️ Parcial: Se entregó parcialmente o sin esperar confirmación
• ❌ Mal: Se implementó directamente sin spec completa

Criterio 2: La IA confirmó el plan antes de implementar

• ✅ Bien: El log incluye el párrafo de confirmación de la IA
• ⚠️ Parcial: La IA dijo algo pero no fue un plan detallado
• ❌ Mal: No hubo confirmación previa

Criterio 3: Se detectó y documentó al menos una desviación (o se confirma que no hubo ninguna)

• ✅ Bien: "La IA intentó añadir paginación (no estaba en la spec). La reconduces con el bloque FUERA DE ALCANCE" / "No hubo desviaciones. La IA siguió la spec sin apartarse."
• ⚠️ Parcial: Se detectó pero no se documentó cómo se recondujo
• ❌ Mal: No hay log de la sesión

Criterio 4: La validación se hizo criterio por criterio

• ✅ Bien: Lista de criterios con ✅/❌ y notas para cada uno
• ⚠️ Parcial: "Todo funciona" sin verificar criterio por criterio
• ❌ Mal: No hay registro de validación

Criterio 5: Los criterios que fallaron se corrigieron reconduciendo a la IA

• ✅ Bien: "Criterio 3 falló. Le dije a la IA: 'La spec dice X. Corrígelo.' Lo corrigió correctamente."
• ⚠️ Parcial: Se arregló pero directamente en el código
• ❌ Mal: No se corrigió o se editó el código sin involucrar la spec

Puntuación mínima para avanzar al M5: 4 criterios ✅, ninguno ❌

Rúbrica M5 — Árbol de specs

Criterio 1: La System Spec tiene propósito, actores y módulos definidos

• ✅ Bien: Propósito en 2-3 frases concretas + lista de actores con su rol + módulos con responsabilidad de cada uno
• ⚠️ Parcial: Tiene propósito pero no actores o módulos
• ❌ Mal: Es una descripción genérica sin estructura

Criterio 2: Los contratos entre módulos están definidos

• ✅ Bien: "Scraper → DB: solo INSERT, nunca UPDATE / API ← Web: solo lectura"
• ⚠️ Parcial: Hay mención de cómo se comunican pero sin especificar el contrato
• ❌ Mal: Sección vacía

Criterio 3: Las invariantes del sistema están listadas

• ✅ Bien: Al menos 3 invariantes concretas ("nunca duplicar subastas", "usuario no autenticado no ve datos privados")
• ⚠️ Parcial: 1 invariante o son demasiado genéricas
• ❌ Mal: Sección vacía

Criterio 4: Las dependencias entre features están documentadas

• ✅ Bien: Cada feature con su lista de "depende de" y "bloquea a"
• ⚠️ Parcial: Hay alguna dependencia pero no todas
• ❌ Mal: No hay mención de dependencias

Criterio 5: Las Feature Specs de las 2 prioritarias tienen los 9 bloques completos

• ✅ Bien: 9 bloques rellenos con profundidad equivalente al M2
• ⚠️ Parcial: Algunos bloques están vacíos o son genéricos
• ❌ Mal: Solo hay una Feature Spec o están incompletas

Puntuación mínima para avanzar al M6: 4 criterios ✅, ninguno ❌

Rúbrica M6 — SDD Playbook

Criterio 1: La definición de SDD está en palabras propias

• ✅ Bien: Suena a ti, no a un manual. Usa referencias a tu contexto real.
• ⚠️ Parcial: Mezcla definición del curso con algo propio
• ❌ Mal: Es una copia literal del M1

Criterio 2: El flujo diario es concreto y ejecutable

• ✅ Bien: Describe acciones específicas con herramientas concretas ("Abro el chat de Copilot con Ctrl+Shift+P, pego el CLAUDE.md, luego la spec...")
• ⚠️ Parcial: Describe el flujo de forma abstracta
• ❌ Mal: Es un resumen del M4 sin adaptación al contexto propio

Criterio 3: Las reglas personales vienen de la experiencia del curso

• ✅ Bien: Cada regla tiene detrás una situación real vivida durante el curso
• ⚠️ Parcial: Las reglas suenan bien pero son genéricas
• ❌ Mal: Son las del curso reformateadas como "mis reglas"

Criterio 4: Los anti-patterns son reconocimientos honestos del comportamiento anterior

• ✅ Bien: "Antes abría Copilot y le decía 'hazme un botón de login'. Eso es vibe coding y lo he hecho 50 veces."
• ⚠️ Parcial: Son anti-patterns genéricos no vinculados a la experiencia propia
• ❌ Mal: No hay anti-patterns o son teóricos

Criterio 5: El Playbook diferencia el contexto corporativo del personal

• ✅ Bien: Sección separada para cada contexto con las adaptaciones concretas (herramienta, archivo de contexto, flujo de puente Gmail)
• ⚠️ Parcial: Menciona los dos contextos pero sin diferenciación real
• ❌ Mal: Un solo flujo genérico para todo

Puntuación para completar el curso: 4 criterios ✅, ninguno ❌

Tabla de progreso general

Usa esta tabla para trackear dónde estás:

Actualiza esta tabla conforme avanzas. Cuando un módulo pase revisión, cambia ⏳ por ✅.

Nota final

La rúbrica es una herramienta de honestidad, no de presión.

Si un criterio está en ⚠️ y lo sabes, corrígelo antes de compartir. Si crees que algo está bien y la revisión dice que no, debátelo — puede que tengas razón o puede que haya algo que no has visto todavía. Ambas opciones son válidas.

Lo que no funciona: avanzar con ❌ sin corregir. El método se aprende haciendo, no leyendo.