# Contexto del proyecto: Block de notas 
**Tipo:** 🧪 Experimental / Aprendizaje
**Etapa actual:** PC-2 — Funcionalidades por Valor

## Idea del proyecto
Un block de notas simple 

## Decisiones tomadas
**Idea traducida:**
Una aplicación web de captura de texto plano, sin formato, de carga mínima, accesible desde cualquier navegador, orientada a usuarios técnicos que necesitan registrar ideas o recordatorios efímeros sin la fricción de herramientas como Notion o Evernote. Su valor real es servir como sandbox de aprendizaje completo del stack FastAPI + Jinja2 + HTMX + SQLAlchemy + PostgreSQL + Redis.
**Problema:**
SÍ — La fricción de apps comerciales (Notion, Evernote) para captura rápida es un dolor documentado. Los workarounds actuales (WhatsApp consigo mismo, .txt locales) confirman que el problema existe aunque la solución no sea novedosa.
Solución diferenciada: PARCIAL — No innova en el producto; se diferencia en velocidad de carga (HTMX) y soberanía de datos. El valor diferencial real es el aprendizaje del stack, no el producto en sí.
Usuario definido: SÍ — Usuario técnico, familiarizado con herrami
**Usuarios:**
Tipo 1 (único): Desarrollador o usuario técnico, adulto, que trabaja frente a una pantalla, accede desde navegador de escritorio o móvil, y necesita capturar texto sin fricción en segundos. No requiere formato, colaboración ni sincronización con terceros. Valora la velocidad y el control sobre sus datos.
**Diferenciación:**
No compite con Notion ni Google Keep en funcionalidades — compite en velocidad y ausencia de fricción:
Carga y escritura en < 1 segundo — HTMX elimina la latencia de una SPA; autofocus activo desde el primer frame.
Autosave sin recarga — guardar no interrumpe el pensamiento; el usuario nunca presiona un botón.
Datos propios en PostgreSQL propio — sin ecosistemas cerrados, sin cuenta de terceros.
Cero formato, cero menús durante la escritura — la UI desaparece; solo existe el texto.
El diferencia
**Arquitectura seleccionada:**
Layered (sin DTOs)

## Outputs de etapas anteriores
### PC-0: Validación Rápida
Gracias por la claridad. Con estas respuestas, entiendo que el proyecto es un "Sandbox de Texto Plano": una excusa para implementar de punta a punta el stack definido, priorizando la velocidad de captura y la simplicidad absoluta.
​Aquí tienes la ejecución de la Sección 0.4 — Validación Rápida de Negocio (PC-0):
​📊 VIABILIDAD DE NEGOCIO: Block de Notas Simple
​Problema: La fricción y el tiempo de carga excesivo en apps de notas comerciales (Notion, Evernote) para capturar ideas rápidas o recordatorios efímeros que no necesitan formato.
Afecta a: Usuarios técnicos (como tú) que buscan una herramienta de "captura limpia" sin distracciones, accesible desde cualquier navegador.
Hoy lo resuelven: Abriendo un chat consigo mismos en WhatsApp/Telegram, usando archivos .txt locales o la app nativa de notas del móvil.
​PUNTOS FUERTES:
​Velocidad Extrema: Al usar HTMX, la interacción se siente instantánea, eliminando la carga de una SPA pesada.
​Soberanía de Datos: Al ser un proyecto de aprendizaje con PostgreSQL, tienes control total sobre dónde y cómo se guarda tu información.
​Curva de Aprendizaje Completa: Permite probar el ciclo de vida completo: desde la persistencia (SQLAlchemy) hasta el despliegue (GitHub Actions).
​PUNTOS DÉBILES:
​Saturación del Mercado: Es un producto con miles de alternativas gratuitas; el valor reside en el aprendizaje, no en la innovación del producto.
​Riesgo de Over-engineering: Usar Redis y PostgreSQL para texto plano puede ser excesivo si no se justifica con funciones de caché o búsqueda rápida.
​RECOMENDACIÓN: ✅ Vale la pena profundizar. Como proyecto experimental, es el "Hello World" perfecto para dominar el stack técnico propuesto sin que la lógica de negocio compleja te distraiga de la arquitectura.
​SUPUESTOS:
​SUPUESTO 1: Asumo que, aunque es "Uso personal", la app requiere un sistema de autenticación básico para que tus notas no sean públicas, dado que el stack incluye PostgreSQL.
​SUPUESTO 2: Asumo que el aprendizaje de Redis se enfocará en el almacenamiento de sesiones o como caché de lecturas para optimizar la velocidad, alineado con el objetivo "probar todo lo que se pueda".
​¿CONTINUAMOS CON LA ENTREVISTA COMPLETA?
[ X ] SÍ, profundicemos
[ ] NO, quiero ajustar la idea primero
​CONSEJO DEL DIRECTOR: Dado que quieres "probar todo", sugiero que en la siguiente fase nos enfoquemos en cómo hacer que esta app sea extremadamente rápida usando HTMX para guardado automático (autosave) sin recargar la página.
​✅ Respuesta registrada. Pega este output en el sistema FASE Director para continuar.

