Plan de trabajo priorizado #29

New Issue

jkuijperm · 2026-07-28T14:55:59Z

jkuijperm commented

2026-07-28 14:55:59 +00:00

Plan de trabajo priorizado — expenses_manager

Junta las dos fuentes: las mejoras de producto (recorrido vista por vista,
archivos 01–10) y el análisis técnico/visual de Code (ANALISIS_code.md).
Organizado en tandas, no por áreas sueltas: cada tanda agrupa cosas que se tocan
juntas, para no abrir la misma vista dos veces.

El orden es una recomendación, no una obligación. La decisión de producto es del
propietario; lo técnico va anotado con el criterio de por qué sí o por qué no.

Tanda 0 — Arreglos rápidos y documentación (bajo esfuerzo, hacer ya) ✅ COMPLETADA

Cosas de bajo riesgo y alta relación coste/beneficio. Ninguna toca la lógica de
negocio de forma peligrosa.

Bug: income_confirm_delete.html mostraba {{ expense.date }} en vez de
{{ income.date }} (fecha vacía en la confirmación). — ya corregido
Memoizar Goal.progress() con cached_property (Code 2.2). Hoy se
recalcula 3-5 veces por objetivo en cada render de home/dashboard/objetivos.
Cambio pequeño, riesgo casi nulo, quita muchas queries. El mejor coste/beneficio
de todo el informe. (Hecho: progress pasó a cached_property; llamadas internas
en percentage()/is_exceeded() ajustadas a self.progress sin paréntesis; tests
actualizados y en verde. Sin migración.)
Actualizar CLAUDE.md (Code 3.1): además de los 3 puntos de Code, se puso al
día todo lo cambiado estas sesiones (Goal con kind/periodos/cached_property,
soft-delete de cuentas, CRUD de categorías y prevención de ciclos, fuel_delete,
/finance-accounts/, settings unificado por env, convención de nombres de plantillas,
workflow dev/main).
Reescribir README.md (Code 3.2): reescrito de cero, fiel al proyecto real
(conda + SQLite en local, tabla de variables de entorno, Dockerfile documentado y
docker-compose.yml de ejemplo sin secretos — el real vive fuera del repo en el NAS).
Crear .env.example (Code 3.8): añadido al repo con todas las variables como
plantilla (placeholders inútiles, sin secretos).
Limpieza trivial (Code 2.9, 3.9): eliminado el import muerto de models.py,
el comentario obsoleto de sourcery en views.py y unificadas las comillas en
GoalForm.Meta.fields.

Tanda 1 — Responsive / usarlo en el móvil (alto valor personal) ✅ COMPLETADA

Motivo de prioridad: el objetivo declarado es "poder usarlo más desde el móvil", y
hoy no se puede porque no está adaptado. Esto es lo que desbloquea ese uso.

Meta viewport en base.html y base_auth.html (Code 1.1) — una línea,
cambia radicalmente cómo se ve en móvil. (Hecho; de paso se corrigió el <!DOCTYPE>
incompleto de base.html y se añadió lang="es".)
Envolver tablas anchas en overflow-x:auto (gastos, comparación del
dashboard, fuel con 7 columnas) para que no desborden. (Hecho: las 8 tablas del
proyecto envueltas en .table-wrap con white-space:nowrap, se ensanchan según
contenido sin anchos fijos arbitrarios.)
Media queries básicas en base.css para los breakpoints principales.
(Hecho: breakpoints 768px y 480px; grids —kpi/dashboard/goals/settings— a 1 columna
en móvil.)

Extras que salieron al probar en móvil y se resolvieron en la misma tanda:

