SLEAK-6484: doc del workload Static Site + flujo static por MCP

content/docs/en/powered-ai/mcp.mdx

@@ -87,6 +87,16 @@ The import tools register resources that already exist in your AWS accounts —
 
 Onboarding a new AWS account (provider, account, network configuration) and importing an EKS cluster are done with the console's import wizard, not through the MCP.
 
+### Deploying a static site end-to-end
+
+With the `static` feature in your subscription, the agent can take a frontend repository to a published site in a single conversation. The target environment must already exist and have a domain configured (see [Static Site](/docs/project/workload/static)) — environments are created in the console.
+
+1. **Create the project** — "Create a static project for repo X on the dev environment, building with Node 20, `npm run build`, output in `dist`". The agent calls `create_project` with `method="static"` and the three build fields (`node_version`, `build_command`, `output_path`).
+2. **Attach the site's domain** — "Serve it at landing.dev.example.com". The agent calls `create_static`; the URL must be a direct subdomain of the environment's domain. Do this **before** the first deployment: a static project's deployable workloads are its Statics, so a deployment without one is rejected.
+3. **First publish is automatic** — once the site's domain is active, SleakOps triggers the first build and its deploy on its own.
+4. **Ship updates** — "Build main and deploy it when it finishes". The agent chains `trigger_build`, `create_release`, `create_deployment`, `approve_deployment` and `wait_for_deployment`. Each deploy syncs the build output to the project's bucket and invalidates the CloudFront cache of every Static with invalidate on deploy enabled (the default).
+5. **Refresh the cache on demand** — "Invalidate the cache of the landing site". The agent calls `invalidate_static`, useful when invalidate on deploy is disabled or you need to force a refresh.
+
 ## What the MCP does not do
 
 Two things stay a deliberate decision in the console:

content/docs/en/project/workload/static.mdx

@@ -0,0 +1,88 @@
+---
+sidebar_position: 6
+---
+
+import Zoom from "react-medium-image-zoom";
+import "react-medium-image-zoom/dist/styles.css";
+import { FiExternalLink } from "react-icons/fi";
+
+# Static Site
+
+**Static sites** build your frontend from its Git repository and serve the output from a private S3 bucket through Amazon CloudFront, on your own domain. There are no containers running and no web server to maintain: SleakOps builds the site, uploads it to S3 and keeps the CloudFront cache fresh.
+
+:::info
+Static sites require the `static` feature in your subscription. Without it, the **Static site** build method and the **Static** tab under Workloads are not shown.
+:::
+
+## How it works
+
+- You create a Project with the **Static site** build method. SleakOps generates the project's Dockerfile automatically — a multistage build that compiles your frontend with Node and packages the output — so there is no Dockerfile to write or maintain.
+- The Project gets a private S3 bucket. Each **Static** attached to the Project is a custom domain served from that bucket through its own CloudFront distribution, with its TLS certificate and DNS record managed for you.
+- Each deploy syncs the new build output to the bucket, so the site always reflects the last deployed build.
+
+## Creating a static site
+
+Navigate to **Projects**, click **Create**, and select your repository and branch as with any Project. Choose **Static site** as the build method and complete the build configuration:
+
+| **Attribute**     | **Description**                                                                                              |
+| ----------------- | ------------------------------------------------------------------------------------------------------------ |
+| **Node version**  | Node.js version used to build the site: 18, 20 or 22. Default: `20`.                                          |
+| **Build command** | The command that produces the production build, e.g. `npm run build`.                                         |
+| **Output path**   | The repo-relative folder the build writes to, e.g. `dist`. Absolute paths and `..` segments are not accepted. |
+| **Subdomain**     | The site's URL: you type a single label and the environment's domain is appended (e.g. `landing` becomes `landing.dev.example.com`). |
+
+{/* TODO: screenshot - Project create form with the Static site build method selected, showing Node version, Build command, Output path and Subdomain */}
+
+The site's URL must be a **direct subdomain of the environment's domain** — the only shape covered by the domain's wildcard certificate. The target environment therefore needs a domain configured (see [Domain](/docs/domain)).
+
+After you submit, SleakOps provisions the project's bucket and the site's CloudFront distribution, certificate and DNS record. Once the domain is active, the first build and deploy run automatically — the site is published without further steps.
+
+:::info
+If the domain's certificate is still being issued, the distribution starts on a default CloudFront certificate without the custom domain attached — the site doesn't answer on its URL yet. SleakOps attaches the domain automatically as soon as the certificate is ready.
+:::
+
+## How deploys work
+
+A static Project follows the same Build → Release → Deployment flow as any other Project. The build compiles your frontend into an image containing the static output; the deploy runs a short-lived job that syncs that output to the project's bucket (removing files that no longer exist in the build) and then invalidates the CloudFront cache of every Static with **Invalidate on deploy** enabled.
+
+Builds and deployments appear in the Builds and Deployments sections as usual. To roll back, redeploy a previous Release — its image contains that version's static output.
+
+## Managing your static sites
+
+Open **Workloads** in the left pane and select the **Static** tab to see every static site with its state, URL and environment.
+
+{/* TODO: screenshot - Statics list under Workloads with a created static site */}
+
+The detail view shows the S3 bucket, the CloudFront distribution and links to the AWS console, and offers two cache controls:
+
+- **Invalidate on deploy** — invalidates the CloudFront cache on every deploy, so visitors get the new version immediately. Enabled by default.
+- **Invalidate cache** — triggers a manual invalidation, available once the distribution is created.
+
+{/* TODO: screenshot - Static detail with the Invalidate on deploy toggle and the Invalidate cache action */}
+
+A Project can serve several Statics: they share the same content — the project's bucket — on different domains, each with its own CloudFront distribution. Changing a Static's URL re-provisions its distribution, certificate and DNS record for the new domain.
+
+The build configuration (Node version, build command, output path) is editable in the project's settings; SleakOps regenerates the Dockerfile on save. The build method itself cannot be switched to or from Static site after creation.
+
+## FAQs
+
+<details>
+  <summary>
+    ### Does it work with single-page applications?
+  </summary>
+  Yes. The CloudFront distribution serves `index.html` as the root object and maps not-found responses back to `index.html`, so client-side routes (React Router, Vue Router, etc.) resolve correctly on direct navigation and refresh.
+</details>
+
+<details>
+  <summary>
+    ### Why doesn't my static site have replicas or CPU settings?
+  </summary>
+  A static site runs no Pods: the content is served by S3 and CloudFront, so there is nothing to scale or allocate resources for. Scaling, health checks and resource settings only apply to containerized workloads such as [Web Services](/docs/project/workload/webservice).
+</details>
+
+<details>
+  <summary>
+    ### When do visitors see the new content after a deploy?
+  </summary>
+  Immediately, when the Static has **Invalidate on deploy** enabled (the default): the deploy invalidates the CloudFront cache after syncing the bucket. If you disabled it, cached content is served until it expires — use **Invalidate cache** in the Static's detail to refresh it on demand.
+</details>

