Recensez les usages actuels des logs générés : qui les consulte, quelles intégrations y accèdent, et quels champs doivent être conservés pour l’audit. Confirmez pourquoi input_prompt et execution_frequency sont nécessaires (traçabilité, régénération, scheduling).

Avant toute modification structurelle, effectuez une sauvegarde complète des données susceptibles d’être impactées. Documentez précisément la procédure de retour en arrière (rollback) et qui est responsable de l’exécution.

Planifiez la migration dans une fenêtre de faible activité. Communiquez aux équipes concernées (dev, produit, support) la durée estimée et les risques.

Lancez la migration pendant la fenêtre prévue. Surveillez les indicateurs de santé (files d’attente, workers, erreurs d’écriture). Ne forcez pas d’opérations d’écriture lourdes simultanées pendant l’opération.

Vérifiez un échantillon de logs récents et anciens : présence des nouveaux champs input_prompt et execution_frequency, comportement des enregistrements liés aux hooks d’agent (références optionnelles). Assurez-vous que les enregistrements existants n’ont pas été corrompus.

Testez les workflows utilisateurs : génération normale, revue, duplication, suppression, export. Vérifiez que les envois vers destinations externes continuent de fonctionner et que la consommation de crédits liée aux régénérations est cohérente.

Activez des journaux et alertes sur les erreurs d’écriture, les échecs d’envoi et les anomalies de performance pendant les 72 heures suivant la migration. Prévoyez une vérification plus complète après 1 semaine.

Renseignez dans le changelog projet les raisons de la modification, la fenêtre d’intervention, les actions réalisées et les éventuels problèmes rencontrés.

Le champ agent_hook_id permet d’indiquer qu’un log a été produit à la suite d’un hook d’agent. Il est nullable : l’absence de valeur signifie log généré manuellement ou depuis une autre source.

Identifiez les hooks actifs, leurs fréquences et destinations. Vérifiez quelles actions déclenchent l’écriture des logs et si elles doivent référencer le hook.

Après activation, contrôlez les enregistrements produits par les hooks : ils doivent référencer le hook associé. Les enregistrements manuels doivent rester sans référence si pertinent.

Définissez le comportement attendu quand un hook est supprimé : conserver l’historique de logs (référence nulle) ou annoter le log comme « hook supprimé ». Planifiez une migration d’annotation si nécessaire.

Créez un hook test et déclenchez une génération. Vérifiez l’association, la visibilité dans l’interface et l’impact sur les exports et envois.

Ouvrez le document depuis l’onglet Changelogs ou depuis la liste de documents et cliquez pour afficher le DialogDocument.

Dans la fenêtre du document, cliquez sur l’action « Duplicate » (ou équivalent). L’interface crée une nouvelle copie en draft.

Avant d’enregistrer : vérifiez le titre, la description, et les métadonnées importantes (agent_id, agent_hook_id, batch_uuid). Corrigez l’input_prompt si vous souhaitez l’adapter.

Enregistrez la copie ; elle apparaîtra dans la liste comme un nouveau document. Vérifiez que les permissions et liens (hooks, exports) sont corrects.

Si la duplication était expérimentale, supprimez la copie une fois validé le besoin, en suivant la procédure de suppression ci-dessous.

Décidez si la suppression doit être « soft » (archivage, conservation d’un historique) ou « hard » (suppression définitive). Préférez le soft-delete en production pour auditabilité.

Accédez au document, cliquez sur l’action « Delete ». L’interface demande une confirmation.

Vérifiez les métadonnées liées (agent_id, agent_hook_id, batch_uuid) et les destinations d’envoi associées. Confirmez l’action.

Après suppression, contrôlez les affichages (changelogs, listes) et systèmes liés (index de recherche, exports sauvegardés). Si soft-delete, assurez-vous que l’entrée est marquée comme archivée et non visible par défaut.

Si une restauration est nécessaire et que l’action était soft-delete, restaurez depuis l’archive. Pour suppression définitive, suivez vos procédures de récupération (si existantes).

Ouvrez le document, vérifiez le contenu, les métadonnées et les paramètres d’export (inclusion du prompt, anonymisation).

• Pour exporter : sélectionnez Export Markdown ou Export JSON.
• Pour envoyer : choisissez la Destination prévue (webhook, email, Notion, etc.).

Avant d’envoyer, sachez que certains envois peuvent déclencher des appels externes ou des régénérations LLM qui consomment des crédits. Confirmez la consommation prévue auprès du responsable coûts.

Cliquez Export ou Send. Surveillez la notification de succès/erreur. Conservez le journal de l’opération (timestamp, destinataire, statut).

Archivez les logs d’envoi et, si nécessaire, anonymisez les prompts dans les copies exportées ou envoyées pour respecter la protection des données.

Identifiez les métadonnées à conserver pour l’audit : agent_id, agent_hook_id, batch_uuid, auteur, date de création, statut de revue.

Pour chaque type de document, fixez : période de conservation active (ex. 90 jours), période d’archivage (ex. 1 an), et suppression définitive.

• Soft-delete : conserve l’entrée en archive (recommandé).
• Hard-delete : suppression définitive, à réserver aux obligations légales ou tests.

Mettez en place des jobs planifiés qui : 1) déplacent en archive, 2) notifient les équipes responsables, 3) attendent une fenêtre pour suppression définitive. Ajoutez un checkpoint manuel avant purge finale.

Si vous dupliquez automatiquement (ex. templates journaliers), assurez-vous que les métadonnées de tracking (batch_uuid) sont régénérées et que les références à hooks anciennes sont nettoyées si non pertinentes.

Conservez un registre des actions de purge/duplication (qui, quand, pourquoi) accessible aux admins pour requêtes réglementaires.

Listez qui peut créer, éditer, finaliser, dupliquer, supprimer, exporter et envoyer des documents. Associez chaque action à des rôles clairs.

Configurez la visibilité du input_prompt : par défaut masqué pour les rôles non-admin. Donnez un contrôle granulaire pour afficher une version redacted.

Vérifiez et limitez les destinations d’envoi (webhooks, e-mails, intégrations). Exigez signatures ou tokens pour les destinations sensibles.

Documentez quelles actions déclenchent des consommations (ex. régénération LLM). Mettez en place des quotas et approbations pour actions coûteuses.

Activez alertes sur usage anormal : envois massifs, régénérations répétées, exports automatiques. Reliez ces alertes à un processus d’investigation.