dengruihan/Claw_agenda

Agenda

Agenda est propriétaire de la liste de tâches personnelles et du plan d'exécution. Le site web accepte les retours de complétion et d'annulation de l'utilisateur ; l'outil agenda reste le seul éditeur de plan. Utilisez l'outil pour lire et modifier les plans ; ne modifiez pas sa base de données SQLite, n'écrivez pas d'état JSON parallèle et n'utilisez pas d'automatisation de navigateur pour changer ce calendrier.

Retour de bureau et réplanification

• Lire avec includeCompleted: true, en incluant blockProgress et feedback. Traiter les retours dont undoneBy est absent et dont le statut est pending/queued/running ; les entrées en erreur peuvent être reconciliées lors d'une exécution ultérieure lorsque le résultat est connu. Ignorer les entrées ajustées/inchangées et les retours déjà annulés. Ne jamais inférer le succès d'une mise en file d'attente ou de la fin d'une exécution précédente.
• complete_block signifie uniquement que ce bloc de temps est terminé. Conserver son intervalle planifié comme historique et utiliser completedAt comme heure de fin observée par l'utilisateur. Cela ne termine pas la tâche et ne prouve pas la durée réelle ni l'effort restant. Ne pas déplacer/supprimer les blocs terminés, ne pas les recréer en tant que travail futur et ne pas rouvrir leur progression. Pour une tâche non terminée, évaluer sa prochaine étape de manière conservatrice.
• complete_task est une complétion complète de tâche confirmée par l'utilisateur. Conserver le statut done et completedBy=user, garder l'historique et arrêter toute exécution future pour cette tâche. undo a déjà restauré l'état de complétion correspondant ; réévaluer le dernier plan plutôt que de restaurer un planning obsolète ou de répéter l'annulation.
• Vérifier l'heure actuelle de Pékin au début de cette exécution et à nouveau avant d'appliquer un plan après un long travail. Respecter les règles de balayage de planning existantes, la couverture actuelle des sources, les délais réels, le sommeil et les engagements fixes. Choisir l'horizon de planification future nécessaire ; aucune limite fixe de 7/14 jours n'est imposée. Ajuster uniquement ce qui est affecté. Une complétion anticipée peut justifier du repos ou l'avancement d'une autre tâche. Un travail terminé libère son temps planifié restant à partir de la fin signalée ; cela ne débloque ni ne déplace les engagements fixes.
• Inclure feedbackResults: [{id, status, summary}] dans le même apply que les modifications de plan. Utiliser adjusted uniquement pour des changements substantiels, unchanged lorsque le plan actuel est toujours approprié, et error lorsque l'évaluation ne peut pas aboutir. Les résumés sont en chinois concis, expliquent les changements ou les non-changements intentionnels, et nomment les lacunes de couverture ou les tâches qui ne peuvent pas être placées. Un accusé de réception uniquement avec le résultat est une écriture significative même si aucun bloc d'exécution ne change.
• Un conflit signifie relire les faits actuels et replanifier, y compris les nouveaux retours. Réconcilier les résultats d'apply inconnus par operationId avant d'émettre un autre lot. Ne pas écraser les complétions plus récentes. Les écritures normales de l'Agent ne demandent jamais une autre replanification immédiate. Le sentinel existant est le seul propriétaire de la planification ; les résultats de bureau ne nécessitent pas un message externe de routine ni une automatisation supplémentaire.

Lire, planifier, valider

