Keep a reviewable project plan alongside your code

Use version control when you need reviewable changes to project plans and source documents alongside code. My Architect’s server stores project information in files, and its workflow supports linked local project materials. The expected outcome is a traceable plan whose authoritative source and transfer history are clear.

A hosted project is stored on its configured server. Connecting an MCP agent does not automatically place that project in your coding repository or create a synchronized Git checkout.

Identify the authoritative source

Confirm the project binding, storage mode, and which source currently owns each artifact before editing. The work hierarchy, requirements, documents, and diagrams are connected records. Modern projects also carry catalog, specification-evolution, and epic-flow data that must be preserved when relevant.

Local repository documents can provide useful project context without becoming the current server specification automatically. Keep their IDs, origins, and revisions explicit. An identical title or a newer file date does not establish which version was accepted.

Review plan changes as changes

For project files you are authorized to manage in Git:

1. Preserve a known baseline and identify the intended scope change.
2. Review the diff for requirements, decisions, relationships, and work ownership—not only filenames and formatting.
3. Keep stable IDs and source provenance when titles change.
4. Verify the resulting project through supported readers and relevant checks.
5. Record the checked revision and any unresolved transfer or reconciliation step.

File formats and storage layouts vary by project version. Do not assume that copying one requirements file or the visible hierarchy preserves the entire project. A compact context response or queue page is not a full backup.

Move existing project data deliberately

Use the supported inventory and reviewed migration workflow when transferring existing local or exported data into a server project. Inspect source conflicts and retained history before applying changes. Do not overwrite an existing destination simply because an import candidate looks newer.

Preserve the full relevant coordination state, including claims, order, policy, history, receipts, and IDs, together with the catalog and source documents. If the destination cannot represent required data, stop before a lossy write and report the exact limitation.

Git review remains useful, but reverting an old project snapshot over live state can erase newer ownership or operations. Reconcile current state instead of treating an old file copy as an automatic rollback.

Give the next agent enough context

Link the reviewed material to the work and record accepted decisions, evidence, source differences, and the next action. Follow resume and handoff for exact requests and receipts after uncertain operations.

Prepare a reviewable plan change for this My Architect project. Confirm the authoritative sources and project binding, preserve IDs and complete relevant state, and show the intended diff and conflicts. Use the supported migration or write workflow only for the accepted scope, then verify the saved result.

For the ordinary implementation loop, use project workflow. For related terminology, see core concepts.

Verified against app/MCP 1.11.0 and workflow plugin 2.6.0 on October 13, 2026. Confirm the connected server’s capabilities before applying a procedure.