@raishin/vanguard-frontier-agentic 2.10.0 → 2.13.0

package/skills/sap/sap-fiori-ui5-ux-review/references/context7-framework-docs.md

@@ -0,0 +1,128 @@
+# Context7 framework docs — SAP Fiori and UI5 UX Review
+
+**Role**: supplementary. Official SAP Fiori design guidelines at experience.sap.com and official SAPUI5 documentation at ui5.sap.com are the primary sources for all review guidance. Context7-sourced OpenUI5/SAPUI5 documentation supplements with code-level examples and implementation detail for MVC patterns, OData model binding, component configuration, and accessibility.
+
+**Library used**: OpenUI5
+Context7 library ID: `/ui5/docs`
+Lookup targets: MVC controller patterns, OData V2/V4 model binding, async component loading, i18n ResourceModel, XML view and fragment patterns, accessibility labeling
+Skill: `sap-fiori-ui5-ux-review`
+Classification: supplementary — strongly applies for MVC, OData consumption, component configuration, and accessibility domains
+
+---
+
+## UI5 MVC — Controller initialization and ResourceModel (supplementary)
+
+Source: OpenUI5 documentation (Context7 `/ui5/docs`)
+Reference: https://github.com/ui5/docs/blob/main/docs/03_Get-Started/step-8-translatable-texts-df86bfb.md
+
+Correct controller `onInit` pattern: instantiate the ResourceModel for i18n and set it as a named model on the view. Business data models should also be set on the view, not on the component or global core, unless cross-view sharing is required.
+
+```javascript
+sap.ui.define([
+   "sap/ui/core/mvc/Controller",
+   "sap/ui/model/json/JSONModel",
+   "sap/ui/model/resource/ResourceModel"
+], (Controller, JSONModel, ResourceModel) => {
+   "use strict";
+
+   return Controller.extend("myApp.controller.Main", {
+      onInit() {
+         const oModel = new JSONModel({ recipient: { name: "World" } });
+         this.getView().setModel(oModel);
+
+         const i18nModel = new ResourceModel({ bundleName: "myApp.i18n.i18n" });
+         this.getView().setModel(i18nModel, "i18n");
+      }
+   });
+});
+```
+
+**Review relevance**: Assess whether models are set correctly on the view (not on `sap.ui.getCore()`), whether the i18n ResourceModel uses a bundle name rather than a hardcoded URL, and whether the `onInit` hook is used appropriately rather than doing model setup in the constructor.
+
+---
+
+## UI5 XML view — Shell control and Fiori launchpad embedding (supplementary)
+
+Source: OpenUI5 documentation (Context7 `/ui5/docs`)
+Reference: https://github.com/ui5/docs/blob/main/docs/03_Get-Started/step-12-shell-control-as-container-4df1d91.md
+
+The `sap.m.Shell` control provides a letterbox layout for standalone app deployment. When the app runs inside the SAP Fiori launchpad, the Shell control is automatically omitted by the launchpad container. Wrapping the `sap.m.App` inside a `Shell` is the correct pattern for apps that must work both standalone and embedded in the launchpad.
+
+```xml
+<mvc:View
+   controllerName="myApp.controller.App"
+   xmlns="sap.m"
+   xmlns:mvc="sap.ui.core.mvc"
+   displayBlock="true">
+   <Shell>
+      <App>
+         <pages>
+            <Page title="{i18n>homePageTitle}">
+               <content>
+                  <!-- page content -->
+               </content>
+            </Page>
+         </pages>
+      </App>
+   </Shell>
+</mvc:View>
+```
+
+**Review relevance**: If the root XML view wraps `sap.m.App` without a `Shell` and the app is expected to run standalone (outside the Fiori launchpad), it will not adapt correctly to larger screens. Classify as a `medium` finding for apps with standalone deployment requirement.
+
+---
+
+## UI5 OData V2 model — Template view and metadata loading (supplementary)
+
+Source: OpenUI5 documentation (Context7 `/ui5/docs`)
+Reference: https://github.com/ui5/docs/blob/main/docs/04_Essentials/xml-templating-5ee619f.md
+
+OData V2 model creation with async metadata loading and annotation URI. The `loadMetadataAsync: true` flag is required for correct async initialization; without it, metadata loading blocks the main thread.
+
+```javascript
+const oModel = new ODataModel(
+   "/sap/opu/odata/IWBEP/GWSAMPLE_BASIC/", {
+      annotationURI: "/path/to/annotations.xml",
+      json: true,
+      loadMetadataAsync: true
+   }
+);
+const oMetaModel = oModel.getMetaModel();
+oMetaModel.loaded().then(() => {
+   // Safe to access metadata here
+});
+```
+
+**Review relevance**: Assess whether `loadMetadataAsync: true` is set on OData V2 model instances declared in `manifest.json` or instantiated in controllers. A V2 ODataModel without this flag blocks metadata loading synchronously. Classify as a `high` performance finding.
+
+---
+
+## UI5 app development best practices (supplementary)
+
+Source: OpenUI5 documentation (Context7 `/ui5/docs`)
+Reference: https://github.com/ui5/docs/blob/main/docs/03_Get-Started/best-practices-for-developers-28fcd55.md
+
+SAP/OpenUI5 best practices for app development cover asynchronous loading, component setup, controller patterns, view and fragment handling, model usage, and resource bundle configuration. Key points for this skill:
+
+- **Asynchronous loading**: All UI5 apps should use the `async` bootstrap parameter and declare `async: true` in the component configuration. Synchronous loading is deprecated and a performance finding.
+- **Components**: Use `UIComponent.extend()` with `metadata.interfaces: ["sap.ui.core.IAsyncContentCreation"]` to enable async content creation and avoid rendering blockers.
+- **Controllers**: Avoid storing references to UI controls in controller properties — use `byId` each time. Store only model references or simple state in controller instance properties.
+- **Models**: Prefer declaring models in `manifest.json` over programmatic instantiation in controllers. Programmatic instantiation is acceptable for local view models not shared across views.
+- **ResourceBundles**: Always reference i18n text keys via `{i18n>key}` binding in XML views rather than resolving them programmatically unless dynamic text construction is required.
+
+**Review relevance**: Use these best practices as the basis for `medium` and `low` findings in the App Structure, XML View, and Controller review domains. Flag violations of asynchronous loading as `high` findings.
+
+---
+
+## Scope boundaries for Context7 usage
+
+Context7 OpenUI5/SAPUI5 documentation applies to the following review domains in this skill:
+
+- **App Structure** (manifest.json, component configuration, async loading): directly applicable
+- **XML View** (view patterns, Shell control, fragment usage): directly applicable
+- **Controller** (onInit patterns, model setup, lifecycle hooks): directly applicable
+- **OData Consumption** (ODataModel V2 creation, metadata async loading, model binding): directly applicable
+- **Accessibility** (ARIA labeling in XML views, accessible control patterns): applicable for control-level patterns
+- **Fiori Design** and **Launchpad**: use official SAP Fiori design guidelines (experience.sap.com) and SAP Help Portal as primary sources; Context7 provides supplementary implementation detail only
+
+Always label Context7-sourced guidance as `context7-supplementary` in responses. For SAPUI5 version-specific control behavior or deprecated API lists, direct the user to verify against the official SAPUI5 changelog at ui5.sap.com.