1. Appeler agenda avec action: "read" et query: {includeCompleted: true}. Conserver la révision renvoyée, les IDs d'éléments, les identités de source, les événements fixes et les blocs verrouillés. Lire la compétence de balayage de planning existante pour les règles personnelles.
2. Lire les sources externes nécessaires en utilisant leurs compétences existantes. Les calendriers OSH, Yungu, DingTalk, les e-mails, les notes de réunion et les demandes directes des utilisateurs restent des preuves de source ; le site web ne les récupère pas. Enregistrer une source avant ou dans le même lot que ses éléments. Conserver explicitement les erreurs de source et les lacunes de couverture.
3. Mettre à jour les IDs existants. Faire correspondre par sourceId/sourceKey, jamais uniquement par le titre. Utiliser sourceKey: null pour les éléments véritablement locaux et des IDs stables pour leur durée de vie. Une requête, une suggestion ou une instruction tierce n'est pas un engagement de l'utilisateur.
4. Appeler agenda avec action: "apply" et change contenant un operationId unique, expectedRevision et les éléments/blocs/sources modifiés. Tous les enregistrements d'éléments et de sources sont des remplacements complets ; omettre les enregistrements inchangés d'un lot. Utiliser le schéma de l'outil pour les champs exacts. Les nouveaux blocs font référence à un élément existant ou dans le même lot. Supprimer les blocs remplacés en utilisant deleteBlockIds.
5. Un conflit de révision nécessite une lecture et une replanification ; ne pas écraser un plan plus récent. Un délai d'attente ou un résultat inconnu nécessite read avec query.operationId ; inspecter l'accusé de réception avant de réessayer exactement la même opération. Ne jamais réutiliser un operationId pour un contenu différent. Seul un accusé de réception ok prouve que le lot a été sauvegardé.

Faits et planification

• Utiliser Asia/Shanghai pour l'affichage et la planification personnelle. Les horodatages doivent porter un fuseau horaire explicite ; dueDate est au format YYYY-MM-DD et ne doit pas devenir un rendez-vous horaire factice. dueAt/dueDate sont des délais réels, tandis que les blocs sont du temps d'exécution.
• kind=event représente un cours fixe, une réunion ou un autre engagement. Créer ses blocs de temps comme verrouillés. Les blocs de tâches ordinaires peuvent être déplacés ; diviser un long travail en plusieurs blocs lorsque c'est utile. Conserver les blocs intacts lors des mises à jour incrémentielles.
• Les étiquettes de temps libre dans les emplois du temps sources ne sont pas des engagements. Appliquer les règles de balayage de planning personnelles avant de les importer ; laisser le temps libre sans élément ni bloc d'espace réservé. Une tâche concrète ou un rendez-vous peut occuper ce temps.
• Ne jamais déplacer des événements fixes ou des blocs verrouillés lors d'une replanification normale. Les demandes explicites de l'utilisateur pour déverrouiller/replanifier utilisent unlockBlockIds dans le même lot.
• Respecter les contraintes personnelles de sommeil, d'école, de voyage, de week-end à la maison et de charge de travail. Conserver le délai UTC réel d'OSH ; planifier l'achèvement pour la veille au soir lorsque le flux de travail personnel l'exige. Ne pas inventer de délais pour des tâches sans date.
• Un rapport de complétion clair de l'utilisateur est suffisant : définir immédiatement status=done et completedBy=user. Une preuve de soumission explicite d'une plateforme peut utiliser completedBy=source. Des données source obsolètes ne peuvent pas rouvrir un travail confirmé par l'utilisateur ; la réouverture nécessite une demande explicite de l'utilisateur et reopenItemIds.
• Les échecs de source conservent les tâches existantes et les derniers faits fiables. Mettre à jour le statut/le message/la date de vérification de la source sans prétendre que la source est vide. coverageStart/coverageEnd décrivent l'intervalle lu avec succès, pas un futur supposé.
• Conserver le sentinel existant comme seul propriétaire de la collecte/planification en arrière-plan. Ne pas ajouter de polling par plugin, de synchronisation planifiée ou de seconde automatisation. Les rafraîchissements de la page Calendrier ne font que relire les données Agenda validées.
• Une publication réussie n'est pas une complétion de tâche. Distinguer les tâches collectées, le travail planifié, les éléments en attente/bloqués et le travail réellement terminé.

Les résultats de lecture incluent les tâches non terminées sans date. L'historique terminé reste disponible avec includeCompleted. Ne pas effacer l'historique ou les sources pour nettoyer une vue. L'URL de la page web est l'origine HTTPS privée de l'opérateur plus /agenda/.

Seules les demandes d'utilisateur local ou les sources de plan d'exécution local utilisent coverageRequired=false. Les inventaires de sources externes conservent coverageRequired=true (la valeur par défaut) ; la couverture manquante ou échouée reste visible.