/repository-assisted-apply

name: repository-assisted-apply
description: Safely review, apply, verify, activate, and record one user-selected object in an ABAP FS Copilot-assisted repository-comparison workflow. Use only after the repository workflow has a prepared assisted-apply plan and the user has enabled Copilot-assisted apply.

Repository Assisted Apply

Use this skill only for the Copilot-assisted apply phase of an ABAP FS repository-comparison workflow. Do not use its apply or activation-record operations for ordinary ABAP editing.

Repository assisted apply propagates reviewed raw source between live SAP systems, saves inactive code through CTS transport handling, and can activate executable repository objects. A wrong object, stale review, guessed transport, incomplete activation set, or unintended retry can overwrite pending work or affect unrelated code. The rules in this skill are authorization and safety boundaries: follow them exactly, fail closed on missing evidence, and return control to the user instead of guessing.

The user owns all authorization boundaries:

• enabling Copilot-assisted mode;
• selecting and saving the exact eligible objects;
• approving an existing transport request, a new-request description, or local handling;
• approving each tool confirmation.

Copilot reviews and orchestrates one selected object at a time. It never chooses objects or transports.

Preconditions

Before any per-object work:

1. The comparison and assisted-apply plan must already exist. 2. The workflow must currently be in Copilot-assisted mode with recorded user consent. 3. The user must have saved the allowed object selection in the workflow UI. 4. The exact object must be pending and eligible.

Use `abapfs_get_repository_workflow` with the smallest required includes. Read `assistedApplyObjects` to confirm selection and state; use `diff` with one exact `objectKey` for a bounded raw or formatted review. Never request unbounded repository source.

Parent-agent orchestration

Prefer delegating execution to `abap-repository-assisted-apply` when that enabled subagent is available. One invocation handles exactly one table object.

Before delegation, the parent agent must:

1. identify one exact `workflowId` and one exact saved `objectKey`; 2. obtain current target transport status when necessary; 3. explain any existing lock to the user; 4. collect the user's exact transport direction; 5. pass only that one object and direction to the subagent.

The transport direction must be one of:

• exact approved existing request number;
• exact approved new-request description for this object;
• explicit local-object handling.

If you are the main agent, you own the user conversation, ordering, bounded-wave approval, worker concurrency, result synthesis, and transport-strategy choice. Follow the `repository-workflow` skill's parallel-wave process. If the user wants one shared new request, create it as the main agent and pass its exact number to the applicable workers. If the user wants one new request per object, pass one exact approved description to each worker. Never infer which strategy the user wants, and never delegate without a complete per-object transport path. Never send multiple objects to one subagent.

If you are the delegated subagent, do not select objects, ask the user to choose a transport, run the user-only bulk transport check, choose a transport strategy, process arrays, launch other agents, or retry failed work. You may create exactly one request only when the parent supplied an exact user-approved per-object description. You handle only the one object delegated to you.

Review and decision

For one selected pending object:

1. Read a bounded object diff. Formatted diff is useful for low-noise review; raw snapshots remain authoritative for apply. 2. Decide exactly one:

• `as-is`: the reviewed source snapshot should be propagated unchanged;
• `skip`: it should not be propagated;
• `needs-human`: uncertainty, target customizations, unsupported changes, or risk require review.

3. Call `abapfs_get_repository_workflow` with `assistedApplyAction: "setDecision"`, the singular `objectKey`, the decision, and a concise evidence-based reason.

Never batch decision updates. Never leave an unexplained `as-is` decision. Stop after `skip` or `needs-human`.

Transport gate

Immediately before applying `as-is`, call `abapfs_get_object_transport_status` for the singular target object. A persisted webview transport check is useful context but can be stale.

| Current status | Allowed direction | |---|---| | `locked` | Use that exact request only after the user approves it | | `not-locked` | Use only the exact existing request number or exact per-object new-request description supplied by the parent. | | `local` | Use local handling; no request is assigned | | error/unknown/conflict | Stop and return to the user |

Never invent a request or description. Never silently create, switch, or fall back to another request. If an object becomes locked differently after approval, stop and ask the parent to resolve the conflict with the user.

The workflow UI also has **Determine transport request for selected objects** with bounded SAP concurrency. It is a visible user-only bulk operation and is not exposed through a Copilot-callable tool, so you cannot invoke it. Do not simulate that bulk operation by looping `abapfs_get_object_transport_status` across the selection.

Guarded apply

Call `abapfs_apply_repository_workflow_object` with exactly:

• the workflow ID;
• one selected object key;
• the user-approved transport choice.

The tool, not the model:

• revalidates workflow consent, saved selection, pending state, eligibility, decision, and reason;
• derives all applicable changed text resources represented by the table object;
• revalidates reviewed raw source and current target hashes;
• arms a short-lived transport intent for each resource;
• writes the reviewed raw bytes directly throu