@raishin/vanguard-frontier-agentic 2.11.0 → 2.13.1

package/skills/sap/sap-guarded-btp-entitlement-change/references/live-environment-access.md

@@ -0,0 +1,93 @@
+# Live environment access — SAP Guarded BTP Entitlement Change
+
+This reference defines credential setup, role requirements, command restrictions by step, and audit log format for guarded BTP entitlement change sessions.
+
+## Credential requirements
+
+### BTP Entitlements API (Cloud Management Service)
+
+Required service instance and binding:
+- Service: `cis` (Cloud Management Service), plan: `central` (for global account operations)
+- Required scope for read-only access (steps 8–9): `EntitlementsManagement.View`
+- Required scope for write access (step 14): `EntitlementsManagement.Edit`
+- Token endpoint: from service key `uaa.url` + `/oauth/token` with client credentials grant
+
+Not permitted:
+- Global Account Administrator user credentials for API calls — use service key with minimum scope
+- Service plan `local` (subaccount-scoped only) for global account entitlement changes
+
+### BTP Subscription Management API
+
+Required service instance:
+- Service: `saas-registry`, plan: `application` or `service`
+- Required scope for read-only (step 8): `SaaS-Registry.read`
+- Required scope for write (step 14): `SaaS-Registry.write`
+
+### BTP Usage Data Management Service
+
+Required service instance:
+- Service: `uas` (Usage Data Management Service), plan: `reporting-ga-admin` (for global account usage reports)
+- Required scope: `uas.usage.report.read` (read-only; no write scope exists)
+
+### BTP Cockpit (human operator access)
+
+Read-only (steps 1–13):
+- Role collection: `Global Account Viewer` (read entitlement assignments without modification rights)
+
+Write (step 14 only):
+- Role collection: `Entitlements Administrator` scoped to the specific global account
+- Not permitted: `Global Account Administrator` role collection (grants directory management, trust configuration, and subaccount creation rights beyond entitlement scope)
+
+## Step-by-step access matrix
+
+| Step | Live system access | Access type | Credential scope |
+|------|--------------------|-------------|-----------------|
+| 1–7 | None | Advisory only | Not applicable |
+| 8 | BTP Entitlements API / Usage API / cockpit | Read-only | EntitlementsManagement.View + uas.usage.report.read |
+| 9 | BTP Entitlements API / Usage API | Read-only (diff and cost baseline) | EntitlementsManagement.View + uas.usage.report.read |
+| 10–13 | None | Advisory only | Not applicable |
+| 14 | BTP Entitlements API / Subscription API | Mutating — entitlement/quota/subscription only | EntitlementsManagement.Edit + SaaS-Registry.write |
+| 15 | BTP Entitlements API / Usage API / cockpit | Read-only | EntitlementsManagement.View + uas.usage.report.read |
+| 16–17 | None | Reporting only | Not applicable |
+
+## Audit log format
+
+Every command executed (steps 8, 9, 14, 15) must be logged before execution:
+
+```
+[BTP_ENTITLEMENT_AUDIT_LOG]
+Step: <step number and name>
+Timestamp (UTC): <ISO 8601>
+Global account: <global account ID and display name>
+Subaccount: <subaccount GUID and display name>
+Tool: <BTP Entitlements API | BTP Subscription API | Usage Data API | BTP cockpit>
+Command/API call: <exact API endpoint and method, credentials omitted>
+Service(s) in scope: <service name, service plan, quota delta>
+Cost delta: <estimated monthly cost change>
+Output summary: <one-line summary>
+Errors/Warnings: <none | list>
+Redactions applied: <yes/no>
+Dual approval gate cleared: <yes (step 13 documented: platform owner + FinOps) | not yet reached>
+```
+
+## Pre-execution gate checklist (step 13 → step 14)
+
+Before executing any entitlement, quota, or subscription change, all of the following must be true:
+
+- [ ] Step 1: Change type, service name, service plan, and billing model classified
+- [ ] Step 2: Target global account ID, subaccount ID, and environment tier confirmed
+- [ ] Step 3: Criticality level and cost sensitivity assigned
+- [ ] Step 4: Requester name and role documented
+- [ ] Step 5: Platform owner and FinOps approver names, roles, and authorization documented (both different from requester)
+- [ ] Step 6: Change management or FinOps budget ticket number confirmed
+- [ ] Step 7: Entitlement change list with service, plan, quota delta, and subaccount documented
+- [ ] Step 8: Current entitlement assignments and consumption baseline obtained (live evidence on record)
+- [ ] Step 9: Diff with quota delta and cost-impact assessment (monthly cost delta) documented
+- [ ] Step 10: Blast radius document confirmed (dependent applications, disruption risk, cost risk)
+- [ ] Step 11: Rollback procedure (exact quota values and API calls to restore) documented and confirmed feasible
+- [ ] Step 12: SoD confirmed — requester differs from both platform owner and FinOps approver
+- [ ] Step 13: Explicit written approval from platform owner on record, naming services and quota amounts
+- [ ] Step 13: Explicit written approval from FinOps approver on record, naming services and quota amounts
+
+If any item is unchecked, refuse step 14 execution until it is resolved.
+If the change is an entitlement increase and FinOps approval is missing, refuse step 14 execution regardless of other approvals.

