CONTINUAR / GUÍA 03
'Sigue con lo de ayer'. Pero con contexto.
Cómo retomar una tarea días después: qué recuperan los specs, los ADRs y la memoria — consultas reales con sus respuestas citadas.
La continuidad no debería depender de que el modelo recuerde una conversación de forma imprecisa. Veamos qué pasa, consulta a consulta, cuando escribes:
«sigue con lo de reembolsos y revisa qué queda pendiente»
El spec dice dónde quedó el trabajo
El sistema consulta la memoria estructural (DuckDB) en lugar de reconstruir el contexto de memoria:
- specs/f1 → CERRADA, con su evidencia: 42/42 · arquitectura verde · webhook replay idempotente.
- specs/f2 (reembolsos) → PENDIENTE, con sus criterios ya escritos.
Nadie tiene que acordarse de nada: el estado es un hecho consultable. La nueva tarea arranca con alcance, criterios y exclusiones ya heredados.
Los ADRs evitan re-decidir lo decidido
Antes de diseñar los reembolsos, el scout busca decisiones previas sobre pagos y recupera:
ADR-0004 — Pasarela: Stripe (contexto: coste, soporte de webhooks, ya decidido en f1). Reutilizar.
Si existiera un ADR sobre reembolsos parciales, aparecería aquí igual. Y si una decisión antigua ya no vale, no se «corrige»: se escribe un ADR NUEVO que la sustituye y explica por qué — el historial de decisiones queda íntegro.
La memoria semántica responde con citas
El builder de f2 duda: «¿cómo hicimos los reintentos del adapter?». No adivina: busca en la biblioteca (palabras + significado, en local) y recupera. Una lección REAL capturada del sistema (2026-10-29, tarea rag-vector-bridge):
«urllib.request.urlopen FOLLOWS 3xx redirects — a loopback-only HTTP adapter contract MUST install a no-redirect opener or a 302 silently exfiltrates query text+auth off-machine (auditor F1)»
Técnica + consecuencia + quién la encontró, con su fuente. (La lección «JobLock» que ilustra el documento de diseño sigue el mismo formato; esta de arriba está grabada de verdad.)
La respuesta llega CITADA: fichero y origen. Si no lo encuentra, lo dice — no rellena el hueco con una invención plausible.
Qué NO prueba un resultado de búsqueda
Regla práctica del sistema: un fragmento sobre reembolsos NO demuestra que los reembolsos estén hechos. El estado lo dice el spec; la búsqueda solo aporta conocimiento. Al revés tampoco: el spec te dice QUE se hizo, no CÓMO — para el cómo está la biblioteca.
Retomar bien: checklist
- Confirma el alcance heredado (¿los FUERA DE ALCANCE siguen valiendo?).
- Revisa los supuestos abiertos de la tarea anterior (¿siguen sin validar?).
- Comprueba qué criterios del spec pendiente ya tienen evidencia.
- Y termina igual que siempre: la evidencia se graba, el spec se cierra, el push es tuyo.