Comment créer et publier un site Web avec Paperclip Agents14 min read

Paperclip coordonne une équipe de site Web d’IA ; ce n’est pas l’hébergeur public du site Web. Utilisez-le pour décomposer le brief, attribuer un travail responsable, collecter des preuves d’assurance qualité et acheminer l’approbation. Déployez ensuite le code révisé via un fournisseur d’hébergement ou publiez explicitement un artefact d’application approprié via AgentGrid.io. Une tâche déplacée vers Terminé n’est pas un déploiement public.

Considérez un site de lancement de produit de trois pages avec une page d’accueil, une page de fonctionnalités et un itinéraire de contact. Le concepteur, le codeur, l’agent d’assurance qualité et le réviseur marketing ne peuvent travailler en parallèle que s’ils partagent des critères d’acceptation et savent quelle révision est en cours de révision. Ce guide montre comment structurer ce transfert sans traiter l’orchestration des agents comme un créateur de site magique en un clic.

Comment publier un site Web avec Paperclip et AgentGrid.io

Paperclip peut organiser le travail des agents sous forme d’affectations et suivre les résultats sous forme d’artefacts. AgentGrid.io peut être l’endroit distinct où la page Web ou le document résultant est inspecté et, s’il est approuvé, publié. Ne réduisez pas ces rôles : une tâche Paperclip ou son enregistrement d’artefact n’est pas automatiquement un artefact AgentGrid, et ces produits ne doivent pas être décrits comme ayant une connexion native sans une intégration vérifiée.

1. Créez d’abord l’espace de travail de destination

Dans AgentGrid, créez ou sélectionnez un espace de travail pour l’équipe qui examinera la sortie. Vérifiez la composition de l’équipe avant d’inviter quelqu’un. Vous pouvez conserver l’agent de Paperclip sur son chemin d’exécution existant et laisser une personne transférer le livrable. L’invitation d’agent de AgentGrid est une voie facultative pour un assistant compatible et délibérément configuré, et ne constitue pas une preuve que la liste d’agents ou la chaîne d’approbation de Paperclip apparaîtra dans AgentGrid. Si vous invitez un agent, utilisez les instructions d’invitation AgentGrid et décochez les fonctionnalités de partage et de publication inutiles avant d’envoyer le lien unique.

Dans Paperclip, donnez à la mission un dossier d’acceptation strict : un concept de page de destination, les sections obligatoires, des liens sources pour les affirmations factuelles et un réviseur humain nommé. Gardez le statut interne de l’affectation distinct de l’autorisation de publication. Une tâche marquée comme terminée signifie que le travail demandé a été livré pour inspection, et non que la diffusion publique est autorisée.

2. Transférez la sortie réelle

Lorsque l’agent a terminé, inspectez les fichiers ou les artefacts écrits qu’il a produits. Pour un petit site, regroupez les fichiers pertinents au format ZIP et utilisez l’importation ZIP de AgentGrid. Pour un rapport texte, importez le document pris en charge ou créez un nouveau document. Nommez-le afin que les réviseurs puissent le connecter au devoir Paperclip et incluez une courte note sur ce qui est prêt, ce qui est provisoire et où se trouvent les documents sources. Vérifiez l’aperçu AgentGrid plutôt que de supposer que les fichiers sont rendus exactement comme ils l’étaient dans l’environnement de l’agent.

3. Séparer l’examen des tâches de l’examen des versions

Utilisez Paperclip pour suivre le devoir et son statut. Demandez à la partie prenante d’inspecter l’artefact AgentGrid lui-même et de laisser des commentaires sur le contenu, les liens, l’accessibilité et toute réclamation externe. AgentGrid prend en charge les commentaires d’artefacts, afin que les commentaires exploitables puissent faire référence à l’élément qui serait publié. Incorporez les révisions et vérifiez le nouvel aperçu. Si la portée de la tâche change, mettez également à jour l’affectation Paperclip, mais ne considérez pas l’approbation dans l’un ou l’autre outil comme une synchronisation magique avec l’autre.

4. Publiez la version vérifiée

Ce n’est qu’après qu’un propriétaire humain a autorisé la publication publique que vous pouvez utiliser le flux de publication de AgentGrid. Ouvrez la page résultante en tant que visiteur et comparez-la avec l’artefact approuvé. AgentGrid distingue l’artefact d’espace de travail modifiable du déploiement public ; les modifications ultérieures nécessitent une autre action de publication. Enregistrez l’URL publique dans la tâche Paperclip sous forme de note de transfert si votre processus l’exige, sans réclamer une intégration automatisée ou un pont d’approbation caché.

Donnez à l’équipe un objectif de site Web, pas une vague instruction

Commencez par un brief précis : audience, objectif de conversion, pages requises, références visuelles, propriétaire du contenu, attentes en matière d’accessibilité et domaine ou destination d’hébergement. Pour une première version, spécifiez les mises en page réactives, les métadonnées, un itinéraire de contact fonctionnel et ce qui est hors de portée.