package/skills/sap/sap-guarded-btp-entitlement-change/references/official-sources.md

@@ -0,0 +1,75 @@
+# Official sources — SAP Guarded BTP Entitlement Change
+
+Use this reference when grounding SAP BTP entitlement management procedures, quota allocation, service subscriptions, and usage monitoring.
+
+**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 Entitlements and Quotas
+
+- SAP BTP entitlements and quotas — concepts
+  https://help.sap.com/docs/btp/sap-business-technology-platform/entitlements-and-quotas
+  source_owner: SAP SE
+  topic_supported: Entitlement model concepts — service plans, quota, distribution to directories and subaccounts, global account vs. subaccount entitlement scope, commercial models (free / metered / subscription / block)
+  why_needed: Authoritative source for the entitlement model used in steps 1 and 3 (classify and criticality); defines quota, service plan, and billing model concepts required to assess cost impact in step 9
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- SAP BTP — managing entitlements and quotas using the cockpit
+  https://help.sap.com/docs/btp/sap-business-technology-platform/managing-entitlements-and-quotas-using-the-cockpit
+  source_owner: SAP SE
+  topic_supported: Step-by-step cockpit procedures for assigning entitlements to directories and subaccounts, adjusting quota, enabling and disabling service plans, bulk entitlement configuration
+  why_needed: Grounds step 14 execution procedures and step 8 read-only inspection for users operating via the BTP cockpit rather than the Entitlements API
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- SAP BTP global account administration
+  https://help.sap.com/docs/btp/sap-business-technology-platform/global-account-administration
+  source_owner: SAP SE
+  topic_supported: Global account hierarchy, directory structure, subaccount governance, administrator roles and least-privilege guidance for global account operations
+  why_needed: Grounds step 2 (target confirmation) and least-privilege credential rules in live-environment-access.md; defines the difference between Global Account Administrator and Entitlements Administrator scope
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP BTP Entitlements API
+
+- SAP BTP Entitlements API (SAP Cloud Management Service)
+  https://help.sap.com/docs/btp/btp-admin-and-ops-neo/entitlements-api
+  source_owner: SAP SE
+  topic_supported: Entitlements API endpoints — GET assigned entitlements, GET available service plans, PUT assign entitlement quota to subaccount; authentication and service key setup for the Cloud Management Service
+  why_needed: Defines the exact API calls permitted for read-only state inspection (step 8) and entitlement assignment execution (step 14); grounds the command patterns in the workflow reference
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP BTP Service Subscriptions
+
+- SAP BTP — subscribe to multitenant applications using the cockpit
+  https://help.sap.com/docs/btp/sap-business-technology-platform/subscribe-to-multitenant-applications-using-the-cockpit
+  source_owner: SAP SE
+  topic_supported: Service subscription model, subscribing and unsubscribing from multitenant applications, subscription status and dependency management
+  why_needed: Grounds step 1 (classify subscription changes), step 10 (blast radius for subscription removals — dependent applications lose access), and step 14 (subscription enable/remove procedures)
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP BTP Cloud Management Service (APIs)
+
+- SAP BTP account administration using the Cloud Management Service APIs
+  https://help.sap.com/docs/btp/sap-business-technology-platform/account-administration-using-apis-of-the-sap-cloud-management-service
+  source_owner: SAP SE
+  topic_supported: Cloud Management Service API overview — entitlements, provisioning, subscription management; authentication setup; scope requirements for Entitlements Administrator and Subaccount Service Administrator
+  why_needed: Authoritative source for the API authentication and scope setup described in live-environment-access.md; provides the token endpoint and scope details for Entitlements API calls in steps 8 and 14
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP BTP Usage and Billing Monitoring
+
+- SAP Usage Data Management Service — monitoring usage via APIs
+  https://help.sap.com/docs/btp/sap-business-technology-platform/monitoring-usage-information-using-apis-of-the-sap-usage-data-management-service
+  source_owner: SAP SE
+  topic_supported: Usage Data Management Service API — GET metered consumption data, usage reports by subaccount and service, cost exposure tracking
+  why_needed: Grounds step 9 (cost-impact assessment using current consumption baseline) and step 15 (post-change billing verification — confirm metered tracking is active and cost center is correct)
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Grounding rule
+
+SAP Help Portal documentation describes the BTP entitlement model design intent, cockpit procedures, and API specifications. It does not prove which entitlements are currently assigned in the user's global account, what the current metered consumption is, or whether the user's SAP BTP contract includes the service plan being requested. Users must supply live evidence from steps 8, 9, and 15 for concrete entitlement and cost assessment. SAP BTP pricing and commercial terms must be confirmed with the user's SAP contract or Customer Success Manager — never inferred from documentation alone.

