@raishin/vanguard-frontier-agentic 2.11.0 → 2.13.1

package/skills/sap/sap-guarded-role-assignment/references/live-environment-access.md

@@ -0,0 +1,93 @@
+# Live environment access — SAP Guarded Role Assignment
+
+This reference defines credential setup, role requirements, command restrictions by step, and audit log format for guarded role assignment sessions.
+
+## Credential requirements
+
+### SAP BTP (Role Collection Management)
+
+Required authorization for the executing user:
+- Role collection: **User and Role Administrator** scoped to the specific target subaccount only
+- Not permitted: Global Account Administrator (grants cross-subaccount write access)
+- Not permitted: Subaccount Administrator (grants configuration changes beyond role assignment)
+
+API token scope (BTP Security API):
+- Minimum: `xs_security.token.client_credentials` with `uaa.resource` scope for the target subaccount
+- Never request organization-level or global account-level token scopes
+
+### S/4HANA and SAP NetWeaver (SU01 / PFCG)
+
+Required authorization objects for the role assignment user:
+- `S_USER_AGR` with `ACTVT = 03` (display) — for step 8 (read-only current state)
+- `S_USER_AGR` with `ACTVT = 22` (assign roles) — for step 14 (execute approved change), scoped to target client only
+- `S_TCODE`: SU01 (display and change), PFCG (display only for role content inspection), SUIM (display)
+- Not permitted: `SAP_ALL` or any BASIS administrator profile
+- Not permitted: `S_USER_GRP` with ACTVT=01/02 (create/modify user master records) — this skill covers role assignment only, not user creation
+
+### SAP Cloud Identity Services (IAS / IPS)
+
+Required service account scope:
+- IAS role: **User Administrator** for the specific IAS tenant
+- IPS role: provisioning operator for the specific IPS system
+- Not permitted: Tenant Administrator role (grants IAS system configuration rights)
+- Never store IAS client ID or client secret in any output
+
+### SAP Access Control / Cloud Identity Access Governance (SoD checks — step 9 only)
+
+Required access:
+- SAP GRC AC: Risk Analyst or Access Request Processor role — read access to SoD risk simulation
+- Cloud IAG: Risk Analyst scope for the relevant business unit
+- Not permitted: GRC System Administrator role (grants ruleset modification rights)
+
+## Step-by-step access matrix
+
+| Step | Live system access | Access type | Credential scope |
+|------|--------------------|-------------|-----------------|
+| 1–7 | None | Advisory only | Not applicable |
+| 8 | BTP Security API / SU01 / IAS API | Read-only | BTP User+Role Admin GET / S_USER_AGR ACTVT=03 / IAS User Admin GET |
+| 9 | SAP GRC / Cloud IAG / BTP API | Read-only (SoD simulation) | GRC Risk Analyst / Cloud IAG Risk Analyst / BTP User+Role Admin GET |
+| 10–13 | None | Advisory only | Not applicable |
+| 14 | BTP Security API / SU01 / IAS API | Mutating — assignment/revocation only | BTP User+Role Admin PUT/DELETE / S_USER_AGR ACTVT=22 / IAS User Admin PATCH |
+| 15 | BTP Security API / SU01 / IAS API / GRC | Read-only | Same as step 8 + GRC Risk Analyst |
+| 16–17 | None | Reporting only | Not applicable |
+
+## Audit log format
+
+Every command executed (steps 8, 9, 14, 15) must be logged before execution:
+
+```
+[ROLE_ASSIGNMENT_AUDIT_LOG]
+Step: <step number and name>
+Timestamp (UTC): <ISO 8601>
+System: <BTP subaccount GUID OR S/4HANA SID + client OR IAS tenant ID>
+Tool: <BTP Security API | S/4HANA SU01 | SAP IAS API | SAP GRC | Cloud IAG>
+Command/API call: <exact command or API endpoint, credentials omitted>
+Target user(s)/group(s): <list of user IDs or group names>
+Role(s) in scope: <list of role collection names or PFCG role names>
+SoD pre-check result: <passed (no conflicts) | failed (<conflict list>) | not yet run>
+Output summary: <one-line summary>
+Errors/Warnings: <none | list>
+Redactions applied: <yes/no>
+Approval gate cleared: <yes (step 13 documented) | not yet reached>
+```
+
+## Pre-execution gate checklist (step 13 → step 14)
+
+Before executing any role assignment or revocation command, all of the following must be true:
+
+- [ ] Step 1: Role change type, role type, and scope classified
+- [ ] Step 2: Target system, subaccount/client, and tier confirmed
+- [ ] Step 3: Criticality level assigned
+- [ ] Step 4: Requester name and role documented
+- [ ] Step 5: Approver name, role, and identity documented (different from requester)
+- [ ] Step 6: Access request or change management ticket number confirmed
+- [ ] Step 7: Complete role list with target user(s)/group(s) and validity period documented
+- [ ] Step 8: Read-only current role assignment snapshot obtained (live evidence on record)
+- [ ] Step 9: SoD pre-check passed (no Critical or High conflicts); effective-permission diff produced
+- [ ] Step 10: Blast radius document confirmed
+- [ ] Step 11: Rollback procedure documented and confirmed feasible
+- [ ] Step 12: SoD confirmed — requester and approver are different individuals; SoD pre-check result is pass
+- [ ] Step 13: Explicit written approval from authorized approver on record
+
+If any item is unchecked, refuse step 14 execution until it is resolved.
+If step 9 returned any SoD conflict, refuse step 14 execution regardless of other steps.

