SAP Transport Gate Skill

AI-assisted pre-release review for SAP Transport Requests. Based on provided evidence, produces a structured Release Readiness Report and an auditable GO / CONDITIONAL_GO / NO_GO / NEED_MORE_EVIDENCE decision.

Core principle: AI does NOT log in to SAP, does NOT execute transports, and does NOT fabricate conclusions from insufficient evidence. Every finding must trace to real evidence. Every gap must be declared.

---

Hard Constraints (enforce at all times)

Constraint	Rule
No SAP login	Never request or accept SAP passwords, connection strings, or session tokens
No transport execution	Never trigger transport release, import, delete, or rollback
No evidence fabrication	No assumption that unread objects are safe; no invented test results
Evidence Level LOW → no GO	If Evidence Level is LOW, the decision must be NEED_MORE_EVIDENCE or NO_GO — never GO
Single-file ≠ full TR review	A single ABAP file does not constitute a Transport Request-level release review
Missing spec → Inferred only	Without a functional specification, Functional Alignment must be labeled Inferred / Limited

Violations of these constraints invalidate the review output. Check them before generating any decision.

---

Step 0 — Load References

Before reading user-provided materials, load the following references in order:

1. references/review-modes.md — Mode detection, Review Package structure, evidence completeness rules
2. references/decision-policy.md — Evidence Level rules, Finding taxonomy, Release Decision Policy
3. references/review-dimensions.md — 10 review dimensions with detailed checks
4. references/report-format.md — Markdown report template and JSON schema
5. references/abap-security-rules.md — Full SEC-_ and AUTH-_ security rule library (load for Dimension 3 and 4)
6. references/abap-quality-rules.md — Full Clean ABAP quality rule library (load for Dimension 1 and 2)

Load references/sap-connectivity.md when:

• Review mode is Online Transport Mode (TR ID provided, no pre-exported package)

Load references/human-loop.md when:

• Target stage is PRD
• Any HIGH or CRITICAL finding is present
• Functional Alignment depends on business interpretation

Load references/regression-tests.md only if asked to run regression checks or build eval cases.

---

Step 0.5 — Extract Transport Request ID

Scan the user's input for a Transport Request ID before proceeding. TR IDs follow the pattern: 3–4 uppercase letters + K + 6 digits (e.g., DEVK900123, ECDK943668, NPLK000045).

Case	Action
TR ID found in input	Record it as {TR_ID}. Use it in the report filename, header, and all references throughout this review.
User provides a Review Package directory	Extract TR ID from manifest.json → meta.tr_id field.
No TR ID found but review was requested	Ask: "Please provide the Transport Request ID (e.g., DEVK900123) to begin the review." Do not proceed until a TR ID is supplied.
User confirms no TR ID exists	Declare scope as Partial / No TR Identity. Evidence Level is capped at LOW. Proceed only to produce a NEED_MORE_EVIDENCE report.

The TR ID is required for the report filename, the Executive Decision header, the Appendix object list, and audit traceability.

---

Step 1 — Identify Review Mode

Determine the review mode from the input. Full rules in references/review-modes.md §1.

Signal	Mode
User provides a standard Review Package (manifest + object list + sources + evidence)	Offline Package Mode
User provides only source files or partial materials (no manifest, no full TR context)	Offline Local Mode
User provides a Transport Request ID and CLI output or live system access via internal tools	Online Transport Mode

Online Transport Mode — Proactive Collection Protocol:

When a TR ID is identified and no pre-assembled package exists, the SKILL must proactively attempt collection rather than waiting for the user to provide materials. Execute the following in order:

1. Check credential availability — inspect .env in the skill directory, ~/.sap-transport-gate/config.json, and process environment variables for SAP_URL, SAP_USERNAME, SAP_PASSWORD, SAP_CLIENT.

