Modulo makers3d desarrollado con codex V 0.0.1

docs/Deployment_Runbook.md

@@ -0,0 +1,162 @@
+# Makers3D - Deployment Runbook
+
+## 1. Requisitos
+
+- Debian 13
+- Docker
+- Docker Compose
+- 4 GB RAM recomendados
+- 20 GB libres como minimo
+
+## 2. Archivos necesarios
+
+- `compose.yaml`
+- `.env`
+- carpeta `apps/`
+- carpeta `packages/`
+- carpeta `infrastructure/`
+- carpeta `docs/`
+
+## 3. Variables minimas
+
+Partir de `.env.example` y ajustar:
+
+- `POSTGRES_PASSWORD`
+- `SESSION_SECRET`
+- `APP_URL`
+- `MINIO_ROOT_USER`
+- `MINIO_ROOT_PASSWORD`
+- `PAYMENT_PROVIDER`
+- `MERCADOPAGO_ACCESS_TOKEN` si se activa el proveedor real
+
+## 4. Primer despliegue
+
+```bash
+cp .env.example .env
+docker compose build
+docker compose up -d
+docker compose exec -T api node apps/api/dist/apps/api/src/scripts/migrate.js
+docker compose exec -T api node apps/api/dist/apps/api/src/scripts/seed.js
+```
+
+### Activar HTTPS real en `dev.jazari.com.ar`
+
+El proyecto ya incluye estructura para Let's Encrypt con renovacion automatica.
+
+1. Ajustar `.env`:
+
+- `APP_URL=https://dev.jazari.com.ar`
+
+2. Obtener el certificado:
+
+```bash
+./scripts/setup-https.sh dev.jazari.com.ar
+```
+
+Si se quiere registrar correo en Let's Encrypt:
+
+```bash
+./scripts/setup-https.sh dev.jazari.com.ar ops@tu-dominio.com
+```
+
+3. Instalar renovacion automatica:
+
+```bash
+./scripts/install-cert-renew-cron.sh
+```
+
+4. Verificar:
+
+```bash
+./scripts/renew-certs.sh
+```
+
+## 5. Verificacion inicial
+
+```bash
+curl -fsS http://127.0.0.1/api/v1/health
+curl -fsS http://127.0.0.1/api/v1/makers
+```
+
+Comprobar tambien:
+
+- `https://dev.jazari.com.ar/`
+- `http://SERVER_IP/login`
+- `http://SERVER_IP/account`
+- instalacion PWA en Android desde Chrome: menu > `Instalar app`
+
+## 6. Credenciales demo
+
+- Admin: `admin@makers3d.local` / `Admin123!`
+- Maker: `maker1@makers3d.local` / `Maker123!`
+- Cliente: `cliente1@makers3d.local` / `Cliente123!`
+
+## 7. Actualizacion
+
+```bash
+docker compose build
+docker compose up -d
+```
+
+Si cambia el esquema:
+
+```bash
+docker compose exec -T api node apps/api/dist/apps/api/src/scripts/migrate.js
+```
+
+## 8. Logs utiles
+
+```bash
+docker compose logs -f api
+docker compose logs -f web
+docker compose logs -f worker
+docker compose logs -f nginx
+docker compose logs -f certbot
+```
+
+## 9. Problemas comunes
+
+### `api` no arranca
+
+Revisar:
+
+- `DATABASE_URL`
+- `SESSION_SECRET`
+- credenciales MinIO
+- si el esquema ya fue aplicado
+
+### `nginx` no responde
+
+Relanzar:
+
+```bash
+docker compose up -d nginx
+```
+
+Si falla solo la parte TLS:
+
+```bash
+cp infrastructure/nginx/nginx.http.conf infrastructure/nginx/runtime/nginx.conf
+docker compose up -d --force-recreate nginx
+./scripts/setup-https.sh dev.jazari.com.ar
+```
+
+### El login falla
+
+Revisar cookies, `APP_URL` y que el navegador entre por Nginx y no directamente al contenedor.
+
+## 10. Corte rapido de la demo
+
+```bash
+docker compose down
+```
+
+Mantiene volumenes.
+
+## 11. Borrado completo
+
+```bash
+docker compose down -v
+```
+
+Elimina datos.

docs/Makers3D_Arquitectura_Infraestructura.md

