@raishin/vanguard-frontier-agentic 2.10.0 → 2.13.0

package/skills/sap/sap-integration-platform-businessops-protocol/SKILL.md

@@ -0,0 +1,162 @@
+---
+name: sap-integration-platform-businessops-protocol
+description: Cross-functional coordination protocol governing handoff contracts between SAP Integration, Platform Engineering, and Business Operations. Activates on failed integration flows, API throttling, event delivery failures, broken partner integrations, data replication failures, middleware instability, and business-process outage. Advisory and audit only — no live mutation.
+allowed-tools: Read Grep Glob WebSearch WebFetch
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-19"
+  category: operational
+  lifecycle: experimental
+---
+
+# SAP Integration / Platform / Business Operations Protocol
+
+## Purpose
+
+This skill is a cross-functional coordination and handoff contract between four complementary advisory roles: SAP Integration Suite flow review, Cloud ALM SRE incident analysis, integration flow governance oversight, and BTP account entitlement governance review. It defines when each role activates, what evidence each role requires before it can produce output, how findings are handed off between roles, who holds decision rights over integration and platform remediation actions, and what approval is required before any irreversible change is recommended to a downstream guarded-mutating operator.
+
+This protocol never mutates. It never invokes or bypasses any guarded-mutating operator gate. It produces advisory packages, incident handoff summaries, and escalation triggers only.
+
+## When to use
+
+Activate this protocol when one or more of the following conditions apply:
+
+- An integration flow has failed, is in an error state, or is producing incorrect output — including iFlow failures in SAP Integration Suite, failed message mappings, or broken adapter configurations.
+- API throttling or rate-limit responses are being returned by SAP Integration Suite, SAP API Business Hub, or a connected system — impacting business processes that depend on real-time data exchange.
+- Event delivery has failed — including SAP Event Mesh messages that are stuck, undelivered, or accumulating in dead-letter queues.
+- A partner or third-party integration has broken — EDI, B2B, or external API integration with a supplier, logistics provider, or financial institution has stopped exchanging data correctly.
+- Data replication has failed — CDS view replication, SAP Landscape Transformation (SLT), or SOAP/REST-based data synchronization between SAP and non-SAP systems is producing stale, incomplete, or corrupt data.
+- Middleware instability is observed — the SAP Integration Suite tenant, a deployed Node instance, or an on-premise Integration Agent is behaving erratically, restarting unexpectedly, or failing health checks.
+- A business-process outage has been declared — a critical business process (order-to-cash, procure-to-pay, hire-to-retire, or equivalent) is interrupted and the root cause is suspected to be in the integration or platform layer.
+
+## Participating agents
+
+The following agents are parties to this protocol. Each operates in its own advisory domain. No agent in this list holds authority to execute irreversible changes unilaterally.
+
+- `sap-integration-suite-reviewer-agent` — reviews SAP Integration Suite iFlow design, adapter configuration, message mapping logic, error handling, retry policies, and monitoring artifacts. Primary entry point for integration flow failure triage.
+- `sap-cloud-alm-sre-incident-agent` — analyzes SAP Cloud ALM health monitoring data, incident records, service desk tickets, and SRE runbook compliance for platform and integration incidents. Produces incident severity classification and escalation recommendations.
+- `sap-integration-flow-guarded-operator-agent` — holds the guarded mutation gate for any integration flow deployment, redeployment, undeploy, or configuration change. No integration flow change proceeds without a signed handoff package from this protocol and explicit human approval. This agent does not activate from this protocol directly; the protocol produces the package that a human submits to the operator gate.
+- `sap-btp-account-entitlement-governance-reviewer-agent` — reviews BTP account and entitlement governance context when platform-layer issues (missing service entitlements, quota exhaustion, environment provisioning gaps) are a contributing factor to integration or business-process outage.
+
+## Required evidence
+
+Before this protocol can produce a handoff package, the activating party must supply:
+
+1. **Incident or error description** — a written description of the failure, including error messages, error codes, impacted integration flows or APIs, and the business process affected.
+2. **Integration flow identifier** — the iFlow ID or name, tenant URL (sanitized — no credentials), and the SAP Integration Suite runtime node or cluster on which the failure occurred.
+3. **Timeline** — when the failure first occurred, whether it is ongoing, and what changed immediately before the failure (deployment, configuration update, dependency change, or nothing identified).
+4. **Monitoring artifacts** — message processing log excerpts, Cloud ALM alert details, or equivalent monitoring data (redacted of PII and credentials).
+5. **Business impact statement** — which business process is affected, how many transactions or users are impacted, and whether a business-process outage has been declared.
+
+Optional but recommended:
+
+- SAP Cloud ALM health monitoring dashboard export or screenshot.
+- Adapter trace log or message processing log for the failing message.
+- Partner integration acknowledgment or error response (redacted of credentials).
+- Current entitlement inventory if platform-layer quota exhaustion is suspected.
+
+## Redaction policy
+
+All evidence submitted to this protocol must be redacted before processing:
+
+- Remove all OAuth tokens, Basic Authentication credentials, client secrets, API keys, and certificate private keys from adapter configurations and trace logs.
+- Remove all personally identifiable information (PII) from message payloads — customer names, personal identification numbers, payment card data, health data.
+- Remove all internal hostnames, IP addresses, and tenant-specific URLs beyond the minimum needed to identify the integration landscape topology.
+- Remove all SAP system IDs (SIDs), client numbers, and basis user credentials.
+- Label redacted fields with `[REDACTED]`.
+
+This protocol does not store, persist, or transmit evidence artifacts. Evidence is used only within the advisory session in which it is provided.
+
+## Decision rights
+
+| Decision | Owner | Protocol role |
+|----------|-------|---------------|
+| Approve integration flow redeployment | Integration Platform Lead + Business Process Owner | Protocol produces recommendation; human approves |
+| Approve iFlow undeploy (stopping an active flow) | Integration Platform Lead | Protocol produces risk assessment; human approves |
+| Approve adapter configuration change | Integration Platform Lead + Security review if authentication scope changes | Protocol produces recommendation; human approves |
+| Escalate to SAP support (incident ticket) | SAP Cloud ALM SRE lead | Protocol produces escalation brief; human opens ticket |
+| Declare business-process outage resolved | Business Process Owner | Protocol confirms integration health signals; human declares resolution |
+| Approve BTP entitlement change to restore service | Global Account Administrator + FinOps lead | Protocol produces recommendation; human approves via separate FinOps protocol if needed |
+| Approve partner integration reconfiguration | Integration Platform Lead + Partner contact | Protocol produces change summary; human coordinates with partner |
+
+## Escalation owners
+
+- **Integration Platform Lead** — primary escalation point for iFlow failures, adapter configuration issues, and middleware instability.
+- **SAP Cloud ALM SRE Lead** — escalation point for platform-level health degradation, incident management, and SRE runbook activation.
+- **Business Process Owner** — escalation point for business-process outage declaration and resolution confirmation.
+- **SAP Support** — escalation point for platform defects, known issues in SAP Integration Suite, and hyperscaler infrastructure events affecting the tenant.
+- **Partner Integration Contact** — escalation point for B2B/EDI failures or third-party API integration breaks that require out-of-band coordination with the external party.
+- **BTP Global Account Administrator** — escalation point when entitlement or environment provisioning is a contributing factor.
+
+## Irreversible-action gate
+
+The following actions are classified as irreversible or high-consequence and require explicit human approval before any recommendation is executed:
+
+- Undeploying a running integration flow that is processing live business transactions (stops all in-flight message processing immediately).
+- Changing the technical sender or receiver adapter credentials that affect all messages in the active channel.
+- Restarting the SAP Integration Suite runtime node or worker (drops all in-memory message state).
+- Disabling an Event Mesh topic subscription (causes immediate message loss for events published after the disable).
+- Removing an iFlow from the integration package (not recoverable without redeployment from a versioned artifact).
+- Revoking API credentials or OAuth client registrations used by partner integrations (immediately breaks all partner channels using those credentials).
+
+This protocol does not invoke `sap-integration-flow-guarded-operator-agent` or any other operator gate. It produces a signed handoff package. A human must present that package to the operator gate and confirm approval before any mutation proceeds.
+
+## Approval requirements
+
+| Action type | Minimum approvers | Approval form |
+|-------------|------------------|---------------|
+| Integration flow redeployment | Integration Platform Lead | Written approval in change record with artifact version reference |
+| iFlow undeploy | Integration Platform Lead + Business Process Owner | Written approval with business impact acknowledgment |
+| Adapter credential rotation | Integration Platform Lead + Security lead | Written approval with credential rotation procedure attached |
+| Event Mesh subscription change | Integration Platform Lead | Written approval with message-loss risk acknowledgment |
+| BTP entitlement change (platform layer) | Global Account Admin + FinOps lead | Separate FinOps protocol handoff required |
+| SAP support escalation (severity 1) | SAP Cloud ALM SRE Lead | Verbal or written authorization with incident reference |
+
+## Audit package
+
+At session close, this protocol produces an audit package containing:
+
+1. **Incident or failure summary** — trigger classification, impacted flows and business processes, and timeline.
+2. **Evidence inventory** — list of evidence artifacts received (types only; no raw content), with redaction confirmation.
+3. **Per-role findings** — advisory output from each activated agent role, labelled by evidence level and severity.
+4. **Root cause hypothesis** — most likely root cause with evidence basis and confidence level (confirmed / probable / possible / unknown).
+5. **Decision rights mapping** — pending decisions and named approvers for each recommended action.
+6. **Irreversible-action gate status** — whether any irreversible action has been recommended, and whether human approval has been confirmed.
+7. **Escalation log** — which escalation owners were notified and what action was requested.
+8. **Handoff status** — whether the package is ready to submit to a guarded-mutating operator gate.
+9. **Business process resolution status** — confirmed resolved / monitoring / unresolved (with blocking items).
+
+## Refusal conditions
+
+This protocol refuses to proceed when:
+
+- No incident description, error message, or monitoring artifact has been provided — advisory output without evidence is not reliable.
+- A request is made to directly invoke `sap-integration-flow-guarded-operator-agent` from within this protocol — that gate is human-mediated only.
+- Raw credentials, OAuth tokens, API keys, or certificate private keys are present in submitted artifacts without redaction — request redaction before proceeding.
+- A request is made to recommend an irreversible action without identifying the human approver — the approver must be named before the package is finalized.
+- The trigger event is outside the scope defined in "When to use" — redirect to the appropriate protocol or skill.
+- A request is made to access live SAP Integration Suite APIs, execute adapter operations, or inspect live message processing logs directly — this protocol accepts only user-provided artifacts.
+
+## Evidence rules
+
+Label all claims with one of:
+
+- `documentation-based` — grounded in SAP Integration Suite documentation, SAP Cloud ALM documentation, SAP Event Mesh documentation, or official SAP Help Portal references.
+- `user-provided evidence` — message processing log excerpts, Cloud ALM alert exports, adapter configuration descriptions, or monitoring screenshots supplied by the user.
+- `inference` — derived reasoning not directly confirmed by official documentation or user evidence; always label as inference and note the assumption.
+
+## Response minimum
+
+Every protocol session must return, at minimum:
+
+- **Trigger classification** — which "When to use" condition(s) activated the protocol.
+- **Participating roles activated** — which of the four agents' advisory domains are relevant to this session.
+- **Evidence received** — inventory of what was supplied, with confirmation of redaction compliance.
+- **Root cause hypothesis** — most likely root cause with confidence level and evidence basis.
+- **Findings per domain** — advisory output for each activated role, with evidence labels and severity.
+- **Decision rights table** — who must approve each pending remediation action.
+- **Irreversible-action gate status** — whether irreversible actions are in scope and whether human approval has been confirmed.
+- **Business process impact** — current status of the affected business process (outage active / degraded / recovering / resolved).
+- **Audit package readiness** — whether the session is complete enough to produce a handoff package for the operator gate.
+- **Next step** — the specific human action required to proceed (e.g., "Obtain Integration Platform Lead approval for iFlow redeployment and submit handoff package to the integration flow operator gate").