package/skills/sap/sap-guarded-btp-entitlement-change/references/safety-checklist.md

@@ -0,0 +1,57 @@
+# Safety checklist — SAP Guarded BTP Entitlement Change
+
+Use before every step and unconditionally before step 14 execution.
+
+## Non-negotiables
+
+- Do not reach step 14 (execute) without documented dual approval from both the platform owner and FinOps approver on record in this session.
+- Do not allow self-approval. The requester (step 4) must be different from both the platform owner and the FinOps approver (step 5). If the requester is the same as either approver, refuse execution.
+- Do not increase entitlements without FinOps approval. Technical necessity does not override this gate.
+- Do not change entitlements for services not on the approved list from step 7.
+- Do not skip or reorder steps. The sequence is mandatory.
+- Do not execute entitlement changes without a documented cost-impact assessment (step 9 diff). Changes with undocumented cost impact are refused.
+- Do not use Global Account Administrator credentials when Entitlements Administrator scope is sufficient for step 14.
+- Do not accept, log, echo, or include BTP service key credential values, OAuth tokens, or cockpit session tokens in any output.
+- Do not attempt self-recovery changes without initiating a new 17-step sequence.
+- Do not remove an entitlement or subscription without confirming and documenting all active consumers in step 10. Removal without consumer identification is refused.
+
+## What people get wrong
+
+- **Treating one approver as sufficient**: Step 13 requires explicit written approval from both the platform owner and the FinOps approver. One approver clearing the gate for both is not permitted.
+- **Skipping the cost-impact assessment because the quota increase seems small**: Step 9 is mandatory regardless of the quota delta. Metered services can accumulate significant cost at scale. The assessment must be documented even if the delta is expected to be negligible.
+- **Assuming non-production global account changes are low risk**: Non-production global accounts share contract entitlement pools with production in many BTP contracts. An entitlement moved to a non-production subaccount may reduce available quota for production applications.
+- **Not identifying active consumers before removing an entitlement**: Applications that depend on a removed entitlement will fail immediately. Step 10 must name every application and service consuming the entitlement being removed.
+- **Using Global Account Administrator credentials for routine entitlement management**: The Entitlements Administrator role collection is sufficient for step 14. Global Account Administrator grants additional rights (trust configuration, directory management) that are not needed and violate least-privilege.
+- **Treating "we'll monitor costs" as a FinOps approval substitute**: A monitoring commitment is not an approval. FinOps must provide explicit written approval naming the service plan and quota amount before step 14.
+- **Batching multiple subaccount changes without per-subaccount cost-impact assessment**: Each subaccount change may have different consumer dependencies and cost exposure. Batching without per-subaccount assessment is refused.
+
+## When to push back
+
+- Push back when the user asks to "just enable the service" without completing prior steps.
+- Push back when the requester is the same as either the platform owner or FinOps approver.
+- Push back when FinOps approval is absent for any entitlement increase.
+- Push back when no cost-impact assessment has been produced (step 9).
+- Push back when no change management or FinOps budget ticket is provided.
+- Push back when the change targets removal of an entitlement without a documented list of active consumers.
+- Push back when the rollback plan is "we'll reassign the entitlement if something goes wrong" without specifying the exact quota values to restore.
+- Push back when step 15 reveals application disruption or unexpected billing events and the user wants to close the session without assessment.
+- Push back when the user provides Global Account Administrator credentials for a task that Entitlements Administrator can perform.
+
+## Evidence labels
+
+- `live evidence` — directly observed from a live BTP global account; include API endpoint, response summary, timestamp, global account ID
+- `documentation-based` — grounded in SAP official docs or SAP BTP pricing documentation; 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 (platform)? | Can approve (FinOps)? |
+|------|-------------|------------------------|----------------------|
+| Developer / architect | Yes | No | No |
+| Subaccount administrator | Yes | No | No |
+| Platform owner (accountable for global account architecture) | No | Yes | No |
+| FinOps manager / cost controller | No | No | Yes |
+| IT manager | No | Yes (for non-production only; platform owner required for production) | No |
+| Requester = platform owner or FinOps | No — SoD violation | Refuse execution | Refuse execution |
+| Single approver for both platform and FinOps roles | No — dual approval required | Refuse execution | Refuse execution |