package/skills/sap/sap-guarded-role-assignment/references/official-sources.md

@@ -0,0 +1,73 @@
+# Official sources — SAP Guarded Role Assignment
+
+Use this reference when grounding SAP role collection management, PFCG authorization procedures, Cloud Identity Services operations, and GRC/access governance controls.
+
+**Evidence level**: documentation-based (SAP Help Portal). Live evidence gathered during steps 8, 9, and 14 is labeled separately as `live evidence` per the audit format in `references/live-environment-access.md`.
+
+## SAP BTP Role Collections
+
+- SAP BTP role collections and roles in global accounts, directories, and subaccounts
+  https://help.sap.com/docs/btp/sap-business-technology-platform/role-collections-and-roles-in-global-accounts-directories-and-subaccounts
+  source_owner: SAP SE
+  topic_supported: BTP role collection structure, role assignment scopes, global account vs. subaccount role collections, predefined vs. custom role collections
+  why_needed: Authoritative source for BTP role collection architecture used in steps 1, 2, 7, 8, and 14 when the target is a BTP subaccount or global account
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- SAP BTP — assign role collections to users or user groups
+  https://help.sap.com/docs/btp/sap-business-technology-platform/assign-role-collections-to-users-or-user-groups
+  source_owner: SAP SE
+  topic_supported: Step-by-step role collection assignment and revocation procedures for BTP subaccounts; API and cockpit methods; group-based assignment
+  why_needed: Defines the exact assignment and revocation operations permitted in step 14 and the read-only inspection methods used in step 8
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- SAP BTP security in the Cloud Foundry environment
+  https://help.sap.com/docs/btp/sap-business-technology-platform/security-in-the-cloud-foundry-environment
+  source_owner: SAP SE
+  topic_supported: Cloud Foundry org/space role model, role bindings, service instance permissions, scoped authorization patterns
+  why_needed: Grounds steps 3 and 10 (criticality and blast radius) for Cloud Foundry environment role assignments, particularly for integration and application runtime access
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP NetWeaver / S/4HANA PFCG Authorization Management
+
+- SAP NetWeaver PFCG role maintenance and authorization management
+  https://help.sap.com/docs/SAP_NETWEAVER_750/6dae0b55c6264f94b4e7e5f2e696d5d2/4a31e3fd18b44f7e9e3d2c16cdcd5e31.html
+  source_owner: SAP SE
+  topic_supported: PFCG transaction, composite role management, user assignment to roles, authorization object maintenance, SU01 user administration
+  why_needed: Authoritative source for PFCG-based role assignment procedures and authorization object scope used in steps 8, 9, and 14 for ABAP/S/4HANA targets
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP Cloud Identity Services (IAS / IPS)
+
+- SAP Cloud Identity Services — manage users
+  https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/manage-users
+  source_owner: SAP SE
+  topic_supported: Identity Authentication Service (IAS) user management, user account attributes, role assignments for IAS-managed users
+  why_needed: Required for steps 8 and 14 when the target user is managed via SAP IAS and role assignment flows through IAS/IPS provisioning
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- SAP Cloud Identity Services — manage groups
+  https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/manage-groups
+  source_owner: SAP SE
+  topic_supported: Group creation and management in IAS, group-to-role-collection mapping, IPS group provisioning to target systems
+  why_needed: Grounds step 7 (scope documentation) and step 14 when role changes target IAS/IPS groups rather than individual users
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP Access Control / Cloud Identity Access Governance
+
+- SAP Access Control — access risk analysis and SoD management
+  https://help.sap.com/docs/SAP_ACCESS_CONTROL/a44f200cb83c4f0fa06c50c73e67e7c8/e5c4e14d9f804a53a1baa2f8d4e12c87.html
+  source_owner: SAP SE
+  topic_supported: SoD risk analysis, access risk simulation for proposed role assignments, access request workflow, risk remediation and mitigation
+  why_needed: Authoritative source for the SoD pre-check methodology used in step 9; defines risk levels, conflict types, and remediation paths; grounds step 12 (SoD verification)
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Grounding rule
+
+SAP Help Portal documentation describes role management design intent, authorization object requirements, and API specifications. It does not prove which roles are currently assigned to a user in the target system, what SoD conflicts exist in the user's landscape configuration, or whether the target system's GRC ruleset matches the default SAP Access Control rulebook. Users must supply live evidence from steps 8, 9, and 15 for concrete access assessment.

