@raishin/vanguard-frontier-agentic 2.10.0 → 2.13.0

package/skills/sap/sap-cap-architecture-review/metadata.json

@@ -0,0 +1,34 @@
+{
+  "id": "sap-cap-architecture-review",
+  "name": "SAP CAP Architecture Review",
+  "type": "skill",
+  "provider": "sap",
+  "harnesses": [
+    "claude-code",
+    "codex",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review SAP Cloud Application Programming Model (CAP) applications for CDS modeling quality, service layer design, authorization correctness (@requires/@restrict), multitenancy architecture, draft handling, and test coverage. Does not access live systems.",
+  "source_type": "original",
+  "category": "architecture",
+  "official_docs": [
+    "https://cap.cloud.sap/docs/guides/security/authorization",
+    "https://cap.cloud.sap/docs/guides/providing-services",
+    "https://cap.cloud.sap/docs/guides/multitenancy/",
+    "https://cap.cloud.sap/docs/guides/fiori/draft-support",
+    "https://cap.cloud.sap/docs/guides/testing/",
+    "https://cap.cloud.sap/docs/cds/cdl",
+    "https://help.sap.com/docs/btp/sap-business-technology-platform/sap-cloud-application-programming-model",
+    "https://cap.cloud.sap/docs/node.js/cds-facade",
+    "https://cap.cloud.sap/docs/java/security"
+  ],
+  "security_notes": "Does not access live CAP applications, BTP subaccounts, HANA databases, or deployment pipelines. Accepts only user-provided CDS source files, service handler code, package.json, test files, or written descriptions. Never request or accept BTP service keys, HANA credentials, OAuth client secrets, or subaccount tenant IDs. Authorization findings (missing @requires/@restrict) must be validated against the deployed CAP runtime version before remediation.",
+  "last_verified": "2026-06-19",
+  "path": "skills/sap/sap-cap-architecture-review",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "lifecycle": "experimental"
+}

package/skills/sap/sap-cap-architecture-review/references/context7-framework-docs.md

@@ -0,0 +1,89 @@
+# Context7 framework docs — SAP CAP Architecture Review
+
+**Role**: supplementary. Official SAP CAP documentation at cap.cloud.sap is the primary source for all architecture guidance. Context7-sourced CAP documentation supplements with code-level examples and implementation detail for authorization, multitenancy, and draft patterns.
+
+**Library used**: SAP Cloud Application Programming Model (CAP)
+Context7 library ID: `/websites/cap_cloud_sap`
+Lookup targets: CDS service authorization (@requires/@restrict), multitenancy extensibility, CAP draft handling, CDS modeling patterns
+Skill: `sap-cap-architecture-review`
+Classification: supplementary — strongly applies for this skill
+
+---
+
+## CAP @requires — service-level authorization (supplementary)
+
+Source: cap.cloud.sap (Context7 `/websites/cap_cloud_sap`)
+Reference: https://cap.cloud.sap/docs/guides/security/remote-authentication
+
+The `@requires` annotation on a CDS service restricts access to callers holding a specified role. This works for both user-facing and App-2-App (technical user) flows.
+
+```cds
+using { sap.capire.flights.data as data } from './data-service';
+
+annotate data with @(requires: 'data-consumer');
+```
+
+A service with no `@requires` annotation is accessible without role restriction. In App-2-App IAS flows, the role is derived from the IAS API identifier registered with the service.
+
+**Relevance**: Use this pattern to assess whether externally exposed CAP services have role-based guards and to classify services missing `@requires` as critical or high findings depending on exposure scope.
+
+---
+
+## CAP @restrict — entity-level fine-grained access control (supplementary)
+
+Source: cap.cloud.sap (Context7 `/websites/cap_cloud_sap`)
+Reference: https://cap.cloud.sap/docs/guides/security/authorization
+
+`@restrict` provides operation-level, role-specific, and instance-level access control on CDS service entities and actions. It is preferred over `@requires` for entities containing sensitive business data.
+
+```cds
+service CustomerService @(requires: 'authenticated-user') {
+  entity Products @(restrict: [
+    { grant: 'READ' },
+    { grant: 'WRITE', to: 'Vendor' },
+    { grant: 'addRating', to: 'Customer'}
+  ]) {/*...*/}
+  actions {
+     action addRating (stars: Integer);
+  }
+  entity Orders @(restrict: [
+    { grant: '*', to: 'Customer', where: (CreatedBy = $user) }
+  ]) {/*...*/}
+  action monthlyBalance @(requires: 'Vendor') ();
+}
+```
+
+Key patterns:
+- `grant: 'READ'` without `to:` allows any authenticated user to read (matches service-level `@requires`).
+- `grant: 'WRITE', to: 'Vendor'` restricts write operations to the `Vendor` role.
+- `where: (CreatedBy = $user)` restricts instance access — each customer sees only their own orders.
+- CAP runtime enforces `@restrict` server-side before any resource access.
+
+**Relevance**: The central annotation model for entity-level security review. Use to assess whether `where` clauses are present for tenant-scoped or user-scoped data, whether write operations are role-restricted, and whether actions have explicit authorization guards.
+
+---
+
+## CAP default authorization stance (supplementary)
+
+Source: cap.cloud.sap (Context7 `/websites/cap_cloud_sap`)
+Reference: https://cap.cloud.sap/docs/guides/security/data-protection
+
+> By default, CAP services and entities are not authorized, requiring developers to design and test access rules.
+
+The CAP runtime guarantees server-side enforcement only after authorization annotations are explicitly declared. The absence of `@requires` or `@restrict` on a service or entity means no authorization enforcement — not a default-deny posture.
+
+**Relevance**: This is the foundational reason why missing annotations are a critical or high finding. The default is permissive, not restrictive. Every service and entity exposed to external callers must have explicit annotation coverage.
+
+---
+
+## Scope boundaries for Context7 usage
+
+Context7 CAP documentation applies to all CAP review domains in this skill:
+
+- **Authorization** (`@requires`, `@restrict`, `where` clauses): directly applicable
+- **CDS Modeling** (entity/service definitions, projection patterns): directly applicable
+- **Multitenancy** (MTX wiring, extensibility activation): applicable for `cds add extensibility` and `@sap/cds-mtxs` patterns
+- **Draft Handling**: applicable for `draftActivate` and `BeforeSave` handler patterns
+- **Testing**: applicable for `cds.test` setup and mock authentication patterns
+
+Always label Context7-sourced guidance as `context7-supplementary` in responses. For runtime version-specific behavior (e.g., `@sap/cds` 7.x vs 8.x), direct the user to verify against the official cap.cloud.sap changelog.

package/skills/sap/sap-cap-architecture-review/references/official-sources.md

@@ -0,0 +1,93 @@
+# Official sources — SAP CAP Architecture Review
+
+Use this reference when grounding CAP CDS modeling guidance, service authorization, multitenancy design, draft handling, and CAP testing patterns.
+
+**Evidence level**: documentation-based (SAP CAP documentation at cap.cloud.sap, SAP Help Portal). No live-system evidence is collected by this skill.
+
+## CAP authorization
+
+- SAP CAP Authorization Guide
+  https://cap.cloud.sap/docs/guides/security/authorization
+  source_owner: SAP SE
+  topic_supported: @requires and @restrict annotations, role-based access control, instance-level restrictions, where clauses, user attribute enforcement, CAP runtime authorization enforcement behavior
+  why_needed: Primary source for classifying authorization gaps in CAP service and entity definitions; defines when a service or entity is unguarded
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- SAP CAP Security — Data Protection and Privacy
+  https://cap.cloud.sap/docs/java/security
+  source_owner: SAP SE
+  topic_supported: CAP Java security integration, Spring Security wiring, token-based authentication, data privacy annotations
+  why_needed: Java-stack authorization specifics that differ from Node.js CAP runtime behavior
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## CDS modeling and service layer
+
+- SAP CAP Providing Services Guide
+  https://cap.cloud.sap/docs/guides/providing-services
+  source_owner: SAP SE
+  topic_supported: CDS service definitions, projection patterns, auto-exposed entities, action and function definitions, service layer separation of concerns
+  why_needed: Authoritative source for service design patterns, projection anti-patterns, and correct entity exposure
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- CDS Definition Language (CDL) Reference
+  https://cap.cloud.sap/docs/cds/cdl
+  source_owner: SAP SE
+  topic_supported: CDS syntax for entities, associations, compositions, aspects, annotations, views, and projections
+  why_needed: Reference for assessing CDS model correctness, association direction, and annotation validity
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Multitenancy
+
+- SAP CAP Multitenancy Guide
+  https://cap.cloud.sap/docs/guides/multitenancy/
+  source_owner: SAP SE
+  topic_supported: MTX service setup, @sap/cds-mtxs configuration, tenant onboarding/offboarding, extensibility service wiring, subscriber passcode, tenant upgrade
+  why_needed: Defines multitenancy architecture requirements for CAP SaaS applications; used to classify MTX wiring gaps
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Draft handling
+
+- SAP CAP Draft Support Guide
+  https://cap.cloud.sap/docs/guides/fiori/draft-support
+  source_owner: SAP SE
+  topic_supported: Draft-enabled entities, draftActivate hook, BeforeSave validation, side effects, draft lock expiry, cancel behavior, Fiori Elements draft lifecycle
+  why_needed: Defines correct draft implementation patterns; used to identify incomplete draft activation logic and missing side-effect handlers
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Testing
+
+- SAP CAP Testing Guide
+  https://cap.cloud.sap/docs/guides/testing/
+  source_owner: SAP SE
+  topic_supported: cds.test setup, Jest integration, mock authentication, CDS test environment, in-memory SQLite testing, beforeAll/afterAll teardown patterns
+  why_needed: Defines CAP-specific testing patterns; used to classify test isolation gaps and missing test teardown
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## BTP deployment
+
+- SAP BTP — SAP Cloud Application Programming Model
+  https://help.sap.com/docs/btp/sap-business-technology-platform/sap-cloud-application-programming-model
+  source_owner: SAP SE
+  topic_supported: CAP on BTP — MTA deployment, service bindings, environment profile configuration, BTP-specific package.json cds block settings
+  why_needed: BTP deployment configuration requirements including profile wiring and service binding completeness
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- SAP CAP Node.js cds Facade API Reference
+  https://cap.cloud.sap/docs/node.js/cds-facade
+  source_owner: SAP SE
+  topic_supported: cds.requires, cds.env, cds.model, service registration, event handler wiring — runtime configuration API
+  why_needed: Used to assess package.json cds block correctness and runtime configuration anti-patterns (e.g., direct db handle access)
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Grounding rule
+
+SAP CAP documentation describes design intent and recommended patterns. It does not prove which CDS annotations are enforced in a specific CAP runtime version deployed in the user's BTP subaccount, or whether the user's MTX configuration has been correctly activated. Users must supply CDS source files, handler code, package.json, and test files for concrete assessment.

package/skills/sap/sap-cap-architecture-review/references/safety-checklist.md

@@ -0,0 +1,37 @@
+# Safety checklist — SAP CAP Architecture Review
+
+Use before making any finding or remediation recommendation, especially for authorization and multitenancy findings.
+
+## Non-negotiables
+
+- Do not access, connect to, or request access to any live CAP application, BTP subaccount, HANA database, or deployment pipeline. This skill reviews artifacts only.
+- Do not accept or request BTP service keys, HANA credentials, OAuth client secrets, IAS application IDs, or subaccount tenant IDs.
+- Do not recommend `@requires: 'any'` as a security baseline. In some CAP runtime configurations this allows unauthenticated access.
+- Do not validate runtime authorization behavior from memory alone. Direct the user to verify annotation enforcement against the deployed CAP runtime version and `@sap/cds` package version in their package.json.
+- Do not conflate CAP Node.js and CAP Java authorization behavior. The `@restrict` enforcement rules and Spring Security integration differ between runtimes.
+- Do not make multitenancy compliance declarations without user-provided MTX configuration evidence. Missing MTX wiring cannot be confirmed from CDS models alone.
+- Do not classify a service as properly secured based on `@requires` alone if the service contains entities or actions with sensitive write operations — entity-level `@restrict` must also be checked.
+
+## What people get wrong
+
+- **`@requires` on service ≠ full authorization coverage**: A `@requires: 'authenticated-user'` on the service grants access to all entities within it to any authenticated user. Entity-level `@restrict` is needed for fine-grained control.
+- **Treating `cds.db.run()` as safe**: Direct database access via `cds.db` in service handlers bypasses CAP authorization enforcement. All data access should go through CAP service calls unless there is an explicit and reviewed reason.
+- **Assuming SQLite tests validate HANA behavior**: CAP in-memory SQLite tests do not catch HANA-specific SQL features, views with parameters, or HANA native procedures. Production HANA validation requires a HANA target.
+- **Draft-enabled entities assumed to self-validate**: CAP draft support does not automatically validate business rules on activation. `draftActivate` and `BeforeSave` handlers must be implemented explicitly.
+- **Extensibility service open by default**: `cds add extensibility` enables the extensibility service endpoint, but role enforcement (`cds.ExtensionDeveloper`) must be verified. An open extensibility endpoint in a SaaS app is a critical finding.
+- **Multitenancy configuration assumed complete from `cds.requires.multitenancy: true`**: This flag alone does not wire tenant onboarding, upgrade, or offboarding. The full MTX lifecycle must be explicitly confirmed in the `@sap/cds-mtxs` configuration.
+
+## When to push back
+
+- Push back when the user asks to confirm authorization correctness without providing CDS service and entity definitions.
+- Push back when the user proposes bypassing CAP authorization by querying the database directly in a handler.
+- Push back when multitenancy is in scope but no MTX configuration or package.json is provided.
+- Push back when the request involves live CAP runtime access or BTP deployment execution — this skill is advisory only.
+- Push back when the user proposes `@requires: 'any'` as a security pattern for externally exposed services.
+
+## Evidence labels
+
+- `documentation-based` — grounded in official SAP CAP docs (cap.cloud.sap) or SAP Help Portal
+- `user-provided evidence` — CDS files, handler code, package.json, test files, or descriptions provided by the user
+- `context7-supplementary` — CAP authorization, multitenancy, or draft patterns sourced from Context7 (supplementary to official SAP CAP docs)
+- `inference` — derived reasoning not directly confirmed; must always be labeled as such

package/skills/sap/sap-cap-architecture-review/references/workflow-and-output.md

@@ -0,0 +1,74 @@
+# Workflow and output contract — SAP CAP Architecture Review
+
+Use this reference for all classification, severity assignment, and output formatting.
+
+## Review domain taxonomy
+
+| Domain | Scope |
+|--------|-------|
+| `CDS Modeling` | Entity definitions, associations, compositions, projections, aspects, annotations, view correctness |
+| `Service Layer` | Service definition quality, action/function design, projection completeness, bypass patterns |
+| `Authorization` | @requires and @restrict annotation coverage, role design, where-clause correctness, unguarded endpoints |
+| `Multitenancy` | MTX service wiring, tenant lifecycle hooks, extensibility activation, subscriber passcode |
+| `Draft Handling` | Draft-enabled entity completeness, draftActivate hooks, BeforeSave validation, side effects, cancel |
+| `Testing` | cds.test setup, mock authentication, test isolation, CDS environment teardown, coverage |
+| `Deployment Config` | package.json cds block, BTP profile wiring, service bindings, MTA descriptor completeness |
+
+## Severity classification
+
+| Severity | Meaning | Examples |
+|----------|---------|---------|
+| `critical` | Security breach or data integrity loss risk | Unguarded service with no @requires; exposed action with no authorization check |
+| `high` | Functional or operational correctness failure | Incomplete draftActivate implementation; missing MTX tenant lifecycle hook; direct DB access bypassing service layer |
+| `medium` | Governance, maintainability, or isolation gap | Service-level @requires only with no entity-level @restrict on sensitive entities; test not using in-memory SQLite |
+| `low` | Best practice deviation or code quality concern | Missing @readonly on projection-only field; inconsistent CDS naming conventions |
+
+## Workflow
+
+1. **Receive artifacts** — CDS model files, service handler code, package.json, test files, MTX configuration, 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 to add, handler method to implement, configuration key to set, test pattern to adopt.
+6. **Prioritize** — critical and high severity first; authorization findings before structural findings; multitenancy gaps before testing gaps.
+7. **Return output** per the output contract below.
+
+## Common finding patterns
+
+### Authorization
+- Service exposed with no `@requires` annotation (critical if externally reachable)
+- Entity action with no `@restrict` or role check (critical for write operations)
+- `@requires: 'any'` used on sensitive services (high — equivalent to unauthenticated access in some CAP versions)
+- Missing `where` clause on `@restrict` for tenant-scoped data (high for multitenant apps)
+
+### CDS Modeling
+- `up_` associations exposed in projection service (medium — internal navigation leaked)
+- `SELECT *` projection without field-level `@readonly` on computed fields (low)
+- Missing `@assert.unique` on business key fields (medium)
+- Composition of aspects without `@mandatory` on required fields (low)
+
+### Multitenancy
+- `cds.requires.multitenancy: true` set but `@sap/cds-mtxs` not in dependencies (high)
+- Tenant upgrade hook (`/-/cds/saas-provisioning/upgrade`) not wired (high)
+- Extensibility service activated without `cds.ExtensionDeveloper` role enforcement (critical)
+
+### Draft Handling
+- Draft-enabled entity with no `draftActivate` event handler (high)
+- Missing `BeforeSave` validation handler (high for transactional correctness)
+- Draft lock expiry not configured (medium)
+
+### Testing
+- Integration test using shared `cds.test` instance without `afterAll` teardown (medium)
+- Mock authentication (`{ auth: { kind: 'mocked' } }`) not used in unit tests against auth-protected services (medium)
+- No test coverage for CAP actions and functions (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 (annotation text, handler method signature, configuration key, or test pattern)
+4. Authorization summary — list of services and entities with their access control coverage
+5. Prioritized remediation sequence (critical → high → medium → low)
+6. Escalation trigger if live CAP runtime or BTP inspection is required before proceeding

package/skills/sap/sap-clean-core-debt-review/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: sap-clean-core-debt-review
+description: Review SAP custom code, modifications, and extensibility debt against the SAP Clean Core standard. Use when assessing custom ABAP, implicit enhancements, customer modifications, or legacy Z/Y code for remediation toward released APIs, ABAP Cloud, RAP objects, key-user extensibility, or developer extensibility on BTP. 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: architecture
+  lifecycle: experimental
+---
+
+# SAP Clean Core Debt Review
+
+## Purpose
+
+Assess the clean core compliance posture of SAP custom code, customer modifications, and extensibility debt. Surface which customizations violate clean core principles, classify them by remediation path (released API, ABAP Cloud object, RAP business object, key-user extensibility, developer extensibility on BTP CAP/RAP, or retire), and recommend a prioritized remediation plan. Does not touch or read live systems.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- audit Z/Y custom ABAP programs, function modules, or classes for clean core compliance,
+- assess customer modifications (`CMOD`/`ENH`/user exits/implicit enhancements/substitutions) against the clean core standard,
+- identify which custom objects use deprecated or non-released SAP APIs,
+- plan remediation of custom code toward released APIs, ABAP Cloud whitelisted objects, or SAP RAP/CAP extensibility patterns,
+- understand the difference between key-user extensibility (in-app) and developer extensibility (side-by-side on BTP),
+- evaluate the clean core compliance impact of an S/4HANA upgrade or migration to S/4HANA Cloud.
+
+## When not to use
+
+- When the user needs live system inspection of custom code — use `sap-live-readonly-landscape-discovery` first to enumerate objects, then return here for advisory review.
+- When the request is about transport mechanics — use `sap-guarded-transport-import`.
+- When the request is about BTP infrastructure provisioning rather than ABAP extensibility patterns.
+
+## Does not touch live systems
+
+This skill operates on code artifacts, architecture documents, upgrade reports (e.g., SAP Readiness Check, ABAP Test Cockpit results, custom code migration app output), or user-provided descriptions. It does not connect to any SAP system, run SE38/SE84 searches, read from BTP cockpit, or invoke ABAP Test Cockpit programmatically. All live enumeration is out of scope.
+
+## Lean operating rules
+
+- Classify first. Every custom object must be classified by clean core violation type before a remediation path is proposed.
+- Use official SAP clean core taxonomy. The four extensibility pillars are: (1) in-app key-user, (2) in-app developer (BAdI/released API), (3) side-by-side developer (BTP CAP/RAP), (4) partner/ISV extensions.
+- Do not recommend deprecated paths. Implicit enhancements, `CALL CUSTOMER FUNCTION`, and customer includes in standard SAP objects are deprecated extensibility patterns. Do not propose them as remediation targets.
+- Separate upgrade risk from clean core debt. Objects that block upgrade (compatibility-level `NOT_RELEASED`) must be distinguished from objects that are technically functional but architecturally non-compliant.
+- Released API = C1 contract. Only ABAP objects with release contract `C1` (use system-internally permitted) or `C2` (use in customer namespace permitted) are clean-core-compliant extensibility entry points.
+- RAP is the preferred ABAP Cloud extensibility layer. For new transactional extensions on S/4HANA Cloud, ABAP RESTful Application Programming Model (RAP) is the strategic direction.
+- CAP is supplementary for side-by-side. SAP Cloud Application Programming Model (CAP) applies for side-by-side extensions on BTP — not for in-system ABAP extensions.
+- Evidence from official SAP sources takes precedence over memory or training data.
+- Load only the reference needed for the component in scope.
+
+## Evidence rules
+
+Label all claims with one of:
+
+- `documentation-based` — grounded in SAP Clean Core docs, ABAP Cloud docs, or S/4HANA extensibility guides
+- `user-provided evidence` — code snippets, upgrade reports, or custom code lists provided by the user
+- `context7-supplementary` — grounded in CAP/RAP framework docs fetched from Context7 (supplementary to official SAP docs)
+- `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 credential, API call, RFC connection, or ABAP system access in this skill's execution path. Users must supply code artifacts, upgrade report output, ABAP Test Cockpit results, or written descriptions of custom objects for this skill to review.
+
+## References
+
+Load only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — classification taxonomy, remediation paths, output format.
+- [Safety checklist](references/safety-checklist.md) — non-negotiables, common mistakes, when to push back.
+- [Official sources](references/official-sources.md) — SAP Clean Core docs, ABAP Cloud, RAP, S/4HANA extensibility.
+- [Context7 framework docs](references/context7-framework-docs.md) — CAP extensibility patterns (supplementary; use for BTP side-by-side guidance).
+
+## Response minimum
+
+Return, at minimum:
+
+- **Problem classification**: clean core violation type(s) and affected object(s).
+- **Evidence used**: documentation-based / user-provided / context7-supplementary / inference.
+- **Risk level**: upgrade-blocking / clean-core-non-compliant / compliant.
+- **Recommended action**: remediation path per object class (released API, ABAP Cloud RAP, key-user, side-by-side CAP, retire).
+- **Refusal / escalation triggers**: if live object inspection is needed, escalate to `sap-live-readonly-landscape-discovery` first.
+- **Business impact**: upgrade risk, cloud readiness, maintenance overhead.
+- **Next verification step**: validate remediation candidates against current SAP API Business Hub release contracts.

package/skills/sap/sap-clean-core-debt-review/agents/openai.yaml

@@ -0,0 +1,11 @@
+interface:
+  display_name: "SAP Clean Core Debt Review"
+  short_description: "Review SAP custom code and modification debt against Clean Core; classify violations and recommend remediation toward released APIs, ABAP Cloud RAP, or BTP side-by-side extensibility"
+  default_prompt: "Use $sap-clean-core-debt-review to classify SAP custom code or modification debt against the Clean Core standard. Identify violation type, release contract status, and recommended remediation path (released API, ABAP Cloud RAP object, key-user extensibility, side-by-side BTP CAP, or retire). State evidence level and upgrade-risk classification for each object reviewed."
+dependencies:
+  tools:
+    - type: "web"
+      value: "https://api.sap.com/"
+      description: "SAP API Business Hub — verify release contracts (C1/C2) and released API availability for custom code remediation candidates"
+policy:
+  allow_implicit_invocation: true

package/skills/sap/sap-clean-core-debt-review/metadata.json

@@ -0,0 +1,33 @@
+{
+  "id": "sap-clean-core-debt-review",
+  "name": "SAP Clean Core Debt Review",
+  "type": "skill",
+  "provider": "sap",
+  "harnesses": [
+    "claude-code",
+    "codex",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review SAP custom code and modification debt against the Clean Core standard; classify violations and recommend remediation toward released APIs, ABAP Cloud RAP objects, key-user extensibility, or side-by-side BTP CAP extensions. Does not access live systems.",
+  "source_type": "original",
+  "category": "architecture",
+  "official_docs": [
+    "https://help.sap.com/docs/abap-cloud/abap-cloud/what-is-abap-cloud",
+    "https://help.sap.com/docs/abap-cloud/abap-cloud/clean-core-extensibility",
+    "https://help.sap.com/docs/abap-cloud/abap-rap/abap-restful-application-programming-model",
+    "https://help.sap.com/docs/abap-cloud/abap-cloud/released-apis",
+    "https://help.sap.com/docs/abap-cloud/abap-cloud/key-user-extensibility",
+    "https://help.sap.com/docs/abap-cloud/abap-cloud/abap-test-cockpit",
+    "https://api.sap.com/products/SAPS4HANACloud/overview",
+    "https://help.sap.com/docs/abap-cloud/abap-cloud/side-by-side-extensibility-on-btp"
+  ],
+  "security_notes": "Does not access live SAP systems. Accepts only user-provided code artifacts, upgrade report output, or written object descriptions. Never request or accept system credentials, client secrets, RFC destinations, or BTP service keys. Remediation recommendations must be validated against current SAP API Business Hub release contracts before implementation.",
+  "last_verified": "2026-06-19",
+  "path": "skills/sap/sap-clean-core-debt-review",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "lifecycle": "experimental"
+}

package/skills/sap/sap-clean-core-debt-review/references/context7-framework-docs.md

@@ -0,0 +1,56 @@
+# Context7 framework docs — SAP Clean Core Debt Review
+
+**Role**: supplementary. Official SAP documentation (SAP Help Portal, ABAP Cloud docs, API Business Hub) is the primary source for all clean core compliance guidance. Context7-sourced CAP documentation supplements guidance for side-by-side BTP extensibility patterns only.
+
+**Library used**: SAP Cloud Application Programming Model (CAP)
+Context7 library ID: `/websites/cap_cloud_sap`
+Lookup target: SAP CAP extensibility, intrinsic extensibility, cds.ExtensionDeveloper, SaaS customer adaptation
+Skill: `sap-clean-core-debt-review`
+Classification: supplementary
+
+---
+
+## CAP intrinsic extensibility (supplementary)
+
+Source: cap.cloud.sap (Context7 `/websites/cap_cloud_sap`)
+
+CAP offers intrinsic extensibility allowing SaaS customers, verticalization partners, or teams to add/override annotations, translations, initial data, extension fields, entities, relationships, and custom logic. Extensions can be bundled as reuse extension packages and feature-toggled per tenant, using the same techniques as in regular projects (CDS Aspects and Event Handlers).
+
+**Relevance to clean core debt review**: When a custom ABAP side-by-side requirement maps to a BTP extension, CAP intrinsic extensibility is the relevant BTP-side pattern for SaaS multi-tenant scenarios. This supplements the SAP Help Portal guidance on side-by-side developer extensibility.
+
+## CAP extensibility service (supplementary)
+
+Source: cap.cloud.sap (Context7 `/websites/cap_cloud_sap`)
+
+The `cds.ExtensibilityService` (internal CAP service) requires `cds.ExtensionDeveloper` role. Extension upload and activation are separate operations:
+
+- `PUT /-/cds/extensibility/Extensions/<id>` — uploads extension as draft (status 1) or activates (status 2)
+- Requires authentication as internal technical user or `cds.ExtensionDeveloper` technical role
+
+**Relevance**: When recommending CAP as a side-by-side extensibility target, the user must be aware of the `cds.ExtensionDeveloper` role requirement and the draft/activation lifecycle — especially for SaaS tenant extensions.
+
+## Enabling CAP extensibility (supplementary)
+
+Source: cap.cloud.sap (Context7 `/websites/cap_cloud_sap`)
+
+```bash
+cds add extensibility
+npm add @sap/cds-mtxs
+```
+
+The `@sap/cds-mtxs` package enables multi-tenancy and extensibility features. Run `cds add extensibility` to automate adding the package and setting `cds.requires.extensibility: true` in `package.json`.
+
+**Relevance**: Guidance for users implementing CAP-based side-by-side extensions as a clean core remediation path.
+
+---
+
+## Scope boundaries for Context7 usage
+
+Context7 CAP documentation applies **only** to the side-by-side BTP CAP remediation path (step 5 in the remediation decision tree). It does not apply to:
+
+- In-system ABAP Cloud or RAP guidance (use SAP Help Portal for ABAP Cloud and ABAP RAP)
+- Key-user extensibility (use SAP Help Portal)
+- Release contract validation (use SAP API Business Hub)
+- Upgrade risk assessment (use SAP Help Portal)
+
+Always label Context7-sourced guidance as `context7-supplementary` in responses.

package/skills/sap/sap-clean-core-debt-review/references/official-sources.md

@@ -0,0 +1,75 @@
+# Official sources — SAP Clean Core Debt Review
+
+Use this reference when grounding clean core compliance assessment, ABAP Cloud patterns, RAP extensibility, and S/4HANA upgrade risk.
+
+**Evidence level**: documentation-based (SAP Help Portal, SAP API Business Hub). No live-system evidence is collected by this skill.
+
+## SAP Clean Core and extensibility
+
+- What is ABAP Cloud
+  https://help.sap.com/docs/abap-cloud/abap-cloud/what-is-abap-cloud
+  source_owner: SAP SE
+  topic_supported: ABAP Cloud programming model overview, tier structure, object release status
+  why_needed: Defines the ABAP Cloud programming model that governs what is and is not permitted in clean core compliant custom code
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- Clean Core extensibility — extensibility overview and pillars
+  https://help.sap.com/docs/abap-cloud/abap-cloud/clean-core-extensibility
+  source_owner: SAP SE
+  topic_supported: Clean Core definition, extensibility pillars (in-app key-user, in-app developer, side-by-side), compliance posture
+  why_needed: Primary taxonomy for classifying custom code violations and remediation paths
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- ABAP RESTful Application Programming Model (RAP)
+  https://help.sap.com/docs/abap-cloud/abap-rap/abap-restful-application-programming-model
+  source_owner: SAP SE
+  topic_supported: RAP business objects, behavior definitions, CDS views, OData exposure — the strategic S/4HANA extensibility layer
+  why_needed: Authoritative source for ABAP Cloud / RAP remediation paths
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- Released APIs in ABAP Cloud
+  https://help.sap.com/docs/abap-cloud/abap-cloud/released-apis
+  source_owner: SAP SE
+  topic_supported: C1/C2 released API catalog for ABAP Cloud, release contract types, API browser usage
+  why_needed: Defines released API contract types and consumption rules for in-app developer extensibility boundary
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- Key-user extensibility in ABAP Cloud
+  https://help.sap.com/docs/abap-cloud/abap-cloud/key-user-extensibility
+  source_owner: SAP SE
+  topic_supported: Key-user apps for fields, logic, forms, workflows without custom ABAP
+  why_needed: Defines the no-code/low-code in-app extensibility path as a clean core compliant alternative
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- ABAP Test Cockpit in ABAP Cloud
+  https://help.sap.com/docs/abap-cloud/abap-cloud/abap-test-cockpit
+  source_owner: SAP SE
+  topic_supported: ABAP Test Cockpit (ATC) check categories for clean core compliance; used to interpret ATC output supplied by the user
+  why_needed: Provides the ATC finding taxonomy this skill uses to classify user-provided ATC results
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- SAP API Business Hub — SAP S/4HANA Cloud product overview and released APIs
+  https://api.sap.com/products/SAPS4HANACloud/overview
+  source_owner: SAP SE
+  topic_supported: C1/C2 released API catalog for S/4HANA Cloud, BTP services; used to validate remediation candidates
+  why_needed: Authoritative source for confirming which SAP APIs carry a C1 or C2 release contract for clean core compliant consumption
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- Side-by-side extensibility on SAP BTP
+  https://help.sap.com/docs/abap-cloud/abap-cloud/side-by-side-extensibility-on-btp
+  source_owner: SAP SE
+  topic_supported: BTP side-by-side extension patterns using CAP, APIs, events; when side-by-side is appropriate vs. in-app extensibility
+  why_needed: Defines the clean-core-compliant side-by-side remediation path for custom code that cannot be addressed within in-app extensibility constraints
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Grounding rule
+
+SAP Help Portal and API Business Hub documentation describe design intent and release contracts. They do not prove which objects exist in the user's ABAP system, what their current release status is in that system version, or whether the user's landscape has applied the relevant SAP notes. Users must supply ATC reports, custom code migration app output, or object lists for concrete assessment.

package/skills/sap/sap-clean-core-debt-review/references/safety-checklist.md

@@ -0,0 +1,36 @@
+# Safety checklist — SAP Clean Core Debt Review
+
+Use before making any remediation recommendation, especially for upgrade-blocking or business-critical custom objects.
+
+## Non-negotiables
+
+- Do not access, connect to, or request access to any live SAP system. This skill reviews artifacts only.
+- Do not accept or request SAP system credentials, RFC destinations, BTP service keys, client secrets, or OAuth tokens.
+- Do not propose implicit enhancements, customer modifications, or `CALL CUSTOMER FUNCTION` as remediation targets. These are deprecated extensibility patterns.
+- Do not recommend consuming NOT_RELEASED SAP APIs as a remediation step. Only C1/C2 released APIs are clean core compliant.
+- Do not validate release contract status from memory alone. Direct the user to verify on SAP API Business Hub for each proposed released API.
+- Do not conflate ABAP Cloud (in-system) with BTP CAP (side-by-side). They serve different use cases and have different deployment models.
+- Do not make upgrade-blocking declarations for objects the user has not provided. Only classify objects that appear in user-provided artifacts.
+
+## What people get wrong
+
+- **Recommending `EXIT_*` or user exits as a migration target**: User exits (`CALL CUSTOMER FUNCTION`) are the source of the problem, not a valid remediation. The migration target is a new ABAP Objects BAdI.
+- **Treating all Z-objects as clean core violations**: A Z-program that only consumes C1/C2 released APIs and uses no SAP internal objects is clean core compliant.
+- **Confusing key-user extensibility with developer extensibility**: Key-user extensibility is configuration-based (no ABAP). Developer extensibility requires ABAP Cloud or side-by-side BTP development.
+- **Skipping API Business Hub validation**: Proposing a released API without verifying its C1/C2 contract on api.sap.com may lead the user to consume an API that is not actually released for their S/4HANA version.
+- **Ignoring system version**: Clean core requirements and released API availability differ between S/4HANA on-premise, S/4HANA Cloud (RISE), and S/4HANA Cloud Public Edition. Always confirm with the user which deployment model is in scope.
+- **Recommending CAP for in-system ABAP logic**: SAP CAP (Node.js/Java) runs on BTP, not inside the ABAP system. It cannot replace in-system ABAP business logic directly — it creates a side-by-side process.
+
+## When to push back
+
+- Push back when the user asks to "just leave the modification" without understanding upgrade risk.
+- Push back when the user proposes a remediation that itself uses NOT_RELEASED APIs.
+- Push back when the artifact is unavailable and the user asks for a compliance ruling from memory alone.
+- Push back when the request involves live object inspection — redirect to `sap-live-readonly-landscape-discovery` first.
+
+## Evidence labels
+
+- `documentation-based` — grounded in SAP Clean Core docs, ABAP Cloud docs, or S/4HANA extensibility guides
+- `user-provided evidence` — code snippets, ATC output, custom code migration app results provided by the user
+- `context7-supplementary` — CAP/RAP framework patterns from Context7 (supplementary to official SAP docs)
+- `inference` — derived reasoning not directly confirmed; must always be labeled as such