Revue de plan et piste d'audit

Objectif de l'utilisateur et périmètre du flux

Ce flux de travail pratique guide les développeurs et les agents de révision dans l'audit des propositions logicielles, des spécifications techniques et des plans d'architecture par rapport aux éléments probants empiriques du dépôt. Les réviseurs comparent les assertions du plan aux contraintes stockées du projet, suivent les modifications à travers des étapes discrètes du cycle de vie (planned, submitted, merged, released, verified) et pérennisent les décisions consensuelles approuvées avec une attribution immuable de provenance.

Disponibilité et prérequis

Les fonctionnalités d'audit et de revue de plan sont disponibles sur les profils de client MCP et la CLI Skill autonome :

• Profils MCP cursor-plugin et ordinary-full : fournissent des fonctionnalités complètes de revue : get_project_context (paquet de projet en lecture seule), recall_context, search_knowledge, update_project_decision (transitions de décisions : resolve, supersede, reopen), update_project_todo (transitions d'éléments de travail : accept, assign, block, unblock, complete, cancel) et query_audit (audite les événements et les enregistrements de consolidation).
• Profil MCP claude-plugin : inclut get_project_context, recall_context, create_pending_decision, resolve_decision, record_event, remember, recall et todo.
• Profils MCP generic-public, chatgpt-public et public-only : prennent en charge get_project_summary(project_id, focus) avec focus="blockers" ou focus="status" pour des résumés rapides, et memory_overview pour les statistiques.
• Skill autonome (Claude Code, Codex, OpenClaw) : commandes textuelles issues du fichier 1.1.35 help.mjs servi : recall-context (lignes 84-87), search (lignes 80-83), remember (lignes 72-75), update (lignes 44-47), todo-add/list/done (lignes 112-123) et activity/stats (lignes 64-71).
• Prérequis : portée de lecture (memory:read) pour interroger les contextes de projet et l'historique d'audit ; portée d'écriture (memory:write) pour enregistrer les décisions et mettre à jour les éléments de travail.

Une tâche complète : audit d'un plan de migration de service

Dans ce parcours d'audit synthétique, un agent examine une proposition de mise à niveau de l'authentification pour le projet proj_security_core, valide les affirmations par rapport aux contraintes du dépôt, effectue la transition des éléments de travail et stocke le résultat approuvé.

Rappeler les contraintes du projet et l'historique d'audit

Récupérez les directives établies du projet et inspectez la provenance des décisions antérieures à l'aide de recall-context ou de get_project_context :

node scripts/xmemo-skill.mjs recall-context --query "token revocation policy session lifetime proj_security_core" --max_items 6 --max_tokens 2500

Effectuer la transition de l'élément de travail et consigner la décision

Marquez le TODO de revue comme terminé et enregistrez la résolution faisant autorité avec sa provenance :

node scripts/xmemo-skill.mjs todo-done --id todo_rev_401
node scripts/xmemo-skill.mjs remember --content "Approved plan auth_migration_v3: enforced 24h token revocation, strict mutual TLS, and zero unauthenticated fallback. Verified by reviewer audit." --path "plans/auth_migration_v3"

Résultat observable

Un audit structuré de plan génère une piste immuable et vérifiable reflétant les jalons discrets du cycle de vie :

• Cinq états de jalons distincts : les plans et les éléments de travail progressent à travers des étapes explicites : planned (spécification rédigée) -> submitted (revue formelle demandée) -> merged (implémentation intégrée) -> released (packagé et déployé) -> verified (validation post-déploiement réussie). Ne confondez jamais planned avec released ou verified.
• Piste d'audit déterministe : query_audit renvoie des enregistrements structurés contenant l'horodatage de l'événement, l'agent_id agissant, l'ID de mémoire/décision cible et les écarts d'état avant/après.
• Préservation de la provenance : lors de l'interrogation de mémoires avec recall ou recall_context, le résultat expose des métadonnées de provenance immuables identifiant la session d'autorisation et l'horodatage exacts.

Ce à quoi les agents peuvent accéder

Les agents effectuant des revues et des audits de plans interagissent avec des représentations structurées et délimitées :

• Journal d'audit en ajout seul : les journaux d'événements d'audit sont strictement en ajout seul (append-only). Les agents ne peuvent ni écraser, ni altérer, ni supprimer les enregistrements historiques d'audit de décision.
• DAG de versions et remplacement : la mise à jour d'une décision ou d'une mémoire existante crée une nouvelle version liée à son prédécesseur ; les états antérieurs restent récupérables en tant que versions remplacées (list_memory_versions dans cursor-plugin / ordinary-full).
• Contexte fondé sur des preuves : les outils de rappel renvoient des éléments factuels extraits des mémoires du projet, évitant que les agents ne confondent des déductions non vérifiées du modèle avec des décisions consignées du projet.

Limites de partage et de stockage

Les enregistrements d'audit et les décisions sont régis par des partitions multi-locataires et de projet strictes :

• Délimitation du périmètre de projet : les décisions et éléments de travail liés à project:proj_security_core restent isolés des projets personnels non liés ou des espaces d'équipe externes.
• Exclusion des brouillons : les brouillons temporaires des développeurs (scratchpads), journaux locaux de débogage et réflexions éphémères ne doivent pas être consignés dans les enregistrements durables de décision.
• Immuabilité de l'attribution : le serveur appose sur chaque décision les identités authentifiées de l'appelant owner_identity et source_identity ; les clients ne peuvent pas falsifier ni usurper l'identité d'autres agents.

Récupération en cas d'échec

Gérez les anomalies d'audit et les conflits de revue en suivant les procédures de résolution standard :

• Assertions non vérifiées ou contradictions de plan : si un plan proposé contredit des décisions d'architecture existantes, ne résolvez pas la décision. Effectuez la transition de la décision avec action="supersede" ou action="reopen" accompagnée d'une resolution_note détaillée décrivant la divergence.
• Identifiant d'élément de travail ou de décision introuvable : lorsqu'un todo_id ou decision_id référencé est introuvable, interrogez les éléments actifs avec todo-list (Skill) ou get_project_context(project_id="proj_security_core") pour localiser l'ID canonique.
• Refus d'autorisation de portée : si un agent ne dispose pas des droits d'écriture sur le projet cible, update_project_decision renvoie HTTP 403 Forbidden. Transmettez la demande à l'administrateur du projet pour l'attribution des rôles.

Référence connexe

Pour découvrir les concepts de sécurité associés, les détails de provenance et la gestion des éléments de travail, consultez les guides suivants :

• Provenance et attribution : /docs/concepts/provenance-attribution pour les spécifications d'attribution des appelants.
• Référence des éléments de travail TODO : /docs/tools/todos pour le suivi des tâches de projet.
• Référence des transactions du registre : /docs/tools/ledger pour l'audit financier et des ressources.
• Reprise et transfert d'agent : /docs/guides/resume-and-handoff pour les flux de points de contrôle de session.
• Guide des projets : /docs/concepts/projects pour l'organisation des espaces de travail de projet.