package/skills/sap/sap-guarded-role-assignment/references/safety-checklist.md

@@ -0,0 +1,57 @@
+# Safety checklist — SAP Guarded Role Assignment
+
+Use before every step and unconditionally before step 14 execution.
+
+## Non-negotiables
+
+- Do not reach step 14 (execute) without a documented approval from an authorized approver on record in this session.
+- Do not allow self-approval. The requester (step 4) and the approver (step 5) must be different individuals. If they are the same, refuse execution.
+- Do not assign any role that produces an SoD conflict identified in step 9 — even with explicit approval from the security owner. SoD conflicts are a hard stop.
+- Do not assign roles not on the approved list from step 7.
+- Do not skip or reorder steps. The sequence is mandatory.
+- Do not use global account administrator or tenant administrator credentials. Use a user with User and Role Administrator scope for the specific target subaccount or system client only.
+- Do not accept, log, echo, or include BTP service keys, IAS client secrets, OAuth tokens, or ABAP logon passwords in any output.
+- Do not attempt self-recovery after a failed assignment without initiating a new 17-step sequence.
+- Do not grant SAP_ALL, Administrator role collections, or any other unrestricted authorization profile under any circumstance — not even temporarily.
+- Do not assign roles without a documented validity period for time-limited access grants.
+
+## What people get wrong
+
+- **Treating verbal approval as sufficient**: Step 13 requires explicit written approval documented in the session. Verbal or assumed approval does not clear the gate.
+- **Skipping the SoD pre-check because the role seems harmless**: Step 9 is mandatory regardless of role type. Configuration roles can create SoD conflicts with existing financial roles.
+- **Assuming QA user assignments are low risk**: QA systems often replicate production authorization landscapes and run integrated UAT. The full sequence applies.
+- **Batching multiple users without per-user SoD checks**: Each target user may have different existing roles. The SoD pre-check must be run per user, not once for the role collection.
+- **Using the wrong credential scope for assignment**: The executing user must have User and Role Administrator authorization scoped to the target subaccount or client only. Global Account Administrator scope is too broad.
+- **Skipping step 9 because GRC is not available**: If no GRC or Cloud IAG tool is available, document the reason, request a manual SoD review from the security owner, and treat the result as an explicit exception — not a pass.
+- **Treating "temporary access" as an exemption from the sequence**: All assignments — including time-limited ones — require the full 17 steps, with the validity period documented in step 7.
+- **Proceeding when step 15 reveals unintended permissions**: If the post-change effective-permission check shows access beyond the intended scope, stop immediately and execute the rollback plan.
+
+## When to push back
+
+- Push back when the user asks to "just assign the role" without completing prior steps.
+- Push back when the requester and approver are the same person.
+- Push back when no access request or change management ticket number is provided.
+- Push back when the SoD pre-check returns any Critical or High risk conflict.
+- Push back when the requested role is SAP_ALL, Administrator, or any broadly privileged collection.
+- Push back when the target system is production and no diff of effective permissions has been produced.
+- Push back when post-change verification (step 15) shows unintended access and the user wants to proceed without assessment or rollback.
+- Push back when the user provides a credential with global account administrator or tenant administrator scope.
+
+## Evidence labels
+
+- `live evidence` — directly observed from a live SAP system; include command, timestamp, system SID or subaccount GUID
+- `documentation-based` — grounded in SAP official docs; no live access
+- `user-provided evidence` — stated, uploaded, or confirmed by the user in this session
+- `inference` — derived reasoning; must always be labeled as such
+
+## SoD verification matrix
+
+| Role | Can request? | Can approve? |
+|------|-------------|-------------|
+| End user (business process owner) | Yes | No |
+| Functional consultant | Yes | No |
+| Security officer / GRC analyst | No | Yes |
+| Compliance officer | No | Yes |
+| IT manager / project manager | No | Yes (with security owner co-signature for high-criticality roles) |
+| Requester and approver in same person | No — SoD violation | Refuse execution |
+| Automated provisioning without human approver | No | Refuse — human approver required |