package/skills/sap/sap-fiori-ui5-ux-review/references/official-sources.md

@@ -0,0 +1,95 @@
+# Official sources — SAP Fiori and UI5 UX Review
+
+Use this reference when grounding Fiori design guideline adherence, SAPUI5 app structure, OData consumption, accessibility, and Fiori launchpad integration guidance.
+
+**Evidence level**: documentation-based (SAP Fiori design guidelines at experience.sap.com, SAPUI5 documentation at ui5.sap.com, SAP Help Portal). No live-system evidence is collected by this skill.
+
+## SAP Fiori Design Guidelines
+
+- SAP Fiori Design Guidelines (Web)
+  https://experience.sap.com/fiori-design-web/
+  source_owner: SAP SE
+  topic_supported: Fiori floorplan selection (List Report, Object Page, Overview Page, Worklist, Wizard), header and footer bar patterns, control usage guidelines, responsive design, UX pattern catalog
+  why_needed: Primary source for classifying Fiori design guideline deviations; defines which floorplan is correct for a given use case and what header/footer patterns are required
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAPUI5 App Descriptor (manifest.json)
+
+- SAPUI5 App Descriptor Reference
+  https://ui5.sap.com/#/topic/003f755d46d34dd1bbce9ffe08c8d46a
+  source_owner: SAP SE
+  topic_supported: manifest.json structure — sap.app, sap.ui, sap.ui5 sections; data source declarations; routing configuration; model declarations; component settings; i18n bundle registration
+  why_needed: Authoritative reference for reviewing manifest.json completeness and identifying missing or incorrect configuration entries
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAPUI5 MVC and Component Architecture
+
+- SAPUI5 MVC Overview
+  https://ui5.sap.com/#/topic/91f0a22d6f4d1014b6dd926db0e91070
+  source_owner: SAP SE
+  topic_supported: Model-View-Controller pattern in UI5 — view types (XML, JSON, HTML), controller lifecycle hooks (onInit, onExit, onBeforeRendering, onAfterRendering), model binding, controller extension
+  why_needed: Defines correct MVC separation and lifecycle hook patterns; used to classify controller code that violates MVC separation or misuses lifecycle hooks
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- SAPUI5 Components and Descriptor
+  https://ui5.sap.com/#/topic/958ead51e2e94ab8bcdc90fb7e9d53d0
+  source_owner: SAP SE
+  topic_supported: UIComponent instantiation, async component loading, component configuration, index.html bootstrap setup, async rendering
+  why_needed: Defines the async component loading pattern; used to classify synchronous loading as a high performance finding
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## OData Consumption
+
+- SAPUI5 OData V2 Model
+  https://ui5.sap.com/#/topic/6c47b2b39db9404582994070ec3d57a2
+  source_owner: SAP SE
+  topic_supported: ODataModel V2 configuration, read/create/update/delete operations, error callbacks, batch mode, deferred groups, filter and sort expressions, metadata handling
+  why_needed: Authoritative source for OData V2 consumption patterns; used to classify missing error callbacks, incorrect batch mode settings, and filter expression anti-patterns
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- SAPUI5 OData V4 Model
+  https://ui5.sap.com/#/topic/5338bd1f9afb45fb8b2af957c3530e8f
+  source_owner: SAP SE
+  topic_supported: ODataModel V4 configuration, list and context binding, auto-batch mode, PATCH-based updates, late properties, binding parameters
+  why_needed: Authoritative source for OData V4 consumption patterns; used to classify V4-specific binding issues and incorrect auto-batch configuration
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Accessibility
+
+- SAPUI5 Accessibility Guidelines
+  https://ui5.sap.com/#/topic/68b9644a253741e8a4b9e4279a35c247
+  source_owner: SAP SE
+  topic_supported: ARIA landmark usage, labelFor associations, high-contrast theme support, keyboard navigation, screen reader compatibility, getAccessibilityInfo() implementation for custom controls
+  why_needed: Defines SAPUI5 accessibility requirements; used to classify missing ARIA labels, incorrect form field labeling, and inaccessible custom controls as high findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Fiori Launchpad Integration
+
+- SAP Fiori Launchpad Overview
+  https://help.sap.com/docs/SAP_FIORI_LAUNCHPAD/fd8d03d7-14b9-40f7-9a07-1a594f20ac8d/what-is-sap-fiori-launchpad
+  source_owner: SAP SE
+  topic_supported: Fiori launchpad architecture, tile configuration, semantic object and action definition, target mapping, cross-application navigation, app descriptor inbound/outbound navigation declarations
+  why_needed: Defines Fiori launchpad integration requirements; used to classify incorrect semantic object definitions, missing target mappings, and broken cross-application navigation intents
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP Fiori Elements
+
+- SAPUI5 Fiori Elements Overview
+  https://ui5.sap.com/#/topic/c9ab34570cc14ea5ab72a6d1a4a03e3f
+  source_owner: SAP SE
+  topic_supported: Fiori Elements floorplans (List Report, Object Page, Analytical List Page, Overview Page), annotation-driven rendering, extension points, building blocks
+  why_needed: Defines the Fiori Elements rendering model; used to distinguish annotation-driven findings from freestyle findings and to classify incorrect extension point usage
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Grounding rule
+
+SAP Fiori design guidelines and SAPUI5 documentation describe design intent and recommended patterns. They do not prove which SAPUI5 controls are rendered correctly in the user's deployed UI5 version, which Fiori Elements features are available for their SAP system version, or whether the Fiori launchpad target mapping is correctly configured in their specific SAP BTP or on-premise launchpad. Users must supply manifest files, XML views, controller code, and OData metadata for concrete assessment.