2. Credentials found → run tr_collector.py collect automatically:

   Using available shell execution tools (e.g., Bash), run:

   python3 scripts/tr_collector.py collect {TR_ID} --output-dir reports/{TR_ID}_package/ --verbose
   

   • Collection succeeds → proceed as Offline Package Mode with the collected package at reports/{TR_ID}_package/. Do NOT ask the user to run the script.

   • Collection fails (HTTP 401, 403, connection refused, SSL error, timeout):

     "SAP connection failed: {error}. Proceeding with Offline Local Mode. See references/sap-connectivity.md §11 for the step-by-step manual export guide if you want a complete evidence package."

     Reclassify to Offline Local Mode and continue.

3. Credentials not configured — no .env, no config file, no env vars:

   "No SAP credentials found. Proceeding with Offline Local Mode using materials already provided.

   To enable automatic TR collection in future reviews, configure credentials via:

   • Option A: Copy .env.example to .env and fill in SAP_URL, SAP_USERNAME, SAP_PASSWORD, SAP_CLIENT.
   • Option B: Run python3 scripts/tr_collector.py configure for interactive setup, then python3 scripts/tr_collector.py ping to verify."

   Reclassify to Offline Local Mode and continue.

4. Shell execution not available — if the AI agent has no shell/bash capability:

   "Shell execution is not available in this environment. To use automatic collection, run:

   python3 scripts/tr_collector.py collect {TR_ID} --output-dir reports/{TR_ID}_package/ --verbose
   

   Once the package is ready, provide the path and I will proceed as Offline Package Mode. Or confirm you cannot run it to proceed now with Offline Local Mode."

   Wait for user response before continuing. Do NOT fabricate materials.

When falling back to Offline Local Mode at any point, reclassify mode, declare the fallback reason in the report, and continue.

Offline Package Mode is the preferred and most complete mode. Always declare the mode at the top of the report.

If mode cannot be determined from the input, ask the user one clarifying question before proceeding.

---

Step 1.5 — Review Scope Selection

Human confirmation required before proceeding.

Ask the user:

"I'll be reviewing Transport Request {TR_ID}.

Which review scope do you need?

(A) Code Quality Review — Covers: code quality, performance, security, authorization, transaction consistency, integration impact, transport completeness, release readiness, and evidence gaps. Assesses whether the code is well-written and safe to release. Does not evaluate whether the implementation matches business requirements.

(B) Functional + Code Quality Review — All of the above, plus Functional Alignment (Dimension 8): verifies that the code correctly implements the stated business requirements. Requires a functional specification or requirements document.

Which scope? (A or B)"

If user selects (A) — Code Quality Review:

• Exclude Dimension 8 (Functional Alignment) from the review. Mark it as N/A — excluded by user choice.
• Proceed to Step 2.

If user selects (B) — Functional + Code Quality Review:

• Check whether a functional specification or requirements document is present in the provided materials.

• Spec is present → proceed to Step 2 with all 10 dimensions active.

• Spec is absent → do not start the review. Prompt:

  "Functional + Code Quality Review requires a functional specification. Please provide one of:

  • A functional spec document (Markdown, Word, PDF, or plain text)
  • A requirements ticket, Jira issue, or user story
  • A change request or design document

  Once provided, I will include Dimension 8 (Functional Alignment) in the review."

  If the user confirms no spec exists but still wants a Functional + Code Quality review:

  • Proceed with all 10 dimensions.
  • Set Dimension 8 outcome to Inferred / Limited — no spec provided per the Hard Constraint.
  • Record an EVIDENCE_GAP finding with severity HIGH for the missing functional specification.
  • This gap will restrict Evidence Level and the final decision.

---

Step 2 — Evidence Intake and Completeness Check

Inventory all materials provided by the user. Required evidence varies by mode — see references/review-modes.md §2 for full checklists.

Quick reference — evidence categories:

Category	Items
TR Identity	Transport Request ID, type, owner, source system, target stage, creation time
Object List	Object type, name, package, changed-by, source file path for each object
Source Code	ABAP programs, classes, function groups, includes, CDS views, DDIC definitions
Dependencies	Intra-TR, extra-TR, table, interface, authorization-object dependencies
Metadata	Table / CDS / authorization / interface / customizing metadata
Functional Material	Functional spec, requirement note, test note
Release Evidence	Syntax check result, activation status, unit/manual test results, collection log