Dans Paperclip, créez un projet et un objectif, puis divisez le travail en tâches détenues. Son modèle de tâches prend en charge un seul propriétaire responsable, bloquant les relations, les threads et les étapes de révision. Désignez un stratège ou un agent PM pour planifier, un concepteur pour produire la direction visuelle, un agent de codage pour mettre en œuvre, un agent d’assurance qualité pour tester et un humain pour approuver le lancement. Ce sont des rôles que vous configurez, pas un créateur de site Web préemballé. Propre au trombone exemple d’équipe de site Web affiche les pages de fonctionnalités, le contrôle qualité bloqué par la mise en œuvre et un déploiement préliminaire en cours de révision.

Invite de planification : « Planifiez un site Web de trois pages pour [audience] qui aide les visiteurs [objectif]. Produisez un plan du site, des critères d’acceptation au niveau de la page, des lacunes dans le contenu, des exigences en matière d’image et une carte des dépendances des tâches. Ne déployez rien. Attribuez à chaque livrable un propriétaire et identifiez les décisions qu’un humain doit prendre. « 

Définir le contrat de libération avant d’affecter des agents

Définissez l’audience, la conversion principale, la copie approuvée, l’inventaire des pages, les ressources visuelles, les points d’arrêt requis, l’hôte cible et le propriétaire du lancement. Incluez des non-objectifs explicites, tels que l’absence de paiement ou la création de compte dans la première version. Donnez à chaque page un critère d’acceptation mesurable : la page de fonctionnalité explique l’offre, le lien de contact atteint une destination de travail et chaque itinéraire a un titre significatif.

Conservez la source, la conception et les preuves ensemble

Donnez au constructeur un référentiel ou un emplacement de projet partagé. Le concepteur fournit une spécification de mise en page et des actifs ; le codeur met en œuvre le même brief. Un commentaire de tâche doit être lié à la branche, à la demande d’extraction, à l’aperçu et aux résultats des tests. Paperclip peut collecter des résultats liés à des tâches et examiner des preuves, mais une pièce jointe à une tâche ne constitue pas automatiquement le site Web en direct ou le référentiel source canonique.

Fixez des limites avant d’accorder l’accès. Si un agent peut transmettre du code via une identité GitHub dans son shell, les contrôles Ask first par outil de Paperclip ne régissent pas ces commandes Git du shell. Limitez l’accès au référentiel et exigez la protection des branches et l’examen des relations publiques sur GitHub. Pour un connecteur de déploiement, faites la distinction entre la lecture des journaux de build et le démarrage d’un déploiement de production ; Les conseils Netlify de Paperclip recommandent de demander d’abord ou de désactiver les modifications de déploiement et de configuration. Conservez les informations d’identification hors de la source du site Web et accordez à chaque agent uniquement l’accès requis par sa tâche.

Invite de génération : « Mettez en œuvre le plan du site approuvé dans [dépôt]. Préservez la conception convenue, rendez la navigation et les formulaires fonctionnels, et ajoutez des métadonnées de titre et de description à chaque page. Travaillez sur une branche, exécutez les vérifications du projet, attachez le PR et l’URL d’aperçu à la tâche Paperclip et arrêtez-vous avant tout déploiement de production. « 

Séparer le statut du problème, le contrôle des sources et la publication

Paperclip enregistre à qui appartient chaque numéro et quelles preuves accompagnent le transfert. Votre référentiel contient toujours l’implémentation et un fournisseur d’hébergement exécute le site Web déployé. Liez chaque problème à la branche exacte, au PR, à l’aperçu, au journal de test et aux captures d’écran. Si la tâche fait uniquement référence à la « dernière version », les réviseurs peuvent accidentellement approuver un aperçu qui ne correspond pas à la branche finalement déployée.

Faites passer en revue une porte, pas un message disant « ça a l’air terminé »

Demandez au QA d’ouvrir l’aperçu réel sur ordinateur et mobile. Vérifiez la promesse sur le premier écran, la navigation au clavier, le texte alternatif, les liens rompus, le comportement du formulaire, le chargement, les erreurs de la console et les métadonnées de la page. Demandez au marketing de vérifier les allégations du produit et le CTA. Enregistrez des preuves reproductibles. Si un formulaire a besoin d’un backend, testez la soumission de bout en bout.

La politique d’exécution de Paperclip peut acheminer un problème vers un réviseur, puis vers un approbateur lorsque son exécuteur tente de marquer la tâche comme terminée. Les modifications demandées reviennent à l’exécuteur testamentaire d’origine. Utilisez une étape d’approbation humaine pour la publication publique et précisez que l’approbation d’une tâche ne constitue pas une autorisation de publication tant que le réviseur n’a pas inspecté l’aperçu final et le domaine cible.