package/skills/sap/sap-fiori-ui5-ux-review/references/safety-checklist.md

@@ -0,0 +1,37 @@
+# Safety checklist — SAP Fiori and UI5 UX Review
+
+Use before making any finding or remediation recommendation.
+
+## Non-negotiables
+
+- Do not access, connect to, or request access to any live UI5 app runtime, BTP subaccount, ABAP backend, Fiori launchpad configuration service, or OData service endpoint. This skill reviews artifacts only.
+- Do not accept or request BTP service keys, ABAP system credentials, OAuth tokens, OData service passwords, or SAP S/4HANA logon credentials.
+- Do not recommend bypassing SAPUI5 rendering lifecycle (direct DOM manipulation, jQuery selectors in controllers) as a workaround.
+- Do not validate UI5 control rendering behavior from memory alone for SAPUI5 versions older than 1.96 — direct the user to verify against the official SAPUI5 changelog and version-specific API documentation.
+- Do not conflate SAP Fiori Elements behavior (annotation-driven) with freestyle UI5 behavior. Annotation-driven findings apply only when Fiori Elements is confirmed as the rendering approach.
+- Do not classify an app as accessible from manifest analysis alone — accessibility findings require review of XML view and controller artifacts.
+- Do not recommend `sap.ui.getCore()` as an API pattern — it is deprecated since SAPUI5 1.118. Direct the user to use `Component.getComponentById()` or `this.getView().getModel()` equivalents.
+
+## What people get wrong
+
+- **Treating `manifest.json` routing as sufficient for navigation review**: Routing configuration errors (wrong `viewPath`, missing `target`, incorrect `pattern`) only become visible when XML views and controller navigation calls are also reviewed. Manifest alone is insufficient.
+- **Assuming `useBatch: false` is safe for write operations**: Disabling batch mode in `ODataModel` V2 causes each write operation to be sent as a separate HTTP request, bypassing transactional consistency. It is acceptable only for specific read-heavy scenarios with explicit justification.
+- **Overlooking `onExit` cleanup**: Event subscriptions registered on the global `EventBus` or resize handlers attached in `onInit` must be deregistered in `onExit`. Missing cleanup causes memory leaks that accumulate across navigation cycles.
+- **Treating Fiori Elements apps as freestyle**: SAP Fiori Elements apps render entirely from OData annotations. Reviewing controller code for logic that overrides Fiori Elements rendering without a registered extension point is a finding, not a pattern.
+- **Assuming ARIA compliance from control names alone**: Many SAPUI5 controls render accessible markup by default, but only when labels and associations are correctly declared in XML views. A `sap.m.Input` without an associated `sap.m.Label` via `labelFor` is not accessible even though `sap.m.Input` supports accessibility.
+- **Missing the `async` bootstrap parameter**: Setting `data-sap-ui-async="true"` in the UI5 bootstrap configuration is the single most impactful performance change for most Fiori apps. Its absence means all UI5 libraries load synchronously, blocking the main thread.
+
+## When to push back
+
+- Push back when the user asks to validate OData service behavior (response payloads, HTTP status codes, error body format) without providing OData metadata or service response examples — this skill reviews UI5 consumer-side artifacts, not backend OData service behavior.
+- Push back when the user asks to confirm Fiori launchpad tile rendering without providing the `manifest.json` inbounds section or tile descriptor.
+- Push back when multitenancy, BTP deployment, or runtime environment configuration is in scope without user-provided `manifest.json` and deployment descriptor artifacts.
+- Push back when the request involves live UI5 runtime access, Fiori launchpad configuration service calls, or ABAP backend OData inspection — this skill is advisory only.
+- Push back when the user asks to review a custom control's rendering behavior without providing the control's `renderer` implementation code.
+
+## Evidence labels
+
+- `documentation-based` — grounded in official SAP Fiori design guidelines (experience.sap.com) or official SAPUI5 documentation (ui5.sap.com)
+- `user-provided evidence` — manifest files, XML views, controller code, fragment files, OData metadata documents, tile descriptors, or descriptions provided by the user
+- `context7-supplementary` — SAPUI5/OpenUI5 MVC patterns, OData model binding, component configuration, or accessibility patterns sourced from Context7 (supplementary to official SAP sources)
+- `inference` — derived reasoning not directly confirmed; must always be labeled as such

