Edt MCP Project Maintenance

EDT-MCP project maintenance

Purpose and trigger

Use this skill for bounded project diagnostics, revalidation, clean/resync, application maintenance, database update, configuration import/export, or Git operations when enabled.

Operating rule

Read and apply the common operating rules before this workflow.

Task boundary

Target one exact EDT project, application, repository tree, or caller-approved import/export location. Route business code and metadata changes to their task skills; do not broaden maintenance to the workspace or unrelated projects.

Primary workflow

1. Diagnose with get_project_errors, get_problem_summary, and targeted revalidate_objects; use apply_quick_fix, clean_project, or resync_to_disk only when current evidence and help select that operation. Apply a quick fix only for an authorized exact marker and variant, then inspect its diff. Before clean_project, prove the exact project has no unsaved in-memory model edits; preserve any through the current supported, authorized save/resync route, or stop if safety cannot be proved. Always pass the exact project; omission rebuilds every EDT project. After any clean, poll list_projects with format=json and bounded backoff for at most five minutes, or a shorter caller deadline, until that exact project reports ready. If the deadline expires, stop and report the unsettled project; do not trust the clean result or continue against an unsettled/unknown state.
2. Resolve application identity with get_applications and list_configurations. For update_database, review the current preview and side effects with terminateRunningClients=false, obtain authority, execute once with the reviewed value, and verify the final state. Use true only when explicit application-wide authority covers every matching EDT-launched client that may appear between preview and apply.
3. Poll a returned job only with get_job_status; use cancel_job only under its current authorization and confirmation contract. Treat a client timeout as an unknown result; reconcile the authoritative operation outcome under current help before retrying, continuing, or reporting completion.
4. For import, confirm a caller-approved source plus a new project target, call import_configuration_from_xml for a directory of XML files or import_project_from_file for a .cf/.cfe/.epf/.erf file, then verify the returned project exists and becomes usable. For export, confirm the exact project and approved output directory, call export_configuration_to_xml, then verify the reported destination and expected export result.
5. Before using the current working tree, inspect actual repository status and diff through the project-approved Git route and prove it clean, free, and not needed for parallel work. Use list_git_branches only for branch/binding identity, then use create_git_branch or switch_git_branch as appropriate. A task branch must be checked out explicitly; verify the returned checkedOut/current branch before any mutation because branch creation alone leaves the working tree on its previous branch by default.
6. When the active project has foreign changes or parallel work is required, do not switch it. Use a separate Git worktree through the project-approved Git route and resolve that checkout as a distinct EDT project before MCP mutation. Lack of MCP worktree support is a capability limitation, not a prohibition; use an authorized route or stop with a concrete question.