package/skills/sap/sap-guarded-btp-entitlement-change/references/workflow-and-output.md

@@ -0,0 +1,132 @@
+# Workflow and output contract — SAP Guarded BTP Entitlement Change
+
+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., cost-impact assessment, dual approval, SoD check) 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 Entitlements API (read — current assignments)
+```
+GET https://entitlements-service.cfapps.{region}.hana.ondemand.com/entitlements/v1/globalAccountAllowances
+  (returns all service plans assigned to the global account)
+
+GET https://entitlements-service.cfapps.{region}.hana.ondemand.com/entitlements/v1/subAccountServicePlans
+  ?subAccountGUID={subaccountGuid}
+  (returns entitlements currently assigned to the specific subaccount)
+```
+
+#### BTP Usage Data Management API (read — current consumption baseline)
+```
+GET https://uas.cfapps.{region}.hana.ondemand.com/reports/v1/monthlyUsage
+  ?fromDate={YYYY-MM}&toDate={YYYY-MM}&globalAccountId={globalAccountId}
+  (returns metered consumption per service and subaccount for cost baseline)
+```
+
+#### BTP cockpit (read)
+```
+BTP Cockpit → Global Account → Entitlements → Entity Assignments
+  → select subaccount → view current service plan assignments and quota
+BTP Cockpit → Global Account → Entitlements → Service Assignments
+  → view all subaccount assignments for a specific service
+```
+
+### Step 9 — Diff and cost-impact assessment
+
+Document for each changed entitlement:
+
+```
+Service: <service name>
+Plan: <service plan name>
+Billing model: <free | metered | subscription | block>
+Current quota: <current value or "not assigned">
+Proposed quota: <proposed value or "remove">
+Quota delta: <+N / -N / new / remove>
+Estimated cost delta: <EUR/USD per month based on SAP BTP pricing for this plan>
+  Source: <user-provided pricing confirmation | SAP contract reference | inference (label accordingly)>
+Active consumers: <list of applications or services consuming this entitlement>
+Risk if removed: <disruption to consumers identified above>
+```
+
+### Step 14 — Execute approved change
+
+#### BTP Entitlements API (mutating — step 14 only, after step 13 dual approval gate is cleared)
+```
+PUT https://entitlements-service.cfapps.{region}.hana.ondemand.com/entitlements/v1/subAccountServicePlans
+Body:
+{
+  "entitlementsToAdd": {
+    "{subaccountGuid}": [
+      { "serviceName": "<service>", "servicePlanName": "<plan>", "quota": <N>, "enable": true }
+    ]
+  },
+  "entitlementsToDelete": {
+    "{subaccountGuid}": [
+      { "serviceName": "<service>", "servicePlanName": "<plan>" }
+    ]
+  }
+}
+```
+
+#### BTP Subscription Management API (mutating — step 14 only)
+```
+POST https://{subaccountSubdomain}.{region}.hana.ondemand.com/saas-manager/v1/applications/{appName}/subscription
+  (subscribe to a multitenant application — approved services only)
+
+DELETE https://{subaccountSubdomain}.{region}.hana.ondemand.com/saas-manager/v1/applications/{appName}/subscription
+  (unsubscribe — only when change type from step 1 is subscription removal and explicitly approved)
+```
+
+**Never call PUT entitlement or POST/DELETE subscription before step 13 dual approval gate is documented.**
+
+## Step completion checklist
+
+| Step | Evidence type | Completion marker |
+|------|--------------|------------------|
+| 1 | user-provided / documentation-based | Change type, service name, service plan, and billing model confirmed |
+| 2 | user-provided evidence | Target global account ID, subaccount ID, and environment tier confirmed |
+| 3 | user-provided evidence | Criticality level and cost sensitivity assigned |
+| 4 | user-provided evidence | Requester name and role on record |
+| 5 | user-provided evidence | Platform owner and FinOps approver names, roles, and authorization on record |
+| 6 | user-provided evidence | Ticket number confirmed |
+| 7 | user-provided evidence | Entitlement change list with service, plan, quota delta, and subaccount on record |
+| 8 | live evidence | Current entitlement assignments and consumption baseline from global account |
+| 9 | live evidence + user-provided / inference | Diff with quota delta and cost-impact assessment (monthly cost delta documented) |
+| 10 | user-provided / inference | Blast radius document confirmed (dependent applications, disruption risk, cost risk) |
+| 11 | user-provided evidence | Rollback procedure (entitlement reversion steps) confirmed feasible |
+| 12 | user-provided evidence | SoD confirmed: requester ≠ platform owner ≠ FinOps approver |
+| 13 | user-provided evidence | Explicit dual approval (platform owner + FinOps) on record, naming services and quota amounts |
+| 14 | live evidence | Execution log with timestamp |
+| 15 | live evidence | Post-change entitlement snapshot confirmed; dependent applications healthy; metered tracking active |
+| 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. Cost-impact status if step 9 or step 13 (documented / missing / pending FinOps review)
+
+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 entitlement and application health verification result
+4. Cost-impact assessment summary (baseline → projected monthly delta)
+5. Rollback status (not needed / standing by / triggered)
+6. Report delivery confirmation