package/skills/sap/sap-fiori-ui5-ux-review/references/workflow-and-output.md

@@ -0,0 +1,96 @@
+# Workflow and output contract — SAP Fiori and UI5 UX Review
+
+Use this reference for all classification, severity assignment, and output formatting.
+
+## Review domain taxonomy
+
+| Domain | Scope |
+|--------|-------|
+| `App Structure` | manifest.json completeness, component configuration, library dependencies, routing setup, data source declarations, model declarations |
+| `XML View` | view nesting correctness, control usage compliance, aggregation binding, layout patterns, fragment reuse, view instantiation |
+| `Controller` | MVC separation, lifecycle hooks, event handler design, controller extension, direct DOM access, memory leak patterns |
+| `OData Consumption` | ODataModel V2/V4 configuration, binding paths, batch mode, error callbacks, filter/sort expressions, deferred groups |
+| `Fiori Design` | floorplan selection, SAP Fiori design guideline adherence, header/footer bar patterns, responsive design, Fiori Elements versus freestyle decision |
+| `Accessibility` | ARIA landmark usage, form field labeling, table header correctness, keyboard navigation, high-contrast theme compatibility, screen reader support |
+| `Launchpad` | tile configuration, semantic object and action definition, target mapping, cross-application navigation intent, app descriptor sap.app and sap.ui5 section correctness |
+| `Performance` | async component loading, lazy view instantiation, OData batch grouping, initial payload size, synchronous module loading, unnecessary re-renders |
+
+## Severity classification
+
+| Severity | Meaning | Examples |
+|----------|---------|---------|
+| `critical` | Security or data integrity risk originating from the UI5 app | Direct DOM manipulation that bypasses CSP; XSS vector via unsanitized binding; client-side authorization bypass |
+| `high` | Functional, operational, or accessibility failure | Missing OData error callback; synchronous component loading; missing ARIA label on interactive control; broken launchpad navigation intent; incorrect routing configuration causing navigation failure |
+| `medium` | Fiori design deviation, maintainability gap, or UX standard violation | Wrong floorplan for the use case; missing footer toolbar in an Object Page; controller code accessing model data outside MVC separation; non-standard control layout |
+| `low` | Best practice deviation or code quality concern | Inconsistent controller naming; unused i18n keys; hardcoded text instead of i18n bundle reference; suboptimal OData batch group naming |
+
+## Workflow
+
+1. **Receive artifacts** — manifest.json, XML views, controller code, fragment files, OData metadata document, launchpad tile descriptor, or user descriptions.
+2. **Classify each finding** by review domain above.
+3. **Assign severity** (critical / high / medium / low).
+4. **Identify evidence level** (documentation-based / user-provided evidence / context7-supplementary / inference).
+5. **Recommend specific remediation** — annotation or configuration to add, control to replace, callback to implement, or pattern to correct.
+6. **Prioritize** — critical and high severity first; accessibility and OData error handling before design and performance findings.
+7. **Return output** per the output contract below.
+
+## Common finding patterns
+
+### App Structure
+- Missing `async: true` in `manifest.json` `sap.ui5.componentUsages` or component `index.js` (high performance finding)
+- Data source URL missing or pointing to a hardcoded absolute URL instead of a relative or destination-based path (high)
+- Missing `sap.ui` section or incorrect minimum SAPUI5 version declaration (medium)
+- Routing configuration missing a default target or using incorrect `viewPath` (high — causes navigation failure)
+
+### XML View
+- Hardcoded text in XML view instead of i18n binding (low)
+- Missing `growing="true"` and `growingThreshold` on large `sap.m.List` or `sap.m.Table` controls (high performance finding)
+- Using deprecated controls (e.g., `sap.ui.commons.*`) instead of `sap.m.*` equivalents (medium)
+- Fragment instantiated inside a controller without caching — creates duplicate fragment on each navigation (high)
+
+### Controller
+- Direct DOM access via `document.getElementById()` or jQuery selectors in controller methods (high)
+- Missing `onExit` lifecycle hook cleanup for event subscriptions or resize handlers (high — memory leak)
+- Business logic (data transformation, validation) mixed into controller instead of separated into a model or utility module (medium)
+- Using `sap.ui.getCore()` to access models instead of `this.getView().getModel()` (medium — deprecated pattern)
+
+### OData Consumption
+- ODataModel `read()` or `create()` call with no `error` callback (high)
+- Submitting changes without calling `ODataModel.submitChanges()` for V2 deferred batch groups (high — silent data loss)
+- Using `sap.ui.model.odata.v2.ODataModel` with `useBatch: false` in production without justification (medium — performance)
+- V4 ODataListBinding context accessed before the binding is resolved (high — runtime error)
+
+### Fiori Design
+- Using a custom freestyle layout where a Fiori Elements List Report or Object Page is the correct pattern for the use case (medium)
+- Object Page missing a dynamic page header with the required header content area (high)
+- Missing "Determine Changes" or "Save" / "Cancel" button pair in an editable Object Page footer (high)
+- Worklist app missing the search field and variant management controls required by the Worklist floorplan (medium)
+
+### Accessibility
+- Interactive control (`sap.m.Button`, `sap.m.Input`) missing `ariaLabelledBy` or `ariaDescribedBy` association and no visible label (high)
+- `sap.m.Table` missing column headers or using empty `sap.m.Column` label (high)
+- Form fields in `sap.ui.layout.form.SimpleForm` without `sap.m.Label` with `labelFor` association (high)
+- Custom control not implementing `getAccessibilityInfo()` method (medium)
+
+### Launchpad
+- `sap.app.crossNavigation.outbounds` missing required semantic object and action for cross-application navigation (high)
+- `sap.app.crossNavigation.inbounds` missing `signature.parameters` definition for intent-based navigation (high)
+- Tile title or subtitle hardcoded instead of using i18n reference in `manifest.json` (low)
+- Missing `sap.app.ach` (Application Component Hierarchy) assignment for support and monitoring (medium)
+
+### Performance
+- `sap/ui/core/Core` loaded synchronously in `index.html` without `data-sap-ui-async="true"` bootstrap parameter (high)
+- Non-critical XML views instantiated eagerly in `onInit` instead of lazily on first navigation (medium)
+- OData `$expand` used with unbounded expand depth — fetches entire entity graph (high — network performance)
+- Large JSON model payload loaded into a `sap.ui.model.json.JSONModel` on app startup instead of paged OData binding (medium)
+
+## Output contract
+
+Return:
+
+1. Artifacts reviewed and domains in scope
+2. Finding(s) per domain with severity and evidence label
+3. Specific remediation recommendation per finding (control to replace, configuration key to set, callback to add, annotation to apply, or pattern to adopt)
+4. Accessibility summary — list of interactive controls and form fields with their labeling and ARIA coverage status
+5. Prioritized remediation sequence (critical → high → medium → low)
+6. Escalation trigger if live UI5 runtime, BTP deployment, or ABAP backend OData inspection is required before proceeding

