SAP Transport / Change Review

Answer "what actually changed?" for a transport or for your in-flight (unactivated) work, as a reviewable report: a per-object unified diff plus risk flags — not a wall of full source.

It leans on two token-cheap ARC-1 primitives so a review of a 30-object transport costs a handful of small diffs instead of 60 full-source reads:

• SAPTransport(action="list", summary=true) — scan many open transports cheaply (objects omitted, objectCount kept), then drill into one.
• SAPRead(action="diff", from=…, to=…) — server-side unified diff per object; the response is just the hunks.

Complements explain-abap-code (deep single-object understanding) and sap-object-documenter (written docs for a package). This skill is about delta — what moved between two points in time — for code review, hand-off, or a pre-release gate.

Pick the mode (who's asking)

For a system-wide inventory of every open transport (basis: who has what open, how big, conflicts — no diffs) that's a different job → sap-transport-overview.

Smart Defaults (apply silently, do NOT ask)

Input

The user provides one of:

• A transport id (e.g. A4HK900123) — review everything in that request.
• "my pending changes" / "before I activate" — review unactivated drafts (active → inactive).
• An object list or package — review those objects' pending changes.
• Nothing specific ("what changed") — list the user's modifiable transports (summary) and ask which one, or default to pending drafts.

Optional: +impact (who consumes the changed CDS/RAP), +atc (new quality findings), output path for a Markdown file.

Scope guard: if the selected set exceeds ~40 diffable objects, show the object table with +/- counts only and ask which objects (or which task) to expand into full diffs. A review nobody reads is worse than no review.

Step 1: Resolve scope

• Transport id given → SAPTransport(action="get", id="<id>") → the tasks[].objects[] list.
• "what changed" / pick a transport → SAPTransport(action="list", summary=true) → a cheap table

(id, description, owner, status, objectCount). Present it, let the user pick, then get that one.

• Pending changes / package → enumerate the objects the user touched (the transport's object list,

or the objects in the named package). No transport id needed for the diff itself.

Step 2: Classify the objects

Split the object list into:

• Diffable (source types above) → these get a real diff in Step 3.
• Metadata-only (SRVB, G4BA, SUSH, DOMA, DTEL, MSAG, VIEW, ENHO, AUTH, DEVC, server-driven, …) →

action="diff" returns "not supported" (their read is parsed metadata/XML, not plain-text source). This is exactly the boundary SAP's own Eclipse ADT 3.6 "Object Changes" has — it prints "Feature not supported for object …" for these same types (e.g. SRVB). Don't try to diff them. For a thorough review, still read the object's metadata (e.g. SAPRead(type="SRVB", name=…)) so the report names what the object is and that it's in the change set — just without a source diff.

Step 3: Diff each object — pick from/to by intent

Run these in parallel (each returns only hunks):

SAPRead(type="<type>", name="<name>", action="diff", from="<from>", to="<to>")

Choose the sides by what the user is reviewing:

Snapshot-sparsity reality (important): ABAP cuts a version snapshot only when a transport is released. So for an open/unreleased transport, objects usually have just the active version (+ maybe an inactive draft) — there is no "before" revision to diff against. Handle it honestly:

1. For each object, SAPRead(type="VERSIONS", name=…, objectType=…). If ≥2 revisions exist, diff the

pre-change revision → active.

1. If only 1 revision (the common case for unreleased work), fall back to active → inactive (shows

the pending edit) and label it "pending (unactivated)".

1. If active == inactive and only 1 revision, report "no diff available (object created in this

transport, or no prior snapshot)" — for a brand-new object, note it's an add, not a change.

Step 4 (optional): impact + quality — only when asked or the change is risky

• Impact (a changed DDLS/BDEF/SRVD can break consumers): SAPContext(action="impact", type="DDLS", name="<view>") → projection views, BDEFs, service defs/bindings, ABAP consumers that depend on it.
• Quality: SAPDiagnose(action="atc", ...) per changed object → new ATC findings the change introduces; or SAPLint(action="lint", name=…) for a fast local pass.
• Pre-release validity: for unactivated work, SAPActivate (or SAPDiagnose action="syntax") confirms the draft even compiles before you stake a release on it.

Step 5: Write the report

# Change review — <transport id or "pending drafts"> on <SID>

_<owner> · <status> · <description>_

## Summary

| Object | Type | Change | +/− | Flags |
|---|---|---|---|---|
| ZCL_ORDER | CLAS | changed | +12 −3 | |
| ZI_ORDER  | DDLS | changed | +4 −0  | impacts 3 consumers |
| ZNEW_REPORT | PROG | added  | —      | new in this transport |
| ZSTATUS   | DOMA | changed | —      | metadata — no source diff |
| ZHELPER   | PROG | $TMP   | —      | ⚠ local — will NOT transport |

## Diffs

### ZCL_ORDER (CLAS)  active → inactive  (+12 −3)

<the unified-diff hunks from SAPRead action="diff">

…one block per diffable object…

## Risk flags
- ⚠ ZHELPER is in $TMP — it will not travel with this transport.
- ⚠ ZI_ORDER (DDLS) has 3 downstream consumers — re-activation order matters (see impact).
- ⚠ ZCL_BP locked in 2 transports — possible import-sequence conflict.

## Verdict
<2–3 lines: what this change set does, what to review first, what's risky / not yet activated.>

Write to disk (default docs/reviews/transport-<id>-<date>.md) only if asked; otherwise return inline.

Error Handling

When to use this skill

• Pre-release / pre-activation gate — "show me everything I'm about to ship."
• Code review of a colleague's transport without leaving the chat — the headless / pasteable / whole-transport-at-once counterpart to Eclipse ADT 3.6's "Object Changes" tab (same per-object diffs, same coverage boundary).
• Hand-off / audit — a written delta of a change set.
• "What changed after my last request / since my last release?" (since-last-release mode).
• "I've been editing for an hour — what have I actually changed?" (pending-drafts mode).

When NOT to use this skill

• System-wide inventory of every open transport (basis: who has what open, sizes, conflicts — no diffs) → sap-transport-overview. This skill is depth-on-one-transport; that one is breadth-across-the-system.
• Understanding one object deeply → explain-abap-code.
• Documenting a whole package (not a delta) → sap-object-documenter.
• Across multiple systems (DEV vs QAS source compare) → out of scope here: ARC-1 binds to one system

per instance. Do a cross-system review by running the ARC-1 CLI against each system (arc1-cli call SAPRead … --url <sys>) and diffing the two outputs — a separate orchestration, not this skill.

Follow-up Options

• "Activate / release this once it looks right?" → SAPActivate, then SAPTransport(action="release").
• "Who breaks if I change this CDS?" → SAPContext(action="impact") (or re-run with +impact).
• "Document these objects properly?" → sap-object-documenter.
• "Clean-core readiness of the changed objects?" → sap-clean-core-atc.