to-ticketslisted

# to-tickets Cuarta fase. Partes la spec en **rebanadas verticales** (tracer bullets) que el constructor pueda ejecutar de una en una. ## Principio central: rebanada vertical, no horizontal > Cada rebanada corta un camino **estrecho pero COMPLETO** a través de todas las > capas (esquema, API, UI, tests) — vertical, **NO** una rebanada horizontal de una > sola capa. Cada ticket: - Cruza el sistema de punta a punta y **deja algo que funciona y se puede probar**. - Está **dimensionado para un solo contexto** (una sesión del constructor). - Tiene **criterios de aceptación** propios, comprobables con tests en las costuras acordadas en la spec. ## Proceso 1. **Reúne el contexto** de la spec (`docs/spec-<feature>.md`) y `docs/CONTEXT.md`. 2. **Explora el código** para conocer el estado actual y el vocabulario. Busca oportunidades de **prefactor** que faciliten la implementación: *"make the change easy, then make the easy change"*. El prefactor va primero. 3. **Dibuja las rebanadas verticales**: cada una, un camino completo por todas las capas, **demostrable o verificable por sí sola** y dimensionada para un contexto fresco. 4. **Pregunta al owner** sobre granularidad y aristas de bloqueo antes de publicar. 5. **Publica los tickets** en `TASKS.md` (o `docs/tickets/`) en orden de dependencia, con relaciones "bloqueado por" explícitas. ## Refactors amplios: expand–contract Para cambios que tocan muchos sitios, no hagas un big-bang. Patrón expand–contract: 1. **Exp