Makers3D/docs/Makers3D_Plan_Desarrollo.md

Makers3D - Plan de Desarrollo

1. Objetivo

Construir un MVP operable por un equipo pequeno, con trabajo paralelo entre humanos y agentes de IA, minimizando dependencias innecesarias y cerrando primero los recorridos que generan valor real.

2. Principios de ejecucion

1. Desarrollo vertical por recorridos completos.
2. Nada entra en produccion beta sin prueba y criterio de salida.
3. La prioridad la marca el negocio: descubrir, contactar, publicar, cobrar y moderar.
4. Todo diferido queda documentado y fuera del backlog P0.

3. Roles de trabajo

• Producto: protege alcance y acepta entregas.
• Backend: dominio, API, datos y pagos.
• Frontend: experiencia publica, area maker y admin.
• Infra: entornos, despliegue, backups y operacion.
• QA: criterios, evidencia y regresion.

En equipos pequenos una misma persona puede asumir varios roles, pero las responsabilidades deben seguir existiendo.

4. Fases

Fase	Objetivo	Prioridad	Estimacion
F0	Base de trabajo	P0	1 semana
F1	Identidad y perfil maker privado	P0	2 semanas
F2	Servicios, trabajos y publicacion	P0	2 semanas
F3	Descubrimiento publico	P0	2 semanas
F4	Consulta y mensajeria	P0	2 semanas
F5	Suscripcion y Mercado Pago	P0	1-2 semanas
F6	Resenas, moderacion y admin	P1	2 semanas
F7	Hardening y beta cerrada	P0	2 semanas

5. Epicas, historias y tareas

F0 - Base de trabajo

Objetivo:

• dejar el repositorio listo para construir sin improvisacion.

Historias:

• como equipo quiero un monorepo funcional;
• como equipo quiero levantar local con un solo comando;
• como equipo quiero CI minimo antes de tocar negocio.

Tareas:

• crear estructura web, api, worker;
• configurar TypeScript, lint y testing;
• levantar PostgreSQL, MinIO y Nginx en Compose;
• crear pipeline minimo;
• documentar comandos y convenciones.

Definition of Done:

• instalacion limpia funciona;
• docker compose up levanta entorno local;
• CI ejecuta checks basicos.

Pruebas:

• build de cada app;
• smoke test local;
• test de conexion a base de datos y storage.

F1 - Identidad y perfil maker privado

Objetivo:

• permitir cuenta, login y area maker sin visibilidad publica.

Historias:

• como usuario quiero registrarme y verificar email;
• como usuario quiero acceder y recuperar mi cuenta;
• como usuario quiero crear mi perfil maker privado.

Tareas:

• tablas de cuentas y sesiones;
• registro, login y recuperacion;
• cookies seguras y CSRF;
• formulario de perfil maker;
• ubicacion unica con privacidad;
• disponibilidad basica.

Dependencias:

• F0 cerrada.

Definition of Done:

• un usuario puede registrarse;
• puede crear perfil maker;
• puede salir y volver sin perder su borrador.

Pruebas:

• unitarias de auth;
• integracion de sesiones;
• E2E de alta y login.

F2 - Servicios, trabajos y publicacion

Objetivo:

• permitir que el maker prepare una oferta real publicable.

Historias:

• como maker quiero publicar un servicio;
• como maker quiero publicar un trabajo con fotos;
• como maker quiero saber si ya cumplo minimos.

Tareas:

• entidades de servicios y trabajos;
• subida de imagenes;
• procesamiento basico;
• pantalla de checklist de publicacion;
• estado de perfil listo/no listo;
• URLs publicas de perfil, servicio y trabajo.

Dependencias:

• F1 cerrada.

Definition of Done:

• el maker puede publicar 1 servicio y 1 trabajo;
• el sistema calcula si esta listo para publicar;
• lo publico sigue inaccesible si no hay habilitacion comercial.

Pruebas:

• integracion de uploads;
• unitarias de elegibilidad;
• E2E de crear servicio y trabajo.

F3 - Descubrimiento publico

Objetivo:

• abrir la promesa principal al visitante.

Historias:

• como visitante quiero buscar por necesidad;
• como visitante quiero filtrar por cercania y capacidad;
• como visitante quiero abrir perfiles y trabajos desde resultados.

Tareas:

• documento de busqueda;
• filtros y ranking minimo;
• pagina de resultados;
• mapa con clusters;
• lista sincronizada;
• fallback a lista si el mapa falla.

Dependencias:

• F2 para contar con oferta real.

Definition of Done:

• un visitante puede descubrir makers sin cuenta;
• entiende resultados;
• nunca ve datos privados.

Pruebas:

• integracion de busqueda y PostGIS;
• E2E de descubrimiento;
• pruebas de permisos sobre recursos publicos.

F4 - Consulta y mensajeria

Objetivo:

• convertir trafico en conversaciones utiles.

Historias:

• como visitante quiero iniciar una consulta contextual;
• como usuario quiero registrarme sin perder el borrador;
• como cliente y maker quiero conversar dentro de la plataforma.

Tareas:

• flujo de contacto guiado;
• persistencia de borrador;
• registro diferido;
• entidades de consulta, conversacion y mensaje;
• bandeja;
• polling controlado;
• rechazo con motivo.

Dependencias:

• F1 y F3.

Definition of Done:

• el contacto se envia una sola vez;
• el contexto de origen se conserva;
• ambos actores ven la misma conversacion.

Pruebas:

• E2E de consulta completa;
• integracion de idempotencia;
• test de polling y permisos.

F5 - Suscripcion y Mercado Pago

Objetivo:

• convertir presencia profesional en negocio.

Historias:

• como maker quiero contratar el plan;
• como sistema quiero recibir el webhook;
• como plataforma quiero controlar visibilidad segun estado comercial.

Tareas:

• modelo interno de suscripcion;
• inicio de pago;
• retorno del navegador;
• verificacion de webhook;
• conciliacion basica;
• retiro de visibilidad por vencimiento.

Dependencias:

• F2 y F4 recomendadas;
• puede empezar al final de F3 para ganar tiempo.

Definition of Done:

• el pago se refleja;
• la suscripcion cambia de estado;
• el perfil no se publica solo por pagar.

Pruebas:

• sandbox de pagos;
• duplicados y eventos fuera de orden;
• E2E de alta comercial.

F6 - Resenas, moderacion y admin

Objetivo:

• cerrar confianza y operacion basica.

Historias:

• como cliente quiero valorar una relacion real;
• como admin quiero revisar una resena reportada;
• como admin quiero suspender un perfil si existe causa.

Tareas:

• relacion completada;
• resena verificada;
• reportes;
• cola de casos;
• pantalla admin de makers;
• auditoria de acciones internas.

Dependencias:

• F4;
• F5 si la beta ya cobra.

Definition of Done:

• existe trazabilidad;
• el admin puede operar sin tocar base de datos manualmente.

Pruebas:

• integracion de moderacion;
• E2E de reporte y revision;
• permisos admin.

F7 - Hardening y beta cerrada

Objetivo:

• demostrar que el sistema soporta usuarios reales controlados.

Historias:

• como equipo quiero restaurar backups;
• como equipo quiero desplegar con rollback claro;
• como operador quiero abrir beta con soporte y monitoreo basicos.

Tareas:

• runbook de deploy;
• backup y restore;
• smoke tests;
• accesibilidad basica;
• pruebas en movil;
• checklist de salida;
• carga inicial de makers fundadores.

Dependencias:

• F1 a F6.

Definition of Done:

• staging estable;
• restore probado;
• cohortes iniciales definidas;
• no hay bloqueantes P0 abiertos.

Pruebas:

• E2E principales;
• pruebas de restore;
• validacion manual de pagos, mensajes y publicacion.

6. Orden optimo de implementacion

1. F0 Base
2. F1 Identidad y perfil privado
3. F2 Servicios, trabajos y publicacion
4. F3 Descubrimiento
5. F4 Consulta y mensajeria
6. F5 Suscripcion y pagos
7. F6 Resenas, moderacion y admin
8. F7 Hardening y beta

Este orden protege una regla: primero crear oferta, despues mostrarla, despues convertirla en consultas, despues cobrarla y operarla.

7. Dependencias criticas

• No hay descubrimiento real sin oferta maker publicada.
• No hay resena valida sin consulta y relacion.
• No hay publicacion comercial sin suscripcion y sin minimos de calidad.
• No hay beta con cobros reales sin restore probado y conciliacion basica.

8. Trabajo paralelizable

Puede correr en paralelo

• frontend publico y modelado de resultados una vez definidos contratos;
• area maker y backend de servicios/trabajos;
• pipeline CI y entorno staging;
• copy UX y validaciones de formularios;
• QA sobre auth mientras backend continua con publicacion.

No conviene paralelizar demasiado pronto

• pagos antes de fijar modelo interno de suscripcion;
• admin antes de definir exactamente que modera;
• optimizaciones de rendimiento antes de tener recorridos completos.

9. Riesgos por fase

Fase	Riesgo principal	Mitigacion
F0	deuda de estructura	monorepo austero y pocas abstracciones
F1	auth insegura	pruebas y cookies seguras desde el inicio
F2	complejidad de uploads	limitar tipos de archivo
F3	ranking confuso	explicaciones simples y filtros duros
F4	duplicados de consulta	idempotencia y borrador persistente
F5	incoherencias de pago	webhook verificado y conciliacion
F6	moderacion lenta	backoffice minimo y motivos claros
F7	falsa sensacion de preparacion	restore, smoke tests y checklist real

10. Criterios de aceptacion globales

Una fase se acepta solo si:

• cumple el recorrido principal;
• contempla errores y estados vacios;
• respeta permisos;
• tiene pruebas suficientes;
• queda documentada;
• y no introduce dependencias tecnicas nuevas sin aprobacion.

11. Definition of Done global

Una historia o tarea esta terminada cuando:

• el comportamiento funciona;
• los permisos son correctos;
• hay prueba adecuada;
• el usuario entiende el resultado;
• no hay regresion conocida;
• y la documentacion minima esta actualizada.

12. Preparacion para humanos e IA

Reparto recomendado

• humanos: decisiones de negocio, revision de UX, moderacion, riesgos y aceptacion final;
• IA: scaffolding, CRUD, validaciones, tests, refactor y documentacion operativa;
• trabajo compartido: contratos, copy UX, casos limite y revisiones.

Regla

La IA acelera entrega, pero no reemplaza la aceptacion del flujo ni la comprobacion de negocio.