@@ -0,0 +1,405 @@
+# Makers3D - Arquitectura e Infraestructura
+
+## 1. Principios tecnicos
+
+1. Un solo sistema, no un conjunto de promesas futuras.
+2. PostgreSQL como fuente canonica unica.
+3. Monolito modular antes que microservicios.
+4. Infraestructura suficiente para beta, no para una escala imaginaria.
+5. Todo servicio debe justificar claramente su existencia.
+
+## 2. Arquitectura elegida
+
+### Vision general
+
+```text
+Usuario web
+   |
+ Nginx
+   |
+ Next.js (web)
+   |
+ NestJS API
+   |
+ PostgreSQL + PostGIS
+   |
+ MinIO
+   |
+ Worker
+```
+
+### Decisiones clave
+
+- una sola aplicacion web para publico, cuenta, area maker y admin;
+- una sola API de negocio;
+- una sola base de datos;
+- un solo worker para tareas asincronas y tareas programadas simples;
+- un solo proxy perimetral;
+- un solo sistema de almacenamiento de objetos.
+
+## 3. Stack aprobado
+
+### Web
+
+- Next.js App Router;
+- renderizado SSR para vistas publicas principales;
+- llamadas a API REST propia;
+- responsive web;
+- sin app nativa en MVP;
+- sin PWA avanzada en MVP.
+
+### API
+
+- NestJS;
+- Fastify;
+- versionado `/api/v1`;
+- validacion de entrada;
+- contratos JSON claros;
+- auth por cookie segura.
+
+### Datos
+
+- PostgreSQL 16;
+- PostGIS;
+- `pg_trgm`;
+- `unaccent`.
+
+### Archivos
+
+- MinIO;
+- buckets publicos y privados separados;
+- URLs firmadas para privados;
+- imagenes publicas optimizadas.
+
+### Asincronia
+
+- worker unico;
+- cola con PostgreSQL;
+- reintentos controlados;
+- tareas idempotentes.
+
+### Mapa
+
+- MapLibre en frontend;
+- teselas o PMTiles servidas por Nginx;
+- fallback completo a lista si el mapa falla.
+
+### Pagos
+
+- Mercado Pago para la suscripcion maker;
+- webhooks verificados;
+- conciliacion basica;
+- pago aprobado no publica automaticamente.
+
+## 4. Servicios y por que existen
+
+| Servicio | Existe porque |
+|---|---|
+| `web` | Entrega toda la experiencia visible del producto. |
+| `api` | Centraliza reglas de negocio, auth, publicacion, pagos y moderacion. |
+| `worker` | Evita bloquear la API con email, imagenes y webhooks. |
+| `postgres` | Conserva datos transaccionales, geograficos y de auditoria. |
+| `minio` | Permite archivos desacoplados del contenedor y faciles de respaldar. |
+| `nginx` | Publica web, API, activos y TLS en una sola capa simple. |
+
+No se crean por ahora:
+
+- `scheduler` separado;
+- `redis`;
+- `grafana`;
+- `prometheus`;
+- `loki`;
+- `tempo`;
+- `rabbitmq`;
+- `kafka`;
+- `elasticsearch`;
+- `opensearch`;
+- `kubernetes`.
+
+## 5. Estructura del proyecto
+
+```text
+makers3d/
+├── apps/
+│   ├── web/
+│   ├── api/
+│   └── worker/
+├── packages/
+│   ├── contracts/
+│   ├── database/
+│   ├── shared/
+│   └── ui/
+├── infrastructure/
+│   ├── docker/
+│   ├── nginx/
+│   ├── scripts/
+│   └── backups/
+└── docs/
+```
+
+Esta estructura es suficiente para trabajar con un equipo pequeno y agentes de IA sin crear paquetes vacios.
+
+## 6. Base de datos
+
+### Entidades principales
+
+- accounts
+- sessions
+- maker_profiles
+- maker_locations
+- maker_services
+- maker_works
+- inquiries
+- conversations
+- messages
+- subscriptions
+- payments
+- relationships
+- reviews
+- moderation_cases
+- audit_events
+
+### Reglas de modelado
+
+- UUID internos;
+- slugs publicos solo donde aporten valor;
+- `timestamptz` para fechas;
+- dinero en enteros por moneda;
+- integridad por claves y restricciones antes que por logica suelta;
+- historial solo donde cambie el comportamiento del negocio.
+
+### PostGIS
+
+Se usa para:
+
+- guardar coordenada privada del maker;
+- derivar punto publico aproximado;
+- calcular distancia real;
+- filtrar por radio;
+- soportar cobertura local.
+
+No se usa para:
+
+- analitica compleja;
+- tracking continuo;
+- multiples geometrias innecesarias en MVP.
+
+## 7. Busqueda
+
+La busqueda inicial se resuelve en PostgreSQL con:
+
+- texto libre;
+- trigramas;
+- campos normalizados;
+- filtros estructurados;
+- radio geografico;
+- distincion entre recogida local y envio.
+
+No se incorpora motor externo hasta que exista evidencia de que PostgreSQL no alcanza.
+
+## 8. Archivos y multimedia
+
+### Tipos permitidos en MVP
+
+- JPG;
+- PNG;
+- WebP;
+- PDF.
+
+### Tipos excluidos en MVP
+
+- STL publico;
+- ZIP;
+- RAR;
+- 3MF;
+- videos largos.
+
+### Flujo
+
+1. La API autoriza una subida.
+2. El archivo se guarda en MinIO.
+3. El worker valida y genera derivados cuando aplique.
+4. El sistema actualiza el estado.
+5. Solo entonces el recurso puede usarse publicamente.
+
+Esto simplifica mucho seguridad y moderacion.
+
+## 9. Autenticacion y autorizacion
+
+### Autenticacion
+
+- email y contrasena;
+- hash Argon2id;
+- verificacion de email;
+- recuperacion por token de un solo uso;
+- sesiones opacas con cookie HttpOnly.
+
+### Autorizacion
+
+Roles fijos del MVP:
+
+- guest;
+- user;
+- maker;
+- admin.
+
+No se implementa un motor de permisos granulares en la primera version. El admin concentra soporte, moderacion y gestion comercial en beta.
+
+## 10. Mensajeria
+
+### Decision
+
+La mensajeria usa polling controlado.
+
+### Motivo
+
+- reduce complejidad operativa;
+- no exige infraestructura de tiempo real;
+- es suficiente para una beta cerrada.
+
+### Frecuencia sugerida
+
+- refresco manual siempre disponible;
+- polling cada 20 a 30 segundos en conversacion abierta;
+- pausa cuando la pestana queda inactiva.
+
+WebSockets quedan fuera del MVP. SSE puede evaluarse mas adelante.
+
+## 11. Infraestructura de despliegue
+
+### Entornos
+
+- local;
+- staging;
+- produccion beta.
+
+No hace falta un cuarto entorno al principio.
+
+### Orquestacion
+
+- Docker Compose en todos los entornos;
+- imagenes versionadas;
+- variables y secretos por entorno;
+- volumentes persistentes claros;
+- despliegue manual asistido al inicio.
+
+### Proxy y TLS
+
+- Nginx como entrada unica;
+- HTTPS obligatorio;
+- certificados automaticos;
+- sin puertos internos expuestos al exterior.
+
+## 12. Backups y restore
+
+### Base de datos
+
+- backup completo nocturno;
+- archivado frecuente de WAL o estrategia equivalente;
+- prueba de restauracion antes de abrir beta.
+
+### Objetos
+
+- copia diaria de buckets;
+- verificacion por hash cuando sea posible.
+
+### Regla de salida
+
+No se abre beta con usuarios reales sin una restauracion comprobada.
+
+## 13. Seguridad
+
+### Obligatoria en MVP
+
+- HTTPS;
+- cookies seguras;
+- CSRF en formularios autenticados;
+- rate limiting;
+- proteccion basica contra brute force;
+- validacion estricta de entrada;
+- sanitizacion de archivos permitidos;
+- ocultacion de coordenadas privadas;
+- URLs firmadas para privados;
+- auditoria de acciones admin.
+
+### Diferida
+
+- MFA para todos los usuarios;
+- SIEM;
+- trazas distribuidas;
+- WAF externo;
+- secretos centralizados avanzados.
+
+## 14. Logs y observabilidad
+
+### Minimo obligatorio
+
+- logs JSON en web, API y worker;
+- request ID;
+- endpoint de health;
+- registro de errores de pagos, uploads y webhooks;
+- panel simple o lectura directa de logs en staging y produccion beta.
+
+### No obligatorio al inicio
+
+- paneles complejos;
+- trazas distribuidas exhaustivas;
+- metricas de alta cardinalidad.
+
+## 15. CI CD
+
+### Pipeline minimo
+
+- install reproducible;
+- lint;
+- typecheck;
+- tests unitarios;
+- tests de integracion esenciales;
+- build de web, api y worker;
+- construccion de imagenes.
+
+### Despliegue minimo
+
+- merge a rama principal;
+- build de imagenes versionadas;
+- despliegue manual a staging;
+- smoke test;
+- aprobacion;
+- despliegue a produccion beta.
+
+Esto es mas realista que automatizar completamente el release desde el primer dia.
+
+## 16. Hardening operativo
+
+Antes de abrir beta:
+
+- backups verificados;
+- conciliacion de pagos probada;
+- moderacion operable;
+- logs utiles;
+- restores probados;
+- rutas privadas revisadas;
+- direccion exacta protegida;
+- contenido minimo de soporte.
+
+## 17. Lo que no se debe construir todavia
+
+- cache distribuida si no hay cuello de botella;
+- cola externa si PostgreSQL aun responde;
+- varios proxies;
+- varios paneles de observabilidad;
+- app movil;
+- publicidad;
+- algoritmos complejos de ranking;
+- permisos internos granulares;
+- ingestion de cualquier tipo de archivo.
+
+## 18. Criterio final
+
+La arquitectura correcta para Makers3D no es la mas sofisticada. Es la que permite:
+
+- lanzar rapido;
+- cobrar sin sustos;
+- moderar sin caos;
+- recuperar datos;
+- y evolucionar sin rehacer el nucleo.

docs/Makers3D_Auditoria_MVP.md

