# 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.