# Revisión de planes y pista de auditoría Recupera restricciones de proyectos, compara planes propuestos con evidencias, realiza un seguimiento de los resultados del ciclo de vida (planificado, enviado, fusionado, publicado, verificado) y guarda resultados aprobados con procedencia. - Canonical: https://docs.xmemo.dev/es/docs/guides/plan-review-and-audit - Locale: es-ES - Content-Locale: es-ES - Canonical-Content-Digest: 175b0b54be778ea414d888fa51982bb437637db88fc7fe769ca86ce36f314e63 - Edition-Digest: 3f3baa2c6d4b9ba4e56291badb43eb512bec8b28aa6f0492c0a4af2a64187eaf - Source-Revision: sha256:fe7c573aca1054f57d1a9a3473cb5469fb99b6d0edc9e97966d5f99565482dbd ## Objetivo del usuario y límites del flujo de trabajo Este flujo de trabajo práctico guía a los desarrolladores y a los agentes revisores en la auditoría de propuestas de software, especificaciones técnicas y planes de arquitectura frente a la evidencia empírica del repositorio. Los revisores comparan las afirmaciones de los planes con las restricciones almacenadas del proyecto, rastrean los cambios a través de fases discretas del ciclo de vida (planned, submitted, merged, released, verified) y conservan las decisiones aprobadas por consenso con una atribución inmutable de procedencia. ## Disponibilidad y requisitos previos Las funciones de auditoría y revisión de planes están disponibles en los perfiles de cliente MCP y en la CLI de Skill independiente: - Perfiles MCP cursor-plugin y ordinary-full: proporcionan capacidades completas de revisión: get_project_context (paquete de proyecto de solo lectura), recall_context, search_knowledge, update_project_decision (transición de decisiones: resolve, supersede, reopen), update_project_todo (transición de elementos de trabajo: accept, assign, block, unblock, complete, cancel) y query_audit (audita eventos y registros de consolidación). - Perfil MCP claude-plugin: incluye get_project_context, recall_context, create_pending_decision, resolve_decision, record_event, remember, recall y todo. - Perfiles MCP generic-public, chatgpt-public y public-only: admiten get_project_summary(project_id, focus) con focus="blockers" o focus="status" para resúmenes rápidos, y memory_overview para estadísticas. - Skill independiente (Claude Code, Codex, OpenClaw): comandos textuales de la versión servida 1.1.35 de help.mjs: recall-context (líneas 84-87), search (líneas 80-83), remember (líneas 72-75), update (líneas 44-47), todo-add/list/done (líneas 112-123) y activity/stats (líneas 64-71). - Requisitos previos: permiso de lectura (memory:read) para consultar contextos de proyecto e historial de auditoría; permiso de escritura (memory:write) para registrar decisiones y actualizar elementos de trabajo. ## Una tarea completa: auditoría de un plan de migración de servicios En este tutorial de auditoría sintética, un agente revisa una propuesta de actualización de autenticación para el proyecto proj_security_core, valida afirmaciones frente a las restricciones del repositorio, realiza la transición de elementos de trabajo y almacena el resultado aprobado. ## Recuperar restricciones del proyecto e historial de auditoría Recupera las directrices establecidas del proyecto e inspecciona la procedencia de decisiones previas mediante recall-context o get_project_context: ```bash node scripts/xmemo-skill.mjs recall-context --query "token revocation policy session lifetime proj_security_core" --max_items 6 --max_tokens 2500 ``` ## Transicionar estado del elemento de trabajo y registrar la decisión Marca el TODO de revisión como completado y guarda la resolución autorizada con procedencia: ```bash 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" ``` ## Resultado observable Una auditoría de planes estructurada genera una pista inmutable y verificable que refleja hitos discretos del ciclo de vida: - Cinco estados de hitos diferenciados: los planes y elementos de trabajo avanzan por etapas explícitas: planned (especificación redactada) -> submitted (solicitud formal de revisión) -> merged (implementación integrada) -> released (empaquetado e implementado) -> verified (validación posterior a la implementación superada). Nunca confunda planned con released o verified. - Pista de auditoría determinista: query_audit devuelve registros estructurados que contienen marca de tiempo del evento, agent_id actuante, ID de memoria/decisión objetivo y diferencias de estado antes/después. - Preservación de procedencia: al consultar memorias con recall o recall_context, el resultado expone metadatos de procedencia inmutables que identifican la sesión autorizadora y la marca de tiempo exactas. ## A qué pueden acceder los agentes Los agentes que realizan revisiones y auditorías de planes interactúan con representaciones estructuradas y acotadas: - Registro de auditoría de solo anexión: los registros de eventos de auditoría son de solo anexión (append-only). Los agentes no pueden sobrescribir, alterar ni eliminar registros históricos de auditoría de decisiones. - DAG de versiones y reemplazo: actualizar una decisión o memoria existente crea una nueva versión vinculada a su predecesora; los estados anteriores continúan siendo recuperables como versiones reemplazadas (list_memory_versions en cursor-plugin / ordinary-full). - Contexto basado en evidencias: las herramientas de recall devuelven evidencias basadas en hechos extraídas de las memorias del proyecto, evitando que los agentes confundan inferencias no verificadas del modelo con decisiones registradas del proyecto. ## Límites de uso compartido y almacenamiento Los registros de auditoría y las decisiones se rigen por estrictas particiones multiinquilino y de proyecto: - Delimitación de alcance de proyecto: las decisiones y elementos de trabajo vinculados a project:proj_security_core permanecen aislados de proyectos personales no relacionados o espacios de equipo externos. - Exclusión de blocs de notas: los borradores temporales de desarrolladores (scratchpads), registros locales de depuración y pensamientos transitorios no deben escribirse en registros de decisiones duraderos. - Inmutabilidad de la atribución: el servidor estampa cada decisión con las identidades autenticadas del emisor owner_identity y source_identity; los clientes no pueden falsificar ni suplantar a otros agentes. ## Recuperación de fallos Gestione discrepancias de auditoría y conflictos de revisión mediante vías de resolución estándar: - Afirmaciones de planes no verificadas o contradicciones: si un plan propuesto contradice decisiones de arquitectura existentes, no resuelva la decisión. Realice la transición de la decisión con action="supersede" o action="reopen" junto con una resolution_note detallada que describa la discrepancia. - Identificador de elemento de trabajo o decisión ausente: cuando no se encuentre un todo_id o decision_id referenciado, consulte los elementos activos usando todo-list (Skill) o get_project_context(project_id="proj_security_core") para localizar el ID canónico. - Permiso de alcance denegado: si un agente carece de permisos de escritura en el proyecto de destino, update_project_decision devuelve HTTP 403 Forbidden. Remita el caso al administrador del proyecto para la asignación de roles. ## Referencia relacionada Para consultar conceptos de seguridad conexos, detalles de procedencia y gestión de elementos de trabajo, explore las siguientes guías: - Procedencia y atribución: /docs/concepts/provenance-attribution para detalles de atribución de emisores. - Referencia de elementos de trabajo TODO: /docs/tools/todos para el seguimiento de tareas de proyectos. - Referencia de transacciones del libro mayor: /docs/tools/ledger para auditoría financiera y de recursos. - Reanudación y transferencia de agentes: /docs/guides/resume-and-handoff para flujos de trabajo de puntos de control de sesión. - Guía de proyectos: /docs/concepts/projects para la organización de espacios de trabajo de proyectos. ## Usuario de ChatGPT Dale a ChatGPT acceso duradero a tus preferencias de XMemo, datos de proyecto, decisiones y TODOs sin pegar fichas bearer en un chat. Conecte el servidor XMemo MCP alojado a través de la aplicación ChatGPT/OpenAI OAuth flow, luego apruebe la subvención de memoria:read y memoria:write para su cuenta XMemo. Guarde una nota de preferencia sintética o de proyecto, inicie un nuevo chat y luego pida a ChatGPT que la recuerde a través de XMemo antes de continuar el trabajo. Si OAuth falla o las herramientas no aparecen, salir del servidor MCP en la aplicación host, volver a conectar la URL del servidor XMemo y volver a probar antes de crear tokens directos. ## Copiloto / Codex desarrollador Lleve decisiones de repo, convenciones de codificación, notas de corrección de errores e historial de tareas entre los agentes IDE y CLI. Use OAuth para VS Code / GitHub Copilot y Gemini CLI cuando esté disponible. Para Copilot CLI, Codex, Cursor u otros clientes MCP directos, mantenga XMEMO_KEY en el entorno local o en el almacén de secretos y establezca un XMEMO_AGENT_INSTANCE_ID estable. Grabe una decisión de base de código o corrección de errores, y luego pida al siguiente agente IDE o CLI que recuerde el contexto XMemo relevante antes de editarlo. Si las memorias están vacías, verifique la ruta de configuración MCP seleccionada, la variable de entorno XMEMO_KEY para clientes directos y cualquier credencial OAuth rancio en la aplicación host. ## Equipo / propietario del piloto de la empresa Evalúe la memoria compartida con controles de cuenta, atribución de origen, flujos de trabajo export/delete y pruebas de configuración seguras para los revisores. Cree o introduzca el espacio de trabajo protegido de XMemo, invite a usuarios aprobados, luego conecte a cada cliente a través de OAuth o una credencial directa con alcance de acuerdo con las insignias de preparación. Haga que un miembro piloto guarde una memoria sintética del equipo, confirme la atribución de origen en XMemo, luego revise delete/export y las rutas de soporte. Si un miembro no puede conectarse, compruebe los permisos de rol, la aprobación de OAuth, el estado de preparación del cliente y la orientación de soporte antes de emitir un nuevo token. ## Operador de agente autónomo Deje que los agentes sin cabeza o programados registren el progreso, recuperen decisiones previas y mantengan una identidad estable de instancia no secreta. Obtener /api/v1/mcp/config/autonomous-agent. Preferir auth_modes.oauth cuando el runner soporta OAuth + cabeceras personalizadas; utilice auth_modes.xmemo_key con XMEMO_KEY de una tienda secreta sólo para runners totalmente sin cabeza. Ejecute una tarea sintética que escriba el progreso a XMemo, reinicie el runner y confirme que recuerda que el progreso usando el mismo XMEMO_AGENT_INSTANCE_ID. Si la atribución cambia o recuerda dividida entre instancias, persistir XMEMO_AGENT_INSTANCE_ID fuera de git y verificar que el runner no lo esté regenerando en cada inicio.