DGatoM/DG-Claw

/dgclaw:agenda, marquer un véritable rendez-vous

Le propriétaire souhaite que quelque chose se produise à une heure précise, sans qu'il soit présent. Cette skill transforme cette demande en un timer systemd, qui vit sur la machine, survit aux redémarrages et se déclenche automatiquement.

La règle d'or, avant toute chose

Il existe deux types de "planifications" dans le monde, et elles ne se ressemblent en rien :

	La planification de la session Claude	L'agenda du DG Claw (cette skill)
où ça vit	dans la conversation ouverte	sur la machine, dans systemd
quand la conversation se ferme	ça meurt avec	ça continue
ça sert à	"reviens là-dessus dans 10 minutes" dans le travail en cours	"tous les jours à 9h, fais X", pour toujours

Vous êtes un agent DG Claw : vous vivez sur une machine qui reste allumée. Quand le propriétaire demande une planification, il demande celle de droite. Ne répondez jamais "je ne peux planifier que dans ma session" : c'est faux pour vous. Vous marquez sur la machine.

Quand l'audio dit "Chrome"

Le propriétaire envoie beaucoup de messages vocaux, et la transcription se trompe souvent sur le mot cron. Dans une demande d'horaire, tous ces mots sont la même chose :

Chrome, crome, crono, crom, croni, cronn, "corn"

"Crée un Chrome pour moi à 9h" signifie crée un cron à 9h. Ne lui demandez pas de répéter et n'ouvrez pas de navigateur. La seule lecture où Chrome est vraiment un navigateur, c'est quand le sujet est d'ouvrir un site, un onglet, une extension ou une connexion. En cas de doute entre les deux, confirmez en une seule ligne : "vous voulez dire une planification, n'est-ce pas ?".

Comment ça marche en interne (dites-le au propriétaire s'il demande)

Le timer n'exécute pas une commande isolée. À l'heure dite, il taquine votre session vivante avec un message écrit par vous, et c'est vous qui décidez quoi faire, avec toute votre mémoire et votre façon de faire. C'est la différence entre un robot qui envoie un texte tout prêt et un employé qui, à l'heure dite, se souvient de ce qu'il avait à faire.

C'est pourquoi le champ le plus important est --poke : c'est le mot que votre "moi futur" va recevoir. Écrivez comme quelqu'un qui laisse un mot à lui-même, avec suffisamment de contexte pour agir sans avoir à demander quoi que ce soit. Comparez :

• mauvais : résumé
• bon : Heure du résumé du jour pour le propriétaire : regarde la working-memory et ce qui s'est passé aujourd'hui, fais un résumé court et envoie-le par Telegram.

L'heure est celle du propriétaire. Ne convertissez jamais

L'heure qu'il donne est celle de son horloge. "Cinq heures de l'après-midi" est 17:00:00, écrit comme ça, point. Ne convertissez pas en UTC, n'ajoutez ni ne soustrayez rien. Le gestionnaire timbre le fuseau du propriétaire (DGCLAW_TZ) dans la planification elle-même, donc c'est le système qui fait la conversion, et il ne se trompe pas. Faire le calcul à la main est le moyen connu de programmer 17h et de voir le rendez-vous tomber à 20h.

Deux choses qui aident à ne pas glisser :

• Découvrez quelle heure il est vraiment avant de calculer quoi que ce soit de relatif ("dans deux heures", "demain matin"). Votre session peut être ouverte depuis des jours, et votre notion du présent est obsolète. Lancez date '+%d/%m %H:%M %Z' et utilisez ce qui est revenu.
• Confirmez en répétant en portugais. Après avoir créé, dites-lui quand aura lieu la prochaine exécution, avec le jour et l'heure. La commande renvoie déjà cela dans la ligne proxima:. Si ce qui est revenu ne correspond pas à ce qu'il a demandé, le problème est maintenant, pas dans une semaine.

S'il est dans un fuseau différent du serveur et que cela apparaît, n'inventez pas de correction : montrez ce que dit timedatectl et proposez d'ajuster (timedatectl set-timezone <fuseau du propriétaire>), ce qui est une modification du serveur entier et nécessite son autorisation.

La commande

Toujours via le gestionnaire, jamais en touchant directement à systemd :

MGR="${CLAUDE_PLUGIN_ROOT}/scripts/persona-cron-mgr.py"
CFG="<workspace>/.dgclaw/config.sh"

python3 "$MGR" --config "$CFG" list --json
python3 "$MGR" --config "$CFG" create --name <apelido> --calendar '<horário>' --poke '<recado>' --desc '<o que é>' --dry-run
python3 "$MGR" --config "$CFG" create --name <apelido> --calendar '<horário>' --poke '<recado>' --desc '<o que é>'
python3 "$MGR" --config "$CFG" edit   --name <apelido> ... (même signature que create)
python3 "$MGR" --config "$CFG" remove --name <apelido>

Si vous n'êtes pas root (l'agent qui tourne dans le conteneur v1), le gestionnaire demande sudo tout seul quand il doit enregistrer la routine. Vous n'avez rien à faire. La routine tourne sous l'identité du propriétaire du dossier de l'agent, pas sous root.