package/skills/sap/sap-guarded-role-assignment/references/workflow-and-output.md

@@ -0,0 +1,133 @@
+# Workflow and output contract — SAP Guarded Role Assignment
+
+Use this reference for all step-by-step execution, command patterns, and output formatting.
+
+## Step execution protocol
+
+For each of the 17 steps, the following must be true before advancing to the next:
+
+1. The step's required evidence is on record in this session.
+2. The user has confirmed the evidence is accurate.
+3. Any step-specific gate (e.g., SoD pre-check, approval, SoD verification) has been explicitly cleared.
+
+If any of these conditions is false, the session pauses at the current step until resolved.
+
+## Command patterns by step
+
+### Step 8 — Read-only current state
+
+#### BTP Security API (read)
+```
+GET /security/v1/subaccounts/{subaccountGuid}/users/{userId}/roleCollections
+GET /security/v1/subaccounts/{subaccountGuid}/groups/{groupId}/roleCollections
+```
+
+#### BTP Cockpit (read)
+```
+BTP Cockpit → Subaccount → Security → Users → select user → view role collections
+BTP Cockpit → Subaccount → Security → Role Collections → view assigned users
+```
+
+#### S/4HANA PFCG / SU01 (read)
+```
+Transaction SU01 → display user → Roles tab (display assigned roles and validity periods)
+Transaction PFCG → display role → User tab (display assigned users)
+Transaction SUIM → User by roles → display users holding a specific role
+```
+
+#### SAP Cloud Identity Services (IAS) API (read)
+```
+GET /service/scim/Users/{userId}    (returns group memberships and assigned roles)
+GET /service/scim/Groups/{groupId}  (returns group members)
+```
+
+### Step 9 — SoD pre-check and diff
+
+#### SAP Access Control / Cloud IAG (SoD simulation)
+```
+SAP GRC → Access Management → Access Risk Analysis → Simulate Risk for User
+  Input: user ID + proposed role(s) to add
+  Output: SoD risk report (Conflict / No Conflict per function pair)
+
+Cloud IAG → Risk Analysis → Run Risk Analysis for proposed assignment
+  Input: user + proposed role collection / role
+  Output: SoD risk level (Critical / High / Medium / Low / None)
+```
+
+**If any Critical or High SoD risk is returned: refuse assignment. Document result as step 9 evidence. Do not proceed to step 10.**
+
+#### Effective-permission diff (BTP)
+```
+Current role collections: [list from step 8]
+Proposed role collections after change: [step 7 list merged with step 8 state]
+Net-new permissions: [roles added] → [derived authorizations]
+Net-removed permissions: [roles removed] → [derived authorizations]
+```
+
+### Step 14 — Execute approved change
+
+#### BTP Security API (mutating — step 14 only, after step 13 gate is cleared)
+```
+PUT /security/v1/subaccounts/{subaccountGuid}/users/{userId}/roleCollections
+Body: { "roleCollectionNames": ["<approved role collection 1>", "<approved role collection 2>"] }
+
+DELETE /security/v1/subaccounts/{subaccountGuid}/users/{userId}/roleCollections/{roleCollectionName}
+  (for revocation of a specific role collection)
+```
+
+#### S/4HANA SU01 (mutating — step 14 only)
+```
+Transaction SU01 → change user → Roles tab → add or remove approved roles → save
+  Authorization required: S_USER_AGR with ACTVT=22 (change user role assignment)
+  Scoped to target client only
+```
+
+#### SAP Cloud Identity Services (IAS) API (mutating — step 14 only)
+```
+PATCH /service/scim/Users/{userId}
+Body (assign group): { "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], "Operations": [{"op": "add", "path": "groups", "value": [{"value": "<groupId>"}]}] }
+Body (remove group): { "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], "Operations": [{"op": "remove", "path": "groups", "value": [{"value": "<groupId>"}]}] }
+```
+
+**Never call mutating endpoints before step 13 approval gate is documented.**
+
+## Step completion checklist
+
+| Step | Evidence type | Completion marker |
+|------|--------------|------------------|
+| 1 | user-provided / documentation-based | Role change type, role type, and scope confirmed |
+| 2 | user-provided evidence | Target system, subaccount/client, and tier confirmed |
+| 3 | user-provided evidence | Criticality level assigned |
+| 4 | user-provided evidence | Requester name and role on record |
+| 5 | user-provided evidence | Approver name, role, and identity on record |
+| 6 | user-provided evidence | Ticket number confirmed |
+| 7 | user-provided evidence | Role list with target user/group and validity period on record |
+| 8 | live evidence | Current role assignment snapshot from target system |
+| 9 | live evidence or documented exception | SoD pre-check result (pass/fail) and effective-permission diff |
+| 10 | user-provided / inference | Blast radius document confirmed |
+| 11 | user-provided evidence | Rollback procedure confirmed feasible |
+| 12 | user-provided evidence | SoD confirmed: requester ≠ approver; SoD pre-check passed |
+| 13 | user-provided evidence | Explicit approval statement on record |
+| 14 | live evidence | Execution log with timestamp |
+| 15 | live evidence | Post-change role check verified; second SoD check passed |
+| 16 | all of the above | Audit record compiled |
+| 17 | user-provided evidence | Report delivered and acknowledged |
+
+## Output contract
+
+Return after each step:
+
+1. Step number and name
+2. Evidence gathered for this step (labeled by evidence type)
+3. Gate status: cleared / pending / blocked
+4. Next step and what is needed to advance
+5. Refusal marker if any gate condition is unmet (do not advance)
+6. SoD status if step 9 or step 12 (pass / fail / pending)
+
+Return after step 17:
+
+1. Complete audit record (all 17 steps with evidence and timestamps)
+2. Final change status (success / partial / failed)
+3. Post-change verification result including second SoD check
+4. Rollback status (not needed / standing by / triggered)
+5. Report delivery confirmation

