Planprüfung & Prüfpfad

Ziel des Benutzers und Workflow-Grenzen

Dieser praktische Workflow leitet Entwickler und prüfende Agenten dabei an, Softwarevorschläge, technische Spezifikationen und Architekturpläne anhand empirischer Repository-Nachweise zu überprüfen. Prüfer vergleichen Planbehauptungen mit gespeicherten Projektbeschränkungen, verfolgen Änderungen über diskrete Lebenszyklusphasen (planned, submitted, merged, released, verified) und persistieren genehmigte Konsensentscheidungen mit unveränderlicher Herkunftszuordnung.

Verfügbarkeit und Voraussetzungen

Prüf- und Planprüfungsfunktionen stehen über MCP-Client-Profile und die eigenständige Skill-CLI zur Verfügung:

• MCP-Profile cursor-plugin und ordinary-full: Bieten umfassende Prüffunktionen: get_project_context (schreibgeschütztes Projektpaket), recall_context, search_knowledge, update_project_decision (überführt Entscheidungen: resolve, supersede, reopen), update_project_todo (überführt Arbeitselemente: accept, assign, block, unblock, complete, cancel) und query_audit (überprüft Ereignisse und Konsolidierungsprotokolle).
• MCP-Profil claude-plugin: Umfasst get_project_context, recall_context, create_pending_decision, resolve_decision, record_event, remember, recall und todo.
• MCP-Profile generic-public, chatgpt-public und public-only: Unterstützen get_project_summary(project_id, focus) mit focus="blockers" oder focus="status" für kurze Zusammenfassungen sowie memory_overview für Statistiken.
• Eigenständiger Skill (Claude Code, Codex, OpenClaw): Wortgetreue Befehle aus der bereitgestellten 1.1.35 help.mjs: recall-context (Zeilen 84-87), search (Zeilen 80-83), remember (Zeilen 72-75), update (Zeilen 44-47), todo-add/list/done (Zeilen 112-123) und activity/stats (Zeilen 64-71).
• Voraussetzungen: Lesebereich (memory:read) zum Abfragen von Projektkontexten und dem Prüfverlauf; Schreibbereich (memory:write) zum Aufzeichnen von Entscheidungen und Aktualisieren von Arbeitselementen.

Eine vollständige Aufgabe: Prüfung eines Dienstmigrationsplans

In diesem synthetischen Prüfungsablauf prüft ein Agent einen Vorschlag zur Authentifizierungsaktualisierung für das Projekt proj_security_core, validiert Behauptungen anhand von Repository-Beschränkungen, überführt Arbeitselemente und speichert das genehmigte Ergebnis.

Projektbeschränkungen und Prüfverlauf abrufen

Rufen Sie festgelegte Projektrichtlinien ab und untersuchen Sie die Herkunft früherer Entscheidungen mithilfe von recall-context oder 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

Status des Arbeitselements überführen und Entscheidung aufzeichnen

Markieren Sie das Prüfungs-TODO als erledigt und speichern Sie den maßgeblichen Beschluss mit Herkunftsnachweis:

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"

Beobachtbares Ergebnis

Ein strukturierter Planprüfpfad erzeugt einen unveränderlichen, überprüfbaren Pfad, der diskrete Meilensteine des Lebenszyklus widerspiegelt:

• Fünf eindeutige Meilensteinstatus: Pläne und Arbeitselemente durchlaufen explizite Phasen: planned (entworfene Spezifikation) -> submitted (formelle Prüfung angefordert) -> merged (Implementierung integriert) -> released (paketiert und bereitgestellt) -> verified (Validierung nach der Bereitstellung bestanden). Verwechseln Sie planned niemals mit released oder verified.
• Deterministischer Prüfpfad: query_audit gibt strukturierte Datensätze zurück, die den Ereigniszeitstempel, die agierende agent_id, die Ziel-Memory-/Entscheidungs-ID und Vorher-/Nachher-Zustands-Diffs enthalten.
• Herkunftserhaltung: Beim Abfragen von Erinnerungen mit recall oder recall_context legt das Ergebnis unveränderliche Herkunftsmetadaten offen, die die genaue autorisierende Sitzung und den Zeitstempel identifizieren.

