Surtidito — dos paneles tipo Inoreader con hnterm como eje de diseño

Fecha: 2026-09-14 · Decisiones de diseño, no implementación (aún)

Idea

Sustituir el lector modal / la lista a todo lo ancho por el layout clásico de lector RSS:

• Izquierda: lista de fuentes (medios), al estilo del panel de suscripciones de Inoreader/Feedly.
• Derecha: el texto de la noticia + la salida anónima (→ original), siempre presente.
• Eje visual/interacción: HNTerm (hnterm.ggerganov.com) — terminal HN de ggerganov, ImTui/ncurses, dividido en ventanas, keyboard-first, índice numérico, monocromo fósforo.

Qué es realmente hnterm (y qué robarle)

• Dos ventanas siempre visibles: lista/índice a la izquierda, contenido a la derecha. Nada de modales.
• Keyboard-first y browse por índice, pero el port web es a la vez clickeable → convive teclado + ratón.
• Rinde solo lo visible (virtualización) → snappy aunque la lista sea larga.
• Estética de fósforo monocromo, grid de caracteres, líneas de box-drawing, status bar inferior.
• Aviso explícito de su autor: “not suitable for mobile devices”. Un terminal real no es táctil.

Esto importa: el eje no es “poner un terminal”, es la gramática de dos ventanas + índice + status sin modales. La identidad AmberConsole ya es 90% compatible; falta la estructura de paneles.

Beneficios

Del lado lector (panel derecho + salida anónima)

1. El core se vuelve arquitectura, no un botón. “Surtidito es puente, no destino”: el split hace visible de forma permanente que estás en la previa y el origen está a la derecha. Hoy la salida vive en el overlay (modal) → se lee con miedo de perder el lugar.
2. Continuidad de tarea. Leer → salir anónimo → volver con back y seguir en el mismo item. Sin re-navegación, sin re-abrir el overlay, sin scroll perdido.
3. Menos cambio de contexto. El overlay fuerza: abrir → leer → cerrar → mover → abrir… El split deja el contexto de “dónde estoy en la lista” siempre visible.
4. Ancho completo para el texto y memoria de scroll por artículo sin afectar la lista.

Del lado fuentes (panel izquierdo)

5. Leer “de quién” de un vistazo. Las categorías actuales (MX/TECH/INTL/OTROS) son auto-guess por regex sobre palabras; la fuente es metadata limpia: 129 medios reales (Aristegui fuera → Quinto Elemento Lab, etc. ya limpiado).
6. Filtro por medio = mínimo esfuerzo, sin ingestión nueva. El dato (description→medio) ya existe en reporte/feed-todo.rss.xml. “Mostrar solo WIRED hoy” o “solo reporte indigo” sale con un filtro, no con scraping nuevo.
7. Anti-burbuja explícita. La burbuja se decide por canal, no por categoría; ver “qué está cubriendo cada medio” hace consciente el sesgo. Encaja con el índice de credibilidad (que ya existe por medio).
8. Anatomía conocida. Inoreader/Feedly/Reeder = cero aprendizaje para el usuario que viene de un lector RSS.

Era de lo que ya existe (cuesta poco)

• El split desktop ya está construido (activarSplit con tecla 2, grid 420px/998px, reader inline). No es feature nueva, es cambiarlo a default.
• El móvil ya es la versión correcta del mismo diseño: tap → lector full-bleed (100dvh) + ✕ cerrar + salida anónima. En <719px el split está medido y no aplica — exactamente como hnterm avisa que un terminal no cabe en móvil.
• La virtualización/cap ya existe (80 items en móvil).

Restricciones honestas

• 129 fuentes en un panel lateral no caben sin jerarquía. Necesita árbol por clúster (MX/TECH/CHINA-R&D/…) o top-N por volumen con búsqueda incremental. 26 categorías ya existen para agrupar.
• Móvil = 1 panel. El “derecho” en móvil es el lector full-bleed; el “izquierdo” (fuentes) debe ser alcanzable desde el lector: botón de fuente en el pie para saltar a su filtro.
• Tacto vs teclado: el split desktop debe seguir soportando j/k/enter (como hnterm) pero el tap en la lista debe abrir el article en el panel derecho (hoy tap en desktop solo selecciona y pide tecla 2).

Plan mínimo propuesto (scope down)

1. Desktop: split por defecto. En vez de list-mode al cargar, arrancar en split (body.split activo), tap/click abre en el panel derecho. 1/2 siguen existiendo para alternar.
2. Panel izquierdo = índice de lectura (items) y barra de fuentes arriba del split (chips por medio, como los tabs de MODO, o un <select> con 129 medios). Decidir 2-paneles vs 3-paneles:
   • 2 paneles: fuentes en el panel izquierdo, texto a la derecha (simplificación pura).
   • 3 paneles (Inoreader real): izquierda fuentes / centro items / derecha texto.
3. Verificación Playwright igual que el pase mobile-first (sin pageerror, overflow 0, split 420/998).

Pendiente de decisión

Ruta A (2 paneles: fuentes|texto) vs Ruta B (3 paneles: fuentes|items|texto). Ruta B es Inoreader literal (más pipeline visual, más jank si 129 fuentes), Ruta A es hnterm literal (índice + contenido) y más barata. Recomendación: A en MVP, guardar B como evolución.