Site web d'application
Livrer le design fourni par l'utilisateur sous forme de site statique autonome, avec des commandes de développement/construction Bun reproductibles et un statut de déploiement explicite. Préserver le fournisseur d'hébergement demandé. Ce workflow provient d'AceCut (/data/swi-algo/Swi-App-Factory/Acecut/website) et de GolfCut ; ces projets sont des exemples, pas des dépendances requises.
Établir les entrées
Lire le fichier AGENTS.md applicable et inspecter le prototype, le site web existant et la documentation de déploiement. Identifier le nom de l'application, le répertoire de destination, le domaine canonique, l'URL réelle de l'App Store et les modifications visuelles demandées. Réutiliser la charte et le contenu existants. Vérifier l'accès en écriture au système de fichiers et l'authentification à l'hébergement/DNS dès le début ; continuer la préparation locale si l'accès au déploiement est indisponible. Ne pas traiter une authentification indisponible comme un succès de déploiement.
Préparer un projet Bun
Pour un nouveau site statique, initialiser un répertoire vide :
python3 <chemin-du-skill>/scripts/init_site.py <répertoire-app>/website --slug <slug-app>
cd <répertoire-app>/website
bun install
Le starter fourni contient les scripts de construction/prévisualisation vérifiés et la configuration Vercel. Conserver les outils d'un projet existant lorsque c'est approprié. public/ contient les sources ; scripts/build.mjs les copie dans dist/ ; la production n'a pas besoin de serveur Bun. Aucune dépendance n'est nécessaire pour du HTML/CSS/JS simple. Si Bun est absent du PATH, vérifier ~/.bun/bin/bun avant d'installer quoi que ce soit. Ne pas copier .git, .vercel, les identifiants ou les données d'identité d'une autre application.
Transférer le prototype
Préférer une exportation ou un dépôt source autorisé. Si seul un prototype statique public est disponible, récupérer le HTML et inspecter récursivement les dépendances src/href HTML de même origine et url() CSS, y compris les pages de fonctionnalités, icônes, SVG et scripts. Télécharger avec curl si l'hôte rejette le client HTTP Python. Signaler visuellement les ressources manquantes ; ne pas enregistrer les corps d'erreur comme images. Mapper les routes de répertoire vers public/<route>/index.html.
Conserver les assets en local. Supprimer les scripts Cloudflare de défi injectés par l'hébergement et les métadonnées de prévisualisation du HTML récupéré, en préservant le JavaScript applicatif. Ne pas copier d'identifiants de service ni ajouter d'analytics sans exigence. Examiner les dépendances externes comme les polices Google. Préserver les liens applicatifs du prototype ; ne jamais inventer un ID App Store ni substituer silencieusement les mentions légales d'une autre application.
Remplacer les origines du prototype dans les URL canoniques, Open Graph, JSON-LD, robots et sitemap par l'origine de production prévue. Préserver les chemins de page de manière cohérente. Pour les demandes de couleur de bouton, inspecter l'asset rendu ainsi que le CSS : un SVG rempli peut masquer un fond CSS. Modifier uniquement les chemins de fond SVG prévus et préserver les chemins de logo/texte, les noms accessibles et les cibles des liens.
Pied de page entreprise et pages légales
Pour les sites web d'applications SWINK qui doivent s'aligner sur AceCut, utiliser © <année> SWINK AI INC., un lien de contact visible mailto:[email protected] et des liens /terms et /privacy fonctionnels sur chaque page, y compris les pages de fonctionnalités et les pages légales elles-mêmes. Conserver la marque et le style visuel de l'application actuelle. Utiliser des assets et une navigation relatifs à la racine pour que les routes imbriquées fonctionnent ; rendre les liens légaux accessibles sans JavaScript. Laisser les liens du pied de page passer à la ligne sur les tablettes et utiliser une disposition mobile compacte sans débordement horizontal.
Lorsque l'utilisateur demande un alignement, utiliser la structure des Conditions Générales/Confidentialité de l'application de référence et les coordonnées de l'entreprise/contact confirmés, puis adapter les noms d'application, les fonctionnalités réelles, les dates, les URL canoniques et les liens croisés. Ne pas transférer aveuglément le fournisseur d'analytics, le comportement de téléchargement, les promesses de stockage/conservation ou les paramètres d'une autre application. Inspecter les preuves produit disponibles pour de telles affirmations ; omettre les détails non confirmés plutôt que de les inventer. Conserver les pages Conditions et Confidentialité en tant que pages autonomes lisibles, les ajouter toutes deux au sitemap et vérifier des URL propres dans les outils locaux et Vercel.
Pour les modifications du pied de page/légal, vérifier toutes les pages concernées aux largeurs bureau, tablette et mobile étroit ; vérifier le texte de l'entreprise, la cible mailto, les deux liens légaux, le texte lisible, l'absence de débordement et la navigation mobile. Préserver les couleurs demandées des boutons de téléchargement. Après le push, vérifier le nouveau déploiement de production et récupérer les vraies pages /terms et /privacy via HTTPS avant de les signaler comme en ligne.
Construire et vérifier
bun run build
bun run preview
Le serveur local prend en charge les routes d'index de répertoire et les URL propres .html, les méthodes GET et HEAD, et renvoie une 404 pour les fichiers manquants. Valider chaque page et chaque asset local via HTTP ; confirmer le sitemap et les URL canoniques. Vérifier les largeurs bureau et mobile étroit (par exemple 1440, 768, 390 et 320), le débordement, les images chargées, les erreurs du navigateur, les menus, les contrôles clavier/tabulation, la FAQ, les filtres et les cibles de téléchargement le cas échéant. Capturer des captures d'écran de révision en dehors de public/. Lorsque la couleur est représentée par un SVG, inspecter ses chemins ou les pixels de la capture d'écran ainsi que le CSS calculé.
Publication GitHub et accès machine
Sur la machine SWI, AceCut a été pushé en utilisant la connexion GitHub CLI existante sous l'utilisateur Linux ubuntu (identité GitHub CC-AIMI). Confirmer l'identité actuelle et l'autorisation d'écriture du dépôt avec gh repo view <propriétaire>/<dépôt> --json viewerPermission,defaultBranchRef,isEmpty avant de se fier à ce précédent. Une erreur réseau/proxy n'est pas une preuve de connexion invalide. Si Git demande un nom d'utilisateur malgré une connexion gh fonctionnelle, utiliser un helper d'identifiants par commande dans le même compte Linux authentifié : git -c credential.helper='!gh auth git-credential' push origin <branche>. Cela réutilise la connexion existante sans exposer son jeton ni modifier la configuration Git globale. Ne pas copier d'identifiants entre comptes ni placer de mots de passe/jetons dans ce skill, les arguments du shell, les fichiers sources ou les logs.
Lorsqu'un utilisateur autorise un compte administrateur à résoudre un problème de permissions Unix, inspecter id et getfacl, et accorder uniquement l'accès nécessaire au projet (par exemple setfacl -m u:<exécuteur>:rwx,d:u:<exécuteur>:rwx <projet>). Préserver le propriétaire/groupe et les permissions non liées. Une connexion administrateur n'authentifie pas Vercel ou GoDaddy.
Si un dépôt explicitement demandé existe déjà, le cloner d'abord et préserver son historique ; ne pas forcer le push d'un commit initial non lié. Placer les fichiers du site à la racine du dépôt, pas dans une couche website/ supplémentaire. Exclure .git, .vercel, dist, node_modules, les captures d'écran de validation et les secrets lors du transfert du code préparé. Si la publication se fait via un autre compte Linux autorisé, utiliser un checkout temporaire appartenant à ce compte et accorder uniquement l'accès en lecture nécessaire aux sources. Configurer l'auteur prévu du dépôt localement, inspecter les fichiers stagés, commiter, pusher vers la branche prévue et vérifier le SHA distant. Garder le checkout de travail principal synchronisé par la suite.
Pour un dépôt autonome tel que diifan/golfcut-website, Vercel doit importer ce dépôt avec le répertoire racine ./. Un simple push GitHub ne crée pas de projet Vercel.
Vercel et DNS
Le starter utilise le framework null (tableau de bord : Other), bun install, bun run build, la sortie dist, cleanUrls: true, trailingSlash: false. Dans un dépôt de site autonome, définir le répertoire racine Vercel sur ./ ; dans un monorepo d'application, utiliser website/. L'intégration GitHub est facultative si la CLI/l'API Vercel authentifiée peut déployer directement. Suivre le périmètre de publication autorisé par l'utilisateur sans ajouter une autre étape d'approbation.
Inspecter le compte/équipe authentifié et le projet existant avant de créer ou lier. Si une connexion CLI est nécessaire, exécuter bun x vercel login et envoyer l'URL d'autorisation de l'appareil à l'utilisateur ; maintenir le processus actif pendant la réalisation de tâches indépendantes. bun x fonctionne même lorsque le shim bunx est manquant. Ne jamais déclarer la connexion tant que la CLI ne la confirme pas. Après la connexion, inspecter les équipes disponibles et le projet AceCut, sélectionner le même périmètre prévu, créer/lier le nouveau projet d'application, connecter son dépôt GitHub exact, puis déployer. Préférer un plugin Vercel connecté s'il fournit ces capacités. Ne pas réutiliser des codes d'appareil expirés ni supposer qu'un plugin suggéré est connecté. Ne jamais réutiliser l'ID de projet d'une autre application. Déployer le site construit et vérifier son URL de déploiement retournée. Pour un domaine demandé app.goswie.com, ajouter ce domaine exact à son projet Vercel, puis obtenir la recommandation DNS actuelle du projet. Sur le fournisseur DNS faisant autorité (AceCut documente GoDaddy), créer/mettre à jour uniquement l'enregistrement d'application demandé, généralement CNAME hôte app. Utiliser la cible retournée par Vercel, pas une cible devinée ou copiée d'AceCut. Préserver les enregistrements non liés, notamment @, www, MX et les serveurs de noms. Résoudre un conflit de propriété avant de remplacer un enregistrement existant non lié. Ajouter uniquement un enregistrement TXT de vérification demandé lorsque Vercel l'exige.
Vérifier le DNS public, le statut du domaine Vercel, HTTPS et les pages déployées. Si des identifiants manquent, terminer la construction et documenter l'action de compte restante exacte ; distinguer la configuration préparée, le déploiement terminé et le domaine vérifié. Ne jamais qualifier un domaine planifié de "en ligne".
Références officielles actuelles (consulter lors du travail de déploiement) :
Séquence CLI vérifiée
GolfCut a été déployé avec Vercel CLI 65.4.0. Après une connexion authentifiée, utiliser --help actuel si les options diffèrent. Substituer le périmètre, le projet et le dépôt vérifiés ; le périmètre SWI réel utilisé pour AceCut et GolfCut est diifans-projects.
bun x vercel teams list
bun x vercel project list --scope <périmètre>
bun x vercel project create <projet> --scope <périmètre>
bun x vercel link --yes --project <projet> --scope <périmètre>
bun x vercel git connect --yes --scope <périmètre>
bun x vercel project update <projet> --framework other --build-command 'bun run build' --install-command 'bun install' --output-directory dist --yes --scope <périmètre>
bun x vercel --prod --yes --scope <périmètre>
bun x vercel domains add <domaine-app> <projet> --scope <périmètre>
bun x vercel domains verify <domaine-app> --scope <périmètre>
Exécuter ces commandes depuis le checkout du site avec le bon remote Git. Sauter la création lorsque le projet correspondant existe. git connect --yes utilise ce remote ; sans --yes, la CLI en mode agent peut quitter sur une invite de confirmation sans réellement connecter. link peut créer .env.local avec un jeton OIDC et .vercel/ ; conserver les deux ignorés. Ne jamais les afficher ni les commiter.
Envoyer immédiatement une URL de connexion d'appareil nouvellement générée, conserver le processus de connexion et attendre son succès explicite. Si un utilisateur signale un code invalide/expiré, arrêter l'ancienne connexion, en émettre une nouvelle et maintenir le tour actif pour l'autorisation ; ne pas continuer à renvoyer l'URL périmée.
Un déploiement READY et un alias de domaine personnalisé ne prouvent pas que le DNS public fonctionne. Tester l'URL publique <projet>.vercel.app sans authentification ainsi que le domaine demandé. domains verify retourne le CNAME exact recommandé ; enregistrer cette valeur pour l'utilisateur s'il gère le DNS. Conserver la prévisualisation publique disponible en attendant le DNS. Lorsque Git est connecté, les pushs ultérieurs devraient déclencher un déploiement ; vérifier le statut de déploiement si un nouveau commit spécifique est annoncé comme en ligne.
Remise
Enregistrer l'origine de la source, les commandes, le résultat de la construction, les preuves de validation et les limitations restantes dans le README du site. Garder les résultats générés, les artefacts de validation locale, les fichiers d'environnement et les identifiants du fournisseur en dehors de Git. Signaler l'URL en ligne réelle uniquement après un déploiement réussi ; sinon fournir le projet prêt et le blocage précis.