@raishin/vanguard-frontier-agentic 2.11.0 → 2.13.0

package/skills/sap/sap-analytics-cloud-planning-governance/references/official-sources.md

@@ -0,0 +1,89 @@
+# Official sources — SAP Analytics Cloud Planning Governance Review
+
+Use this reference when grounding SAC story design, planning model governance, data action review, allocation assessment, connection type evaluation, data access control audit, and performance posture review.
+
+**Evidence level**: documentation-based (SAP Analytics Cloud Help Portal). No live-system evidence is collected by this skill.
+
+## Stories and models
+
+- Stories in SAP Analytics Cloud
+  https://help.sap.com/docs/sap-analytics-cloud/sap-analytics-cloud/stories
+  source_owner: SAP SE
+  topic_supported: Story design, page layout, widget types, filter configuration, model binding, calculated measures in stories
+  why_needed: Primary reference for classifying story design findings including widget-to-model binding correctness, filter scope, and story-level performance governance
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Planning models
+
+- Planning models in SAP Analytics Cloud
+  https://help.sap.com/docs/sap-analytics-cloud/sap-analytics-cloud/planning-models
+  source_owner: SAP SE
+  topic_supported: Planning model creation, version category structure (actual, budget, forecast, rolling forecast), account dimension, date dimension, measure definition, model locking
+  why_needed: Defines the planning model structure — required to classify version category design gaps, dimension configuration errors, and missing version locking as planning integrity findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Data actions
+
+- Data actions in SAP Analytics Cloud
+  https://help.sap.com/docs/sap-analytics-cloud/sap-analytics-cloud/data-actions
+  source_owner: SAP SE
+  topic_supported: Data action step types (Advanced Formula, copy, allocation, date-based distribution), step sequencing, trigger configuration, multi-action orchestration
+  why_needed: Defines the data action execution model — required to classify step sequencing errors, incorrect scope definitions, and missing trigger configuration as planning pipeline findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Allocations
+
+- Allocations in SAP Analytics Cloud
+  https://help.sap.com/docs/sap-analytics-cloud/sap-analytics-cloud/allocations
+  source_owner: SAP SE
+  topic_supported: Allocation methods (spread, distribution, breakback), driver dimension selection, allocation hierarchy scope, allocation result validation
+  why_needed: Defines the allocation step model — required to classify incorrect allocation method selection, unbounded hierarchy scope, and missing validation as planning process findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Connections
+
+- Live data connections in SAP Analytics Cloud
+  https://help.sap.com/docs/sap-analytics-cloud/sap-analytics-cloud/live-data-connections
+  source_owner: SAP SE
+  topic_supported: Live connection vs. import connection capabilities, supported source systems, connection type trade-offs, import data refresh scheduling, incremental load configuration
+  why_needed: Defines the connection type model — required to classify live vs. import connection misuse, missing refresh schedules on import models, and incremental load configuration gaps
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Data access controls
+
+- Data access control in SAP Analytics Cloud
+  https://help.sap.com/docs/sap-analytics-cloud/sap-analytics-cloud/data-access-control
+  source_owner: SAP SE
+  topic_supported: Role-based access (BI Admin, Planner, Viewer, custom roles), team-level data access, dimension member-level access restrictions in planning models, folder and story sharing permissions
+  why_needed: Defines the SAC access control model — required to classify over-permissive role assignments, missing dimension-level data restrictions, and ungoverned story sharing as access control findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Performance
+
+- Performance optimization in SAP Analytics Cloud
+  https://help.sap.com/docs/sap-analytics-cloud/sap-analytics-cloud/performance
+  source_owner: SAP SE
+  topic_supported: Story performance optimization, widget count guidelines, query reduction strategies, model size limits, import model caching, live connection query push-down behavior
+  why_needed: Defines the performance model for SAC stories and models — required to classify stories with excessive widget density, unbounded query scope, or import model refresh cadence gaps as performance findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Overview
+
+- What is SAP Analytics Cloud
+  https://help.sap.com/docs/sap-analytics-cloud/sap-analytics-cloud/what-is-sap-analytics-cloud
+  source_owner: SAP SE
+  topic_supported: SAP Analytics Cloud product overview, feature set, BI and planning capabilities, tenant model
+  why_needed: Provides the product-level context for all governance assessment; defines capability boundaries and tenant model
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Grounding rule
+
+SAP Analytics Cloud Help Portal documentation describes the designed behavior of stories, planning models, data actions, allocations, connections, and access controls. It does not prove which models exist in the user's tenant, whether data actions are correctly configured, or whether version locking is in effect. Users must supply story screenshots, model configuration exports, data action scripts, or written descriptions for concrete assessment.

package/skills/sap/sap-analytics-cloud-planning-governance/references/safety-checklist.md