package/skills/sap/sap-guarded-integration-flow-change/SKILL.md

@@ -0,0 +1,151 @@
+---
+name: sap-guarded-integration-flow-change
+description: Deploy or modify SAP Cloud Integration iFlows and integration artifacts using a mandatory 17-step guarded mutation sequence covering classification, target tenant confirmation, criticality, requester, approver (integration-owner required), ticket, scope, read-only current state, diff of artifact changes, blast radius (downstream partners and throughput), rollback (previous version redeploy), post-change verification via message monitoring, and audit evidence. Refuses if any step is missing, if integration-owner approval is absent, or if a diff has not been produced. Use when a confirmed and approved iFlow deployment or integration artifact change in a non-development Cloud Integration tenant 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 Integration Flow Change
+
+## Purpose
+
+Deploy or modify SAP Cloud Integration iFlows and integration artifacts in non-development tenants under a strict 17-step guarded mutation sequence. Every step must be completed, documented, and confirmed before the deployment execution step is reached. If any step is absent, the deployment is refused until it is completed. This skill treats every iFlow deployment or integration artifact change in a quality, pre-production, or production Cloud Integration tenant as a risk-critical mutating operation requiring explicit integration-owner approval, a documented blast radius covering downstream partners and throughput impact, and a verified rollback path via previous version redeploy.
+
+## When to use
+
+Use this skill when:
+
+- an iFlow, value mapping, script collection, API provider, or other Cloud Integration artifact must be deployed or modified in a quality, pre-production, or production tenant,
+- an integration owner or delivery lead has confirmed the change is approved and requires traceable execution,
+- post-deployment verification via message monitoring and audit evidence are required for change management or compliance purposes,
+- the user needs a structured, risk-controlled execution protocol for SAP Integration Suite Cloud Integration deployments.
+
+## When not to use
+
+- When the target is a development or sandbox tenant (DEV) with no live partner connections — development deployments are lower risk and do not require this full sequence.
+- When the user wants to *design* or *test* an iFlow in the design workspace without deploying — 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 the integration owner has been obtained — refuse execution.
+- When a diff of the artifact changes has not been produced — refuse execution; deployment on an undiffed artifact is forbidden.
+
+## 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 documented integration-owner approval on record in this session.
+- Segregation of duties enforced. The person who requests the deployment (step 4) 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 deployment is proposed. Do not propose a deployment on undocumented current artifact state.
+- Diff before live execution. Step 9 (diff of artifact changes) must precede execution. Document which iFlow components, script steps, routing conditions, adapter configurations, and value mappings are changing.
+- Blast radius documented before execution. Step 10 must list all downstream partner systems, message throughput impacts, dependent iFlows, API consumers, and business processes affected. Deployments with undocumented blast radius are refused.
+- One artifact change at a time. Do not batch-deploy multiple iFlows in a single execution step unless each has completed its own full 17-step sequence.
+- Never hardcode credentials. All system access uses pre-configured service keys, OAuth clients, or process integration runtime users — never credentials in plain text.
+- Evidence labeling mandatory. Every step must produce labeled evidence before the next step proceeds.
+- Integration-owner approval is not optional. The integration owner (the team responsible for the iFlow and its downstream partners) must be the named approver in step 5. General delivery-lead approval is insufficient for production deployments.
+
+## The 17-step guarded mutation sequence
+
+| Step | Name | Description | Evidence required |
+|------|------|-------------|-------------------|
+| 1 | Classify | Classify the artifact type (iFlow, value mapping, script collection, API provider, integration package) and change type (new deployment, update, rollback, undeploy) | Artifact type and change type documented |
+| 2 | Confirm target | Confirm the exact target tenant (Cloud Integration tenant ID, environment tier: QA/PPD/PRD, Integration Suite sub-domain) | Target tenant ID, tier, and sub-domain confirmed by user |
+| 3 | Criticality assessment | Assess business criticality of the affected integration (financial document exchange, order-to-cash, HR data, payment processing, regulatory reporting) | 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 | Integration-owner approval identification | Identify the integration owner — the team or individual accountable for the iFlow and its downstream partner connections (different person from requester — SoD requirement) | Integration-owner name, role, and accountability scope |
+| 6 | Ticket linkage | Link the deployment to a change management ticket (ITSM reference: ServiceNow, Remedy, SAP Solution Manager ChaRM, etc.) | Ticket number confirmed |
+| 7 | Scope documentation | Document the complete list of artifacts to be deployed or modified: iFlow IDs, package names, version numbers, and interdependencies with other iFlows or API providers | Artifact list with IDs, versions, and dependency map |
+| 8 | Read-only current state | Read the current state of the target tenant: deployed artifact versions, runtime status, active message queues, recent error rates from monitoring | Live evidence from target tenant (read-only) |
+| 9 | Diff of artifact changes | Produce a diff of the artifact changes: which iFlow steps, routing conditions, adapter configurations, scripts, and value mappings are changing relative to the currently deployed version | Diff output documenting changed components |
+| 10 | Blast radius | Document all downstream partner systems, dependent iFlows, API consumers, message throughput estimates, and business processes affected; assess risk of message loss or duplication during deployment | Blast radius document with affected partners, consumers, and throughput impact |
+| 11 | Rollback plan | Document the explicit rollback procedure: which artifact version to redeploy, how to trigger a previous-version redeploy from the Cloud Integration design workspace or API, and any partner notification steps required | Rollback procedure documented and confirmed feasible |
+| 12 | SoD verification | Verify that requester (step 4) and integration owner (step 5) are different authorized individuals; confirm no self-approval | SoD confirmed: requester ≠ integration owner / approver |
+| 13 | Approval gate | Obtain explicit written approval from the integration owner for this specific deployment | Approval statement on record in this session |
+| 14 | Execute approved deployment | Deploy or modify the approved artifacts only, in the documented sequence | Deployment command log with timestamp |
+| 15 | Verify via message monitoring | Verify post-deployment state: check runtime status of deployed iFlows, inspect message monitoring for errors, confirm throughput resumes within expected parameters, verify downstream partner acknowledgements where applicable | Post-deployment message monitoring log and verification results |
+| 16 | Audit | Produce complete audit record: all 17 steps, evidence, commands, timestamps, integration-owner approval | Audit record |
+| 17 | Report | Deliver final report to requester, integration owner, and change manager | Report delivered and acknowledged |
+
+## Evidence rules
+
+Label all data with one of:
+
+- `live evidence` — directly observed from a live Cloud Integration tenant 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):
+- Cloud Integration OData API: GET deployed artifact versions and runtime status (read-only)
+- Cloud Integration monitoring: GET message processing log summary, active queues, error rates
+- API Management: GET API provider configuration (read-only)
+
+**Allowed** (step 9 only — diff):
+- Cloud Integration Design API: GET iFlow content for diff comparison against target tenant state (read-only)
+
+**Allowed** (step 14 only — after all prior steps confirmed):
+- Cloud Integration OData API: POST deploy for approved artifacts
+- Cloud Integration Design API: deploy approved package version to target tenant
+- Cloud Integration API: undeploy command (only when change type from step 1 is undeploy and explicitly approved)
+
+**Forbidden** (all other contexts):
+- Any deploy or undeploy command before step 13 approval gate is cleared
+- Any deployment of artifacts not on the approved list from step 7
+- Any modification to tenant-level runtime configuration (JDBC data sources, keystore entries, security material) unless explicitly in scope and approved
+- Any deletion of integration packages or artifacts outside the approved change type
+- Any access with Integration Suite tenant administrator credentials not scoped to the specific package or iFlow
+
+**Least-privilege credential rules**:
+- Cloud Integration OData API: use a service key with `MonitoringDataRead` and `WorkspacePackagesRead` for step 8; use `WorkspacePackagesConfigure` and `NodeManager.deployer` for step 14 — scoped to the specific tenant
+- Integration Suite: use a user with the Integration Developer role for deployment; not the Integration Suite Tenant Administrator role
+- API Management: use a user with the APIPortal.Administrator role scoped to the specific API product — not the full Platform scope
+
+**Approval gate (step 13)**:
+Before step 14 execution, confirm:
+1. All steps 1–12 are documented and evidence is on record.
+2. The integration owner from step 5 has provided explicit written approval in this session.
+3. The integration owner is a different person from the requester.
+4. The approval explicitly names the artifacts and version numbers to be deployed.
+5. A diff from step 9 is on record.
+
+**Rollback**:
+- The rollback plan from step 11 must be documented before step 14 begins.
+- If post-deployment verification (step 15) reveals errors or message processing failures, stop immediately and execute the rollback plan (redeploy previous version) before escalating to the integration owner.
+- Do not attempt self-recovery deployments without a new 17-step sequence.
+
+**Post-deployment (step 15)**:
+- Check the runtime status of all deployed iFlows (started / error / stopping).
+- Inspect the message processing log for ERROR and RETRY status messages.
+- Confirm throughput resumes within the expected processing rate.
+- Where downstream partner acknowledgement is part of the integration pattern, confirm receipt.
+- Document the verification result as `live evidence`.
+
+**Audit (step 16)**:
+- Produce a complete record of all 17 steps, evidence gathered, commands executed, timestamps, integration-owner approval statement, and message monitoring verification results.
+- Retain audit record for the session and deliver to the integration owner 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 Cloud Integration, Integration Suite, OData API, message monitoring docs.
+- [Live environment access](references/live-environment-access.md) — credential setup, role requirements, audit log format.
+
+## Response minimum
+
+Return, at minimum:
+
+- **Problem classification**: artifact type, change type, target tenant, and environment tier.
+- **Evidence used**: live evidence (with command log) / documentation-based / user-provided / inference.
+- **Risk level**: always risk-critical for non-development tenants; critical for financial document or payment processing iFlows.
+- **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 integration-owner approval is absent; refuse if diff has not been produced; refuse if any step is missing; refuse if rollback plan is absent.
+- **Business impact**: what message flows change if the deployment succeeds; what downstream partners are affected if the deployment fails.
+- **Next verification step**: which step number is next and what evidence is required.