package/skills/sap/sap-integration-platform-businessops-protocol/agents/openai.yaml

@@ -0,0 +1,11 @@
+interface:
+  display_name: "SAP Integration / Platform / Business Operations Protocol"
+  short_description: "Cross-functional coordination protocol for failed integration flows, API throttling, event delivery failures, broken partner integrations, data replication failures, middleware instability, and business-process outage. Advisory only — no live mutation."
+  default_prompt: "Use $sap-integration-platform-businessops-protocol to coordinate a cross-functional incident advisory session. Classify the trigger condition, identify which participating agent roles are relevant, inventory the evidence provided (confirming redaction), produce per-domain findings with evidence labels and root cause hypothesis, map decision rights to named approvers, confirm irreversible-action gate status, and return an audit package ready for human review before any operator gate submission."
+dependencies:
+  tools:
+    - type: "web"
+      value: "https://help.sap.com/docs/integration-suite/sap-integration-suite/what-is-sap-integration-suite"
+      description: "SAP Integration Suite product documentation — primary reference for integration flow design, adapter capabilities, and runtime behavior"
+policy:
+  allow_implicit_invocation: true

package/skills/sap/sap-integration-platform-businessops-protocol/metadata.json

@@ -0,0 +1,35 @@
+{
+  "id": "sap-integration-platform-businessops-protocol",
+  "name": "SAP Integration / Platform / Business Operations Protocol",
+  "type": "skill",
+  "provider": "sap",
+  "harnesses": [
+    "claude-code",
+    "codex",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Cross-functional coordination protocol for SAP Integration, Platform Engineering, and Business Operations. Governs handoff contracts for failed integration flows, API throttling, event delivery failures, broken partner integrations, data replication failures, middleware instability, and business-process outage. Advisory and audit only — no live mutation, no operator gate bypass.",
+  "source_type": "original",
+  "category": "operational",
+  "official_docs": [
+    "https://help.sap.com/docs/integration-suite/sap-integration-suite/what-is-sap-integration-suite",
+    "https://help.sap.com/docs/integration-suite/sap-integration-suite/integration-flow-design-guidelines",
+    "https://help.sap.com/docs/integration-suite/sap-integration-suite/message-processing-log",
+    "https://help.sap.com/docs/integration-suite/sap-integration-suite/error-handling-in-integration-flows",
+    "https://help.sap.com/docs/integration-suite/sap-integration-suite/adapter-concepts",
+    "https://help.sap.com/docs/cloud-alm/applicationhelp/operations",
+    "https://help.sap.com/docs/cloud-alm/applicationhelp/integration-monitoring",
+    "https://help.sap.com/docs/sap-event-mesh/sap-event-mesh/what-is-sap-event-mesh",
+    "https://help.sap.com/docs/sap-event-mesh/sap-event-mesh/dead-letter-queue",
+    "https://help.sap.com/docs/btp/sap-business-technology-platform/entitlements-and-quotas"
+  ],
+  "security_notes": "This protocol accepts only user-provided monitoring artifacts and incident descriptions. Never accept or process OAuth tokens, Basic Authentication credentials, client secrets, API keys, certificate private keys, or SAP basis user credentials. All evidence must be redacted of PII, credentials, internal hostnames, and SAP system IDs before processing. This protocol does not invoke any guarded-mutating operator gate. All irreversible integration actions require named human approval before a handoff package is submitted to an operator.",
+  "last_verified": "2026-06-19",
+  "path": "skills/sap/sap-integration-platform-businessops-protocol",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "lifecycle": "experimental"
+}

package/skills/sap/sap-integration-platform-businessops-protocol/references/official-sources.md

@@ -0,0 +1,99 @@
+# Official sources — SAP Integration / Platform / Business Operations Protocol
+
+Use this reference when grounding findings on SAP Integration Suite iFlow design, adapter behavior, error handling, Cloud ALM health monitoring, Event Mesh delivery, and BTP platform entitlements relevant to integration scenarios.
+
+**Evidence level**: documentation-based (SAP Help Portal). No live-system evidence is collected by this protocol.
+
+## SAP Integration Suite — product and iFlow design
+
+- What is SAP Integration Suite
+  https://help.sap.com/docs/integration-suite/sap-integration-suite/what-is-sap-integration-suite
+  source_owner: SAP SE
+  topic_supported: Integration Suite capabilities overview, Cloud Integration, API Management, Event Mesh, Open Connectors, Integration Advisor; product scope and runtime architecture
+  why_needed: Baseline taxonomy for classifying which Integration Suite capability is involved in a failure — required to activate the correct participating role
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- Integration flow design guidelines
+  https://help.sap.com/docs/integration-suite/sap-integration-suite/integration-flow-design-guidelines
+  source_owner: SAP SE
+  topic_supported: iFlow design best practices, message exchange patterns, idempotency, retry configuration, dead-letter handling, logging strategy
+  why_needed: Primary reference for assessing whether iFlow design contributed to a failure; defines the quality bar against which reviewer findings are classified
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- Error handling in integration flows
+  https://help.sap.com/docs/integration-suite/sap-integration-suite/error-handling-in-integration-flows
+  source_owner: SAP SE
+  topic_supported: Exception subprocess configuration, escalation handling, retry policies, dead-letter queue handling, error message enrichment
+  why_needed: Defines the canonical error-handling patterns — required to assess whether a flow failure is a design defect, a configuration gap, or a runtime/infrastructure issue
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- Adapter concepts
+  https://help.sap.com/docs/integration-suite/sap-integration-suite/adapter-concepts
+  source_owner: SAP SE
+  topic_supported: Adapter types (SOAP, REST, OData, SFTP, AS2, JDBC, JMS, etc.), adapter connection properties, credential management, receiver adapter retry behavior
+  why_needed: Reference for adapter-level failure classification — required when a connectivity failure, authentication error, or throttling response needs to be attributed to a specific adapter type
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Message processing and monitoring
+
+- Message processing log
+  https://help.sap.com/docs/integration-suite/sap-integration-suite/message-processing-log
+  source_owner: SAP SE
+  topic_supported: Message processing log structure, log levels, error status codes, attachment handling, retention policies, access via Operations view
+  why_needed: Defines the primary monitoring artifact submitted as evidence — required to interpret error codes, message status transitions, and retry counts in user-provided log excerpts
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP Cloud ALM — operations and integration monitoring
+
+- SAP Cloud ALM operations
+  https://help.sap.com/docs/cloud-alm/applicationhelp/operations
+  source_owner: SAP SE
+  topic_supported: Cloud ALM operations workspace, health monitoring, job monitoring, alert management, integration and exception monitoring across the SAP managed landscape
+  why_needed: Primary reference for the Cloud ALM SRE incident role — defines the health monitoring framework and alert classification model used to triage platform and integration incidents
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- SAP Cloud ALM integration monitoring
+  https://help.sap.com/docs/cloud-alm/applicationhelp/integration-monitoring
+  source_owner: SAP SE
+  topic_supported: Integration and exception monitoring in Cloud ALM, message flow visibility, error drill-down, cross-system end-to-end tracing
+  why_needed: Defines the integration-specific monitoring evidence the Cloud ALM SRE role uses to correlate iFlow failures with business-process impact and SLA breach thresholds
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP Event Mesh — event delivery and dead-letter handling
+
+- What is SAP Event Mesh
+  https://help.sap.com/docs/sap-event-mesh/sap-event-mesh/what-is-sap-event-mesh
+  source_owner: SAP SE
+  topic_supported: SAP Event Mesh product overview, messaging concepts, topic subscriptions, queues, event broker capabilities, client SDK
+  why_needed: Baseline taxonomy for event delivery failure classification — required to distinguish between topic publication failures, subscription delivery failures, and dead-letter queue accumulation
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- Dead-letter queue in SAP Event Mesh
+  https://help.sap.com/docs/sap-event-mesh/sap-event-mesh/dead-letter-queue
+  source_owner: SAP SE
+  topic_supported: Dead-letter queue behavior, message retry exhaustion, DLQ inspection, reprocessing options, message loss risk
+  why_needed: Defines the dead-letter queue mechanics — required to assess whether stuck or failed Event Mesh messages are recoverable and what action is needed to reprocess or discard them
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## BTP entitlements — platform layer context for integration failures
+
+- Entitlements and quotas
+  https://help.sap.com/docs/btp/sap-business-technology-platform/entitlements-and-quotas
+  source_owner: SAP SE
+  topic_supported: Service entitlements, quota assignments, entitlement management lifecycle — relevant when integration failures are caused by quota exhaustion or missing service entitlements at the BTP platform layer
+  why_needed: Required when the BTP account entitlement governance reviewer role is activated — confirms whether platform-layer entitlement gaps are a contributing factor to integration failures
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Grounding rule
+
+SAP Help Portal documentation describes the designed capabilities, configuration options, and operational behavior of SAP Integration Suite, Cloud ALM, and Event Mesh. It does not prove the root cause of a specific failure in the user's tenant, nor does it confirm the configuration state of a specific iFlow or adapter. Users must supply message processing log excerpts, Cloud ALM alert data, adapter configuration descriptions, and incident timelines for concrete advisory output. All credentials, tokens, and PII must be redacted before submission.

package/skills/sap/sap-integration-platform-businessops-protocol/references/safety-checklist.md

@@ -0,0 +1,36 @@
+# Safety checklist — SAP Integration / Platform / Business Operations Protocol
+
+Use before finalizing any finding, handoff package, or escalation trigger. This checklist is mandatory for all advisory sessions involving integration flow changes, credential rotations, or business-process outage declarations.
+
+## Non-negotiables
+
+- Do not accept or process OAuth tokens, Basic Authentication passwords, client secrets, API keys, or certificate private keys present in adapter configurations or trace logs. Refuse immediately and request redaction before proceeding.
+- Do not recommend undeploying an active integration flow without first confirming (with the user) the business impact of stopping in-flight message processing. An undeploy during active transaction processing causes message loss.
+- Do not invoke or recommend invoking `sap-integration-flow-guarded-operator-agent` from within this protocol. The operator gate is human-mediated only. This protocol produces the package; a human submits it.
+- Do not recommend rotating adapter credentials without first confirming that the replacement credentials have been provisioned and tested. Rotating to invalid credentials immediately breaks all channels using those credentials.
+- Do not classify a finding as `critical` without tracing the specific failure to user-provided evidence (log excerpt, alert export, incident record). Severity inflation without evidence is not permitted.
+- Do not recommend restarting the SAP Integration Suite runtime node without first confirming with the user that they have the appropriate support access level to perform a restart and that the restart will not violate a maintenance window restriction.
+- Do not produce a root cause hypothesis at `confirmed` confidence without user-provided evidence directly linking the hypothesis to the observed failure. `probable` or `possible` must be used when the evidence is indirect.
+
+## What people get wrong
+
+- **Conflating message processing errors with infrastructure failures**: A 503 response from a receiver system is a receiver-side issue, not an Integration Suite infrastructure failure. A message processing log showing a mapping exception is a flow design issue, not a platform issue. Classify correctly before recommending remediation.
+- **Assuming retry exhaustion means message loss**: Retry exhaustion moves the message to an error state in the message processing log. It does not delete the message. Messages in error state can often be retried manually via the Operations view. Confirm whether manual retry is available before recommending more invasive remediation.
+- **Conflating Cloud ALM health alerts with iFlow-level errors**: Cloud ALM health monitoring operates at the service level; iFlow errors are visible at the message processing log level. A Cloud ALM green health status does not mean individual messages are processing correctly.
+- **Recommending credential rotation without checking all channels using those credentials**: A single OAuth client or Basic Authentication credential may be used by multiple iFlows or adapters across different packages. Rotating the credential without identifying all dependent channels breaks every one of them simultaneously.
+- **Treating Event Mesh dead-letter queue accumulation as benign**: Messages in the dead-letter queue have exhausted all delivery retries. Without active reprocessing or discard, they consume storage and may indicate a subscription consumer failure that will grow indefinitely. Dead-letter queue accumulation is never a low-severity finding when the queue is growing.
+- **Missing the on-premise Integration Agent in middleware instability triage**: SAP Integration Suite Cloud Integration can connect to on-premise systems via the SAP Connectivity service and Cloud Connector. Middleware instability may originate in the on-premise Cloud Connector or subaccount-level Connectivity service configuration, not in the cloud-side Integration Suite tenant.
+
+## When to push back
+
+- Push back when the user asks for a root cause determination without providing any message processing log excerpt, error message, or Cloud ALM alert data. Root cause analysis without evidence must be labeled `unknown` confidence.
+- Push back when the user asks to directly execute an integration flow change, adapter credential rotation, or Event Mesh subscription change from within this protocol. This protocol is advisory only; redirect the user to the operator gate with the completed handoff package.
+- Push back when the user provides adapter configurations or trace logs containing unredacted credentials. Request redaction before accepting the evidence.
+- Push back when the user asks to declare a business-process outage resolved without the Business Process Owner confirming resolution. This protocol confirms integration health signals; the business declares resolution.
+- Push back when a request requires live access to the SAP Integration Suite Operations view, Cloud ALM dashboard, or Event Mesh management console — this protocol accepts only user-provided artifacts. State clearly that live system access is out of scope.
+
+## Evidence labels
+
+- `documentation-based` — grounded in SAP Integration Suite documentation, SAP Cloud ALM documentation, SAP Event Mesh documentation, or SAP BTP Help Portal references
+- `user-provided evidence` — message processing log excerpts, Cloud ALM alert exports, adapter configuration descriptions, incident timelines, or monitoring screenshots supplied by the user
+- `inference` — derived reasoning not directly confirmed by official documentation or user evidence; always label explicitly and note the assumption being made

package/skills/sap/sap-integration-platform-businessops-protocol/references/workflow-and-output.md

@@ -0,0 +1,76 @@
+# Workflow and output contract — SAP Integration / Platform / Business Operations Protocol
+
+Use this reference for trigger classification, role activation logic, root cause hypothesis structure, finding severity, handoff sequencing, and output format.
+
+## Trigger classification taxonomy
+
+| Trigger class | Description | Primary role activated |
+|---------------|-------------|----------------------|
+| `iflow-failure` | iFlow in error state, message processing failures, or mapping exceptions | sap-integration-suite-reviewer-agent |
+| `api-throttling` | Rate-limit or 429 responses from Integration Suite, API Business Hub, or connected systems | sap-integration-suite-reviewer-agent |
+| `event-delivery-failure` | Event Mesh messages stuck, undelivered, or accumulating in dead-letter queue | sap-integration-suite-reviewer-agent + sap-cloud-alm-sre-incident-agent |
+| `partner-integration-break` | EDI, B2B, or external API integration has stopped exchanging data | sap-integration-suite-reviewer-agent |
+| `data-replication-failure` | CDS view replication, SLT, or SOAP/REST sync producing stale or corrupt data | sap-integration-suite-reviewer-agent + sap-cloud-alm-sre-incident-agent |
+| `middleware-instability` | Integration Suite tenant, Node, or on-premise Agent exhibiting erratic behavior | sap-cloud-alm-sre-incident-agent |
+| `business-process-outage` | Critical business process interrupted; integration or platform layer suspected | All four roles activated; sap-cloud-alm-sre-incident-agent leads triage |
+| `platform-entitlement-gap` | Integration failure caused by missing BTP service entitlement or quota exhaustion | sap-btp-account-entitlement-governance-reviewer-agent |
+
+## Root cause hypothesis structure
+
+For each session, produce a root cause hypothesis using the following structure:
+
+1. **Hypothesis** — the most likely root cause in plain language.
+2. **Evidence basis** — what user-provided evidence or documentation supports this hypothesis.
+3. **Confidence level** — one of: `confirmed` (directly evidenced), `probable` (strongly suggested by evidence), `possible` (plausible but not directly evidenced), `unknown` (insufficient evidence to hypothesize).
+4. **Competing hypotheses** — alternative root causes not yet ruled out, with evidence that would confirm or exclude them.
+5. **Evidence gap** — what additional evidence the user must collect to move from `possible` or `unknown` to `confirmed` or `probable`.
+
+## Finding severity classification
+
+| Severity | Criteria |
+|----------|---------|
+| `critical` | Live business-process outage; active data loss or message loss; security-impacting credential exposure in a deployed adapter; SLA breach with penalty exposure |
+| `high` | Integration flow producing incorrect output without triggering an error (silent data corruption); Event Mesh dead-letter queue accumulating with no reprocessing plan; partner integration break affecting external SLA commitments |
+| `medium` | Integration flow in error state with retry exhausted but no immediate data loss; API throttling degrading (not stopping) business processes; monitoring gap preventing timely incident detection |
+| `low` | iFlow design deviation from best practices with no current impact; missing error notification configuration; suboptimal retry policy that increases blast radius if a downstream system becomes unavailable |
+
+## Workflow
+
+1. **Classify trigger** — identify which trigger class(es) apply from the incident description and evidence.
+2. **Activate relevant roles** — determine which of the four participating agent roles are relevant to this session.
+3. **Inventory evidence** — list all artifacts provided; confirm redaction compliance; request missing mandatory items.
+4. **Produce root cause hypothesis** — structured hypothesis with confidence level and evidence gaps.
+5. **Produce per-role findings** — for each activated role, produce advisory findings with evidence labels and severity classification.
+6. **Map decision rights** — for each recommended action, identify the named human approver from the decision rights table in SKILL.md.
+7. **Gate irreversible actions** — for any finding involving a listed irreversible action, confirm human approval is required before proceeding; do not pre-approve.
+8. **Sequence remediation** — critical findings first (outage resolution), then high (silent corruption, SLA risk), then medium (monitoring gaps), then low (design improvements).
+9. **Produce audit package** — assemble the audit package as defined in SKILL.md.
+
+## Output contract
+
+Return:
+
+1. **Trigger classification** — which trigger class(es) activated, with evidence label.
+2. **Roles activated** — which participating agent domains are in scope for this session.
+3. **Evidence inventory** — types of artifacts received; redaction confirmation; missing mandatory evidence.
+4. **Root cause hypothesis** — structured per the hypothesis template above.
+5. **Per-domain findings** — severity, evidence label, and recommended advisory action for each finding.
+6. **Decision rights table** — pending decisions mapped to named approver roles.
+7. **Irreversible-action gate status** — list of any irreversible actions in scope; human approval status (confirmed / not yet / not applicable).
+8. **Business process impact** — current status (outage active / degraded / recovering / resolved).
+9. **Escalation log** — escalation owners to notify and the action requested from each.
+10. **Audit package readiness** — complete / incomplete (with blocking items).
+11. **Next human step** — specific action required to proceed.
+
+## Handoff to guarded-mutating operator gate
+
+This protocol does not invoke `sap-integration-flow-guarded-operator-agent` directly. When the audit package is complete and human approval has been confirmed for all irreversible actions, the protocol produces a handoff summary containing:
+
+- Approved action type and scope (iFlow redeployment, undeploy, adapter credential rotation, Event Mesh subscription change).
+- Integration artifact identifier (iFlow ID, package name, version reference).
+- Evidence basis and root cause hypothesis supporting the action.
+- Named approvers who confirmed the action.
+- Timestamp of approval confirmation.
+- Reference to the change record where approval is documented.
+
+A human presents this handoff summary to the operator gate. The operator gate independently verifies approval before executing any mutation.

package/skills/sap/sap-integration-suite-review/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: sap-integration-suite-review
+description: Review SAP Integration Suite topology and configuration: Cloud Integration iFlows, API Management policies, Event Mesh topics and queues, OAuth/certificate security, error handling, idempotency patterns, and monitoring. Flags security gaps, missing error handling, and idempotency violations. Does not touch live systems.
+allowed-tools: Read Grep Glob WebSearch WebFetch
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-19"
+  category: platform
+  lifecycle: experimental
+---
+
+# SAP Integration Suite Review
+
+## Purpose
+
+Assess the design, security, and operational posture of SAP Integration Suite components. Review Cloud Integration iFlow design for error handling completeness, idempotency, adapter security, and message processing patterns. Review API Management proxy configuration for OAuth policy correctness, rate limiting, quota enforcement, and threat protection. Review SAP Event Mesh topic and queue design for access control, consumer group isolation, and dead-letter handling. Surface security gaps, missing operational guardrails, and integration anti-patterns. Does not connect to or mutate any live Integration Suite tenant.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review Cloud Integration (CPI) iFlow design for error handling, retry logic, idempotency, exception subprocess coverage, or message mapping correctness,
+- assess API Management proxy configuration including OAuth policy enforcement, rate limiting, quota plans, JWT validation, threat protection, and API product design,
+- evaluate SAP Event Mesh topic configuration, namespace design, queue bindings, consumer group isolation, and dead-letter queue handling,
+- audit Integration Suite security posture: OAuth client credential flows, certificate-based adapter authentication, credential store usage, and absence of plaintext secrets,
+- review monitoring and alerting configuration: Cloud Integration message monitoring, alert rules, retry exhaustion handling, and operational visibility,
+- flag integration anti-patterns: synchronous fallback in async iFlows, missing correlation ID propagation, absent receiver determination, or unclear message routing,
+- assess OData or REST API exposure patterns from Cloud Integration or API Management against standard OData V4 or OpenAPI 3.0 conventions.
+
+## When not to use
+
+- When the user needs live inspection of a running iFlow, deployed API proxy, or Event Mesh namespace — this skill accepts only user-provided iFlow exports, API proxy descriptors, or configuration descriptions.
+- When the request is about BTP account-level governance (entitlements, subaccounts, role collections) — use `sap-btp-governance-review`.
+- When the request is about ABAP integration patterns inside S/4HANA rather than Integration Suite middleware — use `sap-clean-core-debt-review`.
+- When the request is about end-to-end identity and access management — use `sap-security-iam-grc-sod-review`.
+
+## Does not touch live systems
+
+This skill operates on user-provided iFlow export bundles (.iflw files), API proxy descriptors, Event Mesh configuration exports, architecture descriptions, monitoring screenshots, or configuration summaries. It does not connect to any Cloud Integration tenant, API Management portal, Event Mesh namespace, or SAP BTP service API. All live inspection is out of scope.
+
+## Lean operating rules
+
+- Classify integration issues before recommending. Every finding must be assigned to a component domain (Cloud Integration / API Management / Event Mesh / Security / Monitoring) before remediation is proposed.
+- Error handling is non-negotiable. Every iFlow that processes business-critical messages must have an exception subprocess. An iFlow with no exception handling is a `high` severity finding.
+- Idempotency is required for all retry-capable integrations. Any iFlow that uses JMS retry, polling adapter, or webhook delivery without idempotency controls (duplicate check, idempotent receiver, or business-key deduplication) is a `high` severity finding.
+- OAuth is the required API Management security baseline. API proxies without an OAuth or API key policy enforced at the inbound step are a `critical` finding. Basic auth on inbound proxy endpoints is not acceptable.
+- Credentials must use the Credential Store. Plaintext credentials in iFlow configuration properties, message mappings, or API proxy flows are a `critical` finding. All credentials must reference the Integration Suite Secure Store or SAP Credential Store service.
+- OData and OpenAPI exposure must match the declared standard. OData V4 services exposed via Cloud Integration or API Management must conform to OData V4 metadata conventions. OpenAPI 3.0 specs exposed via API Management must accurately describe the deployed API behavior.
+- Event Mesh access control must use role-based bindings. Event Mesh service instance bindings must use dedicated service keys per consumer; shared service keys across multiple consumers are a governance risk.
+- Correlation ID propagation is required for end-to-end traceability. iFlows that do not propagate a correlation ID (SAP-MessageId header or business key) across adapter boundaries impede incident diagnosis.
+- Evidence from user-provided artifacts or official SAP Integration Suite documentation takes precedence over inference.
+- Context7 CAP documentation applies supplementarily when reviewing OData service exposure patterns from CAP-based services integrated via Integration Suite.
+
+## Evidence rules
+
+Label all claims with one of:
+
+- `documentation-based` — grounded in SAP Integration Suite Help Portal, Cloud Integration docs, API Management docs, or Event Mesh docs
+- `user-provided evidence` — iFlow exports, API proxy descriptors, Event Mesh config exports, monitoring screenshots, or descriptions provided by the user
+- `context7-supplementary` — grounded in CAP OData/OpenAPI framework docs fetched from Context7 (supplementary; applies only when CAP-based OData or OpenAPI service integration is in scope)
+- `inference` — derived reasoning not directly confirmed by official docs or user evidence
+
+## Live-environment rules
+
+**This skill does not touch live systems.** There is no Cloud Integration API call, API Management portal request, Event Mesh management API invocation, or BTP service binding access in this skill's execution path. Users must supply iFlow export bundles, API proxy descriptors, Event Mesh configuration exports, or written descriptions of their Integration Suite topology for this skill to review.
+
+## References
+
+Load only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — integration issue taxonomy, severity classification, output format.
+- [Safety checklist](references/safety-checklist.md) — non-negotiables, common mistakes, when to push back.
+- [Official sources](references/official-sources.md) — SAP Integration Suite, Cloud Integration, API Management, Event Mesh, and security documentation.
+- [Context7 framework docs](references/context7-framework-docs.md) — CAP OData service and event handling patterns (supplementary; use when CAP-based service integration is in scope).
+
+## Response minimum
+
+Return, at minimum:
+
+- **Problem classification**: Integration Suite component(s) in scope and specific finding(s) per component.
+- **Evidence used**: documentation-based / user-provided evidence / context7-supplementary / inference.
+- **Risk level**: critical (security or data loss risk) / high (operational reliability risk) / medium (governance gap) / low (best practice deviation).
+- **Recommended action**: specific remediation per finding (exception subprocess addition, idempotency control, OAuth policy enforcement, credential store migration, etc.).
+- **Refusal / escalation triggers**: if live tenant access, iFlow deployment, or API proxy deployment is required to complete the review, state that clearly and do not proceed.
+- **Business impact**: integration failure blast radius, data loss risk, security exposure, or compliance gap.
+- **Next verification step**: validate recommended changes against the current Integration Suite tenant configuration before deploying.

package/skills/sap/sap-integration-suite-review/agents/openai.yaml

@@ -0,0 +1,11 @@
+interface:
+  display_name: "SAP Integration Suite Review"
+  short_description: "Review SAP Integration Suite components: Cloud Integration iFlows, API Management proxy policies, Event Mesh configuration, OAuth/certificate security, error handling, idempotency, and monitoring. Flags security gaps and integration anti-patterns."
+  default_prompt: "Use $sap-integration-suite-review to assess the provided SAP Integration Suite configuration. Classify each finding by component domain (Cloud Integration, API Management, Event Mesh, Security, Monitoring), assign a risk level (critical/high/medium/low), and recommend specific remediation actions. State evidence level (documentation-based, user-provided, context7-supplementary, inference) and whether live tenant access is required to complete the review."
+dependencies:
+  tools:
+    - type: "web"
+      value: "https://help.sap.com/docs/cloud-integration/sap-cloud-integration/sap-cloud-integration"
+      description: "SAP Cloud Integration documentation — primary reference for iFlow design, error handling, idempotency, and security material management"
+policy:
+  allow_implicit_invocation: true

package/skills/sap/sap-integration-suite-review/metadata.json

@@ -0,0 +1,33 @@
+{
+  "id": "sap-integration-suite-review",
+  "name": "SAP Integration Suite Review",
+  "type": "skill",
+  "provider": "sap",
+  "harnesses": [
+    "claude-code",
+    "codex",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review SAP Integration Suite topology: Cloud Integration iFlows, API Management proxy policies, Event Mesh configuration, OAuth/certificate security, error handling, idempotency, and monitoring. Flags security gaps, missing error handling, and integration anti-patterns. Does not access live systems.",
+  "source_type": "original",
+  "category": "platform",
+  "official_docs": [
+    "https://help.sap.com/docs/cloud-integration/sap-cloud-integration/sap-cloud-integration",
+    "https://help.sap.com/docs/sap-api-management/sap-api-management/sap-api-management",
+    "https://help.sap.com/docs/sap-advanced-event-mesh/sap-advanced-event-mesh/what-is-sap-advanced-event-mesh",
+    "https://help.sap.com/docs/cloud-integration/sap-cloud-integration/define-exception-subprocess",
+    "https://help.sap.com/docs/cloud-integration/sap-cloud-integration/idempotent-process-call-handles-duplicates",
+    "https://help.sap.com/docs/sap-api-management/sap-api-management/oauth-v2-0",
+    "https://help.sap.com/docs/cloud-integration/sap-cloud-integration/managing-security-material",
+    "https://help.sap.com/docs/cloud-integration/sap-cloud-integration/message-monitoring"
+  ],
+  "security_notes": "Does not access live SAP Integration Suite tenants, Cloud Integration APIs, API Management portals, or Event Mesh namespaces. Accepts only user-provided iFlow exports, API proxy descriptors, Event Mesh config exports, or written descriptions. Never request or accept tenant OAuth tokens, service keys, credential store values, or API Management admin credentials. Recommendations must be validated against the live tenant configuration before deployment.",
+  "last_verified": "2026-06-19",
+  "path": "skills/sap/sap-integration-suite-review",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "lifecycle": "experimental"
+}