Sitio web de app
Entrega el diseño proporcionado por el usuario como un sitio estático independiente, con comandos de desarrollo/construcción reproducibles con Bun y estado de despliegue explícito. Conserva el proveedor de hosting solicitado. Este flujo proviene de AceCut (/data/swi-algo/Swi-App-Factory/Acecut/website) y GolfCut; esos proyectos son ejemplos, no dependencias requeridas.
Establecer entradas
Lee el AGENTS.md aplicable e inspecciona el prototipo, el sitio web existente y la documentación de despliegue. Identifica el nombre de la app, el directorio de destino, el dominio canónico, la URL real de la App Store y los cambios visuales solicitados. Reutiliza la marca y el contenido existentes. Verifica temprano el acceso de escritura al sistema de archivos y la autenticación de hosting/DNS; continúa con la preparación local si el acceso de despliegue no está disponible. No trates la autenticación no disponible como un éxito de despliegue.
Preparar un proyecto Bun
Para un sitio web estático nuevo, inicializa un directorio vacío:
python3 <directorio-del-skill>/scripts/init_site.py <directorio-de-la-app>/website --slug <slug-de-la-app>
cd <directorio-de-la-app>/website
bun install
El iniciador incluido contiene los scripts de construcción/vista previa verificados y la configuración de Vercel. Mantén las herramientas de un proyecto existente cuando sea apropiado. public/ contiene el código fuente; scripts/build.mjs lo copia a dist/; la producción no requiere servidor Bun. No se necesita dependencia para HTML/CSS/JS plano. Si Bun no está en el PATH, verifica ~/.bun/bin/bun antes de instalar algo. No copies .git, .vercel, credenciales o identidad de otra app.
Transferir el prototipo
Prefiere una exportación de fuente autorizada o un repositorio. Si solo hay disponible un prototipo estático público, recupera el HTML e inspecciona recursivamente los src/href del mismo origen y las dependencias url() de CSS, incluyendo páginas de características, iconos, SVG y scripts. Recupera con curl si el host rechaza el cliente HTTP de Python. Falla de forma visible en recursos faltantes; no guardes cuerpos de error como imágenes. Mapea rutas de directorio a public/<ruta>/index.html.
Mantén los recursos localmente. Elimina los scripts de desafío de Cloudflare inyectados por el hosting y los metadatos solo de vista previa del HTML obtenido, preservando el JavaScript de la aplicación. No copies credenciales de servicio ni añadas análisis sin un requisito. Revisa las dependencias externas como Google Fonts. Preserva los enlaces de la app del prototipo; nunca inventes un ID de App Store ni sustituyas silenciosamente los términos legales de otra app.
Reemplaza los orígenes del prototipo en URLs canónicas, Open Graph, JSON-LD, robots y sitemap con el origen de producción previsto. Preserva las rutas de página de manera consistente. Para solicitudes de color de botón, inspecciona tanto el recurso renderizado como el CSS: un SVG relleno puede ocultar un fondo CSS. Cambia solo las rutas de fondo SVG previstas y preserva las rutas de logotipo/texto, nombres accesibles y destinos de enlace.
Pie de página de la empresa y páginas legales
Para sitios web de apps de SWINK que deban alinearse con AceCut, usa © <año> SWINK AI INC., un enlace de contacto visible mailto:[email protected], y enlaces funcionales a /terms y /privacy en cada página, incluyendo páginas de características y las propias páginas legales. Mantén la marca y el estilo visual de la app actual. Usa recursos y navegación con rutas relativas a la raíz para que las rutas anidadas funcionen; haz que los enlaces legales sean accesibles sin JavaScript. Permite que los enlaces del pie de página se ajusten en tablets y usa un diseño móvil compacto sin desbordamiento horizontal.
Cuando el usuario solicite alineación, usa la estructura de Términos/Privacidad de la app de referencia y los detalles confirmados de la empresa/contacto, luego adapta nombres de app, características reales, fechas, URLs canónicas y enlaces cruzados. No transfieras ciegamente el proveedor de análisis de otra app, el comportamiento de carga, las promesas de almacenamiento/retención o la configuración. Inspecciona la evidencia del producto disponible para tales afirmaciones; omite detalles no confirmados en lugar de inventarlos. Mantén los Términos y la Privacidad como páginas independientes legibles, añade ambas al sitemap y verifica URLs limpias en las herramientas locales y en Vercel.
Para cambios en el pie de página/legal, verifica todas las páginas afectadas en anchos de escritorio, tablet y móvil estrecho; verifica el texto de la empresa, el destino de mailto, ambos enlaces legales, texto legible, sin desbordamiento y navegación móvil. Preserva los colores de botón de descarga solicitados. Después de subir, verifica el nuevo despliegue de producción y obtén las URLs reales de /terms y /privacy a través de HTTPS antes de reportarlas como activas.
Construir y verificar
bun run build
bun run preview
El servidor local soporta rutas de índice de directorio y URLs limpias .html, GET y HEAD, y devuelve 404 para archivos faltantes. Valida cada página y recurso local a través de HTTP; confirma el sitemap y las URLs canónicas. Verifica los anchos de escritorio y móvil estrecho (por ejemplo, 1440, 768, 390 y 320), desbordamiento, imágenes cargadas, errores del navegador, menús, controles de teclado/tabulador, preguntas frecuentes, filtros y destinos de descarga según corresponda. Captura capturas de pantalla de revisión fuera de public/. Cuando el color esté representado por un SVG, inspecciona sus rutas o los píxeles de la captura de pantalla, así como el CSS calculado.
Publicación en GitHub y acceso de máquina
En la máquina SWI, AceCut se subió usando el inicio de sesión existente de GitHub CLI bajo el usuario de Linux ubuntu (identidad de GitHub CC-AIMI). Confirma la identidad actual y el permiso de escritura del repositorio con gh repo view <propietario>/<repo> --json viewerPermission,defaultBranchRef,isEmpty antes de confiar en este precedente. Un error de red/proxy no es prueba de un inicio de sesión inválido. Si Git solicita un nombre de usuario a pesar de un inicio de sesión funcional de gh, usa un ayudante de credenciales por comando en esa misma cuenta autenticada de Linux: git -c credential.helper='!gh auth git-credential' push origin <rama>. Esto reutiliza el inicio de sesión existente sin exponer su token ni cambiar la configuración global de Git. No copies credenciales entre cuentas ni pongas contraseñas/tokens en este skill, argumentos de shell, archivos fuente o registros.
Cuando un usuario autorice una cuenta de administrador para resolver un problema de permisos de Unix, inspecciona id y getfacl, y otorga solo el acceso necesario al proyecto (por ejemplo setfacl -m u:<ejecutor>:rwx,d:u:<ejecutor>:rwx <proyecto>). Preserva el propietario/grupo y los permisos no relacionados. Un inicio de sesión de administrador no autentica Vercel ni GoDaddy.
Si un repositorio solicitado explícitamente ya existe, clónalo primero y preserva su historial; no hagas push forzado de un commit inicial no relacionado. Coloca los archivos del sitio web en la raíz del repositorio, no en otra capa de website/. Excluye .git, .vercel, dist, node_modules, capturas de pantalla de validación y secretos al transferir el código fuente preparado. Si publicas a través de otra cuenta de Linux autorizada, usa un checkout temporal propiedad de esa cuenta y otorga solo acceso de lectura requerido al código fuente. Configura el autor previsto del repositorio localmente, inspecciona los archivos preparados, haz commit, sube a la rama prevista y verifica el SHA remoto. Mantén el checkout de trabajo principal sincronizado después.
Para un repositorio independiente como diifan/golfcut-website, Vercel debe importar ese repositorio con el Directorio Raíz ./. Una subida a GitHub por sí sola no crea un proyecto de Vercel.
Vercel y DNS
El iniciador usa framework null (panel: Otro), bun install, bun run build, salida dist, cleanUrls: true, trailingSlash: false. En un repositorio de sitio web independiente, establece el Directorio Raíz de Vercel en ./; en un monorepo de app, usa website/. La integración con GitHub es opcional si un CLI/API de Vercel autenticado puede desplegar directamente. Sigue el ámbito de publicación autorizado del usuario sin agregar otra puerta de aprobación.
Inspecciona la cuenta/equipo autenticado y el proyecto existente antes de crear o enlazar. Si es necesario iniciar sesión en el CLI, ejecuta bun x vercel login y envía la URL de autorización del dispositivo actual al usuario; mantén el proceso vivo mientras completas trabajo independiente. bun x funciona incluso cuando falta el shim bunx. Nunca afirmes que has iniciado sesión hasta que el CLI lo confirme. Después de iniciar sesión, inspecciona los equipos disponibles y el proyecto de AceCut, selecciona el mismo ámbito previsto, crea/enlaza el nuevo proyecto de la app, conecta su repositorio exacto de GitHub y luego despliega. Prefiere un plugin de Vercel conectado si proporciona estas capacidades. No reutilices códigos de dispositivo caducados ni asumas que un plugin sugerido está conectado. Nunca reutilices el ID de proyecto de otra app. Despliega el sitio web construido y verifica su URL de despliegue devuelta. Para un app.goswie.com solicitado, agrega ese dominio exacto a su proyecto de Vercel, luego obtén la recomendación DNS actual del proyecto. En el proveedor de DNS autorizado (los documentos de AceCut indican GoDaddy), crea/actualiza solo el registro de la app solicitado, normalmente un registro CNAME app. Usa el destino devuelto por Vercel, no un destino adivinado o copiado de AceCut. Preserva los registros no relacionados, especialmente @, www, MX y nameservers. Resuelve un conflicto de propiedad antes de reemplazar un registro no relacionado existente. Agrega solo un registro TXT de verificación solicitado cuando Vercel lo requiera.
Verifica el DNS público, el estado del dominio en Vercel, HTTPS y las páginas desplegadas. Si faltan credenciales, finaliza la construcción y documenta la acción exacta restante de la cuenta; distingue entre configuración preparada, despliegue completado y dominio verificado. Nunca etiquetes un dominio planificado como activo.
Referencias oficiales actuales (consúltalas al realizar trabajo de despliegue):
Secuencia verificada del CLI
GolfCut se desplegó con Vercel CLI 65.4.0. Después de un inicio de sesión autenticado, usa --help actual si las banderas difieren. Sustituye el ámbito, proyecto y repositorio verificados; el ámbito real de SWI usado para AceCut y GolfCut es diifans-projects.
bun x vercel teams list
bun x vercel project list --scope <ámbito>
bun x vercel project create <proyecto> --scope <ámbito>
bun x vercel link --yes --project <proyecto> --scope <ámbito>
bun x vercel git connect --yes --scope <ámbito>
bun x vercel project update <proyecto> --framework other --build-command 'bun run build' --install-command 'bun install' --output-directory dist --yes --scope <ámbito>
bun x vercel --prod --yes --scope <ámbito>
bun x vercel domains add <dominio-de-la-app> <proyecto> --scope <ámbito>
bun x vercel domains verify <dominio-de-la-app> --scope <ámbito>
Ejecuta estos comandos desde el checkout del sitio web con el remoto de Git correcto. Omite la creación cuando el proyecto coincidente existe. git connect --yes usa ese remoto; sin --yes, el CLI en modo agente puede salir en un prompt de confirmación sin conectarse realmente. link puede crear .env.local con un token OIDC y .vercel/; mantén ambos ignorados. Nunca los imprimas ni los confirmes.
Envía una URL de inicio de sesión de dispositivo recién generada inmediatamente, conserva el proceso de inicio de sesión y espera su éxito explícito. Si un usuario reporta un código inválido/expirado, detén el inicio de sesión anterior, emite uno nuevo y mantén el turno activo para autorización; no sigas devolviendo la URL obsoleta.
Un despliegue READY y un alias de dominio personalizado no prueban que el DNS público funcione. Prueba la URL pública <proyecto>.vercel.app sin autenticación, así como el dominio solicitado. domains verify devuelve el CNAME exacto recomendado; registra ese valor para el usuario si gestiona el DNS. Mantén la vista previa pública disponible mientras el DNS está pendiente. Cuando Git está conectado, las subidas posteriores deberían desencadenar un despliegue; verifica el estado del despliegue si afirmas que un nuevo commit en particular está activo.
Traspaso
Registra el origen del código fuente, los comandos, la salida de la construcción, la evidencia de validación y las limitaciones restantes en el README del sitio web. Mantén la salida generada, los artefactos de validación local, los archivos de entorno y las credenciales del proveedor fuera de Git. Reporta la URL activa real solo después de un despliegue exitoso; de lo contrario, proporciona el proyecto listo y el bloqueador preciso.