/sap-transport-request

name: sap-transport-request
description: |
  Resolves a modifiable SAP transport request, applying the
  way_to_get_transport_request policy from sap-dev-core settings.json.
  This is the single entry point that all deploy skills (sap-se11, sap-se38,
  sap-se37, sap-se24, sap-se91) call when they need a TR — it centralises the
  DEFAULT / ASK / CREATE_NEW flow so callers never have to ask the user
  themselves. When a new TR is required, delegates creation to /sap-se01
  (GUI mode) or to its built-in RFC creator (CTS_API_CREATE_CHANGE_REQUEST).
  Honours rule_of_tr_description for the description text. An unverifiable
  or non-modifiable candidate TR is re-prompted per the policy loop —
  never silently replaced by a freshly created TR.
  Resolves Workbench requests by default, or Customizing requests (E070
  TRFUNCTION='W') when called with --type customizing (used by /sap-sm30 and
  /sap-pfcg) — Customizing candidates are additionally validated for request
  class and client (E070C-CLIENT = the pinned client), and use a separate
  sap_dev_customizing_request default so one task can hold a TR of each type.
  Prerequisites: SAP profile saved via /sap-login (RFC password required).
  SAP NCo 3.1 (32-bit, .NET 4.0) in GAC for RFC paths; active SAP GUI session
  (use /sap-login first) is additionally required when way_to_get_transport_request=CREATE_NEW
  delegates creation to /sap-se01 (GUI).
argument-hint: "[transport-request-number] [--type workbench|customizing] [OBJECT_TYPE=<...>] [OBJECT_DESCRIPTION=<...>]"

SAP Transport Request Skill

You resolve a modifiable SAP transport request for the caller, applying the `way_to_get_transport_request` policy from sap-dev-core `settings.json`. This skill is the **single TR-resolution entry point** that all deploy skills must use; they MUST NOT prompt the user for a TR or call `/sap-se01` themselves.

Task: $ARGUMENTS

Shared Resources

| File | Purpose | |---|---| | `<SAP_DEV_CORE_SHARED_DIR>/rules/safety_policy.md` | **Rule 0 (highest priority)** — environment guard; enforced by the create step via `sap_safety_gate.ps1` | | `<SAP_DEV_CORE_SHARED_DIR>/rules/skill_operating_rules.md` | Mandatory operating rules (no SQL writes on standard tables; no unsolicited deploys) | | `<SAP_DEV_CORE_SHARED_DIR>/rules/tr_resolution.md` | Defines `way_to_get_transport_request`, `rule_of_tr_description`, the description placeholders, and the 60-char compression rules. **This skill IS the implementation of that rule.** | | `<SAP_DEV_CORE_SHARED_DIR>/rules/language_independence_rules.md` | GUI-scripting language independence — this skill delegates to GUI-driving `/sap-se01` for new-TR creation, which must observe the rule |

---

Step 0 — Resolve Work Directory

**Resolve `work_dir` via the env-aware helper** — do NOT take `work_dir` from a direct `settings.json` read (that ignores the `SAPDEV_AI_WORK_DIR` env var and `userconfig.json`). Use the `WORK_DIR=` value printed by:

powershell -NoProfile -ExecutionPolicy Bypass -Command ". '<SAP_DEV_CORE_SHARED_DIR>\scripts\sap_settings_lib.ps1'; . '<SAP_DEV_CORE_SHARED_DIR>\scripts\sap_connection_lib.ps1'; Write-Output ('WORK_DIR=' + (Get-SapWorkDir)); Write-Output ('RUN_TEMP=' + (Get-SapRunTemp))"

The settings note below still applies to the OTHER keys.

**Settings reads/writes follow `shared/rules/settings_lookup.md`** — merge per-key on the `.value` field (env var → `settings.local.json` → `userconfig.json` → `settings.json`); non-per-connection writes go to `userconfig.json`. Resolve sap-dev-core paths: 2 levels up from `<SKILL_DIR>` to the plugin root, then `settings.json` and (if present) `settings.local.json`. **Per-connection keys (Phase 4.4)**: `way_to_get_transport_request` and `sap_dev_transport_request` are SAP-system-specific. Per `settings_lookup.md` § Per-connection exception, read them from `connections.json[pinned-profile].dev_defaults` FIRST (resolve the pin via `{work_dir}\runtime\session_registry.json` `ai_sessions[<id>]`); only fall back to the two-file merge when `dev_defaults` is empty. Skipping this step is what causes the silent cross-system contamination Phase 4.3 was meant to fix.

| Setting | Default if blank | |---|---| | `work_dir` | `C:\sap_dev_work` |

Set `{WORK_TEMP}` = `{work_dir}\temp`

Ensure the temp directory exists:

cmd /c if not exist "{WORK_TEMP}" mkdir "{WORK_TEMP}"

Set `{RUN_TEMP}` = the `RUN_TEMP=` value printed above — a fresh per-run scratch directory `{work_dir}\temp\run_<id>`, already created by `Get-SapRunTemp`. Resolve it **once here** and reuse it; write this skill's OWN scratch (the generated `sap_tr_run.*` and the `sap_tr_run.json` log-state file) under `{RUN_TEMP}` so concurrent TR resolutions never collide on fixed names. When this skill calls `/sap-se16n` to read `E070`, it passes its own `{RUN_TEMP}\se16n_E070.txt` as the **explicit output path** so the producer (se16n) and this consumer agree on the same per-run location (se16n otherwise writes to ITS own run dir, which this skill cannot read). `{WORK_TEMP}` (base) is kept only for the Step-0 definition above.

---

Step 0.5 — Start Logging

Start a structured log run. State file: `{RUN_TEMP}\sap_tr_run.json`. Best-effort. Honours `SAPDEV_PARENT_RUN_ID` env var so parent skill calls can be linked.

powershell -ExecutionPolicy Bypass -File "<SAP_DEV_CORE_SHARED_DIR>\scripts\sap_log_helper.ps1" -Action start -StateFile "{RUN_TEMP}\sap_tr_run.json" -Skill sap-transport-request -ParamsJson "{}"

---

Step 1 — Parse Arguments and Read Policy Settings

Parse `$ARGUMENTS`:

| Token | Meaning | |---|---| | A `<SID>K<digits>` token | Caller-supplied TR number override (rare; `DEFAULT`/`ASK` policies still apply on top) | | `--type workbench\|customizing` | Request class to resolve/create. Default `workbench` (E070 `TRFUNCTION='K'`). `customizing` (aliases `cust`, `W`) resolves a Customizing request (`TRFUNCTION='W'`) — see the **Request type** note below. | | `