theus-cli-linux-x64 1.2.2 → 1.4.0

package/vendor/theus-arsenal/commands/prp-planificar.md

@@ -1,501 +0,0 @@
----
-description: "Crea un plan de implementación exhaustivo con análisis del código base y extracción de patrones — parte de la serie PRP."
-argument-hint: "<descripción de la funcionalidad | ruta/al/documento.prd.md>"
----
-
-# PRP Planificar
-
-Parte de la serie de flujos PRP (planificar → implementar → commit).
-
-Crea un plan de implementación detallado y autocontenido que capture todos los patrones, convenciones y contexto del código base necesarios para implementar una funcionalidad en una sola pasada.
-
-**Filosofía central**: un buen plan contiene todo lo necesario para implementar sin hacer más preguntas. Cada patrón, cada convención, cada trampa — capturado una vez, referenciado siempre.
-
-**Regla de oro**: si durante la implementación necesitarías buscar algo en el código base, captura ese conocimiento AHORA en el plan.
-
----
-
-## Fase 0 — DETECTAR
-
-Determina el tipo de entrada a partir de `$ARGUMENTS`:
-
-| Patrón de entrada | Detección | Acción |
-|---|---|---|
-| Ruta que termina en `.prd.md` | Ruta a un PRD | Parsear el PRD, encontrar la siguiente fase pendiente |
-| Ruta a un `.md` con "Fases de implementación" | Documento tipo PRD | Parsear fases, encontrar la siguiente pendiente |
-| Ruta a cualquier otro archivo | Archivo de referencia | Leerlo como contexto, tratarlo como texto libre |
-| Texto libre | Descripción de funcionalidad | Pasar directo a la Fase 1 |
-| Vacío | Sin entrada | Preguntar al usuario qué funcionalidad planificar |
-
-### Parseo del PRD (cuando la entrada es un PRD)
-
-1. Lee el archivo del PRD con `cat "$RUTA_PRD"`
-2. Parsea la sección de **Fases de implementación**
-3. Localiza las fases por estado:
-   - Busca fases `pendiente`
-   - Revisa cadenas de dependencias (una fase puede depender de que otras estén `completa`)
-   - Selecciona la **siguiente fase pendiente elegible**
-4. Extrae de la fase seleccionada:
-   - Nombre y descripción de la fase
-   - Criterios de aceptación
-   - Dependencias de fases anteriores
-   - Notas de alcance o restricciones
-5. Usa la descripción de la fase como la funcionalidad a planificar
-
-Si no quedan fases pendientes, informa que todas las fases están completas.
-
----
-
-## Fase 1 — ANALIZAR
-
-Extrae y clarifica los requisitos de la funcionalidad.
-
-### Comprensión de la funcionalidad
-
-A partir de la entrada (fase del PRD o descripción libre), identifica:
-
-- **Qué** se construye (entregable concreto)
-- **Por qué** importa (valor para el usuario)
-- **Quién** lo usa (usuario/sistema objetivo)
-- **Dónde** encaja (qué parte del código base)
-
-### Historia de usuario
-
-Formatéala así:
-```
-Como [tipo de usuario],
-quiero [capacidad],
-para [beneficio].
-```
-
-### Evaluación de complejidad
-
-| Nivel | Indicadores | Alcance típico |
-|---|---|---|
-| **Pequeña** | Un solo archivo, cambio aislado, sin dependencias nuevas | 1-3 archivos, <100 líneas |
-| **Media** | Varios archivos, sigue patrones existentes, conceptos nuevos menores | 3-10 archivos, 100-500 líneas |
-| **Grande** | Aspectos transversales, patrones nuevos, integraciones externas | 10+ archivos, 500+ líneas |
-| **XL** | Cambios de arquitectura, subsistemas nuevos, migración necesaria | 20+ archivos, considerar dividirla |
-
-### Puerta de ambigüedad
-
-Si cualquiera de estos puntos no está claro, **DETENTE y pregunta al usuario** antes de continuar:
-
-- El entregable central es vago
-- Los criterios de éxito no están definidos
-- Hay varias interpretaciones válidas
-- El enfoque técnico tiene incógnitas mayores
-
-NO adivines. Pregunta. Un plan construido sobre suposiciones falla durante la implementación.
-
----
-
-## Fase 2 — EXPLORAR
-
-Recopila inteligencia profunda del código base. Busca directamente en el código para cada categoría siguiente.
-
-### Búsqueda en el código base (8 categorías)
-
-Para cada categoría, busca con grep, find y lectura de archivos:
-
-1. **Implementaciones similares** — Encuentra funcionalidades existentes parecidas a la planificada. Busca patrones, endpoints, componentes o módulos análogos.
-
-2. **Convenciones de nombres** — Identifica cómo se nombran archivos, funciones, variables, clases y exports en el área relevante del código.
-
-3. **Manejo de errores** — Encuentra cómo se capturan, propagan, registran y devuelven los errores en rutas de código similares.
-
-4. **Patrones de logging** — Identifica qué se registra, a qué nivel y en qué formato.
-
-5. **Definiciones de tipos** — Encuentra tipos, interfaces y esquemas relevantes, y cómo están organizados.
-
-6. **Patrones de tests** — Encuentra cómo se testean funcionalidades similares. Anota ubicación de archivos de test, nomenclatura, patrones de setup/teardown y estilos de aserciones.
-
-7. **Configuración** — Encuentra archivos de configuración, variables de entorno y feature flags relevantes.
-
-8. **Dependencias** — Identifica paquetes, imports y módulos internos usados por funcionalidades similares.
-
-### Análisis del código base (5 trazas)
-
-Lee los archivos relevantes para trazar:
-
-1. **Puntos de entrada** — ¿Cómo entra una petición/acción al sistema y llega al área que vas a modificar?
-2. **Flujo de datos** — ¿Cómo se mueven los datos por las rutas de código relevantes?
-3. **Cambios de estado** — ¿Qué estado se modifica y dónde?
-4. **Contratos** — ¿Qué interfaces, APIs o protocolos deben respetarse?
-5. **Patrones** — ¿Qué patrones de arquitectura se usan (repositorio, servicio, controlador, etc.)?
-
-### Tabla unificada de hallazgos
-
-Compila los hallazgos en una sola referencia:
-
-| Categoría | Archivo:Líneas | Patrón | Fragmento clave |
-|---|---|---|---|
-| Nombres | `src/services/userService.ts:1-5` | servicios camelCase, tipos PascalCase | `export class UserService` |
-| Errores | `src/middleware/errorHandler.ts:10-25` | Clase AppError propia | `throw new AppError(...)` |
-| ... | ... | ... | ... |
-
----
-
-## Fase 3 — INVESTIGAR
-
-Si la funcionalidad involucra bibliotecas externas, APIs o tecnología poco familiar:
-
-1. Busca en la web la documentación oficial
-2. Encuentra ejemplos de uso y buenas prácticas
-3. Identifica trampas específicas de versión
-
-Formatea cada hallazgo así:
-
-```
-HALLAZGO_CLAVE: [qué aprendiste]
-APLICA_A: [qué parte del plan afecta]
-TRAMPA: [advertencias o problemas específicos de versión]
-```
-
-Si la funcionalidad solo usa patrones internos bien conocidos, omite esta fase y anota: "No se necesitó investigación externa — la funcionalidad usa patrones internos establecidos."
-
----
-
-## Fase 4 — DISEÑAR
-
-### Transformación de UX (si aplica)
-
-Documenta la experiencia de usuario antes/después:
-
-**Antes:**
-```
-┌─────────────────────────────────┐
-│  [Experiencia de usuario actual]│
-│  Muestra el flujo actual,       │
-│  qué ve/hace el usuario         │
-└─────────────────────────────────┘
-```
-
-**Después:**
-```
-┌─────────────────────────────────┐
-│  [Nueva experiencia de usuario] │
-│  Muestra el flujo mejorado,     │
-│  qué cambia para el usuario     │
-└─────────────────────────────────┘
-```
-
-### Cambios de interacción
-
-| Punto de contacto | Antes | Después | Notas |
-|---|---|---|---|
-| ... | ... | ... | ... |
-
-Si la funcionalidad es puramente backend/interna sin cambio de UX, anota: "Cambio interno — sin transformación de UX visible para el usuario."
-
----
-
-## Fase 5 — ARQUITECTURA
-
-### Diseño estratégico
-
-Define el enfoque de implementación:
-
-- **Enfoque**: estrategia de alto nivel (p. ej., "Añadir una capa de servicio siguiendo el patrón repositorio existente")
-- **Alternativas consideradas**: qué otros enfoques se evaluaron y por qué se descartaron
-- **Alcance**: límites concretos de lo que SÍ se construirá
-- **NO se construye**: lista explícita de lo que queda FUERA DE ALCANCE (evita la expansión de alcance durante la implementación)
-
----
-
-## Fase 6 — GENERAR
-
-Escribe el documento del plan completo usando la plantilla de abajo. Guárdalo en `.theus/prp/planes/{nombre-en-kebab-case}.plan.md`.
-
-Crea el directorio si no existe:
-```bash
-mkdir -p .theus/prp/planes
-```
-
-### Plantilla del plan
-
-````markdown
-# Plan: [Nombre de la funcionalidad]
-
-## Resumen
-[Vista general en 2-3 frases]
-
-## Historia de usuario
-Como [usuario], quiero [capacidad], para [beneficio].
-
-## Problema → Solución
-[Estado actual] → [Estado deseado]
-
-## Metadatos
-- **Complejidad**: [Pequeña | Media | Grande | XL]
-- **PRD de origen**: [ruta o "N/A"]
-- **Fase del PRD**: [nombre de la fase o "N/A"]
-- **Archivos estimados**: [cantidad]
-
----
-
-## Diseño de UX
-
-### Antes
-[Diagrama ASCII o "N/A — cambio interno"]
-
-### Después
-[Diagrama ASCII o "N/A — cambio interno"]
-
-### Cambios de interacción
-| Punto de contacto | Antes | Después | Notas |
-|---|---|---|---|
-
----
-
-## Lectura obligatoria
-
-Archivos que DEBEN leerse antes de implementar:
-
-| Prioridad | Archivo | Líneas | Por qué |
-|---|---|---|---|
-| P0 (crítico) | `ruta/al/archivo` | 1-50 | Patrón central a seguir |
-| P1 (importante) | `ruta/al/archivo` | 10-30 | Tipos relacionados |
-| P2 (referencia) | `ruta/al/archivo` | todas | Implementación similar |
-
-## Documentación externa
-
-| Tema | Fuente | Conclusión clave |
-|---|---|---|
-| ... | ... | ... |
-
----
-
-## Patrones a imitar
-
-Patrones de código descubiertos en el código base. Síguelos al pie de la letra.
-
-### CONVENCION_NOMBRES
-// FUENTE: [archivo:líneas]
-[fragmento real de código que muestra el patrón de nombres]
-
-### MANEJO_ERRORES
-// FUENTE: [archivo:líneas]
-[fragmento real de código que muestra el manejo de errores]
-
-### PATRON_LOGGING
-// FUENTE: [archivo:líneas]
-[fragmento real de código que muestra el logging]
-
-### PATRON_REPOSITORIO
-// FUENTE: [archivo:líneas]
-[fragmento real de código que muestra el acceso a datos]
-
-### PATRON_SERVICIO
-// FUENTE: [archivo:líneas]
-[fragmento real de código que muestra la capa de servicio]
-
-### ESTRUCTURA_TESTS
-// FUENTE: [archivo:líneas]
-[fragmento real de código que muestra la preparación de tests]
-
----
-
-## Archivos a cambiar
-
-| Archivo | Acción | Justificación |
-|---|---|---|
-| `ruta/al/archivo.ts` | CREAR | Nuevo servicio para la funcionalidad |
-| `ruta/al/existente.ts` | ACTUALIZAR | Añadir método nuevo |
-
-## NO se construye
-
-- [Elemento explícito 1 fuera de alcance]
-- [Elemento explícito 2 fuera de alcance]
-
----
-
-## Tareas paso a paso
-
-### Tarea 1: [Nombre]
-- **ACCIÓN**: [qué hacer]
-- **IMPLEMENTAR**: [código/lógica específica a escribir]
-- **IMITAR**: [patrón de la sección "Patrones a imitar" a seguir]
-- **IMPORTS**: [imports necesarios]
-- **TRAMPA**: [escollo conocido a evitar]
-- **VALIDAR**: [cómo verificar que esta tarea es correcta]
-
-### Tarea 2: [Nombre]
-- **ACCIÓN**: ...
-- **IMPLEMENTAR**: ...
-- **IMITAR**: ...
-- **IMPORTS**: ...
-- **TRAMPA**: ...
-- **VALIDAR**: ...
-
-[Continuar con todas las tareas...]
-
----
-
-## Estrategia de testing
-
-### Tests unitarios
-
-| Test | Entrada | Salida esperada | ¿Caso límite? |
-|---|---|---|---|
-| ... | ... | ... | ... |
-
-### Checklist de casos límite
-- [ ] Entrada vacía
-- [ ] Entrada de tamaño máximo
-- [ ] Tipos inválidos
-- [ ] Acceso concurrente
-- [ ] Fallo de red (si aplica)
-- [ ] Permiso denegado
-
----
-
-## Comandos de validación
-
-### Análisis estático
-```bash
-# Ejecutar el verificador de tipos
-[comando de verificación de tipos del proyecto]
-```
-ESPERADO: cero errores de tipos
-
-### Tests unitarios
-```bash
-# Ejecutar los tests del área afectada
-[comando de tests del proyecto]
-```
-ESPERADO: todos los tests pasan
-
-### Suite completa de tests
-```bash
-# Ejecutar la suite completa
-[comando de suite completa del proyecto]
-```
-ESPERADO: sin regresiones
-
-### Validación de base de datos (si aplica)
-```bash
-# Verificar esquema/migraciones
-[comando de BD del proyecto]
-```
-ESPERADO: esquema al día
-
-### Validación en navegador (si aplica)
-```bash
-# Levantar el servidor de desarrollo y verificar
-[comando de servidor de desarrollo del proyecto]
-```
-ESPERADO: la funcionalidad opera según lo diseñado
-
-### Validación manual
-- [ ] [Checklist de verificación manual paso a paso]
-
----
-
-## Criterios de aceptación
-- [ ] Todas las tareas completadas
-- [ ] Todos los comandos de validación pasan
-- [ ] Tests escritos y en verde
-- [ ] Sin errores de tipos
-- [ ] Sin errores de lint
-- [ ] Coincide con el diseño de UX (si aplica)
-
-## Checklist de finalización
-- [ ] El código sigue los patrones descubiertos
-- [ ] El manejo de errores coincide con el estilo del código base
-- [ ] El logging sigue las convenciones del código base
-- [ ] Los tests siguen los patrones de tests
-- [ ] Sin valores hardcodeados
-- [ ] Documentación actualizada (si hace falta)
-- [ ] Sin ampliaciones de alcance innecesarias
-- [ ] Autocontenido — sin preguntas pendientes durante la implementación
-
-## Riesgos
-| Riesgo | Probabilidad | Impacto | Mitigación |
-|---|---|---|---|
-| ... | ... | ... | ... |
-
-## Notas
-[Contexto adicional, decisiones u observaciones]
-````
-
----
-
-## Salida
-
-### Guardar el plan
-
-Escribe el plan generado en:
-```
-.theus/prp/planes/{nombre-en-kebab-case}.plan.md
-```
-
-### Actualizar el PRD (si la entrada era un PRD)
-
-Si este plan se generó desde una fase de un PRD:
-1. Actualiza el estado de la fase de `pendiente` a `en-progreso`
-2. Añade la ruta del plan como referencia en la fase
-
-### Informe al usuario
-
-```
-## Plan creado
-
-- **Archivo**: .theus/prp/planes/{nombre-en-kebab-case}.plan.md
-- **PRD de origen**: [ruta o "N/A"]
-- **Fase**: [nombre de la fase o "independiente"]
-- **Complejidad**: [nivel]
-- **Alcance**: [N archivos, M tareas]
-- **Patrones clave**: [los 3 principales descubiertos]
-- **Investigación externa**: [temas investigados o "no fue necesaria"]
-- **Riesgos**: [riesgo principal o "ninguno identificado"]
-- **Puntuación de confianza**: [1-10] — probabilidad de implementación en una sola pasada
-
-> Siguiente paso: ejecuta `/prp-implementar .theus/prp/planes/{nombre}.plan.md` para ejecutar este plan.
-```
-
----
-
-## Verificación
-
-Antes de dar el plan por terminado, verifícalo contra estos checklists:
-
-### Completitud del contexto
-- [ ] Todos los archivos relevantes descubiertos y documentados
-- [ ] Convenciones de nombres capturadas con ejemplos
-- [ ] Patrones de manejo de errores documentados
-- [ ] Patrones de tests identificados
-- [ ] Dependencias listadas
-
-### Preparación para implementar
-- [ ] Cada tarea tiene ACCIÓN, IMPLEMENTAR, IMITAR y VALIDAR
-- [ ] Ninguna tarea requiere buscar más en el código base
-- [ ] Las rutas de import están especificadas
-- [ ] Las TRAMPAS documentadas donde aplique
-
-### Fidelidad a los patrones
-- [ ] Los fragmentos de código son ejemplos reales del código base (no inventados)
-- [ ] Las referencias FUENTE apuntan a archivos y líneas reales
-- [ ] Los patrones cubren nombres, errores, logging, acceso a datos y tests
-- [ ] El código nuevo será indistinguible del existente
-
-### Cobertura de validación
-- [ ] Comandos de análisis estático especificados
-- [ ] Comandos de tests especificados
-- [ ] Verificación de build incluida
-
-### Claridad de UX
-- [ ] Estados antes/después documentados (o marcados N/A)
-- [ ] Cambios de interacción listados
-- [ ] Casos límite de UX identificados
-
-### Prueba de "sin conocimiento previo"
-Un desarrollador que no conozca este código base debería poder implementar la funcionalidad usando SOLO este plan, sin buscar en el código ni hacer preguntas. Si no es así, añade el contexto que falta.
-
----
-
-## Siguientes pasos
-
-- Ejecuta `/prp-implementar <ruta-del-plan>` para ejecutar este plan
-- Ejecuta `/plan` para una planificación conversacional rápida sin artefactos
-- Ejecuta `/plan-prd` para crear primero un PRD si el alcance no está claro