@@ -0,0 +1,170 @@
+# Makers3D - Auditoria MVP
+
+## 1. Dictamen ejecutivo
+
+La propuesta original acierta en la promesa de negocio, pero mezcla un MVP real con capas de producto, UX y arquitectura propias de una fase posterior. La reauditoria reduce el proyecto a una plataforma de descubrimiento y contacto profesional para makers 3D en Argentina, manteniendo el negocio principal:
+
+- descubrir makers por zona, especialidad y capacidad;
+- mostrar portfolio real y servicios;
+- iniciar contacto dentro de la plataforma;
+- permitir seguimiento basico de la conversacion;
+- cobrar al maker por aparecer publicamente.
+
+Se elimina o difiere todo lo que no acelera esas cinco promesas.
+
+## 2. Decisiones de recorte
+
+### Se conserva como nucleo
+
+- mapa, lista, busqueda y filtros;
+- perfil publico del maker;
+- trabajos publicados;
+- servicios publicados;
+- cuenta unica para cliente y maker;
+- alta de maker en borrador;
+- publicacion condicionada a calidad minima y suscripcion activa;
+- contacto guiado;
+- bandeja de mensajes;
+- resena verificada tras relacion completada;
+- moderacion y backoffice basicos;
+- un unico plan de pago.
+
+### Se difiere
+
+- favoritos;
+- comparacion entre makers;
+- escaparates tematicos;
+- multiples ubicaciones por maker;
+- dashboard avanzado y analitica de negocio;
+- PWA instalable completa;
+- notificaciones push;
+- patrocinio y publicidad;
+- SEO programatico avanzado;
+- permisos granulares internos;
+- telemetria avanzada;
+- automatizaciones comerciales.
+
+### Se elimina del MVP
+
+- marketplace;
+- checkout cliente-maker;
+- apps nativas;
+- gamificacion;
+- likes, comentarios y senales sociales publicas;
+- reputacion externa no verificable;
+- microservicios;
+- orquestacion compleja;
+- motores de busqueda externos;
+- tiempo real por WebSockets;
+- stack de observabilidad pesada desde el dia uno.
+
+## 3. Clasificacion funcional
+
+| Componente | Clasificacion | Decision |
+|---|---|---|
+| Descubrimiento en mapa y lista | OBLIGATORIO | Es la promesa central del producto. |
+| Busqueda textual y filtros por servicio, tecnologia, material, distancia y envio | OBLIGATORIO | Sin esto el mapa es solo decoracion. |
+| Perfil publico del maker | OBLIGATORIO | Convierte descubrimiento en confianza. |
+| Trabajos publicados con fotos | OBLIGATORIO | La prueba principal de calidad del maker. |
+| Servicios publicados | OBLIGATORIO | Permiten explicar que ofrece cada maker. |
+| Cuenta unica cliente-maker | OBLIGATORIO | Reduce friccion y soporte. |
+| Perfil maker en borrador privado | OBLIGATORIO | Permite preparar la oferta antes de pagar. |
+| Publicacion condicionada a minimos de calidad | OBLIGATORIO | Evita mapa vacio o basura pagada. |
+| Suscripcion unica para aparicion publica | OBLIGATORIO | Es el modelo de ingresos inicial. |
+| Contacto guiado | OBLIGATORIO | Convierte visitas en consultas utiles. |
+| Mensajeria interna basica | OBLIGATORIO | Da trazabilidad y permite resenas verificadas. |
+| Resena verificada tras trabajo completado | OBLIGATORIO | La reputacion debe nacer de relaciones reales. |
+| Moderacion y backoffice basicos | OBLIGATORIO | Sin esto no hay confianza operable. |
+| Geolocalizacion del navegador | RECOMENDADO | Mejora la apertura, pero debe existir alternativa manual. |
+| SEO basico de perfil y trabajo | RECOMENDADO | Aporta captacion sin rehacer producto. |
+| Emails transaccionales | RECOMENDADO | Necesarios para verificacion y eventos criticos. |
+| Favoritos | FASE 2 | Util, pero no cambia la propuesta inicial. |
+| Comparacion entre makers | FASE 2 | Valiosa, pero prescindible para abrir beta. |
+| Escaparates tematicos | FASE 2 | Son una mejora editorial, no una necesidad comercial. |
+| Multiples ubicaciones por maker | FASE 2 | Añade complejidad operativa y geoespacial. |
+| Dashboard con embudos y estadisticas avanzadas | FASE 2 | Conviene medir primero antes de sofisticar. |
+| Notificaciones internas ricas y push | FASE 2 | La combinacion email + badge es suficiente al inicio. |
+| SEO programatico por provincias y categorias | FASE 2 | Requiere oferta real y control editorial. |
+| Programa de makers fundadores automatizado | FASE 2 | Puede operarse manualmente en beta. |
+| Publicidad sectorial y patrocinio | FASE 3 | Solo cuando exista volumen y reglas maduras. |
+| Comunidad, cursos, eventos y contenido social | FASE 3 | Son negocios distintos. |
+| App nativa iOS/Android | FASE 3 | No acelera validacion inicial. |
+| Marketplace completo | ELIMINAR | Cambia el negocio y multiplica riesgo legal y tecnico. |
+| Gamificacion | ELIMINAR | No resuelve el problema principal. |
+| Likes y comentarios publicos | ELIMINAR | Introducen ruido y falsos signos de calidad. |
+| Reseñas externas no verificadas | ELIMINAR | Complican confianza y moderacion sin suficiente valor. |
+
+## 4. Clasificacion tecnica
+
+| Componente | Clasificacion | Decision |
+|---|---|---|
+| API REST monolitica modular | OBLIGATORIO | Mas barata y mas facil de operar que microservicios. |
+| Next.js para web responsive | OBLIGATORIO | Resuelve publico, cuenta, area maker y admin en una sola app. |
+| NestJS para API | OBLIGATORIO | Ordena dominio, auth y pagos sin inventar estructura. |
+| PostgreSQL | OBLIGATORIO | Fuente canonica unica para negocio, mensajes y pagos. |
+| PostGIS | OBLIGATORIO | El mapa y la distancia son parte del producto, no un adorno. |
+| FTS + pg_trgm en PostgreSQL | OBLIGATORIO | Cubre busqueda inicial sin otro motor. |
+| Docker | OBLIGATORIO | Simplifica desarrollo, staging y despliegue. |
+| Docker Compose | OBLIGATORIO | Suficiente para MVP autoalojado. |
+| Nginx como proxy y servidor de activos | OBLIGATORIO | Una sola pieza perimetral basta para empezar. |
+| Storage S3-compatible | OBLIGATORIO | Evita acoplar archivos al contenedor. |
+| MinIO | OBLIGATORIO | Opcion self-hosted simple para almacenamiento inicial. |
+| Worker unico para tareas asincronas | OBLIGATORIO | Necesario para email, imagenes y webhooks. |
+| Polling controlado para mensajeria | OBLIGATORIO | Mucho mas simple que tiempo real completo. |
+| Logs estructurados | OBLIGATORIO | Base minima de soporte y auditoria. |
+| Backups de base de datos y objetos | OBLIGATORIO | Sin esto no debe abrirse beta. |
+| Seguridad base: Argon2id, cookies seguras, CSRF, rate limiting, URLs firmadas | OBLIGATORIO | Minimo para usuarios y cobros reales. |
+| Autenticacion por email y contraseña | OBLIGATORIO | Camino mas directo y entendible. |
+| Autorizacion por roles fijos | OBLIGATORIO | Guest, user, maker y admin cubren el MVP. |
+| Mercado Pago | OBLIGATORIO | Solucion inicial mas pragmatica para cobrar en Argentina. |
+| CI minimo con tests y build | OBLIGATORIO | Reduce roturas al trabajar con humanos e IA. |
+| Geolocalizacion del navegador | RECOMENDADO | Buen atajo UX, nunca obligatoria. |
+| Email transaccional externo | RECOMENDADO | Ahorra mucho riesgo de entregabilidad. |
+| MapLibre + PMTiles | RECOMENDADO | Mantiene control de costes y evita dependencia temprana de terceros. |
+| Observabilidad minima de salud y errores | RECOMENDADO | Suficiente para beta cerrada. |
+| Redis | FASE 2 | Solo si el trafico o el rate limiting lo exigen. |
+| BullMQ | FASE 2 | Solo si PostgreSQL deja de ser suficiente para colas. |
+| CDN | FASE 2 | No hace falta antes de comprobar volumen y geografia real. |
+| Cloudflare | FASE 2 | Puede ayudar despues, no debe condicionar el arranque. |
+| SSE para actualizacion de bandeja | FASE 2 | Mejora UX sin ser requisito inicial. |
+| Scheduler separado | FASE 2 | El worker puede asumir tareas programadas al principio. |
+| Observabilidad con paneles y alertas avanzadas | FASE 2 | Conveniente tras la beta interna. |
+| Grafana | FASE 3 | Util cuando haya mas servicios y alertas formales. |
+| Prometheus | FASE 3 | No justifica su coste operativo al inicio. |
+| Loki | FASE 3 | Los logs estructurados bastan en MVP. |
+| Tempo | FASE 3 | Trazas distribuidas sin sistema distribuido no son prioridad. |
+| Traefik | ELIMINAR | Duplica funciones cubiertas por Nginx. |
+| RabbitMQ | ELIMINAR | Sobreingenieria para el volumen esperado. |
+| Kafka | ELIMINAR | Totalmente fuera de escala para el MVP. |
+| Elasticsearch | ELIMINAR | PostgreSQL cubre el problema inicial. |
+| OpenSearch | ELIMINAR | Mismo motivo que Elasticsearch. |
+| Kubernetes | ELIMINAR | Añade operacion sin aportar valor temprano. |
+| WebSockets | ELIMINAR | La mensajeria puede nacer con polling. |
+| Prisma | ELIMINAR | Penaliza flexibilidad SQL y PostGIS; no simplifica el nucleo. |
+| Microservicios | ELIMINAR | Mas coste, mas despliegue, mas mantenimiento. |
+
+## 5. Reglas de simplificacion aprobadas
+
+1. Un maker tendra una sola ubicacion operativa en el MVP.
+2. Un maker publicara al menos un servicio y un trabajo con foto.
+3. La suscripcion habilita la posibilidad de publicar, pero no publica por si sola.
+4. Las resenas validas nacen de una relacion completada en la plataforma.
+5. Los archivos del MVP se limitan a imagenes y PDF. No habra STL, ZIP o 3MF publicos.
+6. El mapa es importante, pero toda accion critica debe tener alternativa en lista.
+7. El backoffice sera austero: cola de revision, ficha de maker, pagos, casos y auditoria.
+8. Toda capacidad futura solo entra si mejora conversion, confianza o coste operativo.
+
+## 6. Forma final del MVP
+
+Makers3D debe salir como:
+
+- una web responsive;
+- con mapa y lista;
+- con makers publicos de pago;
+- con portfolios visuales simples;
+- con contacto guiado;
+- con seguimiento basico de mensajes;
+- con reputacion nacida de trabajos reales;
+- y con operacion interna suficiente para moderar, cobrar y responder incidencias.
+
+Todo lo demas debe esperar a que exista uso real.