@@ -0,0 +1,35 @@
+# Safety checklist — SAP Analytics Cloud Planning Governance Review
+
+Use before making any remediation recommendation, especially for findings that affect planning version locking, data action execution, allocation design, or role-based access.
+
+## Non-negotiables
+
+- Do not access, connect to, or request access to any live SAC tenant, model, data action, or connected source system. This skill reviews artifacts only.
+- Do not accept or request SAC tenant credentials, OAuth tokens, API keys, model data exports containing financial data, or dimension member lists that may contain personal or organizational data.
+- Do not recommend unlocking a locked actuals version. Locked actuals versions represent closed-period data and must not be unlocked without a documented change control process involving data owners and finance governance.
+- Do not recommend executing a data action or allocation on a production planning model based on review alone. All data action changes must be tested in a development or quality model before production deployment.
+- Do not recommend changing the account dimension type or date dimension granularity of an existing planning model with active data. These are foundational model properties — changing them requires model rebuild and data migration, not in-place configuration change.
+- Do not recommend granting BI Admin role as a workaround for access issues. BI Admin provides tenant-wide administration rights. The correct remedy for access gaps is a scoped custom role, not elevated built-in role assignment.
+- Do not classify a finding as `critical` without being able to trace the specific planning integrity breach or unauthorized access path from user-provided artifacts or official documentation.
+
+## What people get wrong
+
+- **Treating data actions and multi-actions as equivalent**: Data actions contain steps that execute as a single unit within one model. Multi-actions orchestrate multiple data actions, potentially across models, with independent execution and separate failure points. Sequencing recommendations for data action steps do not apply at the multi-action orchestration level and vice versa.
+- **Recommending live connection for planning models**: SAC planning models cannot be backed by a live connection — they require an import connection or are created natively in SAC. Recommending a live connection for a planning model is incorrect; live connections apply only to analytics-only models.
+- **Assuming all dimension member restrictions apply automatically to all story users**: Dimension member-level data access restrictions in SAC apply to teams, not directly to individual users. A user must be a member of a correctly configured team to inherit dimension member restrictions. Recommending restrictions without confirming the team membership model is incomplete.
+- **Conflating version locking with model locking**: Version locking prevents writes to a specific planning version (e.g., actuals). Model locking prevents any user from editing or running data actions on the entire model. They are different controls with different operational consequences.
+- **Missing the impact of model structure changes on active stories**: Changes to the planning model (removing measures, renaming dimensions, changing account hierarchy) immediately break any SAC story that references the changed elements. There is no graceful degradation — stories display errors. Model changes must be coordinated with story owners before deployment.
+- **Recommending full refresh for large import models where incremental load is available**: Full refresh replaces all model data on each run and is appropriate for small models. Large import models (millions of rows) should use incremental (delta) load where the source connection supports it. Recommending full refresh without confirming model size and refresh window creates data availability gaps.
+
+## When to push back
+
+- Push back when the user asks to confirm a data action correctness finding from a description alone without providing the data action script or step configuration.
+- Push back when the user asks for specific allocation amounts or formula values — this skill reviews governance and design, not planning content.
+- Push back when the user asks to recommend unlocking actuals or deploying data action changes to a production model without a development/test validation step.
+- Push back when a request requires live SAC tenant access, model data inspection, data action execution, or allocation run — state clearly that live inspection is out of scope and ask the user to supply the relevant configuration exports or descriptions.
+
+## Evidence labels
+
+- `documentation-based` — grounded in SAP Analytics Cloud Help Portal documentation covering stories, planning models, data actions, allocations, connections, or access control
+- `user-provided evidence` — story screenshots, model export files, data action scripts, planning model configuration summaries, connection descriptions, or architecture documents provided by the user
+- `inference` — derived reasoning not directly confirmed by official docs or user evidence; must always be labeled as such

package/skills/sap/sap-analytics-cloud-planning-governance/references/workflow-and-output.md

