Kenshō

El problema

Preparar algo largo no se parece a hacer una tarea

Una oposición dura años, no semanas. Los gestores de tareas corrientes fallan ahí por diseño: están pensados para cerrar cosas, y una preparación larga no se cierra — se sostiene. Kenshō nace de esa distancia. Es un gestor y planificador de estudio que reparte un temario entre los días que realmente tienes, programa los repasos donde deben caer y registra qué ocurrió de verdad cada día.

La vertical de entrada son las oposiciones, porque es donde el problema aprieta más y donde el temario ya viene estructurado. Pero nada del motor está atado a ellas: sirve igual para una certificación, un idioma o una carrera.

La decisión central

Los repasos mandan sobre el temario nuevo

Cuando cierras la última tarjeta de una unidad, el planificador programa cuatro refuerzos por delante. Si uno vence, ese día se estudia el refuerzo, no la unidad siguiente: el avance se desplaza un día. Es incómodo y es deliberado — consolidar tiene prioridad sobre abrir temario nuevo, y un plan que no lo respeta acaba siendo un plan que se abandona en marzo.

Cómo se reparte el temario

Un día es una ranura, no un presupuesto de minutos

Nada se mide en minutos para decidir si algo cabe. Un día lectivo es una ranura, la ranura es una sesión y la sesión es una tarjeta copiada de tu método. Medir en minutos invita a fragmentar la sesión y perder el foco, así que los minutos declarados por día quedan como referencia informativa junto a cada tarjeta — nunca como límite de capacidad.

Cualquier excepción puntual manda sobre el patrón semanal, en las dos direcciones: puedes abrir un domingo normalmente rojo como día adaptado, o cerrar un miércoles lectivo por un festivo.

Lo que ya funciona

Cuatro paneles en una rejilla configurable

Esta es la única vista operativa hoy, y la que fija el engranaje del resto: una rejilla donde cada panel monta el módulo que elijas. Estructura y Método están estables; Planificador y Registro, en beta.

Tablero de módulos

Cuatro construidos, seis declarados

Los módulos en reserva ya existen en el registro con su ficha: aparecen en el lateral, se pueden seleccionar y explican qué harán. Declarar antes de construir mantiene honesto el mapa del producto y obliga a que el contrato aguante lo que viene.

El contrato

Cuatro reglas que sostienen todo lo demás

Este MVP no busca parecer un producto terminado: busca fijar el engranaje modular antes de escribir una línea de servidor. Un módulo se añade creando su archivo y registrándolo. Nada más. Si hiciera falta tocar el núcleo para meter un módulo, el contrato estaría mal y habría que arreglarlo entonces, no después.

1. Un módulo nunca importa a otro módulo. Solo el bus de eventos y el store. Sí puede importar librerías puras: no son módulos, no tienen estado propio.
2. Un módulo nunca toca el DOM fuera del elemento que le entregan.
3. Un módulo nunca hace fetch por su cuenta. Declara lo que necesita y lo lee del store.
4. Las suscripciones se dan de baja solas al desmontar el módulo.

El algoritmo de planificación vive fuera del módulo, como función pura sin DOM, sin store y sin bus: se prueba en Node sin abrir el navegador. Cambiar de estrategia no toca una línea del panel — la alternativa secuencial, sin repasos, viene incluida para que puedas comparar con tus propios datos en vez de con una promesa.

Cuando Estructura o Método cambian después de generar un plan, el panel no lo reemplaza solo: muestra la lista exacta de qué cambió y espera confirmación. Es literal a la metáfora de git status — describir, nunca actuar por su cuenta.

Por qué el método viene etiquetado

Cada paso lleva su nivel de evidencia

El método por defecto usa solo pasos de evidencia alta y media: recuperación activa, repaso espaciado y registro de errores. Subrayar y releer están en el catálogo, disponibles, pero marcados como evidencia baja. No se esconden ni se prohíben — se señalan, y tú decides.

La misma disciplina rige el registro: el sistema no marca nada por su cuenta. Un día que pasa no convierte una tarjeta en saltada; la deja vencida y visible, esperando a que digas qué ocurrió. Automatizar esa decisión sería fabricar datos falsos sobre tu propio esfuerzo, y son exactamente esos datos los que después deben alimentar la replanificación.

Por eso la racha la rompe una tarjeta saltada, no un día sin tarjeta: descansar cuando estaba previsto descansar no es fallar. Y la cobertura del temario solo cuenta avance, nunca repasos, porque repasar no es avanzar.

Resumen

Ficha técnica