Gráficos de Chart.js responsive: el bug era CSS (una .chart-box de altura
fija envolvía título + canvas y desbordaba). Corregido en dashboard.html y
home.html (título fuera de la caja, canvas en contenedor de altura controlada).
Menú hamburguesa (primer JS del proyecto, expenses/static/expenses/js/nav.js):
botón ☰ bajo 768px que despliega la nav; vanilla JS solo para el toggle, con
aria-expanded. En escritorio no cambia nada.
Dropdown "Configuraciones" plegable por click (amplía nav.js): pasó de
:hover a click en escritorio y móvil, con cierre al pulsar fuera. El toggle es un
<button> real con aria-haspopup/aria-controls y foco por teclado — esto
adelanta el punto 1.4 de la Tanda 3 (dropdown accesible por teclado).
"Quitar filtros temporales" movido a su propia línea bajo los presets del
dashboard (ya no se parte/solapa en móvil).

Tanda 2 — Coherencia visual (base para que todo se vea igual)

Lo que hace que la app deje de verse "un poco fea/inconsistente" (queja explícita).

Variables CSS de color (Code 1.3): definir :root { --color-success… --color-danger… } y sustituir los 3-4 tonos distintos de verde/rojo repartidos
por base.css y los style="..." inline de dashboard.html. Base para todo lo
visual posterior. (Hecho: paleta Forest Teal aplicada con variables semánticas
(--color-bg/--color-surface/--color-text/--color-primary...), pensadas para
soportar dos modos. Hex dispersos e inline sustituidos por variables.)
Botones unificados (parte de 1.2/1.7): clases .btn/.btn-primary/
.btn-secondary/.btn-danger coherentes; los "Volver"/"Cancelar" que eran enlaces
morados pasan a botón real con misma altura y separación; aplicado en formularios y
confirmaciones. (Resuelve lo que se detectó al probar la Tanda 1 en móvil.)
Modo oscuro (extra añadido en esta tanda): segundo juego de valores bajo
[data-theme="dark"], sigue la preferencia del sistema por defecto, botón sol/luna
en la topbar para forzar, elección recordada en localStorage, con script inline
anti-flash en el <head>. Login incluido.
Unificar plantillas de confirmación de borrado (Code 1.2): las 7 son casi
idénticas pero divergen en botón/clase/encabezado. Unificar en un {% include %}
con variables. De paso previene bugs como el de income_confirm_delete.
Clases CSS referenciadas que no existen (Code 1.7): .pagination,
.form-errors, .form-field, etc. — revisar si la paginación y los errores de
formulario se están viendo sin estilo.
Jerarquía de encabezados (Code 1.9) y patrones UI iguales para datos
iguales (Code 1.8: tag_list usa <ul>, categories usa <table>).

Tanda 3 — Accesibilidad (bajo esfuerzo, se hace junto con lo visual)

Dropdown "Configuraciones" accesible por teclado (Code 1.4): hoy es
:hover puro, sin toggle por teclado → un usuario de teclado no puede llegar a
Categorías/Etiquetas/Objetivos. Es una ruta bloqueada, no solo "buena práctica".
(Ya resuelto en la Tanda 1: el toggle pasó a <button> con click + Enter/Espacio
y aria-expanded.)
Labels en selects de filtro (Code 1.5) y ARIA en barras de progreso
(Code 1.6). Bajo esfuerzo, se hace en el mismo pase que la Tanda 2.

Tanda 4 — Home (producto + técnico juntos)

Ver 01_home.md. Al tocar el home, aprovechar para lo técnico de esa vista.

Saldo total + desglose por cuenta.
Banner de avisos (presupuesto excedido, cuenta en negativo).
Comparativa gasto mes actual vs anterior.
Últimos movimientos.
Técnico asociado: reutilizar current_balance()/is_exceeded() ya memoizados
(Tanda 0).

Tanda 5 — Listado de gastos (la pieza de filtrado)

Ver 02_listado_gastos.md. Es la tanda más grande de producto.

Filtrado instantáneo sin recargar (introduce el primer JS de entidad).
Total de lo filtrado, ordenar por columna, exportar CSV/Excel, rango de fechas.
Técnico asociado: al reescribir la vista para responder JSON/fragmento, resolver
de paso la query duplicada de Tag (Code 2.7) y añadir select_related/
prefetch_related (Code 2.5).
Ver 09_transversales.md: el rango de fechas y el mecanismo dinámico deben
diseñarse pensando en reutilizarlos en el dashboard.

