/repository-workflow

name: repository-workflow
description: "Create, inspect, configure, and run ABAP repository comparison workflows across two connected SAP systems. Use when the user asks to compare repositories, discover objects on source and target systems, compare ABAP source code, prepare assisted apply, inspect workflow status, or operate the Repository Comparison Workflow webview with abapfs repository workflow LM tools."
argument-hint: "[source system, target system, object/package scope, or workflow request]"
user-invocable: true
disable-model-invocation: false

ABAP Repository Comparison Workflow

Operate persistent, checkpointed repository comparisons between two connected SAP systems through the `abapfs_*repository_workflow*` LM tools.

This workflow is designed for large SAP landscape comparisons that may inspect thousands of repository objects and, during assisted apply, can save and activate source in a live target system. A wrong system direction, scope, object, transport, or activation set can create heavy SAP load, overwrite pending work, place changes on the wrong request, or activate unrelated code. Treat every instruction below as an authorization and safety boundary: never infer permission, broaden scope, skip a gate, or continue past uncertainty.

Mental Model

The workflow has three user-visible stages:

1. **Scope and discovery** finds matching TADIR objects independently on source and target, then automatically compares the two persisted inventories locally. 2. **Compare systems** presents inventory presence, selects comparable objects, downloads both source snapshots, and compares their source locally. 3. **Assisted apply** lets the user choose manual or Copilot-assisted mode over the same safety-reviewed source-to-target plan. Manual mode can stage one reviewed source file in a dirty target editor. Copilot mode lets the user save the exact objects Copilot may review and permits singular guarded staging and saving after an explicit per-object transport decision. Activation remains separate.

The source/target direction never changes after creation. Always state it explicitly before assisted-apply work.

Critical Operating Principle

This is a potentially high-impact, high-volume feature. Broad discovery can send many ADT requests to SAP; source comparison downloads objects from two systems; assisted apply can place source text in a live target editor. A mistaken scope, direction, selection, or concurrency choice can create substantial SAP load or prepare changes for the wrong system.

Copilot is the user's workflow assistant, not an autonomous repository scanner or change-application operator. The user sets the goal and guides progression. Copilot explains choices, prepares requested inputs, runs only explicitly requested stages, reports results, and stops at decision boundaries.

Mandatory behavior:

• Never create, configure, run, resume, rerun, or prepare an assisted-apply plan merely because it appears to be the next workflow step.
• Require clear user direction before every potentially expensive stage: criteria update, discovery with its automatic local inventory comparison, source comparison/download, and assisted-apply plan preparation.
• Do not interpret “inspect,” “explain,” “review,” “check,” or “what happens?” as permission to run or mutate a workflow.
• Treat discovery and its local inventory comparison as one requested operation. Do not automatically continue from that operation into source comparison or assisted apply unless the user explicitly requested the complete sequence.
• If the user requested a multi-stage sequence, stop immediately if they pause, redirect, or change scope. The newest instruction controls.
• Before discovery, restate source, target, effective scope, subpackage behavior, and any unusually broad pattern. Ask for confirmation when scope or intent is ambiguous.
• Before source comparison, state how many objects will be selected, the source/target SAP download concurrency, and the local verification concurrency. Read the existence summary or bounded artifact first when the count is unknown.
• Before assisted-apply plan preparation, state source-to-target direction and make clear that planning is non-mutating. Prepare it only when requested.
• You may inspect only the user's saved Copilot-assisted selection and must record one review

decision per object. Each apply worker handles exactly one pending `as-is` object; you may run several workers only through the bounded parallel-wave process below. Never choose or invent a transport. You cannot invoke the bulk transport check, activate through the repository apply tool, or mark an object done before save verification and the required separate activation finishes.

• The user-only bulk transport check exists in both assisted-apply modes. Explain where to find it when asked, but never claim permission or ability to trigger it.

Load protection:

• Prefer narrow object-name and package patterns. Never broaden a scope for convenience.
• Treat `includeSubpackages: true` as potentially expensive because package hierarchy expansion can create many bounded SAP queries. Call this out before running discovery.
• Treat omitted object types as all supported types. If that would make discovery broad and the user's intent is unclear, ask which types matter.
• Do not raise concurrency automatically. Preserve saved values unless the user explicitly requests tuning or approves a proposed value.
• Do not rerun completed discovery or source comparison just to inspect results. Read summaries/artifacts instead.
• Do not re-save criteria unless scope must change or the user approves an intentional clean reset. Re-saving invalidates prior work.
• Avoid repeated polling. Workflow operations return completion state, and the webview refreshes from emitted progress events.
• Use bounded, filtered artifact reads. Do not request full inventories merely to count or inspect a few objects.

Tool Map

| I