package/skills/sap/sap-guarded-integration-flow-change/agents/openai.yaml

@@ -0,0 +1,17 @@
+interface:
+  display_name: "SAP Guarded Integration Flow Change"
+  short_description: "Deploy or modify SAP Cloud Integration iFlows and artifacts under a mandatory 17-step guarded mutation sequence — refuses if any step is missing, integration-owner approval absent, diff not produced, or approval gate not cleared"
+  default_prompt: "Use $sap-guarded-integration-flow-change to deploy or modify a SAP Cloud Integration iFlow or artifact. Begin at step 1 (classify) and advance through all 17 steps in order. Do not reach step 14 (execute) without documented integration-owner approval from a person different from the requester, and a diff of artifact changes from step 9. Refuse if any step is skipped, if SoD is violated, if a rollback plan is absent, or if post-deployment message monitoring shows errors without a documented remediation decision."
+dependencies:
+  tools:
+    - type: "api"
+      value: "sap-cloud-integration-odata-api"
+      description: "SAP Cloud Integration OData API — GET deployed artifact versions and runtime status (step 8, step 15); POST deploy for approved artifacts (step 14) using NodeManager.deployer scope only"
+    - type: "api"
+      value: "sap-cloud-integration-design-api"
+      description: "SAP Cloud Integration Design API — GET iFlow content for diff comparison (step 9); deploy approved package version to target tenant (step 14)"
+    - type: "api"
+      value: "sap-cloud-integration-monitoring-api"
+      description: "SAP Cloud Integration Monitoring API — GET message processing log summary, active queue status, and error rates for read-only state (step 8) and post-deployment verification (step 15)"
+policy:
+  allow_implicit_invocation: false