Tanda 6 — Dashboard (producto + el N+1)

Ver 03_dashboard.md. Es la vista más usada para análisis y la que más se
beneficia de tocar producto y rendimiento a la vez.

Tarta por categorías, desglose por subcategorías al pinchar, presupuestos
integrados, rango de fechas, ingresos vs gastos.
Técnico asociado (importante hacerlo en la misma pasada):
- N+1 de saldos por cuenta (Code 2.1): ~40 queries con 5 cuentas.
- Refactor de la función dashboard (Code 3.4): 226 líneas, 5
  responsabilidades, contexto de 35 claves. Extraer en _resolve_period,
  _build_comparison, _build_account_charts.
- El desglose por subcategorías reutiliza el mecanismo dinámico de la Tanda 5.

Tanda 7 — Vistas de gestión (cuentas, categorías, etiquetas, objetivos)

Ver 04–07. Producto de bajo/medio esfuerzo, se pueden repartir.

Cuentas: saldo en listado (🟢), marcar principal (🟡), reordenar (🔴, migración).
Categorías: árbol jerárquico (🟡), nº de gastos (🟢). Considerar separar
category_create del listado (Code 2.6) si se toca la vista.
Etiquetas: contador de uso (🟢), fusionar etiquetas (🔴, transacción).
Objetivos: filtrar por tipo (🟢), histórico (🟡). Añadir docstring a
Goal.progress()/_period_start() (Code 3.5) al tocar el modelo.

Tanda 8 — Módulo de vehículos (módulo nuevo grande)

Ver 08_repostajes_vehiculos.md. Es prácticamente un módulo nuevo; abordar entero,
no a trozos sueltos. Orden interno sugerido en su propio archivo.

Tanda 9 — Módulo de inversiones / patrimonio (el más grande)

Ver 10_modulo_inversiones.md. La evolución de mayor alcance. Empezar por registro
manual de los cuatro tipos; precios automáticos como capa posterior (cripto primero).
La Idea A (clasificar gasto fijo/variable) es independiente y puede ir en cualquier
momento.

Refactors grandes — decididos NO hacer por ahora

Anotados a conciencia como "no hacer salvo que duela de verdad":

Migrar a class-based views (Code 2.3): reduciría ~300-400 líneas, pero toca
20+ vistas que hoy funcionan y están cubiertas por tests. Riesgo/beneficio no
compensa en un proyecto personal. Dejar salvo reescritura por otro motivo.
Partir views.py en un paquete views/ (Code 3.3): más razonable que lo
anterior (es mover funciones, bajo riesgo) pero no urge. Hacerlo el día que el
archivo estorbe de verdad al trabajar, y de forma incremental.
Reorganizar carpetas de plantillas (Code 2.8): puramente cosmético. Solo si
se hace a la vez que otra reestructuración.

Deuda ya conocida (de la fase anterior, no del análisis de Code)

Jenkins: build de la imagen Docker en CI + despliegue automático desde main.
Preparado, pendiente de ejecutar cuando se quiera (ver TODO_revision.md).
gunicorn en requirements pero no en el venv (Code 3.6): mismo patrón que
whitenoise. Revisar todas las dependencias dev vs producción de una vez.
Comentarios en dos idiomas (Code 3.7): fijar convención (español en
comentarios, inglés en identificadores, que es lo mayoritario) y aplicarla a
partir de ahora sin reescribir lo viejo.

