Get startedGuidesPlan review & audit trail

Concept

Plan review & audit trail

Recall project constraints, compare proposed plans against evidence, track lifecycle outcomes (planned, submitted, merged, released, verified), and save approved results with provenance.

User goal and workflow boundary

This practical workflow guides developers and reviewing agents through auditing software proposals, technical specifications, and architectural plans against empirical repository evidence. Reviewers compare plan assertions against stored project constraints, track changes across discrete lifecycle stages (planned, submitted, merged, released, verified), and persist approved consensus decisions with immutable provenance attribution.

Availability and prerequisites

Audit and plan review capabilities are provided across MCP client profiles and the standalone Skill CLI:

  • MCP cursor-plugin and ordinary-full profiles: Provide comprehensive review capabilities: get_project_context (read-only project pack), recall_context, search_knowledge, update_project_decision (transitions decisions: resolve, supersede, reopen), update_project_todo (transitions work items: accept, assign, block, unblock, complete, cancel), and query_audit (audits events and consolidation records).
  • MCP claude-plugin profile: Includes get_project_context, recall_context, create_pending_decision, resolve_decision, record_event, remember, recall, and todo.
  • MCP generic-public, chatgpt-public, and public-only profiles: Support get_project_summary(project_id, focus) with focus="blockers" or focus="status" for quick summaries, and memory_overview for statistics.
  • Standalone Skill (Claude Code, Codex, OpenClaw): Verbatim commands from served 1.1.35 help.mjs: recall-context (lines 84-87), search (lines 80-83), remember (lines 72-75), update (lines 44-47), todo-add/list/done (lines 112-123), and activity/stats (lines 64-71).
  • Prerequisites: Read scope (memory:read) to query project contexts and audit history; write scope (memory:write) to record decisions and update work items.

One complete task: Auditing a service migration plan

In this synthetic audit walkthrough, an agent reviews an authentication upgrade proposal for project proj_security_core, validates claims against repository constraints, transitions work items, and stores the approved outcome.

Recall project constraints and audit history

Retrieve established project guidelines and inspect prior decision provenance using recall-context or 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

Transition work item status and record decision

Mark the review TODO as completed and save the authoritative resolution with 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"

Observable result

A structured plan audit creates an immutable, verifiable trail reflecting discrete lifecycle milestones:

  • Five distinct milestone states: Plans and work items advance through explicit stages: planned (drafted specification) -> submitted (formal review requested) -> merged (implementation integrated) -> released (packaged and deployed) -> verified (post-deployment validation passed). Never conflate planned with released or verified.
  • Deterministic audit trail: query_audit returns structured records containing event timestamp, acting agent_id, target memory/decision ID, and before/after state diffs.
  • Provenance preservation: When querying memories with recall or recall_context, the result exposes immutable provenance metadata identifying the exact authorizing session and timestamp.

What agents can access

Agents performing plan review and audits interact with structured, bounded representations:

  • Append-only audit log: Audit event logs are append-only. Agents cannot overwrite, tamper with, or delete historical decision audit records.
  • Version DAGs and supersession: Updating an existing decision or memory creates a new version linked to its predecessor; previous states remain retrievable as superseded versions (list_memory_versions in cursor-plugin / ordinary-full).
  • Evidence-grounded context: Recall tools return factual evidence extracted from project memories, preventing agents from mistaking unverified model inferences for recorded project decisions.

Sharing and storage boundaries

Audit records and decisions are governed by strict multi-tenant and project partitions:

  • Project scope bounding: Decisions and work items bound to project:proj_security_core remain isolated from unrelated personal projects or external team spaces.
  • Scratchpad exclusion: Temporary developer scratchpads, local debugging logs, and transient thoughts must not be written into durable decision records.
  • Attribution immutability: The server stamps every decision with the authenticated caller owner_identity and source_identity; clients cannot forge or impersonate other agents.

Failure recovery

Manage audit discrepancies and review conflicts using standard resolution pathways:

  • Unverified plan claims or contradictions: If a proposed plan contradicts existing architectural decisions, do not resolve the decision. Transition the decision with action="supersede" or action="reopen" along with a detailed resolution_note describing the discrepancy.
  • Missing work item or decision ID: When a referenced todo_id or decision_id cannot be found, query active items using todo-list (Skill) or get_project_context(project_id="proj_security_core") to locate the canonical ID.
  • Scope permission denied: If an agent lacks write permissions on the target project, update_project_decision returns HTTP 403 Forbidden. Escalate to the project administrator for role assignment.

For related security concepts, provenance details, and work item management, consult the following guides:

  • Provenance and attribution: /docs/concepts/provenance-attribution for caller attribution details.
  • TODO work items reference: /docs/tools/todos for project task tracking.
  • Ledger transactions reference: /docs/tools/ledger for financial and resource auditing.
  • Resume and agent handoff: /docs/guides/resume-and-handoff for session checkpointing workflows.
  • Projects guide: /docs/concepts/projects for project workspace organization.

Persona flows

ChatGPT user

Give ChatGPT durable access to your XMemo preferences, project facts, decisions, and TODOs without pasting bearer tokens into a chat.

Save a synthetic preference or project note, start a new chat, then ask ChatGPT to recall it through XMemo before continuing work.

Copilot / Codex developer

Carry repo decisions, coding conventions, bug-fix notes, and task history between IDE and CLI agents.

Record a codebase decision or bug fix, then ask the next IDE or CLI agent to recall the relevant XMemo context before editing.

Team / enterprise pilot owner

Evaluate shared memory with account controls, source attribution, export/delete workflows, and reviewer-safe setup evidence.

Have a pilot member save a synthetic team memory, confirm source attribution in XMemo, then review delete/export and support paths.

Source: Plan review and audit workflow