docs/Makers3D_Especificacion_Minima.md

@@ -0,0 +1,413 @@
+# Makers3D - Especificacion Minima
+
+## 1. Proposito
+
+Makers3D es una plataforma web para descubrir, evaluar y contactar makers y proveedores de fabricacion 3D en Argentina. No es un marketplace ni procesa el pago entre cliente y maker. Su funcion es ayudar a encontrar al profesional adecuado y permitir el primer contacto con contexto suficiente.
+
+## 2. Alcance del MVP
+
+El MVP incluye:
+
+- descubrimiento publico mediante mapa y lista;
+- busqueda y filtros;
+- perfil publico del maker;
+- publicacion de trabajos y servicios;
+- cuenta unica para cliente y maker;
+- alta de maker en borrador;
+- suscripcion unica para aparecer publicamente;
+- contacto guiado;
+- mensajeria interna basica;
+- resenas verificadas;
+- moderacion y administracion basicas.
+
+Queda fuera del MVP:
+
+- compra de piezas o servicios dentro de la plataforma;
+- apps nativas;
+- favoritos;
+- comparacion entre makers;
+- escaparates tematicos;
+- multiples planes;
+- multiples ubicaciones por maker;
+- gamificacion;
+- publicidad;
+- patrocinio;
+- comunidad social;
+- cotizaciones automáticas.
+
+## 3. Actores
+
+### Visitante
+
+Persona que navega sin cuenta y puede:
+
+- explorar mapa y lista;
+- buscar y filtrar;
+- ver perfiles, trabajos y servicios;
+- iniciar una consulta;
+- registrarse sin perder el contexto.
+
+### Cliente registrado
+
+Usuario con cuenta que puede:
+
+- enviar consultas;
+- mantener conversaciones;
+- marcar un trabajo como completado si ambas partes lo confirman;
+- dejar una resena verificada cuando exista relacion valida;
+- gestionar su cuenta y privacidad.
+
+### Maker
+
+Usuario con cuenta que, ademas, puede:
+
+- crear un perfil profesional privado;
+- configurar una ubicacion publica;
+- publicar servicios;
+- publicar trabajos;
+- gestionar disponibilidad;
+- responder consultas;
+- contratar y gestionar su plan.
+
+### Admin
+
+Usuario interno que puede:
+
+- revisar makers, contenido y resenas;
+- gestionar casos e incidencias;
+- consultar estado de pagos;
+- suspender publicacion cuando exista causa;
+- acceder a auditoria basica.
+
+## 4. Objetos funcionales
+
+### Cuenta
+
+Identidad base del usuario. Una misma cuenta puede actuar como cliente y maker.
+
+### Perfil maker
+
+Ficha profesional del maker. Puede existir en borrador sin ser publica.
+
+### Ubicacion
+
+Unica ubicacion operativa del maker en el MVP. Se guarda con coordenada privada y proyeccion publica protegida cuando corresponda.
+
+### Servicio
+
+Oferta que explica que hace el maker, con capacidad, tecnologia y modalidades.
+
+### Trabajo
+
+Caso real publicado por el maker con fotos y descripcion.
+
+### Consulta
+
+Primer contacto estructurado entre cliente y maker.
+
+### Conversacion
+
+Hilo de mensajes asociado a una consulta.
+
+### Suscripcion
+
+Estado comercial del maker respecto a su aparicion publica.
+
+### Relacion
+
+Confirmacion de que la consulta llego a convertirse en trabajo realizado.
+
+### Resena
+
+Valoracion posterior a una relacion completada.
+
+### Caso de moderacion
+
+Registro interno para revisar contenido, resenas o conducta.
+
+## 5. Recorridos principales
+
+### 5.1 Descubrir un maker
+
+1. El visitante entra en la home.
+2. Ve mapa, lista o ambas vistas segun dispositivo.
+3. Puede usar ubicacion manual o geolocalizacion opcional.
+4. Aplica busqueda y filtros.
+5. Abre un perfil.
+6. Revisa trabajos, servicios, ubicacion publica y resenas.
+7. Inicia una consulta.
+
+### 5.2 Enviar una consulta
+
+1. El usuario pulsa contactar desde perfil, trabajo o servicio.
+2. La plataforma muestra un formulario guiado segun contexto.
+3. El usuario responde necesidad, material, tamano, cantidad, urgencia, envio y adjuntos permitidos.
+4. La plataforma genera un resumen editable.
+5. Si el usuario no esta registrado, se registra o accede sin perder el borrador.
+6. La consulta se envia una sola vez.
+7. Se crea una conversacion.
+
+### 5.3 Crear una presencia maker
+
+1. El usuario crea cuenta.
+2. Activa su area maker.
+3. Completa perfil basico.
+4. Configura una ubicacion.
+5. Declara disponibilidad.
+6. Publica al menos un servicio.
+7. Publica al menos un trabajo con foto.
+8. Contrata el plan.
+9. Solicita publicacion.
+10. El perfil pasa a visible si cumple requisitos y no tiene bloqueos.
+
+### 5.4 Gestionar una conversacion
+
+1. Cliente y maker ven la misma conversacion.
+2. Pueden responder y adjuntar imagenes o PDF.
+3. El maker puede rechazar la consulta con motivo.
+4. Ambas partes pueden continuar por canales externos si lo desean.
+5. La plataforma conserva el origen y el historial de mensajes internos.
+
+### 5.5 Generar una resena verificada
+
+1. La consulta existe.
+2. La conversacion deriva en trabajo realizado.
+3. Hay confirmacion de relacion completada.
+4. El cliente recibe invitacion para valorar.
+5. Se permite una sola resena por relacion y autor.
+6. La resena puede ser reportada y moderada.
+
+## 6. Modulos funcionales
+
+### 6.1 Descubrimiento publico
+
+Incluye:
+
+- home con propuesta de valor;
+- mapa interactivo;
+- lista de resultados;
+- busqueda textual;
+- filtros;
+- perfil publico;
+- detalle de trabajo;
+- detalle de servicio.
+
+No incluye:
+
+- feed social;
+- ranking por popularidad;
+- favoritos;
+- comparacion;
+- contenidos patrocinados.
+
+### 6.2 Perfil publico del maker
+
+Debe mostrar:
+
+- nombre comercial;
+- descripcion;
+- localidad y provincia;
+- cobertura local y modalidad de envio;
+- disponibilidad declarada;
+- servicios;
+- trabajos;
+- resenas verificadas;
+- CTA de contacto.
+
+No debe mostrar:
+
+- direccion privada;
+- telefonos privados si no han sido marcados como publicos;
+- datos fiscales;
+- senales internas de riesgo;
+- metricas vanidosas sin valor publico.
+
+### 6.3 Servicios
+
+Cada maker debe poder publicar servicios con:
+
+- tipo de servicio;
+- descripcion;
+- tecnologias compatibles;
+- materiales compatibles;
+- modalidad local y/o envio;
+- plazos orientativos;
+- precio orientativo opcional.
+
+### 6.4 Trabajos
+
+Cada trabajo debe incluir:
+
+- titulo;
+- descripcion orientada a cliente;
+- fotos;
+- tecnologia o servicio relacionado;
+- material cuando aplique;
+- resultado mostrado;
+- enlace de contacto contextual.
+
+### 6.5 Cuenta y acceso
+
+El sistema debe permitir:
+
+- registro por email y contrasena;
+- verificacion de email;
+- login;
+- recuperacion de contrasena;
+- cierre de sesion;
+- gestion basica de privacidad.
+
+### 6.6 Area maker
+
+Debe permitir:
+
+- editar perfil;
+- editar ubicacion;
+- editar disponibilidad;
+- crear y editar servicios;
+- crear y editar trabajos;
+- consultar estado de publicacion;
+- consultar estado de suscripcion;
+- responder conversaciones;
+- ver resenas recibidas.
+
+### 6.7 Suscripcion y publicacion
+
+Reglas:
+
+- existe un unico plan;
+- pagar no publica automaticamente;
+- la publicacion requiere accion explicita del maker;
+- el perfil solo es visible si cumple minimos y no tiene suspension;
+- al perder suscripcion, el contenido se conserva pero deja de ser visible publicamente.
+
+### 6.8 Moderacion
+
+Se moderan:
+
+- perfiles;
+- trabajos;
+- servicios;
+- resenas;
+- reportes de conducta.
+
+El sistema debe permitir:
+
+- reportar;
+- revisar;
+- dejar evidencia;
+- tomar una medida;
+- dejar trazabilidad.
+
+## 7. Reglas de negocio
+
+1. La plataforma cobra por presencia profesional, no por transaccion.
+2. El ranking organico no se vende.
+3. El perfil publico exige:
+   - suscripcion activa o habilitacion comercial valida;
+   - perfil completo;
+   - una ubicacion;
+   - un servicio;
+   - un trabajo con foto;
+   - un medio de contacto;
+   - ausencia de suspension.
+4. La distancia se calcula con coordenada privada, pero se muestra redondeada.
+5. Un maker que trabaja desde casa no publica direccion exacta por defecto.
+6. La geolocalizacion del visitante es opcional.
+7. La plataforma no garantiza contratacion ni ingresos al maker.
+8. Las resenas validas solo nacen de relaciones registradas en la plataforma.
+9. No se permiten likes, comentarios publicos ni popularidad social.
+10. Los resultados patrocinados no forman parte del MVP.
+11. Un archivo subido al sistema no se publica sin pasar por las reglas del contexto correspondiente.
+12. El contacto puede continuar fuera de la plataforma, pero el origen queda registrado.
+
+## 8. Estados principales
+
+### Perfil maker
+
+- borrador;
+- listo para publicar;
+- publicado;
+- suspendido;
+- oculto por suscripcion inactiva;
+- eliminado.
+
+### Consulta
+
+- borrador;
+- enviada;
+- respondida;
+- rechazada;
+- cerrada;
+- convertida en relacion.
+
+### Suscripcion
+
+- pendiente;
+- activa;
+- en gracia;
+- vencida;
+- cancelada.
+
+### Resena
+
+- publicada;
+- reportada;
+- en revision;
+- retirada.
+
+## 9. Modelo funcional minimo
+
+| Entidad | Relacion principal |
+|---|---|
+| Cuenta | 1 cuenta puede ser cliente y maker |
+| Perfil maker | 1 cuenta puede tener 1 perfil maker activo |
+| Ubicacion | 1 perfil maker tiene 1 ubicacion operativa en MVP |
+| Servicio | 1 perfil maker tiene muchos servicios |
+| Trabajo | 1 perfil maker tiene muchos trabajos |
+| Consulta | 1 cliente abre 1 consulta hacia 1 maker |
+| Conversacion | 1 consulta genera 1 conversacion |
+| Mensaje | muchos mensajes pertenecen a 1 conversacion |
+| Suscripcion | 1 perfil maker tiene 1 suscripcion vigente como maximo |
+| Relacion | 1 consulta puede generar 0 o 1 relacion completada |
+| Resena | 1 relacion permite 1 resena por cliente |
+| Caso | puede referenciar perfil, contenido, resena o usuario |
+
+## 10. Criterios de aceptacion por modulo
+
+### Descubrimiento
+
+- un visitante puede buscar sin cuenta;
+- puede usar mapa o lista;
+- puede entender por que un maker aparece;
+- nunca ve direccion privada.
+
+### Perfil maker
+
+- muestra oferta, evidencia y contacto en una sola vista;
+- no muestra informacion privada;
+- permite abrir consulta desde varias entradas.
+
+### Publicacion maker
+
+- el maker puede guardar borradores;
+- sabe exactamente que le falta para publicar;
+- el sistema no publica perfiles vacios.
+
+### Contacto y mensajeria
+
+- el contexto del origen se conserva;
+- el registro no destruye el borrador;
+- no se crean mensajes duplicados por doble click o recarga.
+
+### Suscripcion
+
+- el pago se registra;
+- la activacion economica no publica automaticamente;
+- una suscripcion vencida retira la visibilidad publica sin borrar contenido.
+
+### Resenas y moderacion
+
+- solo hay resenas verificadas desde relacion completada;
+- toda accion de moderacion deja auditoria;
+- el admin puede retirar contenido si existe causa.