• --name : surnom court en kebab-case (resumo-do-dia, cobranca-cliente). C'est l'identité de la routine : c'est par lui qu'on édite et qu'on supprime.
• --calendar ou --every, jamais les deux :
  • --calendar '*-*-* 09:00:00' → tous les jours à 9h
  • --calendar 'Mon..Fri *-*-* 08:30:00' → du lundi au vendredi, 8h30
  • --calendar 'Mon *-*-* 18:00:00' → tous les lundis, 18h
  • --calendar '*-*-01 10:00:00' → tous les 1er du mois, 10h
  • --every 30min (ou 2h, 1d) → à intervalles réguliers, comptés à partir de la dernière fois
  • --calendar '2026-10-17 14:32:00' → une seule fois, à ce jour et cette heure. Sert à VOUS faire quelque chose à une heure précise (vérifier un e-mail, générer un rapport) : lancez date, ajoutez le délai et écrivez la date COMPLÈTE. N'utilisez jamais *-*-* ici (ça deviendrait tous les jours) ni --every (ça répète). Dans le --poke, ajoutez à la fin : "Après avoir fait, supprimez cette routine avec remove --name .", pour qu'elle n'occupe pas l'une des 10 places.
• Avertir le propriétaire ("rappelle-moi dans 2 minutes", "demain à 10h préviens-moi") n'est pas une routine : utilisez la skill /dgclaw:lembretes. Elle apparaît sur l'écran et le téléphone du propriétaire et insiste jusqu'à ce qu'il confirme. Le timer unique de cette skill avertit une fois et disparaît.
• Le fuseau est celui de la machine (DGCLAW_TZ), déjà configuré. Ne faites pas de calcul de fuseau à la main.

Lancez toujours avec --dry-run d'abord et montrez au propriétaire ce qui va être créé, en portugais : le surnom, quand ça tourne et le message. Ce n'est qu'ensuite que vous lancez pour de vrai. C'est peu coûteux et évite de planifier un rendez-vous erroné à une heure que personne ne vérifiera.

Que faire pour chaque demande

"Planifie pour moi..." → comprenez l'heure, choisissez le surnom, écrivez le message, --dry-run, montrez, confirmez, créez. Terminez en disant quand aura lieu la prochaine exécution et qu'il peut voir cela dans le tableau de bord, onglet Opérations.

"Quelles planifications as-tu ?" → list --json et traduisez en phrases. Ne déversez pas de JSON sur Telegram. Dites le surnom, quand ça tourne et ce que ça fait quand ça se déclenche.

"Annule le X" → remove --name X. Confirmez qu'il a disparu et avertissez qu'il disparaît aussi du tableau de bord. Si le propriétaire décrit la routine au lieu de donner le surnom, listez d'abord et confirmez laquelle.

"Change l'heure du X" → edit, pas supprimer-et-créer. Le edit préserve le surnom et l'historique de la routine.

Limites qui existent par sécurité (et qui valent d'être dites)

• Vous ne gérez que les routines de votre bloc, avec le préfixe dgclaw-<slug>-self-. Les routines de vie qui sont venues avec vous (réflexion nocturne, audit, battement, pouls) et tout autre chose de la machine sont intouchables par cette commande, et c'est voulu.
• Plafond de 10 routines propres. Atteint, la commande refuse et vous devez en supprimer une avant. Si cela se produit, montrez la liste au propriétaire et demandez-lui laquelle supprimer.
• Chaque demande est validée avant : surnom, format d'heure et taille du message. Si le gestionnaire refuse, il donne la raison en une ligne. Lisez le message et corrigez, n'insistez pas.
• Le manifeste (.dgclaw/self-crons.json) est enregistré avec une sauvegarde automatique à chaque modification.

Où le propriétaire voit cela

Dans le tableau de bord, onglet Opérations, carte Agenda de l'agent. Cette liste n'est pas un fichier de configuration : elle est lue depuis systemd au moment où la page s'ouvre. Donc la promesse simple est valable, et vous pouvez le lui dire en toutes lettres : si c'est là, ça existe ; si vous supprimez, ça disparaît tout seul. Il n'y aura jamais de routine fantôme qui a déjà été supprimée, ni de manquante que vous venez de créer.