package/skills/sap/sap-guarded-btp-entitlement-change/SKILL.md

@@ -0,0 +1,156 @@
+---
+name: sap-guarded-btp-entitlement-change
+description: Change SAP BTP entitlements, quotas, and service plan subscriptions using a mandatory 17-step guarded mutation sequence covering classification, target global account and subaccount confirmation, criticality, requester, approver (platform-owner plus FinOps required), ticket, scope, read-only current state, diff of entitlement changes, blast radius (cost and dependent applications), rollback, post-change verification, and audit evidence. Refuses if any step is missing, if FinOps approval is absent for entitlement increases, or if a cost-impact assessment has not been produced. Use when a confirmed and approved BTP entitlement, quota, or subscription change 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: platform
+  lifecycle: experimental
+  execution_tier: mutating-runtime
+---
+
+# SAP Guarded BTP Entitlement Change
+
+## Purpose
+
+Change SAP BTP entitlements, service plan quotas, and service subscriptions in global accounts and subaccounts under a strict 17-step guarded mutation sequence. Every step must be completed, documented, and confirmed before the execution step is reached. If any step is absent, the entitlement change is refused until it is completed. This skill treats every BTP entitlement increase, quota adjustment, or service subscription change as a risk-critical mutating operation requiring dual approval from both the platform owner and FinOps, a documented cost-impact assessment, and a verified rollback path.
+
+Entitlement increases that add billable consumption are never approved on the basis of technical necessity alone — FinOps approval is a hard gate.
+
+## When to use
+
+Use this skill when:
+
+- a BTP service plan entitlement must be assigned, increased, or removed in a global account or subaccount,
+- a service plan quota must be adjusted for a specific subaccount,
+- a service subscription (a service plan enabled for a subaccount) must be added or removed,
+- a platform owner and FinOps approver have confirmed the change is approved and requires traceable execution,
+- post-change verification and audit evidence are required for cost governance, compliance, or capacity planning purposes,
+- the user needs a structured, risk-controlled execution protocol for SAP BTP cockpit or BTP Entitlements API operations.
+
+## When not to use
+
+- When the change targets a trial or free-tier account with no billable consumption — trial accounts are lower risk, but FinOps review is still recommended for resource planning.
+- When the user wants to *view* or *audit* current entitlements without making changes — 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 FinOps approval has not been obtained for any entitlement increase — refuse execution.
+- When a cost-impact assessment (part of step 9 diff) has not been produced — 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 documented dual approval (platform owner + FinOps) on record in this session.
+- FinOps approval is mandatory for all entitlement increases. Any change that adds billable capacity or enables a paid service plan requires explicit FinOps approval documented in step 13. Technical justification alone does not clear this gate.
+- Segregation of duties enforced. The person who requests the entitlement change (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 entitlement change is proposed. Do not propose changes on undocumented current entitlement state.
+- Cost-impact assessment required. Step 9 (diff) must include a documented cost delta — the estimated additional monthly cost from the proposed entitlement increase, based on current pricing. Changes with undocumented cost impact are refused.
+- Blast radius documented before execution. Step 10 must list all dependent applications and services that will be affected if the entitlement change succeeds or fails. Changes with undocumented blast radius are refused.
+- One subaccount change at a time. Do not batch-change entitlements across multiple subaccounts 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 accounts, BTP cockpit SSO, or BTP APIs with scoped OAuth tokens — 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 change type (assign entitlement, increase quota, decrease quota, remove entitlement, add subscription, remove subscription), the service name, service plan, and billing model (free / metered / subscription / block) | Change type, service name, service plan, and billing model documented |
+| 2 | Confirm target | Confirm the exact target global account name/ID, subaccount name/ID, and environment (production global account or non-production) | Target global account ID, subaccount ID, and environment tier confirmed by user |
+| 3 | Criticality assessment | Assess business criticality of the affected service (production application dependency, compliance-required service, revenue-critical integration) and cost sensitivity (metered billing scale risk) | Criticality level: low/medium/high/critical; cost sensitivity: low/medium/high |
+| 4 | Requester confirmation | Confirm the name, role, and authorization of the change requester | Requester name and role documented |
+| 5 | Dual approver identification | Identify both the platform owner (accountable for the global account architecture) and the FinOps approver (accountable for BTP cost governance) — both must be different from the requester | Platform owner name and role; FinOps approver name and role |
+| 6 | Ticket linkage | Link the change to a change management or capacity planning ticket (ITSM or FinOps budget approval reference) | Ticket number confirmed |
+| 7 | Scope documentation | Document the complete list of entitlement changes: service names, service plans, quota amounts (from → to), and target subaccounts | Entitlement change list with service, plan, quota delta, and subaccount |
+| 8 | Read-only current state | Read the current entitlement state of the global account and target subaccount: assigned entitlements, current quota allocations, active subscriptions, current metered consumption | Live evidence from BTP cockpit or Entitlements API (read-only) |
+| 9 | Diff and cost-impact assessment | Produce a diff of entitlement changes (quota before and after per service plan); document the estimated monthly cost delta based on SAP BTP pricing for the billing model; identify any entitlements being removed that have active consumers | Diff with quota delta and cost-impact assessment (monthly cost delta) |
+| 10 | Blast radius | Document all applications, services, and integrations that depend on the affected entitlements; assess risk of service disruption for quota decreases or subscription removals; assess cost overrun risk for quota increases | Blast radius document with dependent applications, disruption risk, and cost risk |
+| 11 | Rollback plan | Document the explicit rollback procedure: which entitlements to restore, which subscriptions to re-enable, and how to revert quota allocations via the Entitlements API or cockpit | Rollback procedure documented and confirmed feasible |
+| 12 | SoD verification | Verify that requester (step 4) is different from both the platform owner and FinOps approver (step 5); confirm no self-approval by any of the three parties | SoD confirmed: requester ≠ platform owner ≠ FinOps approver |
+| 13 | Dual approval gate | Obtain explicit written approval from both the platform owner and the FinOps approver for this specific entitlement change, naming the services, plans, and quota amounts | Dual approval statements on record in this session |
+| 14 | Execute approved change | Execute the entitlement assignments, quota adjustments, or subscription changes for approved services only, in the documented sequence | Execution log with timestamp |
+| 15 | Verify | Verify post-change state: confirm entitlements are active in the target subaccount, confirm dependent applications are functioning, confirm metered consumption tracking is active, check for any unexpected billing events | Post-change entitlement snapshot and application health verification |
+| 16 | Audit | Produce complete audit record: all 17 steps, evidence, commands, timestamps, dual approval statements, cost-impact assessment | Audit record |
+| 17 | Report | Deliver final report to requester, platform owner, FinOps approver, and cost center owner | Report delivered and acknowledged |
+
+## Evidence rules
+
+Label all data with one of:
+
+- `live evidence` — directly observed from a live BTP global account or subaccount in this session (include command, output summary, timestamp)
+- `documentation-based` — grounded in SAP official docs or SAP BTP pricing documentation
+- `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):
+- BTP Entitlements API: GET entitlements for global account and subaccount (read-only)
+- BTP cockpit: view current entitlement assignments, quota allocations, and active subscriptions (read-only)
+- BTP Usage API: GET current metered consumption for context
+
+**Allowed** (step 9 only — diff and cost-impact):
+- BTP Entitlements API: GET entitlement catalog for pricing metadata (read-only)
+- BTP cockpit: entitlement comparison view (read-only)
+
+**Allowed** (step 14 only — after all prior steps confirmed):
+- BTP Entitlements API: PUT/PATCH to assign or adjust entitlements for approved services and quota amounts
+- BTP cockpit: entitlement assignment and quota editing for approved services only
+- BTP Subscription API: POST to enable or DELETE to remove approved service subscriptions
+
+**Forbidden** (all other contexts):
+- Any entitlement assignment, quota change, or subscription modification before step 13 dual approval gate is cleared
+- Any change to services not on the approved list from step 7
+- Any entitlement increase without FinOps approval, regardless of other approvals
+- Any global account configuration changes (trust configuration, directory structure, subaccount creation) — this skill covers entitlement and subscription management only
+- Any access with global account administrator credentials for step 14 if a scoped entitlement manager role is available
+
+**Least-privilege credential rules**:
+- BTP Entitlements API: use a service account with the `Entitlements Administrator` role collection scoped to the specific global account; not Global Account Administrator
+- BTP cockpit: use a user with the `Global Account Viewer` role for steps 8–13 (read-only) and `Entitlements Administrator` role for step 14 only
+- BTP Subscription API: use a service account with `Subaccount Service Administrator` scoped to the specific subaccount; not Global Account Administrator
+
+**Approval gate (step 13)**:
+Before step 14 execution, confirm:
+1. All steps 1–12 are documented and evidence is on record.
+2. The platform owner from step 5 has provided explicit written approval in this session.
+3. The FinOps approver from step 5 has provided explicit written approval in this session.
+4. Both approvers are different from the requester.
+5. The cost-impact assessment from step 9 is on record.
+6. The approval explicitly names the services, service plans, and quota amounts to be changed.
+
+**Rollback**:
+- The rollback plan from step 11 must be documented before step 14 begins.
+- If post-change verification (step 15) reveals application disruption or unexpected billing events, stop immediately and execute the rollback plan before escalating to the platform owner and FinOps.
+- Do not attempt self-recovery changes without a new 17-step sequence.
+
+**Post-change (step 15)**:
+- Retrieve entitlement snapshot for the target subaccount and confirm assigned services match the approved change list.
+- Confirm dependent applications are running and have not lost access to required services.
+- For metered billing services, confirm that consumption tracking is active and reporting to the expected cost center.
+- Document the verification result as `live evidence`.
+
+**Audit (step 16)**:
+- Produce a complete record of all 17 steps, evidence gathered, commands executed, timestamps, dual approval statements, cost-impact assessment, and post-change verification results.
+- Retain audit record for the session and deliver to the platform owner, FinOps approver, and cost center owner.
+
+## 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 BTP entitlements, quotas, subscriptions, Entitlements API docs.
+- [Live environment access](references/live-environment-access.md) — credential setup, role requirements, audit log format.
+
+## Response minimum
+
+Return, at minimum:
+
+- **Problem classification**: change type, service name, service plan, billing model, and target global account / subaccount.
+- **Evidence used**: live evidence (with command log) / documentation-based / user-provided / inference.
+- **Risk level**: always risk-critical for production global accounts; critical for any metered billing service where quota increase carries significant cost exposure.
+- **Recommended action**: current step in the 17-step sequence and what is needed to advance.
+- **Refusal / escalation triggers**: refuse if dual approval gate (platform owner + FinOps) not cleared; refuse if FinOps approval absent for any entitlement increase; refuse if SoD violated; refuse if cost-impact assessment absent; refuse if any step is missing; refuse if rollback plan is absent.
+- **Business impact**: what changes in service availability and cost if the entitlement change succeeds; what applications are disrupted if the change is rolled back.
+- **Next verification step**: which step number is next and what evidence is required.

package/skills/sap/sap-guarded-btp-entitlement-change/agents/openai.yaml

@@ -0,0 +1,17 @@
+interface:
+  display_name: "SAP Guarded BTP Entitlement Change"
+  short_description: "Change SAP BTP entitlements, quotas, and subscriptions under a mandatory 17-step guarded mutation sequence with dual approval (platform-owner + FinOps) — refuses if any step is missing, FinOps approval absent for increases, cost-impact assessment not produced, or approval gate not cleared"
+  default_prompt: "Use $sap-guarded-btp-entitlement-change to assign, increase, decrease, or remove a SAP BTP entitlement, quota, or service subscription. Begin at step 1 (classify) and advance through all 17 steps in order. Do not reach step 14 (execute) without documented dual approval from both the platform owner and FinOps approver, and a cost-impact assessment from step 9. Refuse if any step is skipped, if SoD is violated, if FinOps approval is absent for an entitlement increase, or if a rollback plan is absent."
+dependencies:
+  tools:
+    - type: "api"
+      value: "sap-btp-entitlements-api"
+      description: "SAP BTP Entitlements API (Cloud Management Service) — GET current entitlement assignments and quota allocations for read-only state (step 8); PUT/PATCH entitlement assignments for approved changes (step 14) using Entitlements Administrator scope only"
+    - type: "api"
+      value: "sap-btp-subscription-api"
+      description: "SAP BTP Subscription Management API — GET active subscriptions (step 8); POST to enable or DELETE to remove approved service subscriptions (step 14) using Subaccount Service Administrator scope only"
+    - type: "api"
+      value: "sap-btp-usage-api"
+      description: "SAP Usage Data Management Service API — GET current metered consumption for cost-impact baseline (step 8 and step 9) and post-change billing verification (step 15)"
+policy:
+  allow_implicit_invocation: false

package/skills/sap/sap-guarded-btp-entitlement-change/metadata.json

@@ -0,0 +1,33 @@
+{
+  "id": "sap-guarded-btp-entitlement-change",
+  "name": "SAP Guarded BTP Entitlement Change",
+  "type": "skill",
+  "provider": "sap",
+  "harnesses": [
+    "claude-code",
+    "codex",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Change SAP BTP entitlements, service plan quotas, and service subscriptions in global accounts and subaccounts using a mandatory 17-step guarded mutation sequence: classify, confirm target global account and subaccount, criticality, requester, dual approver (platform-owner plus FinOps), ticket, scope, read-only current state, diff and cost-impact assessment, blast radius (cost and dependent apps), rollback, SoD verification, dual approval gate, execute approved changes only, verify, audit, report. Refuses if any step is missing, if FinOps approval is absent for entitlement increases, or if a cost-impact assessment has not been produced.",
+  "source_type": "original",
+  "category": "platform",
+  "official_docs": [
+    "https://help.sap.com/docs/btp/sap-business-technology-platform/entitlements-and-quotas",
+    "https://help.sap.com/docs/btp/sap-business-technology-platform/managing-entitlements-and-quotas-using-the-cockpit",
+    "https://help.sap.com/docs/btp/btp-admin-and-ops-neo/entitlements-api",
+    "https://help.sap.com/docs/btp/sap-business-technology-platform/subscribe-to-multitenant-applications-using-the-cockpit",
+    "https://help.sap.com/docs/btp/sap-business-technology-platform/account-administration-using-apis-of-the-sap-cloud-management-service",
+    "https://help.sap.com/docs/btp/sap-business-technology-platform/monitoring-usage-information-using-apis-of-the-sap-usage-data-management-service",
+    "https://help.sap.com/docs/btp/sap-business-technology-platform/global-account-administration"
+  ],
+  "security_notes": "Mutating operations are gated behind the 17-step sequence with mandatory dual approval (platform-owner plus FinOps). Never execute an entitlement assignment, quota change, or subscription modification before step 13 dual approval gate is cleared. Never accept self-approval (SoD: requester must differ from both platform owner and FinOps approver). FinOps approval is a hard gate for all entitlement increases — technical necessity does not override it. A cost-impact assessment (step 9 diff) must be produced before any increase is executed. Never use global account administrator credentials where an Entitlements Administrator role is sufficient. Never hardcode service keys, OAuth tokens, or cockpit session credentials in any output. Refuse any request to skip steps or increase entitlements without documented FinOps approval.",
+  "last_verified": "2026-06-19",
+  "path": "skills/sap/sap-guarded-btp-entitlement-change",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "lifecycle": "experimental",
+  "execution_tier": "mutating-runtime"
+}