4.1 Roles y responsabilidades

Somos cinco integrantes. Los cuatro de IDS desarrollaremos un módulo completo cada uno y documentaremos el trabajo realizado, de modo que ninguno dependa de otro para avanzar. Sam se encarga del diseño completo y del design system: la investigación de campo la «omitimos / simulamos» —nos apoyamos en la muestra y los hallazgos ya recogidos en §2— para poder entregar antes, y así Sam concentra su tiempo en interfaz, identidad y sistema visual.

Reparto los módulos de forma que cada uno tenga un frente propio y no haya dos personas trabajando sobre lo mismo:

Tabla 4.1 · Qué programará y qué documentará cada uno de nosotros

Integrante	Qué programa	Qué documenta
Omar	Módulo de registro completo: teclado numérico propio, validación del monto, selección de categoría y guardado del movimiento. Navegación entre pantallas.	Ficha de su módulo, README del repositorio y bitácora de integración.
Paola	Módulo de resumen completo: cálculo del gastado hoy, del gastado en el mes, del disponible y del porcentaje de avance conforme a RN-6 a RN-9.	Ficha de su módulo y la coordinación y cierre del documento de entrega (cada integrante redacta su parte).
David	Módulo de historial completo: agrupación por día, cálculo de subtotales, orden descendente, estados de lista vacía y eliminación con confirmación.	Ficha de su módulo y la bitácora de pruebas.
Santiago	Módulo de datos completo: entidades, consultas, base de datos local, carga inicial de categorías e implementación real del repositorio.	Ficha de su módulo, esquema de datos y procedimiento de migración.
Sam	No programa. Produce el prototipo navegable en Figma y el design system.	Informe de investigación (elaborado a partir de la muestra y los hallazgos de §2), memoria de decisiones de diseño y auditoría de accesibilidad.

4.2 Módulos y fronteras de trabajo

Cada uno de nosotros trabajará únicamente dentro de su carpeta. Los archivos compartidos los modificamos mediante pull request (PR) al branch main.

app/src/main/java/mx/proyecto/gastos/
│
├── MainActivity.kt              compartido · PR (cualquiera propone, equipo aprueba)
├── nav/NavGraph.kt              compartido · PR (cualquiera propone, equipo aprueba)
├── ui/tema/                     compartido · PR con el sistema visual de Sam
│
├── core/                        CONTRATO COMÚN · congela el lunes 31 a las 18:00
│   ├── modelo/Movimiento.kt
│   ├── modelo/Categoria.kt
│   ├── repo/MovimientoRepository.kt        (interfaz)
│   └── repo/RepositorioDePrueba.kt         (datos en memoria)
│
├── datos/                       Santiago · exclusivo
├── registro/                    Omar · exclusivo
├── resumen/                     Paola · exclusivo
├── historial/                   David · exclusivo
├── presupuesto/                 Paola · exclusivo · segunda entrega
└── ajustes/                     Omar · exclusivo · segunda entrega

Tabla 4.2 · Reglas de frontera

Carpeta propia	Cada uno de nosotros crea, modifica y elimina archivos libremente dentro de su carpeta, sin consultar a nadie.
Carpeta ajena	No la tocamos. Si necesitamos un cambio, lo pedimos en el grupo y lo hace su responsable.
Archivos compartidos	Los modificamos mediante PR: branch auxiliar → commit → PR → al menos una aprobación → merge a main.
Contrato común	La carpeta core la congelamos el lunes 31 a las 18:00, al cierre de la reunión de arranque. Cualquier cambio posterior lo acordamos entre todos.
Prohibido	Reformatear código ajeno, renombrar carpetas de otro compañero y subir carpetas de compilación.

La carpeta core — el contrato que hace posible trabajar en paralelo

La carpeta core/ no es de nadie en particular: es el acuerdo de datos que compartimos los cuatro módulos. Contiene la estructura de información (modelo), la lista de operaciones disponibles (interfaz de repositorio) y una implementación de prueba que devuelve datos en memoria.