package/skills/sap/sap-guarded-integration-flow-change/metadata.json

@@ -0,0 +1,33 @@
+{
+  "id": "sap-guarded-integration-flow-change",
+  "name": "SAP Guarded Integration Flow Change",
+  "type": "skill",
+  "provider": "sap",
+  "harnesses": [
+    "claude-code",
+    "codex",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Deploy or modify SAP Cloud Integration iFlows and integration artifacts in quality, pre-production, or production tenants using a mandatory 17-step guarded mutation sequence: classify, confirm target tenant, criticality, requester, integration-owner approval, ticket, scope, read-only current state, diff of artifact changes, blast radius (downstream partners and throughput), rollback (previous version redeploy), SoD verification, approval gate, execute approved deployments only, verify via message monitoring, audit, report. Refuses if any step is missing, if integration-owner approval is absent, or if a diff has not been produced.",
+  "source_type": "original",
+  "category": "delivery",
+  "official_docs": [
+    "https://help.sap.com/docs/cloud-integration/sap-cloud-integration/deploy-integration-artifacts",
+    "https://help.sap.com/docs/cloud-integration/sap-cloud-integration/odata-api",
+    "https://help.sap.com/docs/cloud-integration/sap-cloud-integration/message-processing-log",
+    "https://help.sap.com/docs/cloud-integration/sap-cloud-integration/monitor-message-processing",
+    "https://help.sap.com/docs/cloud-integration/sap-cloud-integration/manage-integration-content",
+    "https://help.sap.com/docs/integration-suite/sap-integration-suite/activating-and-managing-capabilities",
+    "https://help.sap.com/docs/cloud-integration/sap-cloud-integration/versioning-of-artifacts"
+  ],
+  "security_notes": "Mutating operations are gated behind the 17-step sequence. Never deploy or undeploy an artifact before step 13 approval gate is cleared. Never accept self-approval (SoD: requester must differ from the integration owner / approver). Integration-owner approval is mandatory — general delivery-lead approval is insufficient for production deployments. A diff of artifact changes (step 9) must be produced before any deployment is executed. Never use Integration Suite tenant administrator credentials — use Integration Developer role scoped to the specific tenant. Never hardcode service keys, OAuth client secrets, or process integration runtime user passwords in any output. Refuse any request to skip steps or deploy without a documented rollback plan.",
+  "last_verified": "2026-06-19",
+  "path": "skills/sap/sap-guarded-integration-flow-change",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "lifecycle": "experimental",
+  "execution_tier": "mutating-runtime"
+}