@@ -0,0 +1,70 @@
+# Workflow and output contract — SAP Analytics Cloud Planning Governance Review
+
+Use this reference for all finding classification, risk assignment, remediation path selection, and output formatting.
+
+## Design domain taxonomy
+
+| Domain | Scope | Typical findings |
+|--------|-------|-----------------|
+| `stories` | Story layout, widget binding, filter configuration, calculated measures | Incorrect model binding, filter scope too broad or too narrow, excessive page count, missing input control for planning tables |
+| `planning-models` | Version category structure, dimension design, account dimension, date dimension, measure types | Missing actual version lock after period close, incorrect account dimension type, absence of rolling forecast version, incorrect date dimension granularity |
+| `data-actions` | Step type selection, sequencing, Advanced Formula scope, trigger and schedule configuration | Incorrect step order causing data overwrite before read, unbounded MEMBERSET scope, missing trigger configuration, no multi-action failure handling |
+| `allocations` | Allocation method selection, driver dimension, hierarchy scope, validation approach | Incorrect allocation method for use case (spread vs. distribution vs. breakback), unfiltered hierarchy traversal on large model, no result validation step |
+| `value-driver-trees` | Node formula correctness, model binding, hierarchy connectivity | Broken node formula referencing deleted measure, disconnected VDT node, incorrect measure aggregation in VDT formula |
+| `connections` | Live vs. import connection selection, import refresh schedule, incremental load | Live connection to incompatible source object, import model without refresh schedule, full refresh where incremental load is supported and preferred |
+| `data-access-controls` | Role assignment scope, team data access, dimension member restrictions | BI Admin assigned as default role, planner access granted to view-only users, missing dimension member restriction on regulated data, ungoverned public story sharing |
+| `performance` | Widget density, query count, model size, import model caching | Story with excessive widget count per page, live connection story with no default page filter, import model queried without caching strategy |
+
+## Risk severity classification
+
+| Risk level | Criteria |
+|-----------|---------|
+| `critical` | Planning integrity breach or unauthorized data access: missing version lock on actuals allowing post-close changes, BI Admin access granted to non-admin users, missing dimension-level data restriction on regulated financial data |
+| `high` | Planning model failure or data action correctness error: data action step sequencing error producing incorrect plan data, live connection to incompatible source breaking story load, allocation with unfiltered hierarchy causing timeout |
+| `medium` | Governance gap or performance risk: import model without refresh schedule, planning model without rolling forecast version, story with excessive widget density causing slow load |
+| `low` | Best practice deviation: missing naming convention on versions, undocumented data action trigger schedule, VDT with no description on nodes |
+
+## Remediation path decision tree
+
+For each finding:
+
+1. **Is this a missing version lock on an actuals version after the period has closed?**
+   - Yes → `critical`. Lock the actuals version immediately. Audit all data action triggers that write to the actuals version and restrict them to authorized users only. Enable version change history to detect if unauthorized edits occurred during the unlocked window.
+   - No → continue.
+
+2. **Is this an unauthorized role assignment (BI Admin as default, Planner where Viewer is correct)?**
+   - Yes → `critical` or `high` depending on the data sensitivity. Reduce the role to the minimum required (Viewer for read-only consumers, custom scoped Planner role for authorized contributors). Remove generic BI Admin assignments from users who do not require tenant administration.
+   - No → continue.
+
+3. **Is this a data action step sequencing error or unbounded Advanced Formula scope?**
+   - Yes → `high`. For sequencing errors, reorder steps so read steps precede write steps for any shared data region. For unbounded scope, add explicit MEMBERSET restrictions to limit formula execution to the intended version, entity, and time dimensions.
+   - No → continue.
+
+4. **Is this a live connection to an incompatible source object type?**
+   - Yes → `high`. Confirm the source object type against the SAC live connection compatibility matrix. Convert to a compatible source object (for Datasphere: analytic model or analytical dataset; for BW: BEx query or Composite Provider with defined characteristics and key figures) or switch to import connection if live is not required.
+   - No → continue.
+
+5. **Is this a governance or performance gap?**
+   - Yes → `medium`. Define import model refresh schedules, add rolling forecast version to planning model, apply default page filters to live connection stories, or add dimension member restrictions to regulated data models.
+   - No → classify as `low` and provide best practice guidance.
+
+## Workflow
+
+1. **Receive artifacts** — story screenshots, model configuration exports, data action scripts, planning model configuration summaries, connection descriptions, or user descriptions.
+2. **Classify each finding** by design domain and finding type.
+3. **Assign risk level** (critical / high / medium / low).
+4. **Apply remediation decision tree** per finding.
+5. **Prioritize** — critical planning integrity and access control findings first; then high model and data action failures; then medium governance and performance gaps; then low best-practice items.
+6. **Return output** per the output contract below.
+
+## Output contract
+
+Return:
+
+1. Design domain and specific finding type
+2. Evidence label (documentation-based / user-provided evidence / inference)
+3. Risk level per finding (critical / high / medium / low)
+4. Recommended remediation action with specific implementation guidance
+5. Planning governance posture after remediation
+6. Prioritized remediation sequence
+7. Escalation trigger if live SAC tenant access, model refresh, or data action execution is required to confirm or apply the finding