Tabla 4.2.1 · Contenido de la carpeta core

Archivo	Qué es	Quién lo creó
modelo/Movimiento.kt	Data class que define un movimiento: id, monto en centavos, tipo, categoría, fecha y nota.	Lo creo yo (Omar), lo dejo listo antes de la reunión y lo congelamos el lunes 31 a las 18:00.
modelo/Categoria.kt	Enumeración de las seis categorías iniciales.	Lo creo yo (Omar). Solo cambia si acordamos entre todos una nueva categoría.
repo/MovimientoRepository.kt	Interfaz con cuatro funciones: observar mes, observar todos, guardar y eliminar.	Lo creo yo (Omar). Es el contrato que usan Paola, David y Santiago.
repo/RepositorioDePrueba.kt	Implementación que guarda en una lista en memoria.	Lo creo yo (Omar). Lo sustituimos por Room cuando Santiago termine el suyo.

Qué contiene cada archivo

modelo/Movimiento.kt es la data class que describe un movimiento y nada más: un identificador, el monto guardado como número entero de centavos (RN-1), el tipo —gasto o ingreso, RN-3—, la categoría, la fecha contable sin hora (RN-4) y una nota opcional. Es la única definición de «qué es un movimiento» en todo el proyecto; los cuatro módulos leen y escriben objetos de este tipo, así que cualquier cambio aquí los afecta a todos a la vez.

modelo/Categoria.kt es la enumeración con las seis categorías fijas de la primera entrega: comida, transporte, casa, ocio, salud y otro (RN-5). Al ser una enumeración y no un texto libre, el compilador impide inventar una categoría que no exista y las cuatro pantallas muestran exactamente la misma lista, escrita una sola vez.

Qué hace la carpeta repo/

La carpeta repo/ es la puerta de acceso a los datos. Su única función es separar dos cosas que normalmente se mezclan: cómo se piden los movimientos (guardar uno, pedir los del mes…) y dónde están guardados en realidad (una lista en memoria, una base de datos en el teléfono, la nube). Gracias a esa separación, Paola, David y Santiago programan contra una lista de operaciones estable sin tener que esperar a que exista la base de datos real.

repo/MovimientoRepository.kt es una interfaz: declara las operaciones disponibles pero no las implementa —es una lista de promesas, no código que se ejecute—. Son cuatro:

• Observar el mes. Devuelve, como flujo que se actualiza solo cuando cambian los datos, la lista de movimientos cuya fecha cae en el mes en curso. La usan el resumen y el historial.
• Observar todos. Igual que la anterior pero sin filtrar por fecha. Es la base de la búsqueda y los filtros de la segunda entrega.
• Guardar. Inserta un movimiento nuevo o actualiza uno que ya existe. La usa el módulo de registro.
• Eliminar. Borra un movimiento de forma definitiva. La usa el historial, siempre con confirmación (RN-10).

Cada módulo recibe «un MovimientoRepository» y llama a estas funciones. Nunca nombra una base de datos concreta, así que le da igual qué haya detrás.

repo/RepositorioDePrueba.kt es una implementación falsa de esa interfaz que guarda los movimientos en una lista en memoria (MutableList), ya cargada con algunos movimientos de ejemplo. Sirve para que las tres pantallas se puedan construir, abrir y probar desde el primer día, antes de que exista la base de datos. Tiene una limitación deliberada: al cerrar la aplicación los datos se pierden, porque viven solo en memoria. Para desarrollar la interfaz eso no estorba; para la entrega, sí.

Qué es Room y por qué sustituye al repositorio de prueba

Santiago construye, dentro de su carpeta datos/, una segunda implementación de MovimientoRepository —llamémosla RepositorioRoom— que hace exactamente lo mismo que la de prueba pero apoyándose en Room y SQLite en lugar de una lista. Implementa la misma interfaz, con las mismas cuatro funciones y los mismos tipos de entrada y salida; por eso puede ocupar el lugar de la otra sin que nada más se entere.