### PC-1: Entrevista de Descubrimiento
Tengo todo el contexto. Procedo con PC-1.
PC-1 — ENTREVISTA DE DESCUBRIMIENTO
Block de Notas Simple
📋 IDEA TRADUCIDA:
Una aplicación web de captura de texto plano, sin formato, de carga mínima, accesible desde cualquier navegador, orientada a usuarios técnicos que necesitan registrar ideas o recordatorios efímeros sin la fricción de herramientas como Notion o Evernote. Su valor real es servir como sandbox de aprendizaje completo del stack FastAPI + Jinja2 + HTMX + SQLAlchemy + PostgreSQL + Redis.
🎯 PROPÓSITO CENTRAL:
Implementar el stack técnico de punta a punta usando como excusa un block de notas de texto plano, ultra-rápido y sin distracciones.
📊 VALIDACIÓN DE NEGOCIO:
Problema real: SÍ — La fricción de apps comerciales (Notion, Evernote) para captura rápida es un dolor documentado. Los workarounds actuales (WhatsApp consigo mismo, .txt locales) confirman que el problema existe aunque la solución no sea novedosa.
Solución diferenciada: PARCIAL — No innova en el producto; se diferencia en velocidad de carga (HTMX) y soberanía de datos. El valor diferencial real es el aprendizaje del stack, no el producto en sí.
Usuario definido: SÍ — Usuario técnico, familiarizado con herramientas de desarrollo, que accede desde navegador y valora la velocidad sobre las funcionalidades.
Frecuencia de uso: ALTA — La captura de notas rápidas es un comportamiento diario o múltiples veces al día.
Valor percibido: MEDIO — Si no existe, el usuario regresa a WhatsApp/Telegram o .txt. El "dolor" es fricción, no bloqueo total.
🎨 DIFERENCIACIÓN:
Apps similares: Notion, Evernote, Google Keep, Apple Notes, Simplenote, Standard Notes
Lo que hacen ellas: Ricas en funcionalidades, markdown, etiquetas, colaboración, sincronización. Tiempo de carga notable. Registro obligatorio con ecosistemas cerrados.
Lo que hará diferente esta: Cero formato, cero distracciones, carga casi instantánea vía HTMX, datos propios en PostgreSQL propio.
Riesgo: BAJO de ser "una app más" — porque el objetivo declarado es el aprendizaje, no competir en el mercado.
👥 USUARIOS:
Tipo 1 (único): Desarrollador o usuario técnico, adulto, que trabaja frente a una pantalla, accede desde navegador de escritorio o móvil, y necesita capturar texto sin fricción en segundos. No requiere formato, colaboración ni sincronización con terceros. Valora la velocidad y el control sobre sus datos.
📊 EVALUACIÓN DE COMPLEJIDAD:
Complejidad inherente: BAJA — CRUD de texto plano con autenticación básica.
Enfoque recomendado: SIMPLE
Arquitectura seleccionada: Layered (sin DTOs)
Justificación: La lógica de negocio es mínima (crear, leer, editar, borrar notas de texto). Hexagonal sería over-engineering injustificado. DTOs añaden burocracia sin beneficio real en este dominio. Layered simple maximiza claridad y velocidad de implementación, alineado con el objetivo de aprendizaje.
🏢 MULTI-TENANCY:
Aplica: NO
Decisión: Single-tenant por defecto. El proyecto es de uso personal. Se implementa autenticación básica para proteger las notas (confirmado en SUPUESTO 1 de PC-0), pero no hay necesidad de aislar datos entre organizaciones o clientes distintos.
📋 COMPLIANCE:
Regulaciones aplicables: Ninguna — uso personal, sin datos de terceros, sin contexto médico ni financiero.
Datos sensibles identificados: Notas personales del usuario. Sin PII de terceros. Sin obligación GDPR activa dado que no es un servicio público con usuarios registrados externos.
🔮 SUPUESTOS DOCUMENTADOS:
Autenticación básica requerida — Decisión: Se implementa login simple (usuario/contraseña con sesión en Redis) — Por qué añade valor: Sin autenticación, las notas serían públicas en cualquier despliegue, lo que invalida el concepto de "soberanía de datos".
Redis = gestión de sesiones — Decisión: Redis no se usa para lógica de negocio, sino para almacenar sesiones de usuario — Por qué añade valor: Permite aprender Redis con un caso de uso real y justificado sin forzar caché donde no hace falta.
Texto plano únicamente — Decisión: Sin markdown, sin formato, sin etiquetas en v1 — Por qué añade valor: Mantiene la complejidad en mínimo histórico y enfoca el aprendizaje en la arquitectura, no en el renderizado de contenido.
Una nota activa por vez (interfaz tipo "bloc") — Decisión: La UI muestra un área de texto principal con lista de notas guardadas — Por qué añade valor: Refleja el modelo mental del usuario y simplifica el diseño de la interfaz HTMX.
⚠️ ESCENARIOS DE FALLA (solo los que afectan valor):
Autosave falla silenciosamente — Crítico: el usuario pierde texto sin saberlo, destruye la confianza en la herramienta — Protección: indicador de estado visible ("Guardando..." / "Guardado" / "Error") en cada operación HTMX.
Sesión expira sin aviso — Crítico: el usuario escribe y al guardar recibe un redirect al login, perdiendo el contenido — Protección: middleware que detecta sesión próxima a expirar y notifica antes de que ocurra.
📱 VIABILIDAD PWA:
VIABLE pero no prioritaria. La app es HTML estándar con HTMX; puede funcionar como PWA con un manifest básico y service worker mínimo. Para v1, no se implementa: el stack de aprendizaje ya es suficientemente denso. Se deja como extensión documentada.
🎨 UX PRIORITARIA:
Objetivo de velocidad: 1 click (o 0 — autofocus al cargar) para empezar a escribir una nota nueva.
Diferenciador UX: La página carga con el cursor ya en el área de texto. Guardado automático vía HTMX sin recargar. Sin modales, sin confirmaciones, sin menús de navegación visible durante la escritura. La lista de notas previas aparece en sidebar o debajo, sin interrumpir el foco.
📏 MÉTRICAS DE ÉXITO:
Métrica
Objetivo
Tiempo hasta poder escribir (desde URL)
< 1 segundo
Clicks para crear y guardar una nota
≤ 1 (autosave)
Cobertura de tests (pytest)
≥ 80% en capa de servicios
Pipeline CI/CD funcionando
100% — verde en cada push
Funcionalidades del stack ejercitadas
FastAPI + Jinja2 + HTMX + SQLAlchemy + PostgreSQL + Redis = 6/6
✅ PC-1 completado.
Si quieres continuar, pega este output en el sistema FASE Director para avanzar a la siguiente etapa.