docs/Makers3D_Matriz_Trazabilidad.md

@@ -0,0 +1,78 @@
+# Makers3D - Matriz de Trazabilidad
+
+## 1. Cobertura cruzada
+
+| Capacidad | Negocio | Especificacion | UX/UI | Arquitectura | Plan | Estado |
+|---|---|---|---|---|---|---|
+| Descubrimiento por mapa y lista | captar demanda y demostrar valor rapido | 5.1, 6.1 | 4.1, 4.2 | 3, 8, 10 | F3 | CUBIERTO |
+| Perfil publico del maker | convertir visita en confianza | 5.1, 6.2 | 4.3 | 6 | F2, F3 | CUBIERTO |
+| Servicios publicados | explicar oferta | 6.3 | 4.9 | 6 | F2 | CUBIERTO |
+| Trabajos con fotos | mostrar evidencia real | 6.4 | 4.4, 4.10 | 8 | F2 | CUBIERTO |
+| Cuenta unica | reducir friccion | 3, 6.5 | 4.8 | 9 | F1 | CUBIERTO |
+| Perfil maker privado | preparar oferta antes de pagar | 5.3, 6.6 | 4.8 | 6 | F1 | CUBIERTO |
+| Suscripcion unica | monetizacion simple | 6.7 | 4.11 | 3, 10 | F5 | CUBIERTO |
+| Publicacion con minimos | proteger calidad del mapa | 6.7, 7 | 4.8 | 6, 9 | F2, F5 | CUBIERTO |
+| Contacto guiado | subir calidad de consulta | 5.2, 6.1, 6.7 | 4.6 | 10 | F4 | CUBIERTO |
+| Mensajeria interna | trazabilidad y relacion | 5.4, 6.7 | 4.7 | 10 | F4 | CUBIERTO |
+| Resena verificada | confianza basada en hechos | 5.5, 6.8 | 4.7, 4.12 | 6, 9 | F6 | CUBIERTO |
+| Moderacion y admin | operar beta real | 6.8 | 4.12 | 9, 14 | F6 | CUBIERTO |
+| Backups y restore | continuidad operativa | 7, 10 | 8 | 12 | F7 | CUBIERTO |
+| Seguridad base | proteger usuarios y cobros | 7 | 9 | 13 | F1-F7 | CUBIERTO |
+
+## 2. Diferidos confirmados
+
+| Componente | Estado | Razon |
+|---|---|---|
+| Favoritos | FASE 2 | No cambia la validacion del negocio inicial. |
+| Comparacion entre makers | FASE 2 | Util, pero no critica para beta. |
+| Escaparates | FASE 2 | Aportan presentacion, no nucleo. |
+| Multiples ubicaciones | FASE 2 | Complejidad geoespacial adicional. |
+| Dashboard y analitica avanzada | FASE 2 | Primero hay que generar actividad real. |
+| PWA avanzada | FASE 2 | La web responsive cubre el objetivo inicial. |
+| Patrocinio y publicidad | FASE 3 | Requiere reglas maduras y volumen. |
+| Apps nativas | FASE 3 | No aceleran lanzamiento. |
+
+## 3. Eliminados del MVP
+
+| Componente | Motivo |
+|---|---|
+| Marketplace | Cambia el modelo de negocio y complica pagos, legales y soporte. |
+| Gamificacion | No resuelve el problema principal. |
+| Likes y comentarios publicos | Generan ruido y senales falsas. |
+| Resenas externas no verificadas | Debilitan la confianza. |
+| WebSockets | Polling basta en beta. |
+| Microservicios | Añaden despliegue y mantenimiento sin necesidad. |
+| Kafka, RabbitMQ, Elastic, OpenSearch, Kubernetes | Sobreingenieria clara para el volumen esperado. |
+
+## 4. Auditoria transversal final
+
+### No existen contradicciones abiertas entre documentos
+
+- El modelo de negocio habla de una sola suscripcion y la especificacion tambien.
+- UX no define pantallas de favoritos, comparacion o escaparates, coherente con el alcance.
+- Arquitectura no introduce servicios que el plan no necesite.
+- El plan no ordena construir modulos eliminados.
+
+### No existen pantallas sin logica
+
+- Cada pantalla del manual UX esta respaldada por un modulo funcional.
+
+### No existen tablas o dominios sin uso funcional
+
+- La arquitectura solo conserva entidades necesarias para descubrimiento, contacto, cobro, reputacion y operacion.
+
+### No existen servicios sin justificar
+
+- Todos los servicios activos tienen una responsabilidad directa en la entrega del MVP.
+
+### No existe sobreingenieria critica pendiente
+
+- Se descartan microservicios, orquestacion compleja, tiempo real avanzado y motores externos.
+
+## 5. Resultado
+
+AUDITORIA SUPERADA
+
+- Sin contradicciones detectadas entre los documentos finales.
+- Sin huecos funcionales criticos para el MVP definido.
+- Sin componentes tecnicos injustificados para la fase inicial.