Cuando esa implementación está terminada y probada (punto de control del miércoles 2, §5.2), el cambio se hace en un solo lugar: el punto donde se decide qué repositorio se entrega a los módulos, que es la configuración de dependencias en MainActivity. Como MainActivity es archivo compartido y la configuración del proyecto es responsabilidad transversal de Omar, es él quien quita RepositorioDePrueba y pone RepositorioRoom mediante un PR. Ningún módulo de Paola, David o del propio Omar cambia una sola línea, porque todos hablaban con la interfaz y no con la lista en memoria. Ese es exactamente el beneficio del contrato: trabajar en paralelo ahora con datos de mentira y enchufar la base de datos real al final sin rehacer nada. Si el miércoles 2 RepositorioRoom no estuviera listo, la entrega saldría con RepositorioDePrueba y esa misma decisión ya está tomada de antemano (§5.2).

Estrategia de branches

main                          ← rama protegida, solo se fusiona con PR aprobado
│
├── feat/core-contrato        ← Omar, lunes antes de las 18:00
├── feat/registro             ← Omar
├── feat/resumen              ← Paola
├── feat/historial            ← David
├── feat/datos                ← Santiago
├── feat/diseño-sistema-visual ← Sam (Figma, no código)
│
├── fix/navegacion-rutas      ← cualquiera, para cambios en compartidos
├── fix/tema-colores          ← cualquiera, para cambios en compartidos
└── fix/manifest-permisos     ← cualquiera, para cambios en compartidos

Flujo de pull request para archivos compartidos

Tabla 4.2.2 · Pasos del flujo de PR

Paso	Acción	Detalle
1	Crear branch auxiliar	git checkout -b fix/nombre-descriptivo
2	Hacer el cambio	Modificar únicamente el archivo compartido necesario.
3	Commit y push	git add . → git commit -m "fix: descripción" → git push
4	Abrir PR	En GitHub, PR del branch auxiliar hacia main.
5	Revisión	Al menos uno de nosotros, distinto de quien hizo el cambio, revisa y aprueba.
6	Fusionar	Después de la aprobación, merge a main. Se elimina el branch auxiliar.

4.3 Arquitectura: dos capas por módulo

• Capa de lógica. Obtiene los datos del repositorio, hace los cálculos y expone el estado de la pantalla. No depende del diseño, así que la escribimos desde el primer momento.
• Capa de presentación. Dibuja la pantalla a partir de ese estado. Sí depende del diseño, así que la escribimos cuando Sam entrega el material correspondiente.

4.4 Dependencia con el diseño

Tabla 4.3 · Entregas de diseño y trabajo que habilita cada una

Clave	Entregable de Sam	Fecha	Qué habilita
D-1	Flujo de usuario y bocetos de baja fidelidad.	Lunes 31, 17:00	Omar crea la navegación y pantallas vacías.
D-2	Sistema visual base: paleta, tipografía, escala.	Lunes 31, 21:00	Los cuatro podemos maquetar sin inventar medidas.
D-3	Diseño de alta fidelidad de las tres pantallas.	Martes 1, 19:00	Cada uno implementa la presentación con referencia exacta.
D-4	Prototipo navegable, propuesta de identidad e ícono de la app.	Martes 1, 21:00	Validación del recorrido completo; Omar ya puede aplicar el ícono el miércoles.
D-5	Resultados de prueba de usabilidad con cinco personas.	Miércoles 2, 20:00	Los hallazgos se clasifican para la segunda entrega (§6.1).

4.5 Acuerdos de trabajo

Tabla 4.5 · Acuerdos de coordinación

Reunión diaria	Diez minutos a las 16:00, al juntarnos, para abrir la tarde de trabajo. Tres frases cada uno: qué hice, qué sigue y qué me bloquea.
Subida diaria	Todos subimos nuestra rama antes de las 11:59 de la noche.
Integración	Primera entrega: miércoles 2 por la tarde. Segunda: cada viernes a las 18:00.
Decisiones	Toda decisión que cambie el alcance la escribimos en el grupo y Paola la registra.