package/vendor/theus-arsenal/commands/reanudar-sesion.md

@@ -1,160 +0,0 @@
----
-description: Carga el archivo de sesión más reciente de ~/.theus/arsenal/session-data/ y retoma el trabajo con todo el contexto desde donde terminó la sesión anterior.
----
-
-# Comando de reanudar sesión
-
-Carga el último estado de sesión guardado y oriéntate por completo antes de hacer cualquier trabajo.
-Este comando es la contraparte de `/guardar-sesion`.
-
-La resolución de archivos de sesión sigue la misma convención que la librería portada
-`${THEUS_PLUGIN_ROOT}/scripts/lib/session-manager.js` (directorio actual `~/.theus/arsenal/session-data/`
-con compatibilidad de lectura del directorio heredado `~/.theus/arsenal/sessions/`).
-
-## Cuándo usarlo
-
-- Al iniciar una sesión nueva para continuar el trabajo de un día anterior
-- Después de arrancar una sesión fresca por límites de contexto
-- Al recibir un archivo de sesión de otra fuente (basta con proporcionar la ruta del archivo)
-- Siempre que tengas un archivo de sesión y quieras que Theus lo absorba por completo antes de continuar
-
-## Uso
-
-```
-/reanudar-sesion                                                      # carga el archivo más reciente de ~/.theus/arsenal/session-data/
-/reanudar-sesion 2024-01-15                                           # carga la sesión más reciente de esa fecha
-/reanudar-sesion ~/.theus/arsenal/session-data/2024-01-15-abc123de-session.tmp  # carga un archivo de sesión actual con id corto
-/reanudar-sesion ~/.theus/arsenal/sessions/2024-01-15-session.tmp               # carga un archivo específico en formato heredado
-```
-
-## Proceso
-
-### Paso 1: Encontrar el archivo de sesión
-
-Si no se proporciona ningún argumento:
-
-1. Revisa `~/.theus/arsenal/session-data/`
-2. Elige el archivo `*-session.tmp` modificado más recientemente
-3. Si la carpeta no existe o no tiene archivos que coincidan, dile al usuario:
-   ```
-   No se encontraron archivos de sesión en ~/.theus/arsenal/session-data/
-   Ejecuta /guardar-sesion al final de una sesión para crear uno.
-   ```
-   Y detente.
-
-Si se proporciona un argumento:
-
-- Si parece una fecha (`YYYY-MM-DD`), busca primero en `~/.theus/arsenal/session-data/` y luego en el heredado
-  `~/.theus/arsenal/sessions/`, archivos que coincidan con `YYYY-MM-DD-session.tmp` (formato heredado) o
-  `YYYY-MM-DD-<idcorto>-session.tmp` (formato actual)
-  y carga la variante modificada más recientemente para esa fecha
-- Si parece una ruta de archivo, lee ese archivo directamente
-- Si no se encuentra, repórtalo con claridad y detente
-
-### Paso 2: Leer el archivo de sesión completo
-
-Lee el archivo íntegro. No resumas todavía.
-
-### Paso 3: Confirmar la comprensión
-
-Responde con un briefing estructurado exactamente en este formato:
-
-```
-SESIÓN CARGADA: [ruta real resuelta del archivo]
-════════════════════════════════════════════════
-
-PROYECTO: [nombre del proyecto / tema según el archivo]
-
-QUÉ ESTAMOS CONSTRUYENDO:
-[resumen de 2-3 frases con tus propias palabras]
-
-ESTADO ACTUAL:
-PASS: Funcionando: [cantidad] ítems confirmados
- En progreso: [lista de archivos en progreso]
- Sin empezar: [lista de lo planificado pero no tocado]
-
-QUÉ NO REINTENTAR:
-[lista de cada enfoque fallido con su razón — esto es crítico]
-
-PREGUNTAS ABIERTAS / BLOQUEOS:
-[lista de bloqueos o preguntas sin responder]
-
-SIGUIENTE PASO:
-[el siguiente paso exacto si está definido en el archivo]
-[si no está definido: "No hay siguiente paso definido — se recomienda revisar juntos 'Qué NO se ha intentado todavía' antes de empezar"]
-
-════════════════════════════════════════════════
-Listo para continuar. ¿Qué te gustaría hacer?
-```
-
-### Paso 4: Esperar al usuario
-
-NO empieces a trabajar automáticamente. NO toques ningún archivo. Espera a que el usuario diga qué hacer a continuación.
-
-Si el siguiente paso está claramente definido en el archivo de sesión y el usuario dice "continúa", "sí" o algo similar — procede con ese paso exacto.
-
-Si no hay un siguiente paso definido — pregunta al usuario por dónde empezar y, opcionalmente, sugiere un enfoque de la sección "Qué NO se ha intentado todavía".
-
----
-
-## Casos límite
-
-**Varias sesiones para la misma fecha** (`2024-01-15-session.tmp`, `2024-01-15-abc123de-session.tmp`):
-Carga el archivo coincidente modificado más recientemente para esa fecha, sin importar si usa el formato heredado sin id o el formato actual con id corto.
-
-**El archivo de sesión referencia archivos que ya no existen:**
-Señálalo durante el briefing — "ADVERTENCIA: `ruta/al/archivo.ts` referenciado en la sesión pero no encontrado en disco."
-
-**El archivo de sesión tiene más de 7 días:**
-Señala la brecha — "ADVERTENCIA: esta sesión es de hace N días (umbral: 7 días). Las cosas pueden haber cambiado." — y luego procede con normalidad.
-
-**El usuario proporciona una ruta de archivo directamente (p. ej., reenviada por un compañero):**
-Léela y sigue el mismo proceso de briefing — el formato es el mismo sin importar la fuente.
-
-**El archivo de sesión está vacío o malformado:**
-Reporta: "Se encontró el archivo de sesión pero parece vacío o ilegible. Puede que necesites crear uno nuevo con /guardar-sesion."
-
----
-
-## Salida de ejemplo
-
-```
-SESIÓN CARGADA: /Users/tu-usuario/.theus/arsenal/session-data/2024-01-15-abc123de-session.tmp
-════════════════════════════════════════════════
-
-PROYECTO: my-app — Autenticación con JWT
-
-QUÉ ESTAMOS CONSTRUYENDO:
-Autenticación de usuarios con tokens JWT almacenados en cookies httpOnly.
-Los endpoints de registro y login están parcialmente hechos. La protección
-de rutas vía middleware no se ha empezado todavía.
-
-ESTADO ACTUAL:
-PASS: Funcionando: 3 ítems (endpoint de registro, generación de JWT, hashing de contraseñas)
- En progreso: app/api/auth/login/route.ts (el token funciona, la cookie aún no se establece)
- Sin empezar: middleware.ts, app/login/page.tsx
-
-QUÉ NO REINTENTAR:
-FAIL: Next-Auth — entra en conflicto con el adaptador Prisma personalizado; lanzaba un error de adaptador en cada request
-FAIL: localStorage para el JWT — causa desajuste de hidratación en SSR, incompatible con Next.js
-
-PREGUNTAS ABIERTAS / BLOQUEOS:
-- ¿cookies().set() funciona dentro de un Route Handler o solo en Server Actions?
-
-SIGUIENTE PASO:
-En app/api/auth/login/route.ts — establecer el JWT como cookie httpOnly usando
-cookies().set('token', jwt, { httpOnly: true, secure: true, sameSite: 'strict' })
-y luego probar con Postman que la respuesta traiga la cabecera Set-Cookie.
-
-════════════════════════════════════════════════
-Listo para continuar. ¿Qué te gustaría hacer?
-```
-
----
-
-## Notas
-
-- Nunca modifiques el archivo de sesión al cargarlo — es un registro histórico de solo lectura
-- El formato del briefing es fijo — no omitas secciones aunque estén vacías
-- "Qué no reintentar" debe mostrarse siempre, aunque solo diga "Ninguno" — es demasiado importante como para pasarlo por alto
-- Tras reanudar, el usuario puede querer ejecutar `/guardar-sesion` de nuevo al final de la nueva sesión para crear un nuevo archivo con fecha