content/docs/en/project/workload/webservice.mdx

@@ -117,7 +117,9 @@ This gives your application enough time to handle graceful shutdown procedures,
 <summary>
 ### How can I deploy my static web service?
 </summary>
-At the moment, Sleakops doesn't natively support static sites, but you can still deploy them using the same flow as other sites, by containerizing them with a web server like Nginx. Below is a simple example of a Dockerfile and the corresponding nginx.conf to serve your static content.
+SleakOps supports static sites natively: create a Project with the **Static site** build method and the platform builds your frontend and serves it from S3 through CloudFront on your own domain — see [Static Site](/docs/project/workload/static). It requires the `static` feature in your subscription.
+
+Without that feature, you can still deploy a static site as a regular Web Service by containerizing it with a web server like Nginx. Below is a simple example of a Dockerfile and the corresponding nginx.conf to serve your static content.
 
 ```
 FROM node:20.11.0-alpine AS base

content/docs/es/powered-ai/mcp.mdx

@@ -87,6 +87,16 @@ Los tools de import registran recursos que ya existen en tus cuentas de AWS —
 
 El onboarding de una cuenta AWS nueva (provider, account, configuración de red) y el import de un cluster EKS se hacen con el wizard de import de la console, no por el MCP.
 
+### Deployar un sitio estático de punta a punta
+
+Con la feature `static` en tu suscripción, el agente puede llevar un repositorio de frontend a un sitio publicado en una sola conversación. El environment de destino ya debe existir y tener un dominio configurado (ver [Sitio Estático](/docs/project/workload/static)) — los environments se crean en la console.
+
+1. **Creá el proyecto** — "Creá un proyecto static para el repo X en el environment dev, compilando con Node 20, `npm run build`, salida en `dist`". El agente llama a `create_project` con `method="static"` y los tres campos de build (`node_version`, `build_command`, `output_path`).
+2. **Asociá el dominio del sitio** — "Servilo en landing.dev.example.com". El agente llama a `create_static`; la URL debe ser un subdominio directo del dominio del environment. Hacelo **antes** del primer deployment: los workloads deployables de un proyecto static son sus Statics, así que un deployment sin uno se rechaza.
+3. **La primera publicación es automática** — cuando el dominio del sitio queda activo, SleakOps dispara el primer build y su deploy por su cuenta.
+4. **Publicá actualizaciones** — "Buildeá main y deployalo cuando termine". El agente encadena `trigger_build`, `create_release`, `create_deployment`, `approve_deployment` y `wait_for_deployment`. Cada deploy sincroniza el resultado del build al bucket del proyecto e invalida la caché de CloudFront de cada Static con invalidate on deploy habilitado (el default).
+5. **Refrescá la caché a demanda** — "Invalidá la caché del sitio landing". El agente llama a `invalidate_static`, útil cuando invalidate on deploy está deshabilitado o necesitás forzar un refresh.
+
 ## Qué no hace el MCP
 
 Hay dos cosas que siguen siendo una decisión deliberada en la console:

content/docs/es/project/workload/static.mdx

@@ -0,0 +1,88 @@
+---
+sidebar_position: 6
+---
+
+import Zoom from "react-medium-image-zoom";
+import "react-medium-image-zoom/dist/styles.css";
+import { FiExternalLink } from "react-icons/fi";
+
+# Sitio Estático
+
+Los **sitios estáticos** compilan tu frontend desde su repositorio Git y sirven el resultado desde un bucket S3 privado a través de Amazon CloudFront, en tu propio dominio. No hay contenedores corriendo ni servidor web que mantener: SleakOps compila el sitio, lo sube a S3 y mantiene fresca la caché de CloudFront.
+
+:::info
+Los sitios estáticos requieren la feature `static` en tu suscripción. Sin ella, el build method **Static site** y la pestaña **Static** dentro de Workloads no se muestran.
+:::
+
+## Cómo funciona
+
+- Creás un Project con el build method **Static site**. SleakOps genera el Dockerfile del proyecto automáticamente — un build multistage que compila tu frontend con Node y empaqueta el resultado — así que no hay Dockerfile que escribir ni mantener.
+- El Project obtiene un bucket S3 privado. Cada **Static** asociado al Project es un dominio custom servido desde ese bucket a través de su propia distribución de CloudFront, con su certificado TLS y su registro DNS administrados por la plataforma.
+- Cada deploy sincroniza el nuevo build al bucket, así que el sitio siempre refleja el último build deployado.
+
+## Crear un sitio estático
+
+Navegá a **Projects**, hacé clic en **Create** y seleccioná tu repositorio y branch como en cualquier Project. Elegí **Static site** como build method y completá la configuración de build:
+
+| **Atributo**      | **Descripción**                                                                                                 |
+| ----------------- | --------------------------------------------------------------------------------------------------------------- |
+| **Node version**  | Versión de Node.js usada para compilar el sitio: 18, 20 o 22. Default: `20`.                                      |
+| **Build command** | El comando que produce el build de producción, p. ej. `npm run build`.                                            |
+| **Output path**   | La carpeta relativa al repo donde el build escribe el resultado, p. ej. `dist`. No se aceptan rutas absolutas ni segmentos `..`. |
+| **Subdomain**     | La URL del sitio: escribís una sola etiqueta y el dominio del environment se agrega como sufijo (p. ej. `landing` se convierte en `landing.dev.example.com`). |
+
+{/* TODO: screenshot - Formulario de creación de Project con el build method Static site seleccionado, mostrando Node version, Build command, Output path y Subdomain */}
+
+La URL del sitio debe ser un **subdominio directo del dominio del environment** — la única forma que cubre el certificado wildcard del dominio. El environment de destino necesita, por lo tanto, un dominio configurado (ver [Domain](/docs/domain)).
+
+Al enviar el formulario, SleakOps aprovisiona el bucket del proyecto y la distribución de CloudFront, el certificado y el registro DNS del sitio. Una vez que el dominio está activo, el primer build y su deploy corren automáticamente — el sitio queda publicado sin pasos adicionales.
+
+:::info
+Si el certificado del dominio todavía se está emitiendo, la distribución arranca con un certificado default de CloudFront sin el dominio custom adjunto — el sitio todavía no responde en su URL. SleakOps adjunta el dominio automáticamente apenas el certificado queda emitido.
+:::
+
+## Cómo funcionan los deploys
+
+Un Project estático sigue el mismo flujo Build → Release → Deployment que cualquier otro Project. El build compila tu frontend en una imagen que contiene el resultado estático; el deploy corre un job de corta duración que sincroniza ese resultado al bucket del proyecto (eliminando los archivos que ya no existen en el build) y luego invalida la caché de CloudFront de cada Static con **Invalidate on deploy** habilitado.
+
+Los builds y deployments aparecen en las secciones de Builds y Deployments como siempre. Para hacer rollback, re-deployá un Release anterior — su imagen contiene el resultado estático de esa versión.
+
+## Administrar tus sitios estáticos
+
+Abrí **Workloads** en el panel izquierdo y seleccioná la pestaña **Static** para ver cada sitio estático con su estado, URL y environment.
+
+{/* TODO: screenshot - Listado de Statics dentro de Workloads con un sitio estático creado */}
+
+La vista de detalle muestra el bucket S3, la distribución de CloudFront y links a la consola de AWS, y ofrece dos controles de caché:
+
+- **Invalidate on deploy** — invalida la caché de CloudFront en cada deploy, para que los visitantes reciban la nueva versión de inmediato. Habilitado por default.
+- **Invalidate cache** — dispara una invalidación manual, disponible una vez creada la distribución.
+
+{/* TODO: screenshot - Detalle del Static con el toggle Invalidate on deploy y la acción Invalidate cache */}
+
+Un Project puede servir varios Statics: comparten el mismo contenido — el bucket del proyecto — en dominios distintos, cada uno con su propia distribución de CloudFront. Cambiar la URL de un Static re-aprovisiona su distribución, certificado y registro DNS para el nuevo dominio.
+
+La configuración de build (Node version, build command, output path) es editable en los settings del proyecto; SleakOps regenera el Dockerfile al guardar. El build method en sí no puede cambiarse hacia o desde Static site después de la creación.
+
+## FAQs
+
+<details>
+  <summary>
+    ### ¿Funciona con single-page applications?
+  </summary>
+  Sí. La distribución de CloudFront sirve `index.html` como objeto raíz y mapea las respuestas not-found de vuelta a `index.html`, así que las rutas del lado del cliente (React Router, Vue Router, etc.) resuelven correctamente en navegación directa y al refrescar.
+</details>
+
+<details>
+  <summary>
+    ### ¿Por qué mi sitio estático no tiene réplicas ni configuración de CPU?
+  </summary>
+  Un sitio estático no corre Pods: el contenido lo sirven S3 y CloudFront, así que no hay nada que escalar ni recursos que asignar. El escalado, los health checks y la configuración de recursos solo aplican a workloads containerizados como los [Web Services](/docs/project/workload/webservice).
+</details>
+
+<details>
+  <summary>
+    ### ¿Cuándo ven los visitantes el contenido nuevo después de un deploy?
+  </summary>
+  De inmediato, cuando el Static tiene **Invalidate on deploy** habilitado (el default): el deploy invalida la caché de CloudFront después de sincronizar el bucket. Si lo deshabilitaste, el contenido cacheado se sirve hasta que expira — usá **Invalidate cache** en el detalle del Static para refrescarlo a demanda.
+</details>

content/docs/es/project/workload/webservice.mdx

@@ -116,7 +116,9 @@ Esto le da a tu aplicación tiempo suficiente para manejar procedimientos de apa
 <summary>
 ### Como puedo desplegar mi sitio web estatico?
 </summary>
-Por el momento, Sleakops no ofrece soporte nativo para sitios estáticos. Sin embargo, puedes desplegarlos utilizando el mismo flujo que para otros sitios, contenedorizándolos con un servidor web como Nginx. A continuación, se muestra un ejemplo sencillo de un Dockerfile y su correspondiente nginx.conf para servir tu contenido estático.
+SleakOps soporta sitios estáticos de forma nativa: crea un Project con el build method **Static site** y la plataforma compila tu frontend y lo sirve desde S3 a través de CloudFront en tu propio dominio — ver [Sitio Estático](/docs/project/workload/static). Requiere la feature `static` en tu suscripción.
+
+Sin esa feature, todavía puedes desplegar un sitio estático como un Web Service normal, contenedorizándolo con un servidor web como Nginx. A continuación, se muestra un ejemplo sencillo de un Dockerfile y su correspondiente nginx.conf para servir tu contenido estático.
 
 ```
 FROM node:20.11.0-alpine AS base