package/skills/sap/sap-guarded-transport-import/SKILL.md

@@ -0,0 +1,144 @@
+---
+name: sap-guarded-transport-import
+description: Execute SAP transport request imports using a mandatory 17-step guarded mutation sequence covering classification, target confirmation, criticality, requester, approver, ticket, scope, read-only current state, diff and dry-run, blast radius, rollback plan, segregation of duties, approval gate, execute approved imports only, verify, audit, and report. Refuse if any step is missing. Use when a confirmed and approved transport import into a non-development SAP system (quality, pre-production, or production) must be executed under traceable controls.
+allowed-tools: Read Grep Glob WebSearch WebFetch Bash
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-19"
+  category: delivery
+  lifecycle: experimental
+  execution_tier: mutating-runtime
+---
+
+# SAP Guarded Transport Import
+
+## Purpose
+
+Execute SAP transport request imports into non-development systems under a strict 17-step guarded mutation sequence. Every step must be completed, documented, and confirmed before the import execution step is reached. If any step is absent, the import is refused until it is completed. This skill treats every transport import into a quality, pre-production, or production system as a risk-critical mutating operation requiring explicit approval and a documented rollback path.
+
+## When to use
+
+Use this skill when:
+
+- a transport request (TR) must be imported into a quality, pre-production, or production SAP system,
+- a change manager or project lead has confirmed the import is approved and requires traceable execution,
+- post-import verification and audit evidence are required for change management or compliance purposes,
+- the user needs a structured, risk-controlled execution protocol for SAP CTS+, STMS, or cloud transport management imports.
+
+## When not to use
+
+- When the import target is a development system (DEV) — development imports are lower risk and do not require this full sequence.
+- When the user wants to *plan* a transport without executing — advise on the sequence but do not reach the execution step.
+- When any of the 17 steps cannot be completed — refuse execution until all steps are resolved.
+- When no explicit approval from an authorized approver has been obtained — refuse execution.
+
+## Lean operating rules
+
+- 17 steps, no shortcuts. The sequence is mandatory and must be completed in order. Steps cannot be skipped or reordered.
+- Refuse before step 13. Never reach the execution step (step 14) without a documented approval from an authorized approver on record in this session.
+- Segregation of duties enforced. The person who requests the transport (step 5) must not be the same person who approves it (step 12). If SoD is violated, refuse execution.
+- Read current state before any change. Step 8 (read-only current state) must be completed before any import is proposed. Do not propose an import on undocumented target state.
+- Dry-run before live execution. Step 9 (diff/dry-run) must precede execution. If the SAP system does not support dry-run for the transport type, document the reason and require enhanced approval.
+- Blast radius documented before execution. Step 10 (blast radius) must list all objects, programs, and business processes potentially affected. Imports with undocumented blast radius are refused.
+- One transport at a time. Do not batch-import multiple transports in a single execution step unless each has completed its own full 17-step sequence.
+- Never hardcode credentials. All system access uses pre-configured RFC destinations, STMS users, or CTS+ API service keys — never credentials in plain text.
+- Evidence labeling mandatory. Every step must produce labeled evidence before the next step proceeds.
+
+## The 17-step guarded mutation sequence
+
+| Step | Name | Description | Evidence required |
+|------|------|-------------|-------------------|
+| 1 | Classify | Classify the transport type (workbench, customizing, Support Package, cloud transport) and content category (ABAP, Fiori, configuration, master data) | Transport type + content category documented |
+| 2 | Confirm target | Confirm the exact target system (SID, client, environment tier: QA/PPD/PRD) | Target SID, client, and tier confirmed by user |
+| 3 | Criticality assessment | Assess business criticality of the transported objects (financial postings, payroll, integration interfaces, core customizing) | Criticality level: low/medium/high/critical |
+| 4 | Requester confirmation | Confirm the name, role, and authorization of the change requester | Requester name and role documented |
+| 5 | Approver identification | Identify the authorized approver (different person from requester — SoD requirement) | Approver name, role, and authorization level |
+| 6 | Ticket linkage | Link the import to a change management ticket (ITSM reference: ServiceNow, Remedy, SAP Solution Manager, etc.) | Ticket number confirmed |
+| 7 | Scope documentation | Document the complete list of transport requests in the import queue, their descriptions, and interdependencies | TR list with descriptions and sequence |
+| 8 | Read-only current state | Read the current state of the target system: transport queue, import queue status, active objects, last import log | Live evidence from target system (read-only) |
+| 9 | Diff and dry-run | Perform a diff of transported objects against current target system content; run dry-run import if system supports it | Diff output or documented dry-run result |
+| 10 | Blast radius | Document all ABAP programs, configuration entries, Fiori apps, interfaces, and business processes potentially affected | Blast radius document with affected components |
+| 11 | Rollback plan | Document the explicit rollback procedure: which transports to re-import, configuration steps, or system restore path | Rollback procedure documented and confirmed feasible |
+| 12 | SoD verification | Verify that requester (step 4) and approver (step 5) are different authorized individuals; confirm no self-approval | SoD confirmed: requester ≠ approver |
+| 13 | Approval gate | Obtain explicit written approval from the authorized approver for this specific import sequence | Approval statement on record in this session |
+| 14 | Execute approved import | Execute the import for approved transport requests only, in the documented sequence | Import command log with timestamp |
+| 15 | Verify | Verify post-import system state: check import log for errors, run smoke tests, confirm business process availability | Post-import log and verification results |
+| 16 | Audit | Produce complete audit record: all 17 steps, evidence, commands, timestamps, approvals | Audit record |
+| 17 | Report | Deliver final report to requester, approver, and change manager | Report delivered and acknowledged |
+
+## Evidence rules
+
+Label all data with one of:
+
+- `live evidence` — directly observed from a live SAP system in this session (include command, output summary, timestamp)
+- `documentation-based` — grounded in SAP official docs
+- `user-provided evidence` — stated or supplied by the user in this session
+- `inference` — derived reasoning not directly confirmed by live data or official docs; must always be labeled
+
+## Live-environment rules
+
+**Allowed** (step 8 only — read-only current state):
+- STMS display transactions (read-only transport queue inspection)
+- CTS+ API GET calls to read import queue status
+- SAP Cloud Transport Management Service GET API calls
+- Read-only import log inspection
+
+**Allowed** (step 14 only — after all prior steps confirmed):
+- STMS import execution for approved transport requests
+- CTS+ API import trigger for approved requests
+- SAP Cloud Transport Management Service import trigger for approved requests
+
+**Forbidden** (all other contexts):
+- Any import command before step 13 approval gate is cleared
+- Any import of a transport not on the approved TR list from step 7
+- Any modification to transport route configuration
+- Any deletion of transport requests from the queue without explicit user instruction
+- Any ABAP system access with developer-level credentials (use transport administrator role only)
+
+**Least-privilege credential rules**:
+- STMS: use a user with `S_TRANSPRT` import authorization for the specific target system only; not BASIS administrator
+- CTS+: use a service user with CTS+ transport manager role scoped to the specific transport route
+- SAP Cloud TMS: use a Transport Operator role scoped to the specific transport node; not Transport Administrator with delete rights
+
+**Approval gate (step 13)**:
+Before step 14 execution, confirm:
+1. All steps 1–12 are documented and evidence is on record.
+2. The approver from step 5 has provided explicit written approval in this session.
+3. The approver is a different person from the requester.
+4. The approval explicitly names the transport requests to be imported.
+
+**Rollback**:
+- The rollback plan from step 11 must be documented before step 14 begins.
+- If post-import verification (step 15) reveals errors, stop immediately and escalate to the approver before any further action.
+- Do not attempt self-recovery imports without a new 17-step sequence.
+
+**Post-import (step 15)**:
+- Read the import log for all ERROR, WARNING, and ABAP short dump entries.
+- Run the smoke test or business process check specified in the blast radius document.
+- Document the verification result as `live evidence`.
+
+**Audit (step 16)**:
+- Produce a complete record of all 17 steps, evidence gathered, commands executed, timestamps, approval statement, and verification results.
+- Retain audit record for the session and deliver to the approver and change manager.
+
+## References
+
+Load only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — 17-step execution details, command patterns, output format.
+- [Safety checklist](references/safety-checklist.md) — non-negotiables, SoD rules, refusal triggers.
+- [Official sources](references/official-sources.md) — SAP TMS, CTS+, Cloud TMS, STMS docs.
+- [Live environment access](references/live-environment-access.md) — credential setup, STMS/CTS+ role requirements, audit log format.
+
+## Response minimum
+
+Return, at minimum:
+
+- **Problem classification**: transport type, content category, and target environment tier.
+- **Evidence used**: live evidence (with command log) / documentation-based / user-provided / inference.
+- **Risk level**: always risk-critical for non-development targets.
+- **Recommended action**: current step in the 17-step sequence and what is needed to advance.
+- **Refusal / escalation triggers**: refuse if approval gate not cleared; refuse if SoD violated; refuse if any step is missing; refuse if rollback plan is absent.
+- **Business impact**: what changes if the import succeeds; what breaks if it fails.
+- **Next verification step**: which step number is next and what evidence is required.