For each category, mark: Present / Partial / Missing.

Missing evidence does not stop the review — it restricts what can be concluded. Every missing item must be flagged as an EVIDENCE_GAP finding.

---

Step 3 — Evidence Level

Determine Evidence Level before beginning dimensional review. Full rules in references/decision-policy.md §1.

Level	Meaning
HIGH	TR objects, source, dependencies, functional spec, syntax/activation status, and test evidence are substantially complete
MEDIUM	Key evidence is largely complete but some items are missing (e.g., test evidence incomplete or dependencies partial)
LOW	Only source fragments, incomplete object list, missing functional spec, or missing release-critical evidence
UNKNOWN	Input materials are unstructured, unreadable, or scope cannot be determined

Decision gates by Evidence Level:

• UNKNOWN → immediately output NEED_MORE_EVIDENCE; do not proceed with dimensional review
• LOW → proceed with dimensional review, but the final decision must be NEED_MORE_EVIDENCE or NO_GO; GO and CONDITIONAL_GO are forbidden

---

Step 4 — Multi-Dimension Review

Complete all 10 dimensions below. Never skip a dimension — if nothing was found, state "No issues found."

Full detail for each dimension in references/review-dimensions.md.

#	Dimension	Focus
1	Code Quality	Naming, maintainability, exception handling, duplication, hardcoding, complexity
2	Performance	SELECT IN LOOP, full table scan, missing key condition, inefficient internal table ops
3	Security	Dynamic SQL, dangerous functions, external calls, sensitive data exposure, unvalidated input
4	Authorization	AUTHORITY-CHECK coverage, auth object correctness, privilege escalation paths, bypass patterns
5	Transaction Consistency	COMMIT/ROLLBACK placement, BAPI commit, LUW integrity, update consistency
6	Integration Impact	RFC, IDoc, OData, HTTP, BAPI, file interfaces — impact on external systems
7	Transport Completeness	Object list completeness, missing extra-TR dependencies, DDIC/CDS/config dependencies
8	Functional Alignment	Code vs. functional spec — business rules, boundary conditions, exception flows
9	Release Readiness	Syntax check status, activation status, test evidence, rollback plan, pre-conditions
10	Evidence Gap	Missing materials, unverifiable assumptions, items requiring human confirmation

For Functional Alignment: skip if no functional spec is provided and label as Inferred / Limited — no spec provided. Do not infer requirements independently.

For Evidence Gap: always produce at least one finding per missing evidence category.

---

Step 5 — Findings

Each finding must include all fields. Full schema in references/decision-policy.md §2.

Required fields per finding:

• id — unique identifier within this review (e.g., F-001)
• type — one of: CODE_QUALITY, PERFORMANCE, SECURITY, AUTHORIZATION, TRANSACTION_CONSISTENCY, INTEGRATION_IMPACT, TRANSPORT_COMPLETENESS, FUNCTIONAL_ALIGNMENT, RELEASE_READINESS, EVIDENCE_GAP
• severity — INFO / LOW / MEDIUM / HIGH / CRITICAL
• confidence — HIGH (direct evidence) / MEDIUM (indirect evidence) / LOW (inferred)
• object — affected object name
• location — file, line, or section reference
• evidence — real code snippet or material excerpt (max 15 lines); never fabricated
• reasoning — why this is a risk
• impact — what can go wrong if unaddressed
• recommendation — specific, actionable fix
• requires_human_confirmation — true / false

Severity calibration (abbreviated; full rules in references/decision-policy.md §2.2):

• CRITICAL: severe data loss, security breach, production outage, unrecoverable release risk
• HIGH: significant function failure, major performance degradation, missing critical dependency, release blocker
• MEDIUM: clear risk, mitigable by fix or human confirmation
• LOW: code quality or maintainability, does not directly block release
• INFO: advisory, informational

When severity is uncertain, choose the higher level.

---

Step 6 — Release Decision

Derive a single decision from Evidence Level + Findings. Full policy in references/decision-policy.md §3.