docs/Makers3D_Plan_Desarrollo.md

@@ -0,0 +1,415 @@
+# 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.

docs/Makers3D_UX_UI.md

@@ -0,0 +1,428 @@
+# Makers3D - UX UI
+
+## 1. Principios
+
+1. Menos pasos, mas claridad.
+2. El mapa atrae; el trabajo publicado convierte.
+3. Todo CTA importante debe estar disponible tambien fuera del mapa.
+4. La interfaz debe explicar confianza sin inventar prestigio.
+5. Ninguna pantalla debe depender de datos que el MVP todavia no sabe medir con honestidad.
+
+## 2. Direccion visual
+
+### Personalidad
+
+- tecnica;
+- cercana;
+- clara;
+- confiable;
+- visual;
+- sobria.
+
+### Sistema visual
+
+- fondo principal: grafito profundo;
+- superficies: azul grisaceo oscuro;
+- accion primaria: azul electrico;
+- acento secundario: cyan frio;
+- exito: verde controlado;
+- alerta: ambar;
+- error: rojo sobrio.
+
+### Tipografia
+
+- titulos: `Space Grotesk`;
+- interfaz y cuerpo: `Manrope`;
+- datos tecnicos o chips: `IBM Plex Sans`.
+
+### Radio y forma
+
+- tarjetas y modales: 18 px;
+- chips y botones pequenos: 999 px;
+- sombras suaves, no teatrales;
+- bordes sutiles para separar sin endurecer la UI.
+
+## 3. Navegacion
+
+### Publica
+
+- Inicio
+- Resultados
+- Perfil maker
+- Trabajo
+- Servicio
+- Acceso / Registro
+- Consultas
+
+### Privada maker
+
+- Resumen
+- Perfil
+- Servicios
+- Trabajos
+- Bandeja
+- Resenas
+- Suscripcion
+- Cuenta
+
+### Admin
+
+- Makers
+- Casos
+- Resenas
+- Pagos
+- Auditoria
+
+## 4. Pantallas obligatorias
+
+### 4.1 Inicio
+
+Objetivo:
+
+- explicar rapidamente que hace la plataforma;
+- llevar al usuario a buscar por zona o necesidad.
+
+Bloques:
+
+- hero con buscador;
+- acceso a geolocalizacion opcional;
+- vista inicial de mapa o lista segun dispositivo;
+- categorias o necesidades frecuentes;
+- explicacion simple de como funciona.
+
+### 4.2 Resultados
+
+Objetivo:
+
+- combinar descubrimiento geografico con evaluacion rapida.
+
+Elementos:
+
+- buscador superior;
+- filtros visibles;
+- conmutador lista/mapa en movil;
+- lista de tarjetas;
+- mapa con clusters;
+- aviso claro cuando la geolocalizacion no esta activa;
+- estados vacios y alternativa de ampliar zona.
+
+### 4.3 Perfil publico del maker
+
+Objetivo:
+
+- convertir curiosidad en confianza y confianza en consulta.
+
+Jerarquia:
+
+- cabecera con nombre, localidad, disponibilidad y CTA;
+- servicios principales;
+- trabajos publicados;
+- resenas verificadas;
+- informacion de cobertura y envio;
+- datos de contacto publicos si el maker decide mostrarlos.
+
+### 4.4 Detalle de trabajo
+
+Objetivo:
+
+- demostrar calidad y contexto.
+
+Contenido:
+
+- galeria;
+- titulo;
+- problema resuelto;
+- solucion aplicada;
+- servicio relacionado;
+- CTA "Quiero algo parecido".
+
+### 4.5 Detalle de servicio
+
+Objetivo:
+
+- aclarar que puede contratarse.
+
+Contenido:
+
+- tipo de servicio;
+- descripcion;
+- tecnologias y materiales;
+- modalidad local y envio;
+- plazo orientativo;
+- precio orientativo opcional;
+- CTA de consulta contextual.
+
+### 4.6 Contacto guiado
+
+Objetivo:
+
+- obtener una consulta mas util que un "hola, cuanto sale?".
+
+Flujo:
+
+1. necesidad;
+2. detalles del trabajo;
+3. urgencia y entrega;
+4. adjuntos permitidos;
+5. resumen editable;
+6. registro o acceso si hace falta;
+7. confirmacion.
+
+### 4.7 Bandeja y conversacion
+
+Objetivo:
+
+- sostener el intercambio minimo necesario.
+
+Vista:
+
+- lista de conversaciones;
+- ficha breve del contexto;
+- hilo de mensajes;
+- composer;
+- estado de envio;
+- acciones de rechazo o cierre.
+
+### 4.8 Alta maker
+
+Objetivo:
+
+- convertir una cuenta normal en presencia profesional.
+
+Pasos:
+
+- datos del perfil;
+- ubicacion;
+- disponibilidad;
+- primer servicio;
+- primer trabajo;
+- resumen de requisitos;
+- suscripcion;
+- solicitud de publicacion.
+
+### 4.9 Gestion de servicios
+
+Objetivo:
+
+- publicar una oferta clara y mantenible.
+
+Vista:
+
+- lista de servicios;
+- crear/editar;
+- activar/desactivar;
+- indicador de servicio incompleto.
+
+### 4.10 Gestion de trabajos
+
+Objetivo:
+
+- construir portfolio con el menor esfuerzo posible.
+
+Vista:
+
+- lista de trabajos;
+- borradores y publicados;
+- formulario con fotos primero;
+- vista previa publica;
+- control de minimos.
+
+### 4.11 Suscripcion
+
+Objetivo:
+
+- explicar el estado comercial sin ambiguedad.
+
+Contenido:
+
+- plan actual;
+- precio;
+- estado;
+- fecha relevante;
+- accion principal;
+- aviso de que pagar no publica automaticamente.
+
+### 4.12 Moderacion y admin
+
+Objetivo:
+
+- operar sin glamour, con velocidad y trazabilidad.
+
+Pantallas:
+
+- listado de makers;
+- cola de casos;
+- detalle de caso;
+- detalle de pago;
+- historial de acciones.
+
+## 5. Wireframes textuales
+
+### Inicio movil
+
+```text
+[Logo]              [Entrar]
+
+Encuentra quien imprime cerca de ti
+[Buscar por pieza, material o servicio]
+[Usar mi ubicacion] [Elegir ciudad]
+
+[Mapa/Lista]
+[Filtros rapidos]
+[Tarjetas de makers]
+```
+
+### Perfil maker movil
+
+```text
+[Portada]
+[Avatar] Nombre del maker
+Localidad - Disponibilidad
+[Contactar]
+
+Servicios
+[chips]
+
+Trabajos
+[galeria vertical]
+
+Resenas verificadas
+[bloques]
+
+Informacion
+```
+
+### Contacto guiado movil
+
+```text
+Paso 2 de 5
+Que necesitas imprimir o fabricar?
+[campo]
+
+Tienes archivo?
+( ) Si
+( ) No
+
+[Adjuntar imagen o PDF]
+[Continuar]
+```
+
+### Area maker movil
+
+```text
+Hola, Nombre
+Estado: listo para publicar / publicado / incompleto
+
+Te falta para publicar
+- Ubicacion
+- Primer trabajo
+
+[Editar perfil]
+[Crear servicio]
+[Crear trabajo]
+[Ver suscripcion]
+```
+
+## 6. Componentes
+
+### Basicos
+
+- boton primario;
+- boton secundario;
+- chip de filtro;
+- tarjeta de maker;
+- tarjeta de trabajo;
+- tarjeta de servicio;
+- badge de estado;
+- barra superior;
+- bottom sheet movil;
+- modal de confirmacion.
+
+### Formularios
+
+- input de texto;
+- textarea;
+- select;
+- chips multiseleccion;
+- subida de imagen;
+- subida de PDF;
+- resumen revisable.
+
+### Feedback
+
+- skeleton;
+- vacio;
+- error;
+- exito;
+- aviso;
+- bloqueo por requisito pendiente.
+
+## 7. Estados
+
+Toda pantalla relevante debe contemplar:
+
+- carga;
+- vacio;
+- error;
+- sin permisos;
+- sin conexion momentanea;
+- accion exitosa;
+- accion duplicada bloqueada.
+
+## 8. Responsive
+
+### Movil
+
+- prioridad absoluta;
+- mapa y lista no compiten en pantalla reducida;
+- CTA fijo en perfil y trabajo;
+- formularios en un solo eje vertical.
+
+### Tablet
+
+- mas densidad de tarjetas;
+- filtros laterales cuando convenga;
+- lista y mapa pueden convivir parcialmente.
+
+### Escritorio
+
+- mapa y lista simultaneos en descubrimiento;
+- bandeja con dos columnas;
+- admin con tablas densas.
+
+## 9. Accesibilidad
+
+- contraste AA como minimo;
+- foco visible;
+- navegacion completa por teclado;
+- labels reales en formularios;
+- mensajes de error claros;
+- alternativa funcional al mapa;
+- respeto a `prefers-reduced-motion`;
+- iconos nunca como unico soporte semantico.
+
+## 10. Animacion
+
+Mantener solo animaciones con utilidad:
+
+- aparicion suave de clusters;
+- subida de bottom sheet;
+- confirmacion de mensaje enviado;
+- transicion corta al aplicar filtros.
+
+No usar:
+
+- parallax;
+- counters de vanidad;
+- animaciones largas de carga;
+- efectos de marca que ralenticen la tarea.
+
+## 11. Criterio de calidad UX
+
+Una pantalla esta bien resuelta si:
+
+1. el usuario entiende que hacer en menos de cinco segundos;
+2. la accion principal es obvia;
+3. no depende de datos falsos o insuficientes;
+4. el sistema evita callejones sin salida;
+5. la confianza aumenta antes del contacto.