package/skills/sap/sap-guarded-transport-import/agents/openai.yaml

@@ -0,0 +1,14 @@
+interface:
+  display_name: "SAP Guarded Transport Import"
+  short_description: "Execute SAP transport imports under a mandatory 17-step guarded mutation sequence — refuses if any step is missing or approval gate is not cleared"
+  default_prompt: "Use $sap-guarded-transport-import to execute a SAP transport request import. Begin at step 1 (classify) and advance through all 17 steps in order. Do not reach step 14 (execute) without a documented approval from an authorized approver who is different from the requester. Refuse if any step is skipped, if SoD is violated, or if a rollback plan is absent."
+dependencies:
+  tools:
+    - type: "cli"
+      value: "stms"
+      description: "SAP Transport Management System (STMS) — used for read-only queue inspection (step 8) and approved import execution (step 14) using transport administrator role only"
+    - type: "api"
+      value: "sap-cloud-tms"
+      description: "SAP Cloud Transport Management Service API — GET for read-only queue status (step 8), POST import for approved requests only (step 14)"
+policy:
+  allow_implicit_invocation: false

package/skills/sap/sap-guarded-transport-import/metadata.json

@@ -0,0 +1,34 @@
+{
+  "id": "sap-guarded-transport-import",
+  "name": "SAP Guarded Transport Import",
+  "type": "skill",
+  "provider": "sap",
+  "harnesses": [
+    "claude-code",
+    "codex",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Execute SAP transport request imports into quality, pre-production, or production systems using a mandatory 17-step guarded mutation sequence: classify, confirm target, criticality, requester, approver, ticket, scope, read-only current state, diff/dry-run, blast radius, rollback, SoD, approval gate, execute approved only, verify, audit, report. Refuses if any step is missing.",
+  "source_type": "original",
+  "category": "delivery",
+  "official_docs": [
+    "https://help.sap.com/docs/cloud-transport-management/sap-cloud-transport-management/what-is-sap-cloud-transport-management",
+    "https://help.sap.com/docs/cloud-transport-management/sap-cloud-transport-management/transport-nodes-and-routes",
+    "https://help.sap.com/docs/cloud-transport-management/sap-cloud-transport-management/importing-transport-requests",
+    "https://help.sap.com/docs/sap-solution-manager/sap-solution-manager/change-request-management",
+    "https://help.sap.com/docs/cloud-transport-management/sap-cloud-transport-management/transport-management-system-integration",
+    "https://help.sap.com/docs/btp/sap-business-technology-platform/change-management-in-sap-btp",
+    "https://help.sap.com/docs/abap-platform/abap-platform/transport-organizer-and-stms",
+    "https://help.sap.com/docs/cloud-transport-management/sap-cloud-transport-management/segregation-of-duties-in-transport-management"
+  ],
+  "security_notes": "Mutating operations are gated behind the 17-step sequence. Never execute an import before step 13 approval gate is cleared. Never accept self-approval (SoD: requester must differ from approver). Never use BASIS administrator credentials — use transport administrator role scoped to the target system. Never import transports not on the approved TR list. Never hardcode or accept system credentials, ABAP passwords, or CTS+ service key values in plain text. Refuse any request to skip steps.",
+  "last_verified": "2026-06-19",
+  "path": "skills/sap/sap-guarded-transport-import",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "lifecycle": "experimental",
+  "execution_tier": "mutating-runtime"
+}

package/skills/sap/sap-guarded-transport-import/references/live-environment-access.md

@@ -0,0 +1,81 @@
+# Live environment access — SAP Guarded Transport Import
+
+This reference defines credential setup, role requirements, command restrictions by step, and audit log format for guarded transport import sessions.
+
+## Credential requirements
+
+### STMS (ABAP Transport Management)
+
+Required authorization objects for the transport import user:
+- `S_TRANSPRT` with `ACTVT = 03` (display) — for step 8 (read-only current state)
+- `S_TRANSPRT` with `ACTVT = 42` (import) — for step 14 (execute approved import), scoped to target system only
+- `S_TCODE`: SE10 (display), STMS (display and import), no development transactions
+
+Never use:
+- A user with `SAP_ALL` or BASIS administrator profile
+- A developer user (S_DEVELOP with ACTVT 01/02) for transport import execution
+- A user with `S_TRANSPRT ACTVT = 06` (delete) — transport deletion is never permitted by this skill
+
+### CTS+ Service User
+
+Required role: CTS+ Transport Manager scoped to the specific CTS+ system
+Not permitted: CTS+ System Administrator role (grants transport route modification rights)
+
+### SAP Cloud TMS
+
+Required role: **Transport Operator** scoped to the specific transport node
+Not permitted: **Transport Administrator** role (grants delete and route configuration rights)
+
+OAuth token scope: minimum required for `/v2/nodes/{nodeId}/transportRequests` GET and `/v2/nodes/{nodeId}/transportRequests/{trId}/deploy` POST only.
+
+Never request broader scopes. Never store OAuth tokens in plaintext in any output.
+
+## Step-by-step access matrix
+
+| Step | Live system access | Access type | Credential scope |
+|------|--------------------|-------------|-----------------|
+| 1–7 | None | Advisory only | Not applicable |
+| 8 | STMS / CTS+ / Cloud TMS | Read-only | S_TRANSPRT ACTVT=03 / Cloud TMS Transport Operator GET |
+| 9 | STMS / Cloud TMS (if dry-run supported) | Read-only or dry-run | S_TRANSPRT ACTVT=03 / Cloud TMS Transport Operator GET |
+| 10–13 | None | Advisory only | Not applicable |
+| 14 | STMS / CTS+ / Cloud TMS | Mutating — import only | S_TRANSPRT ACTVT=42 / Cloud TMS Transport Operator POST (approved TRs only) |
+| 15 | STMS / Cloud TMS | Read-only | S_TRANSPRT ACTVT=03 / Cloud TMS Transport Operator GET |
+| 16–17 | None | Reporting only | Not applicable |
+
+## Audit log format
+
+Every command executed (steps 8, 14, 15) must be logged before execution:
+
+```
+[TRANSPORT_AUDIT_LOG]
+Step: <step number and name>
+Timestamp (UTC): <ISO 8601>
+System: <ABAP SID + client OR Cloud TMS node ID>
+Tool: <STMS | CTS+ API | Cloud TMS API>
+Command/API call: <exact command or API endpoint, credentials omitted>
+TR(s) in scope: <list of transport request numbers>
+Output summary: <one-line summary>
+Errors/Warnings: <none | list>
+Redactions applied: <yes/no>
+Approval gate cleared: <yes (step 13 documented) | not yet reached>
+```
+
+## Pre-execution gate checklist (step 13 → step 14)
+
+Before executing any import command, all of the following must be true:
+
+- [ ] Step 1: Transport type and content category classified
+- [ ] Step 2: Target system SID, client, and tier confirmed
+- [ ] Step 3: Criticality level assigned
+- [ ] Step 4: Requester name and role documented
+- [ ] Step 5: Approver name, role, and identity documented
+- [ ] Step 6: Change management ticket number confirmed
+- [ ] Step 7: Complete TR list with descriptions documented
+- [ ] Step 8: Read-only current state snapshot obtained (live evidence on record)
+- [ ] Step 9: Diff/dry-run completed or documented exception on record
+- [ ] Step 10: Blast radius document confirmed
+- [ ] Step 11: Rollback procedure documented and confirmed feasible
+- [ ] Step 12: SoD confirmed — requester and approver are different individuals
+- [ ] Step 13: Explicit written approval from authorized approver on record
+
+If any item is unchecked, refuse step 14 execution until it is resolved.