Le tableau de bord local : votre espace vu par l’agent

Le tableau de bord local est une petite application web qui montre votre espace de travail tel que votre agent le voit : les produits, ce que l’agent sait de chacun, l’avancement de l’onboarding, chaque état de soumission enregistré, ce qui a besoin de vous, et les dates de relance. Il ne tourne que sur votre machine, ne contacte aucun annuaire, et a été ajouté dans la version du 15 septembre 2026 listée au changelog. Ce guide couvre comment le lancer, à quoi sert chaque écran, et les règles qu’il fait respecter.

Le lancer

Sous Windows, utilisez py -3 à la place de python3 dans les commandes ci-dessous (ou python si cette commande lance Python 3.10 ou plus récent). Gardez votre espace de travail dans un dossier local privé, hors de OneDrive et des autres dossiers synchronisés.

python3 scripts/dashboard.py            # opens 127.0.0.1:8765 in your browser
python3 scripts/dashboard.py --demo     # explore a throwaway sample workspace
python3 scripts/dashboard.py --port 8790 --no-open

C’est de la bibliothèque standard Python 3.10+ : aucune dépendance, aucune étape de build. Lancez-le depuis votre espace de travail privé, le dossier créé par scripts/init-workspace.py. Lancé depuis le checkout de livraison partagé, il propose seulement de créer cet espace. La voie la plus simple reste le prompt de démarrage du guide de démarrage en trois étapes : l’agent crée l’espace de travail, démarre le serveur et vous remet le lien.

La vue d’ensemble

Le premier écran répond à « qu’est-ce qui a besoin de moi ? » avant tout le reste : relais CAPTCHA et double authentification que l’agent n’a pas pu terminer, plateformes marquées bloquées, relances en retard et onboarding inachevé. Viennent ensuite vos produits avec les totaux par groupe d’états — vous attend, problèmes, en modération, programmé, en ligne — et la santé de l’espace de travail lue dans workspace.json. Si vous n’ouvrez le tableau de bord qu’une fois par semaine, c’est cette page qu’il faut regarder.

La page produit

Chaque produit reçoit une checklist de préparation produite par doctor.py, le résumé de la dernière session, ses soumissions avec filtres, les vérifications d’onboarding, le brief produit, l’identité, les permissions et les notes. Une « vue agent » liste quels fichiers sont remplis et lesquels sont encore vides — utile quand une session s’arrête tôt et que vous voulez savoir ce que la suivante demandera. Le vocabulaire des états affiché ici est celui du suivi ; l’entrée de glossaire statut de fiche explique ce que signifie chaque état.

Planifier et reprendre une exécution

Commencez avec un objectif de 10 nouvelles soumissions confirmées et un seul worker navigateur. Le planificateur construit l’exécution à partir des voies prêtes et gratuites et enregistre aussi un budget de temps : 15 minutes par plateforme et, par défaut, 150 minutes actives au total. S’il existe moins de voies adaptées que votre objectif, il propose l’exécution plus petite et honnête.

Enregistrez l’exécution, puis copiez son prompt dans votre agent. Utilisez /goal si votre hôte le prend en charge ; sinon, collez le même texte comme un message normal. Le tableau de bord conserve le plan et affiche le travail restant, mais il ne lance pas de workers d’agent et n’effectue aucune action dans le navigateur. Un objectif ne peut pas passer outre les limites du fournisseur ni les défis réservés aux humains.

Seules les nouvelles soumissions confirmées comptent : en modération, en file, programmées ou en ligne, une fois par plateforme. Les brouillons et les fiches existantes ne comptent pas. Reprenez une exécution enregistrée au lieu d’en lancer une nouvelle qui oublierait la progression précédente. Le guide d’exécution explique l’achèvement, les relais et la fermeture des fenêtres.

Enregistrer les résultats, catalogue et prompts

Le formulaire Record outcome (enregistrer un résultat) écrit via scripts/record.py et applique exactement les règles de la ligne de commande : un des états distincts, ni lien ni secret dans les notes, une URL publique plus votre attestation pour live, une date de lancement égale ou postérieure au plancher pour scheduled, et un remplacement explicite quand une ligne existe déjà. Le guide d’enregistrement des résultats passe en revue chacune de ces règles et leur raison d’être.

New product prend un nom de produit, propose un nom de dossier modifiable en vérifiant les doublons et les noms réservés, crée le dossier à partir de templates/project et vous remet soit le prompt d’onboarding pour votre agent, soit les formulaires à remplir vous-même. Catalog s’ouvre sur les voies prêtes et gratuites vérifiées, les voies conditionnelles, de recherche uniquement et indisponibles étant rangées dans des vues séparées ; vous pouvez chercher et filtrer, lire n’importe quel playbook, superposer le statut d’un produit et enregistrer directement depuis la liste. Agent prompts and docs affiche les prompts pour l’agent avec des boutons de copie et rend la documentation du kit sur place, si bien que vous avez rarement besoin d’ouvrir les fichiers markdown à la main.

Ce qu’il ne fera jamais

Les limites sont délibérées et valent d’être connues avant de s’y fier :

• Il n’écoute que sur 127.0.0.1 et rejette les requêtes intersites.
• Il ne modifie que les fichiers JSON et markdown du produit que l’agent modifie aussi. credentials.json est affiché sous forme de plateforme, méthode et état ; ses valeurs ne sont jamais envoyées au navigateur.
• Il ne soumet rien, ne contrôle aucun navigateur et ne vérifie aucune fiche. Enregistrer un état est une déclaration de l’opérateur, pas une preuve — le tableau de bord rend cette déclaration facile à faire et difficile à faire de travers, rien de plus.

La place du tableau de bord entre le produit, l’agent et les annuaires est dessinée sur la page comment ça marche. Si vous voulez l’essayer sans espace de travail à vous, --demo est la porte d’entrée.