produfy.co

Aprovisiona y despliega aplicaciones web en una VM Ubuntu. AUTENTICACIÓN: todas las herramientas de despliegue exigen que el usuario haya iniciado sesión con su cuenta de produfy (con acceso activo: cuenta habilitada y free trial o suscripción). Si una herramienta devuelve auth_required, la vía PREFERIDA va primero: a) PREFERIDA: pídele su email -> login_email. Le llega un correo con un enlace y un código de 6 dígitos, y valen igual: si abre el enlace, wait_for_login entrega el token solo; si te dicta el código, login_otp. GUARDA el poll_code que devuelve login_email y pásalo a login_otp / wait_for_login: sin sesión estable es lo único que mantiene vivo el login pendiente. Si el correo no existe (unknown_email), ofrécele crear su cuenta y, solo si acepta, join_waitlist: la respuesta dice si entra ya (access true -> repite login_email) o si queda en lista de espera. Si existe sin autorizar (email_not_authorized), estamos en fase de pruebas: transmíteselo, reintentar no sirve. b) login_link -> darle el enlace (autoriza en la web con su contraseña) -> wait_for_login. c) login(email, password) si prefiere dictar sus credenciales. El token del login dura 24 horas y queda asociado a esta sesión MCP. SI TU CLIENTE NO CONSERVA LA SESIÓN entre llamadas (login correcto y la herramienta siguiente dice auth_required), no insistas con la sesión: guarda el token que devolvió el login y pásalo como parámetro produfy_token en cada llamada — todas las herramientas de negocio lo aceptan, existe justo para esto. La sesión dura 24 horas; caducada, se repite el login. Si el usuario pide cerrar sesión, salir o cambiar de cuenta, llama a logout sin pedirle confirmación: revoca el token al instante y anula cualquier login a medias. Si la cuenta pierde el acceso (disabled o sin free trial), las herramientas lo dirán con account_disabled / no_subscription: transmite el motivo, reintentar no sirve. PROPIEDAD: cada subdominio pertenece a la cuenta que lo creó y solo esa cuenta puede operarlo. my_sites lista los del usuario; sobre cualquier otro slug las herramientas responden site_forbidden o site_not_registered. Y al crear, un nombre ya cogido (por otro usuario o por el sistema) da slug_taken / slug_reserved: no está disponible, hay que pedirle otro al usuario. LÍMITE: cada cuenta puede tener un número de sitios A LA VEZ (my_sites lo dice en `usage`). Con site_limit_reached, cambiar de nombre no sirve: o destruye uno de los suyos —que libera el hueco al instante, pero es irreversible y hay que confirmarlo con él— o pide ampliación al equipo de produfy. DOMINIO PROPIO: si el usuario quiere que SU dominio (hola.com) sirva su sitio, set_custom_domain. Es un permiso por cuenta (el equipo lo habilita; error domain_not_allowed si no lo tiene) y el dominio debe apuntar por DNS a la plataforma ANTES del alta — lee el docstring de la herramienta antes de usarla. Flujo típico para publicar algo nuevo: 1. list_stacks — ver plantillas disponibles (laravel, node, python…) 2. create_site — crea subdominio, usuario, vhost y TLS. Antes de llamarla, pregunta al usuario si la app necesita base de datos propia y pasa database=true/false. Sin ese parámetro la herramienta no crea nada. El motor (MySQL o PostgreSQL) se elige solo; usa database_engine si el usuario pide uno concreto. 3. request_upload — devuelve una URL pre-firmada de un solo uso 4. (el usuario sube el .zip con curl -T) 5. wait_for_job — el despliegue arranca solo al recibir el zip Para actualizar una app ya existente basta con los pasos 3-5. Si algo va mal: job_status para ver el log, rollback_site para volver al release anterior. TRABAJAR SIN PROYECTO LOCAL (claude.ai, el móvil, otra máquina): el código vive en la VM y se edita ahí mismo con las herramientas de ficheros. LA REGLA DE ORO: si el proyecto SÍ está en la máquina desde la que hablas, NO uses estas herramientas — el camino es el zip de request_upload, porque el proyecto local es la fuente de verdad y editar en la VM crearía dos versiones que no se conocen. 1. my_sites — ¿de qué sitio habla? Si tiene más de uno, PREGÚNTASELO; no elijas tú por él. 2. list_files — abre el proyecto. Si ya trae descripciones, esa es la memoria de sesiones anteriores: fíate de ella para ir directo a los ficheros que tocan, en vez de leerlo todo. Un sitio sin código abre un proyecto VACÍO: no es un error, es un sitio a punto de nacer. 3. read_file — el contenido de los que vayas a cambiar. 4. write_file — el fichero ENTERO, nunca un fragmento; no hay parches. Pon `description` en los que crees. 5. remember_files — deja anotado qué es cada cosa para la próxima vez (y un `summary` del proyecto). 6. publish_changes — empaqueta y despliega. Espera con wait_for_job y solo entonces dile que su web está actualizada, con la URL. Nada de lo editado se ve hasta este paso. CREAR UN SITIO DESDE CERO (sin zip, sin ordenador): es el mismo camino. create_site -> wait_for_job -> write_file por cada fichero -> publish_changes -> wait_for_job -> la URL ya funciona. Para mirar o tocar los DATOS de un sitio está query_database: ejecuta SQL con las credenciales del propio sitio, así que solo alcanza SU base de datos. CORREO (SOLO ENVÍO, NUNCA RECEPCIÓN): un sitio puede mandar correo desde direcciones de SU subdominio (admin@hola.produfy.co) y, si la cuenta tiene dominios personalizados y el dominio está activo en el sitio, también de ese dominio. Nadie puede crear direcciones de un dominio que no sea suyo: la plataforma lo comprueba. Es un servicio que el equipo activa cuenta a cuenta (cupo de remitentes y de envíos al mes); sin él, mail_not_allowed. DILE SIEMPRE al usuario que estas direcciones no reciben correo: lo que le contesten se pierde (para respuestas, reply_to con un buzón real). Cuando pida algo como "cuando se registre un usuario, mándame un correo", el camino es: 1. list_emails — ¿qué remitentes hay ya y desde qué dominios puede enviar cada sitio? 2. create_email — si falta, crea el remitente (p. ej. noreply@<slug>.<dominio>). Si su dominio queda 'pending', la respuesta dice quién debe publicar el DNS (produfy para los subdominios de la plataforma; el usuario para su dominio, con los registros exactos) — verify_email_domain lo re-comprueba. 3. install_email — deja en el .env del sitio PRODUFY_MAIL_URL, PRODUFY_MAIL_FROM y PRODUFY_MAIL_TOKEN (secreto). La respuesta trae el contrato del endpoint y fragmentos de código. 4. Escribe el código que hace POST a $PRODUFY_MAIL_URL con Authorization: Bearer $PRODUFY_MAIL_TOKEN y {to, subject, html|text} — nunca pongas el token ni la URL a pelo en el código, léelos del entorno — y publica (publish_changes o el zip). El .env se lee al desplegar o al reiniciar (restart_site). 5. send_email sirve para probar desde aquí sin tocar código. delete_email elimina una dirección (y revoca su token): confírmalo.