Site de aplicativo
Entregue o design fornecido pelo usuário como um site estático independente, com comandos de desenvolvimento/build reproduzíveis usando Bun e status de implantação explícito. Preserve o provedor de hospedagem solicitado. Este fluxo de trabalho é originado do AceCut (/data/swi-algo/Swi-App-Factory/Acecut/website) e do GolfCut; esses projetos são exemplos, não dependências obrigatórias.
Estabelecer entradas
Leia o AGENTS.md aplicável e inspecione o protótipo, o site existente e a documentação de implantação. Identifique o nome do aplicativo, diretório de destino, domínio canônico, URL real da App Store e as alterações visuais solicitadas. Reutilize a identidade visual e o conteúdo existentes. Verifique o acesso de escrita ao sistema de arquivos e a autenticação de hospedagem/DNS antecipadamente; continue a preparação local se o acesso de implantação não estiver disponível. Não trate autenticação indisponível como sucesso de implantação.
Preparar um projeto Bun
Para um novo site estático, inicialize um diretório vazio:
python3 <diretório-do-skill>/scripts/init_site.py <diretório-do-app>/website --slug <slug-do-app>
cd <diretório-do-app>/website
bun install
O starter empacotado contém os scripts de build/preview verificados e a configuração Vercel. Mantenha as ferramentas de um projeto existente quando apropriado. public/ contém a fonte; scripts/build.mjs copia para dist/; a produção não requer servidor Bun. Nenhuma dependência é necessária para HTML/CSS/JS simples. Se o Bun não estiver no PATH, verifique ~/.bun/bin/bun antes de instalar qualquer coisa. Não copie .git, .vercel, credenciais ou identidade de outro aplicativo.
Transferir o protótipo
Prefira uma exportação autorizada da fonte ou repositório. Se apenas um protótipo estático público estiver disponível, recupere o HTML e inspecione recursivamente os src/href de HTML de mesma origem e dependências url() de CSS, incluindo páginas de funcionalidades, ícones, SVGs e scripts. Baixe com curl se o host rejeitar o cliente HTTP Python. Falhe visivelmente em recursos ausentes; não salve corpos de erro como imagens. Mapeie rotas de diretório para public/<rota>/index.html.
Mantenha os recursos localmente. Remova scripts de desafio Cloudflare injetados pela hospedagem e metadados de pré-visualização do HTML buscado, preservando os JS do aplicativo. Não copie credenciais de serviço nem adicione analytics sem um requisito. Revise dependências externas como Google Fonts. Preserve os links do aplicativo do protótipo; nunca invente um ID da App Store ou substitua silenciosamente os termos legais de outro aplicativo.
Substitua origens de protótipo em URLs canônicas, Open Graph, JSON-LD, robots e sitemap pela origem de produção pretendida. Preserve os caminhos das páginas de forma consistente. Para solicitações de cor de botão, inspecione o recurso renderizado e também o CSS: um SVG preenchido pode esconder um fundo CSS. Altere apenas os caminhos de fundo SVG pretendidos e preserve caminhos de logotipo/texto, nomes acessíveis e alvos de links.
Rodapé da empresa e páginas legais
Para sites de aplicativos SWINK que devem se alinhar ao AceCut, use © <ano> SWINK AI INC., um link de contato visível mailto:[email protected], e links funcionais para /terms e /privacy em cada página, incluindo páginas de funcionalidades e as próprias páginas legais. Mantenha a marca e o estilo visual do aplicativo atual. Use ativos e navegação relativos à raiz para que rotas aninhadas funcionem; torne os links legais acessíveis sem JavaScript. Deixe os links do rodapé quebrarem em tablets e use um layout móvel compacto sem estouro horizontal.
Quando o usuário solicitar alinhamento, use a estrutura de Termos/Privacidade do aplicativo de referência e os detalhes confirmados da empresa/contato, depois adapte nomes de aplicativos, funcionalidades reais, datas, URLs canônicas e links cruzados. Não transfira cegamente o provedor de analytics de outro aplicativo, comportamento de upload, promessas de armazenamento/retenção ou configurações. Inspecione a evidência disponível do produto para tais afirmações; omita detalhes não confirmados em vez de inventá-los. Mantenha Termos e Privacidade como páginas legíveis independentes, adicione ambos ao sitemap, e verifique URLs limpas nas ferramentas locais e no Vercel.
Para alterações de rodapé/legais, verifique todas as páginas afetadas nas larguras desktop, tablet e móvel estreita; verifique texto da empresa, alvo do mailto, ambos os links legais, texto legível, sem estouro, e navegação móvel. Preserve as cores de botão de download solicitadas. Após o push, verifique a nova implantação de produção e baixe o /terms e /privacy reais via HTTPS antes de relatá-los como ativos.
Build e verificação
bun run build
bun run preview
O servidor local suporta rotas de índice de diretório e URLs limpas .html, GET e HEAD, e retorna 404 para arquivos ausentes. Valide cada página e recurso local via HTTP; confirme sitemap e URLs canônicas. Verifique larguras desktop e móvel estreita (por exemplo 1440, 768, 390 e 320), estouro, imagens carregadas, erros do navegador, menus, guias/controles de teclado, FAQ, filtros e alvos de download conforme aplicável. Capture screenshots de revisão fora de public/. Quando a cor for representada por um SVG, inspecione seus caminhos ou pixels de screenshot, bem como o CSS computado.
Publicação GitHub e acesso de máquina
Na máquina SWI, o AceCut foi enviado usando o login existente do GitHub CLI sob o usuário Linux ubuntu (identidade GitHub CC-AIMI). Confirme a identidade atual e a permissão de escrita do repositório com gh repo view <dono>/<repo> --json viewerPermission,defaultBranchRef,isEmpty antes de confiar neste precedente. Um erro de rede/proxy não é prova de um login inválido. Se o Git pedir um nome de usuário apesar de um login gh funcional, use um helper de credencial por comando na mesma conta Linux autenticada: git -c credential.helper='!gh auth git-credential' push origin <branch>. Isso reutiliza o login existente sem expor seu token ou alterar a configuração global do Git. Não copie credenciais entre contas nem coloque senhas/tokens neste skill, argumentos de shell, arquivos fonte ou logs.
Quando um usuário autorizar uma conta de administrador para resolver um problema de permissão Unix, inspecione id e getfacl, e conceda apenas o acesso necessário ao projeto (por exemplo setfacl -m u:<executor>:rwx,d:u:<executor>:rwx <projeto>). Preserve dono/grupo e permissões não relacionadas. Um login de administrador não autentica Vercel ou GoDaddy.
Se um repositório explicitamente solicitado já existir, clone-o primeiro e preserve seu histórico; não force push de um commit inicial não relacionado. Coloque os arquivos do site na raiz do repositório, não em outra camada website/. Exclua .git, .vercel, dist, node_modules, screenshots de validação e segredos ao transferir o código fonte preparado. Se publicar através de outra conta Linux autorizada, use um checkout temporário de propriedade dessa conta e conceda apenas acesso de leitura necessário ao código fonte. Configure o autor pretendido do repositório localmente, inspecione os arquivos preparados, faça commit, push para o branch pretendido, e verifique o SHA remoto. Mantenha o checkout principal de trabalho sincronizado depois.
Para um repositório independente como diifan/golfcut-website, o Vercel deve importar esse repositório com Diretório Raiz ./. Um push no GitHub sozinho não cria um projeto Vercel.
Vercel e DNS
O starter usa framework null (painel: Other), bun install, bun run build, saída dist, cleanUrls: true, trailingSlash: false. Em um repositório de site independente, defina o Diretório Raiz do Vercel como ./; em um monorepo de aplicativo, use website/. A integração GitHub é opcional se um Vercel CLI/API autenticado puder implantar diretamente. Siga o escopo de publicação autorizado do usuário sem adicionar outro gate de aprovação.
Inspecione a conta/equipe autenticada e o projeto existente antes de criar ou vincular. Se o login CLI for necessário, execute bun x vercel login e envie a URL de autorização do dispositivo atual para o usuário; mantenha o processo ativo enquanto conclui trabalho independente. bun x funciona mesmo quando o shim bunx está ausente. Nunca reivindique login até que o CLI o confirme. Após o login, inspecione as equipes disponíveis e o projeto AceCut, selecione o mesmo escopo pretendido, crie/vincule o novo projeto do aplicativo, conecte seu repositório GitHub exato, então implante. Prefira um plugin Vercel conectado se ele fornecer essas capacidades. Não reutilize códigos de dispositivo expirados ou presuma que um plugin sugerido está conectado. Nunca reutilize o ID de projeto de outro aplicativo. Implante o site construído e verifique sua URL de implantação retornada. Para um app.goswie.com solicitado, adicione esse domínio exato ao seu projeto Vercel, então obtenha a recomendação DNS atual do projeto. No provedor DNS autoritativo (AceCut documenta GoDaddy), crie/atualize apenas o registro do aplicativo solicitado, geralmente CNAME host app. Use o alvo retornado pelo Vercel, não um alvo AceCut adivinhado ou copiado. Preserve registros não relacionados, especialmente @, www, MX e nameservers. Resolva uma propriedade/conflito antes de substituir um registro não relacionado existente. Adicione apenas um registro TXT de verificação solicitado quando o Vercel exigir.
Verifique o DNS público, o status do domínio Vercel, HTTPS e as páginas implantadas. Se as credenciais estiverem faltando, termine o build e documente a ação de conta exata restante; distinga configuração preparada, implantação concluída e domínio verificado. Nunca rotule um domínio planejado como ativo.
Referências oficiais atuais (consulte ao fazer trabalho de implantação):
Sequência CLI verificada
O GolfCut foi implantado com Vercel CLI 65.4.0. Após um login autenticado, use --help atual se as flags diferirem. Substitua o escopo, projeto e repositório verificados; o escopo SWI real usado para AceCut e GolfCut é diifans-projects.
bun x vercel teams list
bun x vercel project list --scope <escopo>
bun x vercel project create <projeto> --scope <escopo>
bun x vercel link --yes --project <projeto> --scope <escopo>
bun x vercel git connect --yes --scope <escopo>
bun x vercel project update <projeto> --framework other --build-command 'bun run build' --install-command 'bun install' --output-directory dist --yes --scope <escopo>
bun x vercel --prod --yes --scope <escopo>
bun x vercel domains add <domínio-do-app> <projeto> --scope <escopo>
bun x vercel domains verify <domínio-do-app> --scope <escopo>
Execute estes comandos a partir do checkout do site com o remote Git correto. Pule a criação quando o projeto correspondente existir. git connect --yes usa esse remote; sem --yes, o CLI em modo agente pode sair em um prompt de confirmação sem realmente conectar. link pode criar .env.local com um token OIDC e .vercel/; mantenha ambos ignorados. Nunca imprima ou faça commit deles.
Envie uma URL de login de dispositivo gerada imediatamente, mantenha o processo de login e aguarde seu sucesso explícito. Se um usuário relatar um código inválido/expirado, pare o login antigo, emita um novo e mantenha a janela ativa para autorização; não continue retornando a URL desatualizada.
Uma implantação READY e um alias de domínio personalizado não provam que o DNS público funciona. Teste a URL pública <projeto>.vercel.app sem autenticação, bem como o domínio solicitado. domains verify retorna o CNAME recomendado exato; registre esse valor para o usuário se ele gerenciar o DNS. Mantenha a pré-visualização pública disponível enquanto o DNS estiver pendente. Quando o Git estiver conectado, pushes posteriores devem disparar implantação; verifique o status da implantação se estiver afirmando que um commit específico está ativo.
Handoff
Registre a origem do código fonte, comandos, saída do build, evidências de validação e limitações restantes no README do site. Mantenha a saída gerada, artefatos de validação local, arquivos de ambiente e credenciais do provedor fora do Git. Relate a URL ativa real apenas após uma implantação bem-sucedida; caso contrário, forneça o projeto pronto e o bloqueador preciso.