Decision	Meaning
GO	No blocking findings; evidence sufficient; safe to proceed
CONDITIONAL_GO	Proceed only after completing specified fixes or human confirmations
NO_GO	Serious risk present; do not release
NEED_MORE_EVIDENCE	Insufficient evidence for a reliable judgment

Decision priority (highest wins):

NO_GO               ← CRITICAL risk or severe unmitigated HIGH risk
NEED_MORE_EVIDENCE  ← Evidence too thin for reliable judgment
CONDITIONAL_GO      ← Risk exists but mitigable before release
GO                  ← Sufficient evidence, no blocking risk

Non-negotiable rules:

1. Evidence Level LOW → GO and CONDITIONAL_GO are forbidden
2. Evidence Level UNKNOWN → always NEED_MORE_EVIDENCE
3. Any CRITICAL SECURITY / AUTHORIZATION / TRANSACTION_CONSISTENCY finding → NO_GO
4. If CRITICAL risk and evidence gap coexist → NO_GO; list evidence gap as additional risk

---

Step 7 — Generate Reports

Generate both outputs. Templates in references/report-format.md.

Markdown Report (primary)

Structure:

1. Executive Decision (Decision, Evidence Level, Overall Risk, Target Stage, TR ID, Review Mode, Rule Pack)
2. Scope Reviewed (what was reviewed, what was not)
3. Evidence Summary (present / missing / restricted)
4. Key Findings (by severity)
5. Review by Dimension (all active dimensions; Dimension 8 marked N/A if user selected Code Quality Review)
6. Required Actions Before Release
7. Human Confirmation Checklist
8. Decision Rationale
9. Appendix:
   • §9.1 Object List Summary (mandatory) — every TR object listed by type, name, and whether its source was reviewed
   • §9.2 Evidence References
   • §9.3 Assumptions
   • §9.4 Limitations and Unreviewed Scope
   • §9.5 Sign-off Table

Report rules:

• Every high-risk finding must have a recommendation
• Every evidence gap must explain its impact on the decision
• All inferred conclusions must be labeled [Inferred] or [Needs confirmation]
• Never write "looks fine" or "seems OK" without citing evidence
• Report language: English

File naming: TR_REVIEW_{TR_ID}_{YYYYMMDD}.md When NO_GO: prefix NOGO_TR_REVIEW_{TR_ID}_{YYYYMMDD}.md When NEED_MORE_EVIDENCE: prefix NME_TR_REVIEW_{TR_ID}_{YYYYMMDD}.md Full naming table in references/report-format.md §3.

Save location — always use a TR-specific subdirectory:

Always save reports to reports/{TR_ID}_package/ regardless of review mode. Never save directly to reports/.

Mode	Directory creation
Online Transport Mode	tr_collector.py collect --output-dir reports/{TR_ID}_package/ creates the directory automatically. Reports are saved inside it alongside manifest.json and sources/.
Offline Package Mode	If the user provided a package at a different path, save reports to that path. If no path was specified, create reports/{TR_ID}_package/ and save there.
Offline Local Mode	Create reports/{TR_ID}_package/ even if no manifest exists. Save all reports and any user-provided evidence files there.

Create the target directory automatically. Never ask the user to create it manually.

JSON Summary (secondary)

For CI pipelines, dashboards, and audit archives. Schema in references/report-format.md §2.

---

References Index

File	When to read
references/review-modes.md	Mode detection, Review Package structure, evidence checklists
references/review-dimensions.md	Detailed check items per dimension
references/decision-policy.md	Evidence Level rules, Finding schema, Release Decision Policy
references/report-format.md	Markdown report template, JSON schema
references/abap-security-rules.md	SEC-_ and AUTH-_ security rule library (Dimensions 3 & 4)
references/abap-quality-rules.md	Clean ABAP quality rules (Dimensions 1 & 2)
references/abap-report-template.md	Structured Markdown report template for individual object reviews
references/sap-connectivity.md	SAP ADT auth, TR extraction CLI, credential setup (Online Transport Mode)
references/human-loop.md	Who confirms what, when, based on what evidence
references/regression-tests.md	Bad cases, regression assertions, eval cases