docs/Makers3D_Vision_Negocio.md

@@ -0,0 +1,248 @@
+# Makers3D - Vision de Negocio
+
+## 1. Tesis
+
+Makers3D quiere resolver un problema concreto y cotidiano: encontrar un proveedor fiable de impresion o fabricacion 3D sin depender de busquedas desordenadas en redes sociales, Google y WhatsApp.
+
+La oportunidad no esta en vender objetos dentro de la plataforma, sino en ordenar una oferta fragmentada y convertirla en presencia profesional pagable.
+
+## 2. Problema
+
+Hoy el cliente no sabe:
+
+- quien puede resolver su necesidad;
+- quien esta cerca;
+- quien envia;
+- quien ya hizo trabajos parecidos;
+- quien responde bien;
+- en quien se puede confiar.
+
+Hoy el maker tampoco tiene un escaparate profesional especializado ni un canal comun donde competir por calidad, especializacion y reputacion en lugar de depender solo de Instagram o del boca a boca.
+
+## 3. Propuesta de valor
+
+### Para clientes
+
+- descubrir makers por ubicacion y capacidad;
+- ver trabajos reales antes de escribir;
+- comparar especializacion y reputacion verificable;
+- iniciar una consulta con contexto util;
+- reducir tiempo y riesgo antes del primer contacto.
+
+### Para makers
+
+- presencia profesional visible en un canal especializado;
+- llegada a clientes locales y nacionales;
+- portfolio ordenado;
+- reputacion construida sobre trabajos reales;
+- un flujo de consultas mas util que un mensaje vacio por redes.
+
+## 4. Mercado
+
+El mercado inicial es Argentina, con foco en:
+
+- personas que necesitan piezas, repuestos o impresiones puntuales;
+- profesionales creativos y tecnicos;
+- pequenos negocios y talleres;
+- makers independientes;
+- estudios y microempresas de fabricacion digital.
+
+La expansion geografica no es prioridad inicial. Antes debe validarse:
+
+- densidad de oferta por zona;
+- tasa de consulta util;
+- conversion de maker a pago;
+- retencion de makers publicados.
+
+## 5. Competencia real
+
+La competencia principal no son otras startups especializadas. Son los sustitutos actuales:
+
+- Instagram;
+- Facebook;
+- Google Maps;
+- Mercado Libre como canal impropio;
+- grupos de WhatsApp;
+- recomendaciones personales;
+- sitios web individuales.
+
+Makers3D no gana por tener mas funciones. Gana por:
+
+- especializacion sectorial;
+- mejor contexto antes del contacto;
+- evidencia visual estructurada;
+- reputacion ligada a relaciones reales;
+- busqueda geografica y funcional en el mismo lugar.
+
+## 6. Modelo de ingresos
+
+### Modelo inicial
+
+- un solo plan de suscripcion;
+- el maker paga por aparecer publicamente;
+- el cliente no paga;
+- la plataforma no toma comision por trabajo.
+
+### Por que este modelo
+
+- es simple de explicar;
+- es simple de operar;
+- evita negociar comisiones o custodiar pagos;
+- filtra perfiles poco comprometidos;
+- se alinea con el valor principal: visibilidad profesional.
+
+### Ingresos futuros posibles
+
+- complementos funcionales reales;
+- mayor capacidad de contenido;
+- herramientas avanzadas para makers;
+- espacios patrocinados claramente etiquetados.
+
+No entran en la fase inicial:
+
+- comision por transaccion;
+- reputacion pagada;
+- posicion organica vendida;
+- publicidad invasiva.
+
+## 7. Roadmap de negocio
+
+### Etapa 1 - Beta cerrada
+
+Objetivo:
+
+- validar que los makers pagan por presencia;
+- validar que los clientes entienden el valor del mapa y del portfolio;
+- medir si el contacto guiado mejora la calidad de las consultas.
+
+### Etapa 2 - Beta ampliada
+
+Objetivo:
+
+- aumentar oferta por zonas con suficiente densidad;
+- mejorar retencion del maker;
+- estabilizar soporte, cobros y moderacion.
+
+### Etapa 3 - Crecimiento controlado
+
+Objetivo:
+
+- ampliar provincias;
+- introducir SEO mas fuerte;
+- lanzar herramientas de retencion y analitica;
+- evaluar patrocinio etiquetado.
+
+### Etapa 4 - Expansion
+
+Objetivo:
+
+- decidir si conviene abrir nuevas categorias, nuevos paises o evolucionar a un modelo comercial mas profundo.
+
+## 8. Riesgos
+
+### Riesgos de producto
+
+- mapa sin oferta suficiente;
+- baja calidad de perfiles;
+- consultas pobres o poco convertibles;
+- exceso de complejidad antes de tener uso real.
+
+### Riesgos comerciales
+
+- makers que no perciben valor suficiente para pagar;
+- concentracion geografica en pocas zonas;
+- demanda insuficiente al inicio;
+- soporte manual costoso si el flujo no esta claro.
+
+### Riesgos operativos
+
+- moderacion insuficiente;
+- conciliacion de pagos defectuosa;
+- mala entregabilidad del correo;
+- caidas o perdida de datos.
+
+## 9. Ventajas competitivas defendibles
+
+- foco exclusivo en makers 3D;
+- descubrimiento geografico + portfolio + reputacion en una sola experiencia;
+- reputacion nacida de relaciones dentro de la plataforma;
+- menor dependencia de algoritmos sociales externos;
+- modelo simple de monetizacion;
+- operacion posible con equipo pequeno.
+
+## 10. Estructura de costes
+
+### Costes fijos principales
+
+- servidores;
+- almacenamiento;
+- correo transaccional;
+- dominios y certificados;
+- soporte operativo minimo;
+- tiempo de moderacion y atencion al maker.
+
+### Costes variables principales
+
+- trafico de imagenes y mapas;
+- volumen de correo;
+- soporte;
+- comisiones de pago;
+- almacenamiento de portfolios.
+
+### Regla de control
+
+No se añade una tecnologia o funcionalidad si:
+
+- no aumenta conversion;
+- no mejora confianza;
+- no reduce soporte;
+- o no reduce riesgo operativo real.
+
+## 11. KPIs de direccion
+
+### Oferta
+
+- makers en borrador;
+- makers publicados;
+- makers con suscripcion activa;
+- cobertura geografica por provincia.
+
+### Demanda
+
+- visitas a perfiles;
+- consultas iniciadas;
+- consultas enviadas;
+- ratio visita a consulta.
+
+### Calidad
+
+- tiempo medio de primera respuesta;
+- porcentaje de consultas rechazadas;
+- porcentaje de relaciones completadas;
+- porcentaje de resenas verificadas.
+
+### Negocio
+
+- conversion maker gratuito a pago;
+- churn de makers;
+- ingreso mensual recurrente;
+- coste operativo por maker activo.
+
+### Riesgo
+
+- casos de moderacion por cada 100 consultas;
+- pagos inconsistentes;
+- tiempo medio de resolucion;
+- incidentes tecnicos criticos.
+
+## 12. Pitch corto
+
+Makers3D organiza el mercado fragmentado de impresion y fabricacion 3D en Argentina. Ayuda a cualquier persona a encontrar un maker fiable cerca suyo o con envio, ver trabajos reales, entender capacidades y contactarlo con contexto suficiente. Cobra a los makers por una presencia profesional visible, sin convertirse en marketplace ni intermediar el pago del trabajo.
+
+## 13. Decision de negocio final
+
+El producto no debe optimizarse para parecer grande. Debe optimizarse para demostrar tres cosas lo antes posible:
+
+1. que hay makers dispuestos a pagar por aparecer;
+2. que los clientes encuentran oferta relevante mas rapido que en redes;
+3. que la reputacion y el portfolio convierten mejor cuando el contacto empieza con contexto.