package/skills/sap/sap-audit-evidence-packaging/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: sap-audit-evidence-packaging
+description: Package and structure audit evidence for SAP controls covering Segregation of Duties, change management, access management, and financial controls. Defines evidence taxonomy, maps controls to evidence artifacts, establishes chain-of-custody and redaction requirements, and aligns evidence packages to SOC 2, ISO 27001, SOX, and GxP frameworks. Does not touch live systems and never includes secrets, credentials, or personal identifiable information in evidence packages.
+allowed-tools: Read Grep Glob WebSearch WebFetch
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-19"
+  category: compliance
+  lifecycle: experimental
+---
+
+# SAP Audit Evidence Packaging
+
+## Purpose
+
+Structure, classify, and package audit evidence for SAP system controls to support internal audit, external audit, and regulatory compliance assessments. Define an evidence taxonomy aligned to SAP control domains. Map controls to the specific evidence artifacts required to demonstrate control effectiveness. Establish chain-of-custody requirements and redaction rules for evidence that contains sensitive system or personal data. Assess evidence reproducibility and advise on gaps. Align evidence packages to the requirements of SOC 2 Type II, ISO/IEC 27001, SOX ITGC, and GxP (21 CFR Part 11 / EU Annex 11) frameworks. Does not connect to any live SAP system, never requests or accepts credentials, and never includes secrets, credentials, personal identifiable information, or customer data in evidence packages.
+
+## When to use
+
+Use this skill when the user needs to:
+
+- define an evidence taxonomy for a SAP audit: which artifact types constitute valid evidence for each SAP control domain (SoD, access management, change management, financial controls),
+- map specific SAP controls from a control framework (SOX ITGC, SOC 2 CC6/CC8, ISO 27001 A.9, GxP Annex 11) to the concrete evidence artifacts that demonstrate their effectiveness,
+- structure an evidence package for a specific control: what to collect, how to label it, what metadata to include, and how to maintain chain-of-custody,
+- review a set of evidence artifacts provided by the user and assess whether they are sufficient to demonstrate control effectiveness for the stated control objective,
+- advise on redaction of sensitive data from SAP audit evidence: which fields must be redacted from GRC SoD reports, role assignment exports, transport request logs, and financial posting reports before inclusion in an audit package,
+- assess evidence reproducibility: whether the evidence artifact can be regenerated from the same source system state and time window, and what risks affect reproducibility,
+- define a control-to-evidence mapping document suitable for use in an audit readiness assessment or external auditor evidence request response.
+
+## When not to use
+
+- When the user needs live enumeration of SAP system configuration to gather evidence — use `sap-live-readonly-landscape-discovery` or `sap-live-readonly-identity-trust-discovery` for read-only live evidence gathering.
+- When the user needs SoD conflict review or IAM posture assessment rather than evidence packaging — use `sap-security-iam-grc-sod-review`.
+- When the request is about implementing SAP GRC Access Control rulesets or configuring audit log settings — this skill is advisory and evidence-packaging focused, not implementation focused.
+- When the request is about non-SAP control evidence packaging or general compliance framework interpretation without SAP-specific context.
+
+## Does not touch live systems
+
+This skill operates on user-provided evidence artifacts, control descriptions, audit scope descriptions, control framework excerpts, and written descriptions of the SAP landscape. It does not connect to any SAP system, BTP subaccount, GRC Access Control instance, ABAP system, S/4HANA tenant, or audit log service. All live evidence gathering is out of scope.
+
+## Lean operating rules
+
+- Classify evidence by control domain before structuring. Every evidence artifact or gap must be assigned to a control domain (SoD / Access Management / Change Management / Financial Controls / System Configuration) before packaging advice is given.
+- Chain-of-custody is required for all live evidence. Evidence gathered from a live SAP system must be accompanied by: source system identifier, extraction method, extraction timestamp, person who extracted it, and any transformations applied. Evidence without chain-of-custody metadata is incomplete.
+- Redaction before packaging is mandatory. Any evidence artifact that contains passwords, API keys, OAuth tokens, SAML private keys, personal identifiable information (employee IDs, social security numbers, salary data), or customer confidential data must be redacted before inclusion in an audit package.
+- Reproducibility must be assessed. For each evidence artifact, advise whether it can be reproduced from the same source and time window. Evidence that cannot be reproduced (e.g., a one-time GRC report extraction from a period now past) must be designated as non-reproducible and stored with heightened custody controls.
+- Framework alignment is explicit. For each control-to-evidence mapping, state which specific control requirement from the target framework (SOC 2 Trust Service Criteria, ISO 27001 Annex A, SOX ITGC, GxP Annex 11) the evidence addresses.
+- Gaps are findings. A control that lacks sufficient evidence to demonstrate effectiveness is a gap finding. Classify gaps by severity: a control with no evidence is `critical`; a control with partial evidence is `high`; a control with evidence that does not cover the full audit period is `medium`.
+- Evidence from user-provided artifacts and official SAP and regulatory framework documentation takes precedence over inference.
+- Load only the reference needed for the control domain in scope.
+
+## Evidence rules
+
+Label all claims with one of:
+
+- `documentation-based` — grounded in SAP audit and compliance documentation, GRC best practices, or regulatory framework requirements (SOC 2, ISO 27001, SOX, GxP)
+- `user-provided evidence` — audit evidence artifacts, control descriptions, audit scope descriptions, or written landscape descriptions provided by the user
+- `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 SAP system API call, GRC Access Control connection, BTP subaccount access, ABAP RFC call, audit log service query, or S/4HANA tenant access in this skill's execution path. Users must supply evidence artifacts, control descriptions, and audit scope information for this skill to advise on packaging, redaction, and framework alignment.
+
+**This skill never includes in any output**:
+- Passwords, API keys, OAuth tokens, or credentials of any kind
+- SAML signing certificate private keys or X.509 private keys
+- Personal identifiable information: employee names, employee IDs, national identification numbers, salary data, or health data
+- Customer confidential data or customer personal data
+- BTP service key values, client secrets, or connection strings with embedded credentials
+
+If a user-provided evidence artifact contains any of the above, advise on redaction before including any excerpt in this skill's output.
+
+## References
+
+Load only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — evidence taxonomy, control-to-evidence mapping structure, chain-of-custody format, output contract.
+- [Safety checklist](references/safety-checklist.md) — non-negotiables, redaction requirements, common audit evidence mistakes, when to push back.
+- [Official sources](references/official-sources.md) — SAP GRC documentation, SAP audit and compliance guides, SOC 2, ISO 27001, SOX ITGC, and GxP references.
+
+## Response minimum
+
+Return, at minimum:
+
+- **Problem classification**: control domain(s) in scope (SoD / Access Management / Change Management / Financial Controls / System Configuration) and the specific controls or evidence gaps being addressed.
+- **Evidence used**: documentation-based / user-provided evidence / inference.
+- **Risk level**: critical (control with no evidence; unmitigated gap before audit deadline) / high (partial evidence; evidence not covering full audit period) / medium (evidence present but chain-of-custody incomplete; redaction not applied) / low (minor metadata gap; reproducibility risk only).
+- **Recommended action**: specific evidence artifact to collect, redaction to apply, chain-of-custody metadata to add, or framework mapping to document.
+- **Refusal / escalation triggers**: if live SAP system access, GRC report extraction, or audit log query is required to complete the evidence package, state that clearly and direct to `sap-live-readonly-landscape-discovery` or `sap-live-readonly-identity-trust-discovery` for the evidence gathering step.
+- **Business impact**: audit finding risk, regulatory non-compliance, certification failure, or evidence admissibility challenge.
+- **Next verification step**: confirm chain-of-custody completeness and redaction with the control owner before submitting evidence to an external auditor.

package/skills/sap/sap-audit-evidence-packaging/agents/openai.yaml

@@ -0,0 +1,11 @@
+interface:
+  display_name: "SAP Audit Evidence Packaging"
+  short_description: "Package and structure audit evidence for SAP controls: SoD, change management, access management, and financial controls — with evidence taxonomy, chain-of-custody, redaction, and SOC 2/ISO 27001/SOX/GxP alignment"
+  default_prompt: "Use $sap-audit-evidence-packaging to advise on structuring the provided SAP audit evidence. Classify findings by control domain (SoD / Access Management / Change Management / Financial Controls / System Configuration), assign severity to evidence gaps (critical / high / medium / low), state evidence level (documentation-based / user-provided evidence / inference), and recommend specific artifacts, chain-of-custody metadata, redaction actions, and framework mappings per control. Never include credentials, personal identifiable information, or customer data in any output."
+dependencies:
+  tools:
+    - type: "web"
+      value: "https://help.sap.com/docs/sap-grc-access-control/sap-grc-access-control/what-is-sap-grc-access-control"
+      description: "SAP GRC Access Control documentation — verify SoD evidence artifact types and control report formats"
+policy:
+  allow_implicit_invocation: true

package/skills/sap/sap-audit-evidence-packaging/metadata.json

@@ -0,0 +1,33 @@
+{
+  "id": "sap-audit-evidence-packaging",
+  "name": "SAP Audit Evidence Packaging",
+  "type": "skill",
+  "provider": "sap",
+  "harnesses": [
+    "claude-code",
+    "codex",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Package and structure audit evidence for SAP controls covering Segregation of Duties, change management, access management, and financial controls. Defines evidence taxonomy, control-to-evidence mapping, chain-of-custody, redaction rules, and framework alignment for SOC 2, ISO 27001, SOX, and GxP. Does not access live systems and never includes secrets, credentials, or personal identifiable information in evidence packages.",
+  "source_type": "original",
+  "category": "compliance",
+  "official_docs": [
+    "https://help.sap.com/docs/sap-grc-access-control/sap-grc-access-control/what-is-sap-grc-access-control",
+    "https://help.sap.com/docs/sap-grc-access-control/sap-grc-access-control/segregation-of-duties",
+    "https://help.sap.com/docs/sap-grc-process-control/sap-grc-process-control/what-is-sap-grc-process-control",
+    "https://help.sap.com/docs/sap-grc-process-control/sap-grc-process-control/documentation-and-evidence-collection",
+    "https://help.sap.com/docs/btp/sap-business-technology-platform/audit-logging-in-the-cloud-foundry-environment",
+    "https://help.sap.com/docs/sap-s4hana-cloud/sap-s4hana-cloud/audit-management",
+    "https://help.sap.com/docs/sap-s4hana-cloud/sap-s4hana-cloud/change-document-logs",
+    "https://help.sap.com/docs/btp/sap-business-technology-platform/change-and-transport-system"
+  ],
+  "security_notes": "Does not access live SAP systems, GRC Access Control instances, BTP subaccounts, ABAP systems, audit log services, or S/4HANA tenants. Accepts only user-provided evidence artifacts, control descriptions, and audit scope information. Never request or accept SAP system credentials, BTP service keys, OAuth tokens, or GRC logon credentials. Never include in output: passwords, API keys, personal identifiable information, employee IDs, salary data, customer confidential data, or SAP SAML private keys. Any user-provided evidence artifact containing sensitive data must be advised for redaction before inclusion.",
+  "last_verified": "2026-06-19",
+  "path": "skills/sap/sap-audit-evidence-packaging",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "lifecycle": "experimental"
+}

package/skills/sap/sap-audit-evidence-packaging/references/official-sources.md

@@ -0,0 +1,92 @@
+# Official sources — SAP Audit Evidence Packaging
+
+Use this reference when grounding SAP control evidence requirements, GRC documentation, audit log configuration, change management evidence, and regulatory framework alignment.
+
+**Evidence level**: documentation-based (SAP Help Portal, SAP GRC documentation, regulatory framework publications). No live-system evidence is collected by this skill.
+
+## SAP GRC Access Control
+
+- What Is SAP GRC Access Control
+  https://help.sap.com/docs/sap-grc-access-control/sap-grc-access-control/what-is-sap-grc-access-control
+  source_owner: SAP SE
+  topic_supported: GRC Access Control overview — Access Risk Analysis, Access Request Management, Emergency Access Management, Business Role Management; evidence artifact types generated by each module
+  why_needed: Defines the GRC Access Control report types and module outputs that constitute valid SoD and access management audit evidence
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- Segregation of Duties in SAP GRC Access Control
+  https://help.sap.com/docs/sap-grc-access-control/sap-grc-access-control/segregation-of-duties
+  source_owner: SAP SE
+  topic_supported: SoD rule sets, function definitions, permission-level risk definitions, SoD conflict report generation, risk classification, mitigation control documentation
+  why_needed: Defines what a complete SoD evidence artifact looks like from GRC Access Control; used to assess whether a user-provided SoD report is sufficient for audit
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP GRC Process Control
+
+- What Is SAP GRC Process Control
+  https://help.sap.com/docs/sap-grc-process-control/sap-grc-process-control/what-is-sap-grc-process-control
+  source_owner: SAP SE
+  topic_supported: Continuous control monitoring, control documentation, assessment workflows, policy management, issue management — evidence artifacts for financial and operational controls
+  why_needed: Defines the GRC Process Control evidence artifact types for financial control and operational control assessment documentation
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- Documentation and Evidence Collection in SAP GRC Process Control
+  https://help.sap.com/docs/sap-grc-process-control/sap-grc-process-control/documentation-and-evidence-collection
+  source_owner: SAP SE
+  topic_supported: Evidence attachment to controls in GRC Process Control, assessment documentation, evidence types, audit trail of assessment activities
+  why_needed: Authoritative source for what constitutes valid evidence attachment in GRC Process Control; used to advise on evidence linking and chain-of-custody within the GRC system
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## BTP Audit Logging
+
+- Audit Logging in the Cloud Foundry Environment
+  https://help.sap.com/docs/btp/sap-business-technology-platform/audit-logging-in-the-cloud-foundry-environment
+  source_owner: SAP SE
+  topic_supported: BTP audit log service — configuration audit messages, security event logging, audit log retrieval via API, audit log retention
+  why_needed: Defines BTP audit log evidence artifact types and API-based extraction methods for BTP platform controls; used to assess BTP audit log evidence completeness
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## S/4HANA Cloud Change Management
+
+- SAP S/4HANA Cloud — change document logs
+  https://help.sap.com/docs/sap-s4hana-cloud/sap-s4hana-cloud/change-document-logs
+  source_owner: SAP SE
+  topic_supported: Change document logs in S/4HANA Cloud: financial posting change documents, master data change documents, configuration change logging, evidence export
+  why_needed: Defines change document evidence artifacts for financial control and master data governance audits; used to assess evidence completeness for SOX ITGC change management controls
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- BTP Change and Transport System
+  https://help.sap.com/docs/btp/sap-business-technology-platform/change-and-transport-system
+  source_owner: SAP SE
+  topic_supported: SAP Change and Transport System (CTS), transport request lifecycle, transport route configuration, transport log export, import queue management
+  why_needed: Defines the change management evidence artifact types from CTS; used to assess completeness of transport log and approval evidence for SOX ITGC change management controls
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## S/4HANA Cloud Audit and Compliance
+
+- SAP S/4HANA Cloud — audit management
+  https://help.sap.com/docs/sap-s4hana-cloud/sap-s4hana-cloud/audit-management
+  source_owner: SAP SE
+  topic_supported: S/4HANA Cloud audit management — security audit log activation, audit log analysis, data access logging, retention settings for audit evidence
+  why_needed: Defines the S/4HANA Cloud audit log and security audit evidence artifacts available for access control and financial control audits
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Grounding rule
+
+SAP documentation describes available report types, API endpoints, and control artifact formats. It does not prove whether a specific GRC report was run for the correct audit period, whether the change management approval chain was actually followed, or whether evidence artifacts are sufficient to satisfy a specific external auditor's evidentiary requirements. Compliance declarations and evidence sufficiency assessments must be made by qualified auditors, not by this skill.
+
+## Regulatory framework references
+
+The following are cited by this skill for framework alignment. They are referenced by name and article/clause only — do not treat this skill as a legal or regulatory compliance authority.
+
+- **SOC 2 Trust Service Criteria**: CC6 (Logical and Physical Access Controls), CC8 (Change Management) — AICPA Trust Services Criteria 2017 with 2022 points of focus
+- **ISO/IEC 27001:2022**: Annex A controls A.5 (Organizational Controls), A.8 (Technological Controls), A.9 (Physical Controls) — particularly A.5.15 (Access Control), A.8.2 (Privileged Access Rights), A.8.32 (Change Management)
+- **SOX ITGC**: Logical Access, Program Change, Computer Operations, and Data Center / Physical Security control categories as defined in AS 2201 (PCAOB)
+- **GxP**: 21 CFR Part 11 (FDA electronic records and signatures) and EU GMP Annex 11 (Computerised Systems) — particularly clauses 7 (Access Security), 10 (Change and Configuration Management), 11 (Data Storage), and 12 (Audit Trails)

package/skills/sap/sap-audit-evidence-packaging/references/safety-checklist.md

@@ -0,0 +1,38 @@
+# Safety checklist — SAP Audit Evidence Packaging
+
+Use before making any evidence packaging recommendation or including any excerpt from user-provided artifacts in output.
+
+## Non-negotiables
+
+- Do not access, connect to, or request access to any live SAP system, GRC Access Control instance, BTP subaccount, ABAP system, audit log service, or S/4HANA tenant. This skill advises on packaging only.
+- Do not accept or request SAP system credentials, BTP service keys, GRC logon passwords, OAuth tokens, SAML private keys, or connection strings with embedded credentials.
+- Do not include in any output: passwords, API keys, OAuth tokens, client secrets, SAML private keys, employee personal identifiable information (names, national IDs, salary data), or customer confidential data — even if the user provides them in an evidence artifact.
+- If a user-provided artifact contains sensitive data, advise on redaction before including any excerpt. Never echo sensitive values back in the response.
+- Do not declare a control as compliant or an evidence package as audit-ready. This skill assesses completeness and packaging quality; compliance declarations must be made by qualified auditors.
+- Do not produce evidence artifacts on behalf of the user. This skill advises on what to collect, how to label it, and how to structure it; it does not generate evidence that did not exist from a real SAP system.
+- Do not classify evidence as sufficient based solely on the existence of an artifact type — the artifact must also cover the full audit period and be accompanied by valid chain-of-custody metadata.
+
+## What people get wrong
+
+- **Treating a GRC SoD report screenshot as complete evidence**: A screenshot of a GRC SoD conflict report is not sufficient without the underlying report export (CSV, PDF, or XLS with full conflict detail), chain-of-custody metadata (extraction date, system, extractor role), and confirmation of the audit period covered.
+- **Overlooking the audit period gap**: Evidence that covers 9 months of a 12-month audit period is a `high` gap, not a `medium` one. The full audit period must be covered without interruption.
+- **Assuming access review completion equals evidence**: A completed access review workflow in GRC or a ticketing system is evidence of the review process, not evidence of the role assignment state. Both the review completion record and the role assignment export at that point in time are required.
+- **Including live personal data in evidence packages**: GRC SoD reports, SUIM user-role exports, and IAS user lists often contain employee names, email addresses, and employee IDs. These must be redacted or pseudonymized per applicable data protection requirements before submission to an external auditor.
+- **Missing chain-of-custody for evidence gathered outside GRC**: Evidence gathered via BTP CLI, CF CLI, or ABAP transaction exports is often not automatically stamped with a timestamp or extractor identity. The chain-of-custody metadata must be manually documented at the time of extraction.
+- **Treating non-reproducible evidence as low risk**: If an evidence artifact cannot be regenerated from the same source (e.g., an ABAP SM20 audit log from a period that has since been archived or overwritten), it must be stored with heightened custody controls and its non-reproducibility documented explicitly.
+- **Assuming a transport log is sufficient change management evidence alone**: A transport log demonstrates that transports moved; it does not demonstrate that the approval chain was followed. Approval records (workflow completion, second-pair-of-eyes sign-off) are a separate required artifact.
+
+## When to push back
+
+- Push back when the user asks to generate evidence that does not exist from a real SAP system (e.g., to fabricate a GRC report or produce a synthetic role assignment export).
+- Push back when the user asks to include credentials, personal identifiable information, or customer data in an evidence package without redaction.
+- Push back when the user asks to declare a control compliant or an audit package ready — direct to the qualified auditor or control owner for the compliance declaration.
+- Push back when the user asks to extract live evidence from a SAP system — redirect to `sap-live-readonly-landscape-discovery` or `sap-live-readonly-identity-trust-discovery` for the evidence gathering step.
+- Push back when the audit scope is ambiguous (audit period not defined, control framework not stated, SAP systems in scope not identified) — request clarification before advising on evidence mapping.
+- Push back when the user provides an evidence artifact and asks whether it satisfies a regulatory requirement without specifying which regulatory framework or which specific control requirement is being addressed.
+
+## Evidence labels
+
+- `documentation-based` — grounded in SAP GRC documentation, SAP audit guides, or regulatory framework requirements (SOC 2, ISO 27001, SOX ITGC, GxP)
+- `user-provided evidence` — audit evidence artifacts, control descriptions, audit scope descriptions, or written SAP landscape descriptions provided by the user
+- `inference` — derived reasoning not directly confirmed by official docs or user evidence; must always be labeled as such

package/skills/sap/sap-audit-evidence-packaging/references/workflow-and-output.md

@@ -0,0 +1,129 @@
+# Workflow and output contract — SAP Audit Evidence Packaging
+
+Use this reference for evidence taxonomy, control-to-evidence mapping structure, chain-of-custody format, and output formatting.
+
+## Evidence taxonomy
+
+SAP audit evidence is classified by control domain and artifact type:
+
+### Control domains
+
+| Domain | Description |
+|--------|-------------|
+| `SoD` | Segregation of Duties — evidence that incompatible functions are not held by the same user |
+| `Access Management` | User provisioning, deprovisioning, access review, role assignment, and privileged access controls |
+| `Change Management` | Transport request lifecycle, approval chains, emergency change controls, and change freeze enforcement |
+| `Financial Controls` | Posting authorization, period-end close controls, journal entry approval, and reconciliation evidence |
+| `System Configuration` | SAP system parameter settings, security profile settings, audit log configuration, and baseline configuration |
+
+### Artifact types
+
+| Artifact type | Description | Typical source |
+|---------------|-------------|---------------|
+| `GRC SoD report` | Machine-generated SoD conflict report from GRC Access Control or equivalent | SAP GRC Access Control NWBC report / Pathlock / Fastpath |
+| `Role assignment export` | Export of user-to-role or user-to-role-collection assignments at a point in time | BTP CLI, SUIM transaction, GRC Access Control, IAS export |
+| `Transport log` | Log of transport request creation, release, import approvals, and execution timestamps | STMS transaction export, CTS+ log, Cloud ALM transport log |
+| `Access review report` | Periodic access review completion record showing reviewer, outcome, and date | GRC Access Control recertification report, manual review record |
+| `Audit log extract` | System audit log entries demonstrating monitoring is active and events are captured | SM19/SM20 ABAP audit log export, BTP audit log service export |
+| `Security parameter screenshot or export` | System parameter values (login/fails_to_user_lock, auth/rfc_authority_check, etc.) | RZ11 transaction export, parameter configuration export |
+| `Approval record` | Documented approval of a specific action (emergency access, transport import, user creation) | Workflow completion record, ServiceNow ticket, email chain with timestamp |
+| `Period-end evidence` | Evidence that period-end close procedures were executed and controls operated | Financial posting report, period-lock screenshot, reconciliation sign-off |
+
+## Control-to-evidence mapping structure
+
+For each control, document:
+
+```
+Control ID:        <control reference from audit framework, e.g., SOX ITGC CC-01>
+Control objective: <what the control is designed to prevent or detect>
+Domain:            <SoD | Access Management | Change Management | Financial Controls | System Configuration>
+Framework refs:    <SOC 2 CC6.1 | ISO 27001 A.9.2 | SOX ITGC | GxP Annex 11 clause X>
+Required artifacts:
+  - <artifact type 1>: <what exactly to collect; time window; format>
+  - <artifact type 2>: <what exactly to collect; time window; format>
+Chain-of-custody:
+  - Source system: <SAP SID or BTP subaccount or GRC tenant>
+  - Extraction method: <transaction/CLI command/API/manual export>
+  - Extraction timestamp: <ISO 8601>
+  - Extracted by: <role/person (no personal names in the mapping template)>
+  - Transformations: <redactions applied; format conversions>
+Completeness status: <sufficient | partial | missing>
+Gap description:   <if partial or missing — what is absent and why>
+```
+
+## Chain-of-custody format
+
+Every live evidence artifact included in an audit package must carry:
+
+```
+[CHAIN_OF_CUSTODY]
+Artifact name:        <descriptive name, e.g., "SoD_Report_FI_2026Q1.xlsx">
+Control ID(s):        <comma-separated control IDs this artifact supports>
+Domain:               <SoD | Access Management | Change Management | Financial Controls | System Configuration>
+Source system:        <SAP SID, BTP subaccount ID, or GRC tenant identifier>
+Extraction method:    <GRC NWBC report / SUIM export / btp CLI / SM20 export / CloudALM API>
+Extraction timestamp: <ISO 8601>
+Extracted by role:    <GRC viewer / BTP subaccount viewer / ABAP display user>
+Audit period covered: <start date ISO 8601> to <end date ISO 8601>
+Redactions applied:   <yes/no — list what was redacted>
+Reproducible:         <yes | no | partial — explanation>
+Storage location:     <placeholder — do not include actual system paths with credentials>
+Hash (SHA-256):       <file hash for tamper evidence — populate after file is finalized>
+```
+
+## Redaction requirements before packaging
+
+The following must be redacted from all evidence artifacts before inclusion in an audit package:
+
+| Data category | Redaction action |
+|--------------|-----------------|
+| SAP system password, client secret, API key | Replace value with `[REDACTED:CREDENTIAL]` |
+| Employee personal name | Replace with employee ID only, or `[REDACTED:PII_NAME]` if employee ID is also not permitted |
+| National identification number or social security number | Replace with `[REDACTED:PII_NID]` |
+| Salary or compensation data | Replace with `[REDACTED:PII_SALARY]` |
+| Customer name or customer personal data | Replace with `[REDACTED:CUSTOMER_PII]` |
+| SAML signing certificate private key | Replace with `[REDACTED:SAML_PRIVATE_KEY]` |
+| Connection string with embedded credentials | Replace with `[REDACTED:CONN_STRING]` |
+
+After redaction, document what was redacted in the chain-of-custody `Redactions applied` field.
+
+## Severity classification for evidence gaps
+
+| Severity | Meaning | Examples |
+|----------|---------|---------|
+| `critical` | Control has no supporting evidence; gap cannot be closed before audit deadline | No SoD report extracted for the audit period; no transport approval records for the change management control |
+| `high` | Evidence is partial; does not cover full audit period or key evidence artifact is missing | SoD report covers only part of the audit period; access review records missing for one system in scope |
+| `medium` | Evidence is present but chain-of-custody is incomplete or redaction has not been applied | Evidence artifact lacks extraction timestamp or extracted-by role; personal data not yet redacted |
+| `low` | Minor metadata gap or reproducibility risk only | File hash not yet calculated; storage location not yet documented in chain-of-custody |
+
+## Framework alignment matrix
+
+| Control domain | SOC 2 Trust Service Criteria | ISO 27001 Annex A | SOX ITGC | GxP (21 CFR Part 11 / EU Annex 11) |
+|---------------|------------------------------|-------------------|----------|-------------------------------------|
+| SoD | CC6.3, CC6.6 | A.9.2.3, A.9.4.1 | Access to Programs and Data | Annex 11 clause 12 (audit trail), clause 7 (access control) |
+| Access Management | CC6.1, CC6.2, CC6.3 | A.9.2.1, A.9.2.2, A.9.2.6 | Logical Access | Annex 11 clause 7 |
+| Change Management | CC8.1 | A.14.2.2, A.14.2.4 | Program Change | Annex 11 clause 10 |
+| Financial Controls | CC4.1 (monitoring) | A.12.4.1 (logging) | Financial Reporting ITGC | N/A (GxP is process-industry focused) |
+| System Configuration | CC6.6, CC7.1 | A.12.1.2, A.14.1.1 | Operations | Annex 11 clause 4 (validation), clause 11 (data storage) |
+
+## Workflow
+
+1. **Receive scope** — audit scope description, control list, or evidence request from user.
+2. **Classify each control** by domain (SoD / Access Management / Change Management / Financial Controls / System Configuration).
+3. **Map to required artifacts** — define the specific artifact types needed per control.
+4. **Assess completeness** — review user-provided artifacts for sufficiency, period coverage, and chain-of-custody completeness.
+5. **Flag gaps** — classify gaps by severity (critical / high / medium / low).
+6. **Apply redaction checks** — identify any sensitive data requiring redaction.
+7. **Align to frameworks** — map each control to specific SOC 2, ISO 27001, SOX ITGC, or GxP requirements.
+8. **Return output** per the output contract below.
+
+## Output contract
+
+Return:
+
+1. Audit scope summary (control domains in scope, audit period, frameworks applicable)
+2. Control-to-evidence mapping for each control in scope (required artifacts, chain-of-custody requirements, framework mapping)
+3. Completeness assessment per control (sufficient / partial / missing) with gap severity and description
+4. Redaction advisory (which artifacts require redaction and what to redact)
+5. Reproducibility assessment per artifact type
+6. Escalation trigger if live SAP system access is required to gather missing evidence (with pointer to the appropriate live discovery skill)