Worauf Agenten zugreifen können

Agenten, die Planprüfungen und Audits durchführen, interagieren mit strukturierten, abgegrenzten Darstellungen:

• Nur-Anhängen-Prüfprotokoll: Prüfereignisprotokolle sind rein fortlaufend (append-only). Agenten können historische Entscheidungsprüfungsdatensätze weder überschreiben, manipulieren noch löschen.
• Versions-DAGs und Ersetzung: Das Aktualisieren einer bestehenden Entscheidung oder Erinnerung erstellt eine neue Version, die mit ihrem Vorgänger verknüpft ist; frühere Zustände bleiben als ersetzte Versionen abrufbar (list_memory_versions in cursor-plugin / ordinary-full).
• Evidenzbasierter Kontext: Recall-Werkzeuge liefern sachliche Nachweise aus Projekterinnerungen und verhindern, dass Agenten unbestätigte Modellinferenzen mit erfassten Projektentscheidungen verwechseln.

Freigabe- und Speichergrenzen

Prüfungsdatensätze und Entscheidungen unterliegen strengen Mandanten- und Projektpartitionen:

• Projektbereichsbegrenzung: An project:proj_security_core gebundene Entscheidungen und Arbeitselemente bleiben von nicht verwandten persönlichen Projekten oder externen Team-Bereichen isoliert.
• Ausschluss temporärer Notizen: Temporäre Entwickler-Notizen (Scratchpads), lokale Debugging-Protokolle und flüchtige Gedanken dürfen nicht in dauerhafte Entscheidungsdatensätze geschrieben werden.
• Unveränderlichkeit der Zuweisung: Der Server versieht jede Entscheidung mit der authentifizierten Anrufer-Identität owner_identity und source_identity; Clients können andere Agenten weder vortäuschen noch imitieren.

Fehlerbehebung

Verwalten Sie Prüfungsdiskrepanzen und Überprüfungskonflikte über standardmäßige Lösungspfade:

• Nicht verifizierte Planbehauptungen oder Widersprüche: Wenn ein vorgeschlagener Plan bestehenden Architektur-Entscheidungen widerspricht, schließen Sie die Entscheidung nicht ab. Überführen Sie die Entscheidung mit action="supersede" oder action="reopen" zusammen mit einer detaillierten resolution_note, die die Diskrepanz beschreibt.
• Fehlende Arbeitselement- oder Entscheidungs-ID: Wenn eine referenzierte todo_id oder decision_id nicht gefunden werden kann, fragen Sie aktive Elemente über todo-list (Skill) oder get_project_context(project_id="proj_security_core") ab, um die kanonische ID zu lokalisieren.
• Berechtigung im Bereich verweigert: Wenn einem Agenten Schreibberechtigungen für das Zielprojekt fehlen, gibt update_project_decision HTTP 403 Forbidden zurück. Wenden Sie sich zur Rollenzuweisung an den Projektadministrator.

Verwandte Referenzen

Weitere Informationen zu Sicherheitskonzepten, Herkunftsdetails und zur Verwaltung von Arbeitselementen finden Sie in den folgenden Leitfäden:

• Herkunft und Zuordnung: /docs/concepts/provenance-attribution für Details zur Anrufer-Herkunft.
• TODO-Arbeitselemente-Referenz: /docs/tools/todos für die Nachverfolgung von Projektaufgaben.
• Hauptbuch-Transaktionsreferenz: /docs/tools/ledger für Finanz- und Ressourcenprüfungen.
• Wiederaufnahme und Agentenübergabe: /docs/guides/resume-and-handoff für Workflows zur Sitzungs-Checkpoint-Erstellung.
• Projektleitfaden: /docs/concepts/projects für die Organisation von Projektarbeitsbereichen.