# Plan de trabajo priorizado — expenses_manager Junta las dos fuentes: las mejoras de **producto** (recorrido vista por vista, archivos `01`–`10`) y el **análisis técnico/visual de Code** (`ANALISIS_code.md`). Organizado en tandas, no por áreas sueltas: cada tanda agrupa cosas que se tocan juntas, para no abrir la misma vista dos veces. El orden es una recomendación, no una obligación. La decisión de producto es del propietario; lo técnico va anotado con el criterio de por qué sí o por qué no. --- ## Tanda 0 — Arreglos rápidos y documentación (bajo esfuerzo, hacer ya) ✅ COMPLETADA Cosas de bajo riesgo y alta relación coste/beneficio. Ninguna toca la lógica de negocio de forma peligrosa. - [x] **Bug**: `income_confirm_delete.html` mostraba `{{ expense.date }}` en vez de `{{ income.date }}` (fecha vacía en la confirmación). — *ya corregido* - [x] **Memoizar `Goal.progress()`** con `cached_property` (Code 2.2). Hoy se recalcula 3-5 veces por objetivo en cada render de home/dashboard/objetivos. Cambio pequeño, riesgo casi nulo, quita muchas queries. **El mejor coste/beneficio de todo el informe.** *(Hecho: `progress` pasó a `cached_property`; llamadas internas en `percentage()`/`is_exceeded()` ajustadas a `self.progress` sin paréntesis; tests actualizados y en verde. Sin migración.)* - [x] **Actualizar `CLAUDE.md`** (Code 3.1): además de los 3 puntos de Code, se puso al día todo lo cambiado estas sesiones (Goal con `kind`/periodos/`cached_property`, soft-delete de cuentas, CRUD de categorías y prevención de ciclos, `fuel_delete`, `/finance-accounts/`, settings unificado por env, convención de nombres de plantillas, workflow dev/main). - [x] **Reescribir `README.md`** (Code 3.2): reescrito de cero, fiel al proyecto real (conda + SQLite en local, tabla de variables de entorno, Dockerfile documentado y `docker-compose.yml` de ejemplo sin secretos — el real vive fuera del repo en el NAS). - [x] **Crear `.env.example`** (Code 3.8): añadido al repo con todas las variables como plantilla (placeholders inútiles, sin secretos). - [x] **Limpieza trivial** (Code 2.9, 3.9): eliminado el import muerto de `models.py`, el comentario obsoleto de sourcery en `views.py` y unificadas las comillas en `GoalForm.Meta.fields`. --- ## Tanda 1 — Responsive / usarlo en el móvil (alto valor personal) ✅ COMPLETADA Motivo de prioridad: el objetivo declarado es "poder usarlo más desde el móvil", y hoy no se puede porque no está adaptado. Esto es lo que desbloquea ese uso. - [x] **Meta viewport** en `base.html` y `base_auth.html` (Code 1.1) — una línea, cambia radicalmente cómo se ve en móvil. *(Hecho; de paso se corrigió el `<!DOCTYPE>` incompleto de `base.html` y se añadió `lang="es"`.)* - [x] **Envolver tablas anchas** en `overflow-x:auto` (gastos, comparación del dashboard, fuel con 7 columnas) para que no desborden. *(Hecho: las 8 tablas del proyecto envueltas en `.table-wrap` con `white-space:nowrap`, se ensanchan según contenido sin anchos fijos arbitrarios.)* - [x] **Media queries** básicas en `base.css` para los breakpoints principales. *(Hecho: breakpoints 768px y 480px; grids —kpi/dashboard/goals/settings— a 1 columna en móvil.)* **Extras que salieron al probar en móvil y se resolvieron en la misma tanda:** - [x] **Gráficos de Chart.js responsive**: el bug era CSS (una `.chart-box` de altura fija envolvía título + canvas y desbordaba). Corregido en `dashboard.html` y `home.html` (título fuera de la caja, canvas en contenedor de altura controlada). - [x] **Menú hamburguesa** (primer JS del proyecto, `expenses/static/expenses/js/nav.js`): botón ☰ bajo 768px que despliega la nav; vanilla JS solo para el toggle, con `aria-expanded`. En escritorio no cambia nada. - [x] **Dropdown "Configuraciones" plegable por click** (amplía `nav.js`): pasó de `:hover` a click en escritorio y móvil, con cierre al pulsar fuera. El toggle es un `<button>` real con `aria-haspopup`/`aria-controls` y foco por teclado — **esto adelanta el punto 1.4 de la Tanda 3** (dropdown accesible por teclado). - [x] **"Quitar filtros temporales"** movido a su propia línea bajo los presets del dashboard (ya no se parte/solapa en móvil). --- ## Tanda 2 — Coherencia visual (base para que todo se vea igual) Lo que hace que la app deje de verse "un poco fea/inconsistente" (queja explícita). - [x] **Variables CSS de color** (Code 1.3): definir `:root { --color-success… --color-danger… }` y sustituir los 3-4 tonos distintos de verde/rojo repartidos por `base.css` y los `style="..."` inline de `dashboard.html`. Base para todo lo visual posterior. *(Hecho: paleta **Forest Teal** aplicada con variables semánticas (`--color-bg`/`--color-surface`/`--color-text`/`--color-primary`...), pensadas para soportar dos modos. Hex dispersos e inline sustituidos por variables.)* - [x] **Botones unificados** (parte de 1.2/1.7): clases `.btn`/`.btn-primary`/ `.btn-secondary`/`.btn-danger` coherentes; los "Volver"/"Cancelar" que eran enlaces morados pasan a botón real con misma altura y separación; aplicado en formularios y confirmaciones. *(Resuelve lo que se detectó al probar la Tanda 1 en móvil.)* - [x] **Modo oscuro** (extra añadido en esta tanda): segundo juego de valores bajo `[data-theme="dark"]`, sigue la preferencia del sistema por defecto, botón sol/luna en la topbar para forzar, elección recordada en `localStorage`, con script inline anti-flash en el `<head>`. Login incluido. - [ ] **Unificar plantillas de confirmación de borrado** (Code 1.2): las 7 son casi idénticas pero divergen en botón/clase/encabezado. Unificar en un `{% include %}` con variables. De paso previene bugs como el de `income_confirm_delete`. - [ ] **Clases CSS referenciadas que no existen** (Code 1.7): `.pagination`, `.form-errors`, `.form-field`, etc. — revisar si la paginación y los errores de formulario se están viendo sin estilo. - [ ] **Jerarquía de encabezados** (Code 1.9) y **patrones UI iguales para datos iguales** (Code 1.8: `tag_list` usa `<ul>`, `categories` usa `<table>`). --- ## Tanda 3 — Accesibilidad (bajo esfuerzo, se hace junto con lo visual) - [x] **Dropdown "Configuraciones" accesible por teclado** (Code 1.4): hoy es `:hover` puro, sin toggle por teclado → un usuario de teclado no puede llegar a Categorías/Etiquetas/Objetivos. Es una ruta bloqueada, no solo "buena práctica". *(Ya resuelto en la Tanda 1: el toggle pasó a `<button>` con click + Enter/Espacio y `aria-expanded`.)* - [ ] **Labels en selects de filtro** (Code 1.5) y **ARIA en barras de progreso** (Code 1.6). Bajo esfuerzo, se hace en el mismo pase que la Tanda 2. --- ## Tanda 4 — Home (producto + técnico juntos) Ver `01_home.md`. Al tocar el home, aprovechar para lo técnico de esa vista. - [ ] Saldo total + desglose por cuenta. - [ ] Banner de avisos (presupuesto excedido, cuenta en negativo). - [ ] Comparativa gasto mes actual vs anterior. - [ ] Últimos movimientos. - Técnico asociado: reutilizar `current_balance()`/`is_exceeded()` ya memoizados (Tanda 0). --- ## Tanda 5 — Listado de gastos (la pieza de filtrado) Ver `02_listado_gastos.md`. **Es la tanda más grande de producto.** - [ ] Filtrado instantáneo sin recargar (introduce el primer JS de entidad). - [ ] Total de lo filtrado, ordenar por columna, exportar CSV/Excel, rango de fechas. - Técnico asociado: al reescribir la vista para responder JSON/fragmento, resolver de paso la **query duplicada de `Tag`** (Code 2.7) y añadir `select_related`/ `prefetch_related` (Code 2.5). - Ver `09_transversales.md`: el rango de fechas y el mecanismo dinámico deben diseñarse pensando en reutilizarlos en el dashboard. --- ## Tanda 6 — Dashboard (producto + el N+1) Ver `03_dashboard.md`. Es la vista más usada para análisis y la que más se beneficia de tocar producto y rendimiento a la vez. - [ ] Tarta por categorías, desglose por subcategorías al pinchar, presupuestos integrados, rango de fechas, ingresos vs gastos. - Técnico asociado (importante hacerlo *en la misma pasada*): - **N+1 de saldos por cuenta** (Code 2.1): ~40 queries con 5 cuentas. - **Refactor de la función `dashboard`** (Code 3.4): 226 líneas, 5 responsabilidades, contexto de 35 claves. Extraer en `_resolve_period`, `_build_comparison`, `_build_account_charts`. - El desglose por subcategorías reutiliza el mecanismo dinámico de la Tanda 5. --- ## Tanda 7 — Vistas de gestión (cuentas, categorías, etiquetas, objetivos) Ver `04`–`07`. Producto de bajo/medio esfuerzo, se pueden repartir. - [ ] Cuentas: saldo en listado (🟢), marcar principal (🟡), reordenar (🔴, migración). - [ ] Categorías: árbol jerárquico (🟡), nº de gastos (🟢). Considerar separar `category_create` del listado (Code 2.6) si se toca la vista. - [ ] Etiquetas: contador de uso (🟢), fusionar etiquetas (🔴, transacción). - [ ] Objetivos: filtrar por tipo (🟢), histórico (🟡). Añadir docstring a `Goal.progress()`/`_period_start()` (Code 3.5) al tocar el modelo. --- ## Tanda 8 — Módulo de vehículos (módulo nuevo grande) Ver `08_repostajes_vehiculos.md`. Es prácticamente un módulo nuevo; abordar entero, no a trozos sueltos. Orden interno sugerido en su propio archivo. --- ## Tanda 9 — Módulo de inversiones / patrimonio (el más grande) Ver `10_modulo_inversiones.md`. La evolución de mayor alcance. Empezar por registro manual de los cuatro tipos; precios automáticos como capa posterior (cripto primero). La Idea A (clasificar gasto fijo/variable) es independiente y puede ir en cualquier momento. --- ## Refactors grandes — decididos NO hacer por ahora Anotados a conciencia como "no hacer salvo que duela de verdad": - **Migrar a class-based views** (Code 2.3): reduciría ~300-400 líneas, pero toca 20+ vistas que hoy funcionan y están cubiertas por tests. Riesgo/beneficio no compensa en un proyecto personal. Dejar salvo reescritura por otro motivo. - **Partir `views.py` en un paquete `views/`** (Code 3.3): más razonable que lo anterior (es mover funciones, bajo riesgo) pero no urge. Hacerlo el día que el archivo estorbe de verdad al trabajar, y de forma incremental. - **Reorganizar carpetas de plantillas** (Code 2.8): puramente cosmético. Solo si se hace a la vez que otra reestructuración. --- ## Deuda ya conocida (de la fase anterior, no del análisis de Code) - **Jenkins**: build de la imagen Docker en CI + despliegue automático desde `main`. Preparado, pendiente de ejecutar cuando se quiera (ver `TODO_revision.md`). - **`gunicorn` en requirements pero no en el venv** (Code 3.6): mismo patrón que `whitenoise`. Revisar todas las dependencias dev vs producción de una vez. - **Comentarios en dos idiomas** (Code 3.7): fijar convención (español en comentarios, inglés en identificadores, que es lo mayoritario) y aplicarla a partir de ahora sin reescribir lo viejo.

Sign in to join this conversation.

No Label

No Milestone

No project

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: jkuijperm/expenses_manager#29