docs/Production_Checklist.md

@@ -0,0 +1,57 @@
+# Makers3D - Production Checklist
+
+## Antes de usuarios reales
+
+- Cambiar todas las credenciales demo.
+- Cambiar `SESSION_SECRET`.
+- Configurar dominio y HTTPS real delante de Nginx.
+- Sustituir `PAYMENT_PROVIDER=demo` por el proveedor real.
+- Validar correo transaccional real.
+- Confirmar politicas de privacidad y terminos.
+- Probar login, publicacion y consulta desde movil Android real.
+
+## Antes de cobros reales
+
+- Cargar credenciales reales de Mercado Pago.
+- Confirmar URLs y webhooks productivos.
+- Validar que pagar no publica automaticamente.
+- Ejecutar prueba completa de activacion, renovacion y cancelacion.
+- Registrar responsable operativo de conciliacion.
+
+## Seguridad minima
+
+- Limitar acceso SSH por IP o clave.
+- Mantener Debian actualizado.
+- No publicar puertos internos salvo `80/443`.
+- Respaldar `.env` fuera del servidor.
+- Revisar logs de `api`, `nginx` y `worker`.
+
+## Backup minimo
+
+- Backup diario de PostgreSQL.
+- Backup diario de buckets de MinIO.
+- Ensayo de restauracion antes de abrir beta real.
+
+## Escalado recomendado
+
+Primero:
+
+- mas RAM;
+- mas disco;
+- cache HTTP;
+- tuning de PostgreSQL.
+
+Despues:
+
+- Redis si aparece necesidad real;
+- CDN si el trafico de imagenes lo justifica;
+- observabilidad mas profunda si la operacion lo exige.
+
+## No hacer todavia
+
+- microservicios;
+- Kubernetes;
+- Elastic u OpenSearch;
+- WebSockets;
+- app nativa;
+- features sociales.