sap-transport-review

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: Normalize CTS entries, then classify

SAPTransport get returns CTS identities, not guaranteed SAPRead inputs. Each entry has pgmid, CTS type, name, and wbtype; real transports may also contain subobjects such as LIMU/METH, LIMU/REPS, language entries, and package/metadata entries.

Before diffing:

1. Flatten tasks[].objects[], but keep the task id and original CTS key for the report.
2. Treat supported R3TR entries (R3TR/CLAS, R3TR/DDLS, …) as direct repository objects and

deduplicate exact repeats.

1. Never pass pgmid (LIMU, LANG), a CTS subtype (METH, REPS), or wbtype (CLAS/OM,

PROG/I, …) to SAPRead(type=…).

1. Fold a subobject into a direct parent entry only when the parent is unambiguous. If the response

exposes only the subobject, report it as parent resolution unavailable rather than guessing a class/include name. This is a coverage limitation, not evidence that nothing changed.

1. Count both raw CTS entries and unique resolved repository objects; do not present entry count as

a unique-object count.

Then split the resolved repository objects 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 resolved object, query SAPRead(type="VERSIONS", name=…, objectType=…) where supported.
2. For a released request, locate the revision tagged with that request and its immediate predecessor.

If either cannot be established, do not substitute current active source for an old transport.

1. For an open request, use active → inactive only for the pending portion. A prior released

revision → active comparison is useful, but label it "since released snapshot" because it can include other open requests.

1. If there is no inactive delta and no trustworthy pair of snapshots, report baseline unavailable.

Do not call it an add unless independent object metadata proves creation in this request.

The report must state its coverage: pending draft, released snapshot, since released snapshot (may span requests), or baseline unavailable.

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: when the user requests +atc, or risk justifies it, run SAPDiagnose(action="atc", ...)

only for the bounded changed set. Use SAPLint(action="lint", name=…) for a cheaper local pass.

• Pre-release validity: use the read-only SAPDiagnose action="syntax" check for unactivated work.

SAPActivate mutates system state; run it only when the user explicitly asks to activate.

Step 5: Write the report

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

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

_Coverage: <pending draft | released snapshot | since released snapshot | baseline unavailable>_

## Summary

| Object | Type | Change | +/− | Flags |
|---|---|---|---|---|
| ZCL_ORDER | CLAS | changed | +12 −3 | |
| ZI_ORDER  | DDLS | changed | +4 −0  | impacts 3 consumers |
| ZNEW_REPORT | PROG | unknown | —     | baseline unavailable |
| ZSTATUS   | DOMA | changed | —      | metadata — no source diff |
| <CTS subobject> | LIMU/METH | unresolved | — | parent resolution unavailable |

## Diffs

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

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

…one block per diffable object…

## Risk flags
- ⚠ ZI_ORDER (DDLS) has 3 downstream consumers — re-activation order matters (see impact).
- ⚠ ZCL_BP appears in two explicitly expanded request manifests; current lock holder is A4HK900123.
- ⚠ A4HK900123 has no target — this is a local request and cannot be imported onward.

## 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.