Invite de contrôle qualité : « Testez l’aperçu par rapport aux critères d’acceptation sur une fenêtre d’affichage mobile et un bureau étroits. Renvoyez un tableau de réussite, d’échec, d’URL de preuve ou de capture d’écran et les étapes de reproduction. Ne pas approuver ni déployer ; renvoyer les échecs au propriétaire de l’implémentation. « 

Une liste de contrôle d’acceptation pratique pour le lancement

• Produit : comparez la promesse du héros, les déclarations de prix et les destinations d’appel à l’action avec la copie approuvée.
• Fonction : cliquez sur Navigation, soumettez une demande de contact test et inspectez le chemin de réussite ou d’échec.
• Conception réactive : examinez les écrans étroits, le bureau, le débordement de contenu, le recadrage des images et l’espacement lisible.
• Accessibilité : vérifiez l’ordre du clavier, les étiquettes, le texte alternatif, les titres sémantiques et le contraste.
• Recherche et fiabilité : confirmez les titres et descriptions spécifiques aux itinéraires, les liens rompus, les erreurs de console et le chargement des actifs de production.

Déployer la version approuvée sur une URL publique réelle

Choisissez la destination de production avant la dernière révision. Pour une base de code conventionnelle, connectez le référentiel à un hôte tel que Netlify ou Vercel, vérifiez ses paramètres de construction et ses variables d’environnement, et laissez l’hôte produire d’abord un aperçu. Après l’approbation humaine, promouvez ou déployez la révision révisée à l’aide du flux de travail documenté de cet hôte. Ouvrez l’URL de production lorsque vous êtes déconnecté ; testez la navigation, les formulaires, le certificat, le domaine et la révision déployée. L’exécution de Paperclip sur un serveur rend uniquement l’application d’orchestration accessible ; il ne publie pas le site Web.

Si le site Web est un artefact d’application HTML ou React approprié, AgentGrid.io peut être le lieu partagé où les personnes et les agents connectés modifient la même version. Importez un dossier de projet ou un ZIP, ou demandez à un agent connecté de créer l’artefact dans l’espace de travail prévu. Consultez son application rendue et son historique ici. Un lien d’artefact est privé pour les personnes ayant accès à l’espace de travail ; la publication est une action distincte et explicite qui crée une URL publique. Un agent connecté a besoin d’une capacité de publication et d’une demande humaine pour publier. Les modifications ultérieures restent hors de la page publique jusqu’à ce qu’elles soient republiées. Les domaines personnalisés nécessitent un forfait payant éligible et vérifié DNS. Il s’agit d’une voie de publication alternative et non d’une affirmation selon laquelle Paperclip s’intègre automatiquement à AgentGrid.io.

Invite de lancement : « La révision approuvée par l’homme est [version de validation ou d’artefact]. Déployez-la sur [hôte spécifié] ou publiez [artefact AgentGrid.io spécifié] uniquement après autorisation explicite. Renvoyez l’URL publique, la révision déployée, le résultat de la construction et une liste de contrôle de test de fumée. Si la cible ou l’autorisation est manquante, arrêtez et demandez. « 

La promotion doit faire référence à une révision spécifique

Avant la publication, enregistrez la version approuvée de la validation ou de l’artefact, l’hôte ou l’espace de travail cible, le domaine et qui peut lancer la publication. Si l’hôte génère des URL d’aperçu, inspectez l’aperçu final de cette même révision avant de la promouvoir. Ensuite, ouvrez l’URL publique sans session privilégiée et répétez les tests de fumée critiques. Enregistrez une référence de restauration au cas où l’itinéraire de contact ou les actifs seraient interrompus dans les paramètres de production.

Quand une équipe doit-elle utiliser chaque couche ?

Trombone : choisissez-le lorsque plusieurs agents ont besoin de problèmes, de dépendances, de révisions et d’un propriétaire de lancement humain responsable. Il indique à l’équipe quoi faire et suit le travail, plutôt que de se substituer au contrôle de code source ou à un hébergeur Web.

Dépôt et hébergeur : choisissez cette voie lorsque le site a besoin d’un processus de publication d’ingénierie existant, de fonctionnalités de serveur, de paramètres d’infrastructure ou de contrôles de restauration établis. L’enregistrement de validation et de déploiement examiné doit identifier la version active.

Continuer à partir de la version approuvée

Paperclip est propriétaire des devoirs et des révisions. Votre référentiel et votre propre hébergeur déploient votre production conventionnelle. AgentGrid.io peut contenir un artefact partagé et versionné et sa publication délibérée. Pour une comparaison d’un autre flux de travail agent-site, consultez notre Grok Guide de publication du robot; pour le problème de transfert derrière les artefacts partagés, lisez notre introduction au AgentGrid.io; et pour un chemin axé sur le design, voir publication d’un site Web Claude Design.

Prêt à conserver le site Web approuvé au même endroit ? Créer un artefact AgentGrid.io, invitez le prochain collaborateur disposant d’un accès approprié et publiez uniquement lorsque la version publique a été révisée.