@raishin/vanguard-frontier-agentic 2.11.0 → 2.13.0

package/skills/sap/sap-custom-code-remediation-review/references/safety-checklist.md

@@ -0,0 +1,39 @@
+# Safety checklist — SAP Custom Code Remediation Review
+
+Use before making any ATC finding classification, deprecated API replacement recommendation, or ATC exemption guidance.
+
+## Non-negotiables
+
+- Do not access, connect to, or request access to any live SAP system. This skill reviews user-provided artifacts only.
+- Do not accept or request SAP system credentials, ABAP developer logon passwords, RFC destinations, or BTP service keys.
+- Do not recommend a deprecated pattern as a remediation target. Classic user exits, implicit enhancements, `CALL CUSTOMER FUNCTION`, and direct access to SAP internal DDIC objects are deprecated source patterns — they are never valid remediation destinations.
+- Do not recommend a replacement API without directing the user to verify its C1/C2 release contract on SAP API Business Hub. A released-sounding API name is not sufficient — the contract must be confirmed.
+- Do not grant or imply that an ATC exemption has been approved. Exemptions require formal customer authorization. This skill can describe when an exemption may be warranted and what justification is needed, but cannot approve one.
+- Do not classify findings that the user has not provided. Only assess ATC findings or deprecated patterns present in user-supplied artifacts.
+- Do not conflate ATC S/4HANA readiness findings with general ABAP quality findings. The `SCI_S4HANA_READINESS` variant is specifically scoped to conversion-relevant issues; general code quality findings require a separate ATC variant.
+
+## What people get wrong
+
+- **Treating all ATC warnings as optional**: Some ATC priority-3 (warning) findings indicate post-conversion functional regressions in critical business processes. Always assess the business context of warning-class findings before deferring them.
+- **Recommending replacement APIs without release contract verification**: An SAP function module with a readable name (e.g., `BAPI_MATERIAL_GET`) may not carry a C1/C2 release contract in the user's target S/4HANA release. Always verify on api.sap.com before recommending.
+- **Equating ABAP Cloud compliance with S/4HANA conversion readiness**: ABAP Cloud readiness (tier compliance, forbidden construct elimination) and S/4HANA system conversion readiness (simplification item resolution) are related but distinct. Conversion can succeed with non-ABAP-Cloud-compliant code; the clean core debt remains.
+- **Recommending SELECT on SAP internal tables as an intermediate step**: Recommending direct SELECT on SAP internal tables as a "temporary fix" accumulates technical debt that is harder to remove later. Always recommend the released API path, even if it requires more effort.
+- **Treating ATC exemption as the primary remediation path**: Exemptions should be the last resort for genuinely irreplaceable conversion-blocking code. Using exemptions broadly indicates an under-resourced remediation program, not an appropriate risk management decision.
+- **Ignoring the distinction between ABAP Cloud Tier 1/2/3**: ABAP Cloud has three tiers with different constraints. Tier 1 (ABAP language subset) applies to all ABAP Cloud objects. Tier 2 (released API consumption) applies to objects accessing SAP objects. Tier 3 (ABAP Platform and S/4HANA standard) applies to delivered SAP standard. Custom code must comply with Tier 1 and Tier 2 constraints.
+- **Confusing SYCM scope with ATC scope**: The Custom Code Migration App (SYCM) provides a high-level usage and impact analysis. ATC with the S/4HANA readiness variant provides finding-level detail. Both are needed for a complete picture; neither is a substitute for the other.
+
+## When to push back
+
+- Push back when the user wants to defer all blocker-class ATC findings without a formal exemption process and justification.
+- Push back when the proposed replacement API for a deprecated finding has not been verified for C1/C2 release contract.
+- Push back when the user proposes maintaining `CALL CUSTOMER FUNCTION` user exits as a "working solution" post-conversion.
+- Push back when the remediation plan lacks a testing strategy for verifying that replaced APIs produce the same business results as the deprecated code.
+- Push back when the user wants to use `SELECT *` on SAP internal tables in ABAP Cloud objects as a transitional approach.
+- Push back when ATC findings are provided from a generic quality variant rather than the S/4HANA readiness or ABAP Cloud readiness variant — the findings are not conversion-representative.
+- Push back when the conversion program has no defined owner for custom code remediation and no budget allocated for the remediation volume indicated by the SYCM report.
+
+## Evidence labels
+
+- `documentation-based` — grounded in SAP ATC documentation, ABAP Cloud docs, S/4HANA simplification item catalog, or SAP Help Portal
+- `user-provided evidence` — ATC result exports, SYCM output, ABAP source code listings, or object 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-custom-code-remediation-review/references/workflow-and-output.md

@@ -0,0 +1,83 @@
+# Workflow and output contract — SAP Custom Code Remediation Review
+
+Use this reference for ATC finding classification, deprecated API mapping, remediation path selection, and output formatting.
+
+## ATC finding severity taxonomy (S/4HANA readiness variant)
+
+| Severity | ATC priority | Conversion impact | Assessment action |
+|----------|-------------|-----------------|------------------|
+| `blocker` | Priority 1 (error) | Conversion cannot complete until resolved | Must fix or formally exempt before conversion; add to critical remediation path |
+| `error` | Priority 2 (error) | Conversion may complete but system behavior is undefined or degraded | Strongly recommended to resolve before conversion; document risk if deferred |
+| `warning` | Priority 3 (warning) | No conversion block; functional or performance risk post-conversion | Plan remediation in Realize phase; include in post-conversion testing scope |
+| `information` | Priority 4 (info) | Advisory only; no functional impact | Document; no remediation action required |
+
+## Custom code disposition taxonomy
+
+| Disposition | Criteria | Preferred action |
+|------------|---------|-----------------|
+| `retire` | Business function now covered by SAP S/4HANA standard; custom object has no residual business value | Decommission after confirming standard process covers the requirement |
+| `replace-standard` | SAP standard S/4HANA process exists but requires configuration or fit-to-standard adoption | Remove custom code; configure standard process |
+| `remediate-released-api` | Deprecated API or internal FM used; released C1/C2 replacement exists | Refactor to consume released API; validate release contract on API Business Hub |
+| `remediate-abap-cloud` | Language construct or object type violates ABAP Cloud tier constraints; ABAP Cloud rewrite feasible | Rewrite using ABAP Cloud permitted constructs; validate via ATC with ABAP_CLOUD variant |
+| `side-by-side-btp` | In-system requirement cannot be met with released API or ABAP Cloud; side-by-side BTP extension feasible | Rebuild as BTP CAP or SAP Build extension consuming released OData or API Management APIs |
+| `defer-with-exemption` | Conversion-blocking risk, but business-critical and no replacement available before go-live | Request formal ATC exemption with documented justification and owner; plan post-go-live remediation |
+| `escalate` | Cannot classify without live system data or additional ATC output from user | Redirect to `sap-live-readonly-landscape-discovery` or request ATC export |
+
+## Deprecated API replacement patterns (common examples)
+
+These patterns appear frequently in ATC S/4HANA readiness findings. Verify all replacement candidates on SAP API Business Hub before recommending.
+
+| Deprecated pattern | Replacement direction |
+|-------------------|----------------------|
+| Direct SELECT on `MARA`, `MARC`, `MAKT` and other material master transparent tables | Released OData APIs for Material Master (verify C1 contract on api.sap.com) |
+| `CALL FUNCTION 'BAPI_MATERIAL_GETLIST'` (non-released BAPI) | Released SAP API for material data with C1 contract; verify on api.sap.com |
+| `CALL FUNCTION 'ENQUE_*'` internal enqueue FMs | Use `cl_abap_enq_*` classes or lock objects with released contracts |
+| `CALL SCREEN` / `CALL DIALOG` in ABAP Cloud objects | Replace with Fiori/UI5 or SAP Build Apps for UI-facing logic; no screen calls in ABAP Cloud |
+| Classic BAdI via `CALL CUSTOMER FUNCTION` / user exit | Implement new ABAP Objects BAdI with released enhancement spot |
+| Access to internal DDIC structures (no release contract) | Consume data via released CDS views (exposed via OData) or released ABAP APIs |
+
+Note: This table is illustrative. Verify all replacements against the user's specific S/4HANA release and API Business Hub contract for the exact API proposed.
+
+## Remediation decision tree (per ATC finding or deprecated object)
+
+1. **Is the custom object's entire business function now covered by SAP standard S/4HANA?**
+   - Yes → Retire. Confirm with business stakeholder. No remediation coding required.
+   - No → Continue to step 2.
+
+2. **Is there a released C1/C2 SAP API that covers the deprecated function call or internal table access?**
+   - Yes → Refactor to consume the released API. Verify contract on api.sap.com.
+   - No → Continue to step 3.
+
+3. **Does the deprecated construct violate ABAP Cloud language constraints (forbidden statement)?**
+   - Yes → Rewrite using ABAP Cloud permitted constructs. Run ATC with `SCI_ABAP_CLOUD_READINESS` variant to verify.
+   - No → Continue to step 4.
+
+4. **Is the requirement a transactional ABAP extension feasible in ABAP Cloud RAP?**
+   - Yes → Plan ABAP Cloud RAP remediation. Use `sap-abap-cloud-rap-review` for detailed RAP modeling guidance.
+   - No → Continue to step 5.
+
+5. **Is the requirement addressable as a side-by-side BTP extension?**
+   - Yes → Plan CAP/SAP Build extension consuming released OData or API Management APIs. No in-system ABAP retained.
+   - No → Formally assess for ATC exemption with documented justification and post-go-live remediation plan.
+
+## Workflow
+
+1. **Receive artifacts** — ATC export (XML, XLS, or described findings), SYCM output, ABAP source code, or object list.
+2. **Identify ATC check variant** — confirm `SCI_S4HANA_READINESS`, `SCI_ABAP_CLOUD_READINESS`, or describe variant if unknown.
+3. **Classify each finding** by severity (blocker / error / warning / information).
+4. **Apply disposition taxonomy** — assign retire / replace-standard / remediate-released-api / remediate-abap-cloud / side-by-side-btp / defer-with-exemption / escalate per finding class.
+5. **Map deprecated APIs** — identify deprecated patterns and proposed released replacements; direct to api.sap.com for contract verification.
+6. **Prioritize** — blocker and error findings first; then warning with business impact; then advisory.
+7. **Return output** per the output contract below.
+
+## Output contract
+
+Return:
+
+1. ATC check variant used and finding severity distribution
+2. Evidence label per finding group (documentation-based / user-provided evidence / inference)
+3. Finding classification table: object, deprecated pattern, severity, disposition
+4. Deprecated API replacement mapping (with api.sap.com verification instruction for each replacement)
+5. Risk level per dimension (upgrade-blocking / clean-core-non-compliant / technically-functional / compliant)
+6. Prioritized remediation plan with timeline recommendation relative to conversion phases
+7. Escalation trigger if live system ATC execution or additional artifact is needed before classification

package/skills/sap/sap-data-migration-cutover-readiness/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: sap-data-migration-cutover-readiness
+description: Review data migration and cutover READINESS for an SAP S/4HANA transformation. Assesses SAP Migration Cockpit approach, data quality and validation gate completeness, mock run results, cutover plan structure, rollback and fallback viability, reconciliation strategy, and go/no-go criteria. Advisory only — never executes migration, cutover, or any live data movement. Use when assessing whether a program is ready to proceed to cutover, not when executing one.
+allowed-tools: Read Grep Glob WebSearch WebFetch
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-19"
+  category: delivery
+  lifecycle: experimental
+---
+
+# SAP Data Migration and Cutover Readiness Review
+
+## Purpose
+
+Assess whether an SAP S/4HANA transformation program is ready to proceed to data migration execution and system cutover. Review the SAP Migration Cockpit (LTMC/LTMOM) approach and migration object scope, evaluate data quality and validation gate completeness, interpret mock run results and open issues, assess cutover plan structure and sequencing, evaluate rollback and fallback plan viability, review reconciliation strategy and sign-off process, and validate that go/no-go criteria are formally defined and measurable. This is an advisory readiness review. It does not execute, trigger, or assist in executing any data migration, cutover action, or live system change.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- assess whether the data migration approach (SAP Migration Cockpit, LTMC, LTMOM, or third-party ETL) is correctly scoped and configured for their S/4HANA transformation,
+- review data quality results from extraction, validation, or mock migration runs and classify open data quality issues by severity,
+- evaluate the completeness of cutover plan documentation: task list, sequencing, duration estimates, responsible parties, and dependency mapping,
+- assess whether mock run results (mock run 1, mock run 2, dress rehearsal) indicate readiness or outstanding risk for go-live,
+- review rollback and fallback procedures: technical feasibility, activation triggers, decision authority, and time-to-rollback estimates,
+- validate that reconciliation checks (financial totals, open items, inventory balances, master data record counts) are defined and will be executed at cutover,
+- assess whether go/no-go criteria are formally documented with measurable thresholds and a named decision authority,
+- identify data migration readiness gaps that would represent unacceptable risk for proceeding to production cutover.
+
+## When not to use
+
+- When the user wants to execute a data migration or cutover — this skill does not assist with execution. A separate guarded live-execution agent would be required for that purpose.
+- When the user needs a transformation strategy assessment (brownfield vs greenfield) — use `sap-s4hana-transformation-architecture-review`.
+- When the user needs custom code remediation review — use `sap-custom-code-remediation-review`.
+- When the user needs live transport management — use `sap-guarded-transport-import`.
+- When live system discovery is needed to enumerate migration objects or open cutover tasks — use `sap-live-readonly-landscape-discovery` first.
+
+## Advisory-only boundary — explicitly stated
+
+**This skill does not execute, trigger, or assist in executing any data migration, cutover, or live system change.** It does not:
+- connect to any SAP system, LTMC/LTMOM session, or Migration Cockpit tenant,
+- trigger migration runs, transformation jobs, staging table loads, or cutover scripts,
+- approve, authorize, or initiate go/no-go decisions for live cutovers,
+- access production data, financial records, or business partner master data.
+
+All readiness assessment is based on documentation, mock run reports, cutover plan documents, and data quality validation outputs supplied by the user. Live cutover execution is a risk-critical mutating operation that requires a separate, explicitly guarded execution skill with approval gates and rollback controls.
+
+## Lean operating rules
+
+- Readiness is binary per gate. Each readiness dimension (data quality, mock run completion, cutover plan, rollback, reconciliation, go/no-go criteria) is either sufficiently complete or not. Partial completion is classified as a gap, not as partial readiness.
+- Mock run evidence is required before assessing cutover readiness. A program cannot be assessed as cutover-ready without at least one completed mock run with documented results. Dress rehearsal results carry the most weight.
+- Data quality thresholds must be explicit. "Data quality is good" is not a sufficient readiness indicator. Thresholds must be defined (e.g., error rate < 1% for master data; 0% error tolerance for financial open items) and the last validation run must have met or exceeded those thresholds.
+- Rollback must be time-bounded. A rollback plan that says "restore from backup if needed" without a documented time-to-rollback estimate and activation threshold is not a credible rollback plan.
+- Go/no-go criteria must have a named decision authority. Go/no-go criteria documented but with no identified decision authority are not enforceable criteria.
+- Do not fabricate mock run statistics or data quality metrics. Only classify findings the user has provided from their actual mock run reports or validation outputs.
+- Evidence from official SAP sources takes precedence over memory or training data.
+
+## Evidence rules
+
+Label all claims with one of:
+
+- `documentation-based` — grounded in SAP Migration Cockpit docs, SAP Activate cutover methodology, or SAP Help Portal
+- `user-provided evidence` — mock run reports, data quality validation outputs, cutover plan documents, go/no-go checklists, or reconciliation templates provided by the user
+- `inference` — derived reasoning not directly confirmed by official docs or user evidence; must always be labeled
+
+## Live-environment rules
+
+**This skill does not touch live systems.** There is no credential, API call, RFC connection, LTMC session, or SAP system access in this skill's execution path. Users must supply mock run reports, cutover plan documents, data quality outputs, and written descriptions of their migration approach and readiness status for this skill to review.
+
+## References
+
+Load only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — readiness gate taxonomy, assessment dimensions, cutover plan evaluation criteria, output format.
+- [Safety checklist](references/safety-checklist.md) — non-negotiables, common readiness assessment mistakes, advisory boundary enforcement, when to push back.
+- [Official sources](references/official-sources.md) — SAP Migration Cockpit, LTMC/LTMOM, SAP Activate cutover methodology, data validation and reconciliation guidance.
+
+## Response minimum
+
+Return, at minimum:
+
+- **Problem classification**: migration approach (SAP Migration Cockpit / LTMC / LTMOM / third-party ETL), migration object scope, and current readiness phase (pre-mock / mock run 1 complete / mock run 2 complete / dress rehearsal complete).
+- **Evidence used**: documentation-based / user-provided evidence / inference.
+- **Risk level**: cutover-blocking / high-risk / medium-risk / low-risk per readiness gate assessed.
+- **Recommended action**: gap remediation recommendation per readiness dimension, grounded in SAP Activate cutover methodology or Migration Cockpit guidance.
+- **Refusal / escalation triggers**: refuse to assess execution readiness if no mock run results are available; escalate to live system discovery if migration object inventory is unknown; do not provide execution guidance under any circumstances.
+- **Business impact**: go-live date risk, data integrity risk in production, rollback window implications, financial close impact.
+- **Next verification step**: which readiness gate or mock run evidence must be provided before the program can be assessed as cutover-ready.

package/skills/sap/sap-data-migration-cutover-readiness/agents/openai.yaml

@@ -0,0 +1,14 @@
+interface:
+  display_name: "SAP Data Migration and Cutover Readiness Review"
+  short_description: "Advisory readiness review for SAP S/4HANA data migration and cutover — assess Migration Cockpit approach, data quality gates, mock run results, cutover plan completeness, rollback viability, reconciliation, and go/no-go criteria. Never executes migration or cutover."
+  default_prompt: "Use $sap-data-migration-cutover-readiness to review the data migration and cutover readiness posture. Classify the migration approach (SAP Migration Cockpit / LTMC / third-party ETL), identify which readiness gates have been met and which have open gaps (data quality thresholds, mock run completion, cutover plan, rollback plan, reconciliation, go/no-go criteria), and surface cutover-blocking risks. State evidence level and risk classification per readiness gate. This is advisory only — do not provide execution guidance or authorize go/no-go decisions."
+dependencies:
+  tools:
+    - type: "web"
+      value: "https://help.sap.com/docs/SAP_S4HANA_ON-PREM/d1c4d824383f4aefba12efafb36e5a01"
+      description: "SAP Migration Cockpit (LTMC/LTMOM) documentation — verify migration object support, staging table approach, validation run procedures, and error handling guidance"
+    - type: "web"
+      value: "https://help.sap.com/docs/SAP_ACTIVATE"
+      description: "SAP Activate cutover methodology — verify cutover planning deliverables, mock run sequence requirements, and go/no-go gate definitions"
+policy:
+  allow_implicit_invocation: true

package/skills/sap/sap-data-migration-cutover-readiness/metadata.json

@@ -0,0 +1,32 @@
+{
+  "id": "sap-data-migration-cutover-readiness",
+  "name": "SAP Data Migration and Cutover Readiness Review",
+  "type": "skill",
+  "provider": "sap",
+  "harnesses": [
+    "claude-code",
+    "codex",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Advisory readiness review for SAP S/4HANA data migration and cutover: assess SAP Migration Cockpit approach, data quality validation gates, mock run results, cutover plan completeness, rollback and fallback viability, reconciliation strategy, and go/no-go criteria. Never executes migration or cutover — advisory only.",
+  "source_type": "original",
+  "category": "delivery",
+  "official_docs": [
+    "https://help.sap.com/docs/sap-s4hana-on-premise/sap-s4hana-on-premise/migration-cockpit-overview",
+    "https://help.sap.com/docs/sap-s4hana-on-premise/sap-s4hana-on-premise/migration-objects",
+    "https://help.sap.com/docs/sap-s4hana-on-premise/sap-s4hana-on-premise/staging-tables",
+    "https://help.sap.com/docs/sap-s4hana-on-premise/sap-s4hana-on-premise/simulation-and-validation",
+    "https://help.sap.com/docs/sap-activate/sap-activate-methodology/cutover-planning",
+    "https://help.sap.com/docs/sap-s4hana-cloud/sap-s4hana-cloud/reconciliation",
+    "https://help.sap.com/docs/sap-s4hana-cloud/sap-s4hana-cloud/data-migration-to-sap-s4hana-cloud"
+  ],
+  "security_notes": "Does not access live SAP systems. Accepts only user-provided documentation: mock run reports, data quality validation outputs, cutover plan documents, go/no-go checklists, and reconciliation templates. Never request or accept SAP system credentials, LTMC/LTMOM session tokens, database connection strings, or production data extracts. Does not execute, trigger, or advise on execution of any data migration run, cutover step, or live system change. Never provides go/no-go authorization — that authority belongs to the customer project governance body.",
+  "last_verified": "2026-06-19",
+  "path": "skills/sap/sap-data-migration-cutover-readiness",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "lifecycle": "experimental"
+}

package/skills/sap/sap-data-migration-cutover-readiness/references/official-sources.md

@@ -0,0 +1,73 @@
+# Official sources — SAP Data Migration and Cutover Readiness Review
+
+Use this reference when grounding SAP Migration Cockpit configuration assessment, LTMC/LTMOM approach review, cutover methodology guidance, data quality validation interpretation, and go/no-go criteria evaluation.
+
+**Evidence level**: documentation-based (SAP Help Portal, SAP Activate portal). No live-system evidence is collected by this skill.
+
+## SAP Migration Cockpit (LTMC/LTMOM)
+
+- SAP Migration Cockpit — overview
+  https://help.sap.com/docs/sap-s4hana-on-premise/sap-s4hana-on-premise/migration-cockpit-overview
+  source_owner: SAP SE
+  topic_supported: SAP Migration Cockpit (LTMC / LTMOM) architecture; migration project setup; migration object types; staging table approach vs. direct transfer approach; scope and prerequisites
+  why_needed: Primary reference for assessing whether the user's Migration Cockpit configuration and migration object scope are appropriate for their business data migration requirements
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- SAP Migration Cockpit — migration objects
+  https://help.sap.com/docs/sap-s4hana-on-premise/sap-s4hana-on-premise/migration-objects
+  source_owner: SAP SE
+  topic_supported: Supported migration objects (business partners, materials, open items, balances, purchase orders, sales orders, assets); object dependencies and sequencing; data mapping templates
+  why_needed: Defines which business objects can be migrated via SAP Migration Cockpit and what sequencing dependencies exist — used to assess migration object scope completeness and sequencing risk
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- SAP Migration Cockpit — staging tables
+  https://help.sap.com/docs/sap-s4hana-on-premise/sap-s4hana-on-premise/staging-tables
+  source_owner: SAP SE
+  topic_supported: Staging table approach: staging table structure, data load into staging tables, field mapping and transformation, staging table validation
+  why_needed: Defines the staging table approach used by most LTMC migration projects — required to assess whether staging data load and mapping steps are complete before productive migration
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- SAP Migration Cockpit — simulation and validation
+  https://help.sap.com/docs/sap-s4hana-on-premise/sap-s4hana-on-premise/simulation-and-validation
+  source_owner: SAP SE
+  topic_supported: Migration run phases (Read, Convert, Write); validation run (dry run / simulation) before productive run; error log interpretation; error correction and re-run approach
+  why_needed: Grounds assessment of mock run completeness — specifically whether the user has completed validation runs for each migration object and resolved errors before productive migration
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## S/4HANA Cloud data migration
+
+- SAP S/4HANA Cloud — data migration to SAP S/4HANA Cloud
+  https://help.sap.com/docs/sap-s4hana-cloud/sap-s4hana-cloud/data-migration-to-sap-s4hana-cloud
+  source_owner: SAP SE
+  topic_supported: Data migration approach for S/4HANA Cloud Public Edition; cloud-specific constraints on migration object support; difference between on-premise Migration Cockpit and cloud Migration Cockpit
+  why_needed: Required when assessing readiness for S/4HANA Cloud Public Edition migration — the cloud variant has a different tool interface and more restricted migration object catalog than the on-premise LTMC
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP Activate cutover methodology
+
+- SAP Activate — cutover planning
+  https://help.sap.com/docs/sap-activate/sap-activate-methodology/cutover-planning
+  source_owner: SAP SE
+  topic_supported: SAP Activate Deploy phase cutover deliverables: cutover plan structure, mock run sequence (mock run 1 → mock run 2 → dress rehearsal), go/no-go gate definition, hypercare plan
+  why_needed: Authoritative methodology reference for assessing whether the user's cutover plan structure and mock run sequence meet SAP Activate recommended standards
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Reconciliation and financial data validation
+
+- S/4HANA Cloud — reconciliation of migrated data
+  https://help.sap.com/docs/sap-s4hana-cloud/sap-s4hana-cloud/reconciliation
+  source_owner: SAP SE
+  topic_supported: Financial data migration reconciliation: G/L balance migration approach, open item migration validation, asset accounting migration cutover, reconciliation account balancing
+  why_needed: Critical reference for assessing financial reconciliation strategy completeness — financial data migration is the highest-risk migration object category with zero tolerance for balance discrepancies
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Grounding rule
+
+SAP Help Portal and SAP Activate documentation describe migration tool capabilities, recommended cutover methodology, and validation approaches. They do not prove which migration objects the user's program has scoped, what error rates appear in the user's actual mock runs, whether the user's data quality meets the thresholds needed for go-live, or whether the user's rollback plan is technically executable in their specific landscape. Users must supply mock run reports, validation outputs, cutover plan documents, and data quality results for concrete readiness assessment.

package/skills/sap/sap-data-migration-cutover-readiness/references/safety-checklist.md

@@ -0,0 +1,51 @@
+# Safety checklist — SAP Data Migration and Cutover Readiness Review
+
+Use before making any readiness assessment, gap classification, or recommendation related to data migration or cutover planning.
+
+## Non-negotiables
+
+- Do not access, connect to, or request access to any live SAP system, migration staging environment, LTMC session, or production landscape.
+- Do not accept or request SAP system credentials, LTMC/LTMOM session tokens, database connection strings, RFC destinations, BTP service keys, or any extracts of production data.
+- Do not execute, trigger, assist in executing, or provide step-by-step execution guidance for any data migration run, cutover step, or live system change. This skill is advisory only.
+- Do not authorize or imply authorization for a go/no-go decision. Go/no-go authority belongs to the customer project governance body with a named decision owner. This skill can assess whether criteria are met based on user-provided evidence, but cannot authorize the decision.
+- Do not assess cutover readiness if no mock run results have been provided. A program without at least one completed mock run cannot be assessed as ready or not-ready — insufficient evidence.
+- Do not fabricate migration error rates, mock run durations, or data quality metrics. Only classify findings the user has provided from their actual migration reports or validation outputs.
+- Do not recommend proceeding to production cutover when cutover-blocking gaps are identified. Always surface blocking gaps first.
+
+## Advisory-only boundary enforcement
+
+If the user asks this skill to:
+- "run the migration,"
+- "trigger the cutover,"
+- "start the productive run,"
+- "help me execute step X of the cutover plan,"
+- "approve the go/no-go,"
+
+respond: This skill is an advisory readiness reviewer and does not execute, trigger, or authorize any data migration, cutover action, or go/no-go decision. For live execution of migration runs, a separate guarded live-execution agent with approval gates and rollback controls would be required.
+
+## What people get wrong
+
+- **Treating mock run 1 as sufficient for dress rehearsal**: Mock run 1 identifies issues. Mock run 2 validates remediation. Dress rehearsal validates the full cutover plan execution including duration and sequencing. Skipping from mock run 1 to production cutover is a high-risk shortcut.
+- **Treating validation run results as equivalent to productive run readiness**: A successful Migration Cockpit validation run (dry run / simulation) confirms that data can be transformed correctly. It does not confirm that all source data is extracted, that all dependencies are sequenced correctly, or that the productive write will complete within the cutover window. Validation run success is necessary but not sufficient.
+- **Accepting subjective go/no-go criteria**: "Data quality is good enough" and "the team is confident" are not measurable go/no-go criteria. Thresholds must be numeric (e.g., zero errors on financial open items; < 0.5% error rate on material master) and formally approved by the project governance body.
+- **Treating rollback as a technical afterthought**: Rollback feasibility depends on infrastructure configuration (database point-in-time restore capability, snapshot strategy, legacy system availability during cutover window). Many programs discover their rollback is not technically executable at dress rehearsal. Rollback viability must be tested, not assumed.
+- **Scoping migration objects late**: Programs that discover missing migration object scope in the Realize phase or late in Deploy face compressed timelines for data mapping, validation template creation, and mock run completion. Migration object scope must be confirmed in the Explore phase.
+- **Ignoring financial close timing**: Production cutover during or near a financial period-end close creates compounding reconciliation risk. Cutover timing should align with a low-activity financial period wherever possible. If not possible, the go/no-go criteria must explicitly address period-end implications.
+- **Assuming third-party ETL is equivalent to SAP Migration Cockpit**: Third-party ETL tools are not certified by SAP for Migration Cockpit-equivalent support. Programs using third-party tools must document explicit risk acceptance and ensure the tool has been validated against the target S/4HANA release.
+
+## When to push back
+
+- Push back when the user wants a readiness assessment without providing any mock run results or data quality validation output.
+- Push back when the go/no-go criteria are subjective or have no named decision authority.
+- Push back when the rollback plan is "restore from backup" with no tested time-to-rollback estimate.
+- Push back when financial reconciliation checks are not defined for G/L balances and open items.
+- Push back when the user describes a production cutover timeline with no dress rehearsal completed.
+- Push back when the user asks for execution guidance for any migration run step or cutover task.
+- Push back when the migration object scope has not been confirmed as complete and sequenced.
+- Push back when the user wants to proceed to go-live without a hypercare plan.
+
+## Evidence labels
+
+- `documentation-based` — grounded in SAP Migration Cockpit docs, SAP Activate cutover methodology, or SAP Help Portal
+- `user-provided evidence` — mock run reports, data quality validation outputs, cutover plan documents, go/no-go checklists, or reconciliation templates 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-data-migration-cutover-readiness/references/workflow-and-output.md

@@ -0,0 +1,85 @@
+# Workflow and output contract — SAP Data Migration and Cutover Readiness Review
+
+Use this reference for all readiness gate assessment, cutover plan evaluation, and output formatting.
+
+## Migration approach taxonomy
+
+| Approach | Description | Readiness considerations |
+|----------|-----------|------------------------|
+| `sap-migration-cockpit-staging` | LTMC/LTMOM staging table approach: data extracted to staging tables, transformed, validated in simulation run before productive run | Requires completed validation run per migration object; error rate thresholds must be defined and met |
+| `sap-migration-cockpit-direct` | Direct transfer approach (on-premise to S/4HANA on same system) | Available only for specific brownfield scenarios; fewer migration objects supported |
+| `sap-migration-cockpit-cloud` | Cloud variant for S/4HANA Cloud Public Edition: reduced migration object catalog, SaaS-delivered tool | Cloud-specific object catalog limitations must be assessed against scope |
+| `third-party-etl` | Customer or partner ETL tooling (e.g., Syniti, SNP, or custom extraction/load) outside SAP Migration Cockpit | Requires proof of SAP certification or explicit customer acceptance of unsupported tool risk |
+
+## Readiness gate taxonomy
+
+Each gate is assessed as: `PASS` / `PARTIAL` / `FAIL` / `NOT-YET-ASSESSED`
+
+| Gate | Minimum pass criteria | Common failure modes |
+|------|----------------------|---------------------|
+| `migration-object-scope` | All business objects required for go-live are in scope with confirmed Migration Cockpit or ETL support | Missing migration object types; financial objects not scoped; master data dependencies not sequenced |
+| `data-quality-thresholds` | Error rate thresholds are explicitly defined per object type; last validation run results are below threshold | No defined thresholds; threshold met for master data but not transactional data; error rate not measured |
+| `mock-run-completion` | At minimum mock run 1 completed with documented results; dress rehearsal ideally complete before go-live assessment | No mock runs completed; mock runs completed but results not formally documented; open errors unresolved |
+| `cutover-plan-structure` | Cutover plan includes: task list with owner and duration, sequencing with dependencies, critical path identified, system downtime window defined | Generic task list with no durations; no critical path; no defined downtime window |
+| `rollback-plan-viability` | Rollback procedure documented with: activation threshold, time-to-rollback estimate, named decision authority, technical steps | Rollback is "restore from backup" with no time estimate; no named authority to trigger rollback |
+| `reconciliation-strategy` | Reconciliation checks defined for: financial totals (G/L balances, open items), master data record counts, inventory quantities; sign-off process defined | No financial reconciliation checks; reconciliation checks defined but no sign-off authority named |
+| `go-no-go-criteria` | Go/no-go criteria are measurable (specific thresholds), named decision authority identified, criteria formally documented | Criteria exist but are subjective ("quality is acceptable"); no named decision authority; criteria not formally approved |
+| `hypercare-plan` | Hypercare period defined with: support coverage, escalation path, rollback activation window, and business process monitoring | No hypercare plan; hypercare period too short for financial close or period-end processing |
+
+## Mock run maturity model
+
+| Stage | Mock run | Evidence required | Readiness signal |
+|-------|---------|-----------------|-----------------|
+| Pre-mock | Not yet started | None | Not ready for any cutover assessment |
+| Mock run 1 | First end-to-end trial with production-representative data | Migration log with error counts per object; identified gaps | Initial risk surface; remediation plan required |
+| Mock run 2 | Second trial after mock run 1 gaps resolved | Updated migration log showing error reduction; duration improvement | Remediation effectiveness confirmed; cutover duration more reliable |
+| Dress rehearsal | Final cutover simulation including all cutover tasks in sequence | Full cutover task log with actual duration; all reconciliation checks executed | Highest confidence readiness signal; remaining gaps are go/no-go blockers |
+
+## Cutover plan assessment criteria
+
+A complete cutover plan must include for each task:
+
+- Task description and owner (named individual, not just role)
+- Duration estimate (in hours/minutes)
+- Predecessor and successor dependencies
+- Go/no-go decision point (which tasks are critical path vs. parallel)
+- System downtime window confirmed with business stakeholders
+- Escalation contact if task is delayed beyond buffer
+
+Assess the user's cutover plan against these criteria. Flag missing elements as readiness gaps.
+
+## Rollback plan viability criteria
+
+A viable rollback plan must include:
+
+- Activation threshold: objective criteria that trigger rollback (e.g., "if reconciliation error rate > 0.5% on financial open items after productive run")
+- Time-to-rollback: estimated duration from trigger decision to system available for legacy operation
+- Named decision authority: who can authorize rollback (named individual + backup)
+- Technical steps: what happens technically to restore legacy system availability (point-in-time restore, database fallback, transport reversal)
+- Business impact of rollback: what business processes must restart; what data entered during production downtime window is lost
+
+## Workflow
+
+1. **Identify migration approach** — confirm tooling: Migration Cockpit (staging/direct/cloud), third-party ETL, or hybrid.
+2. **Assess migration object scope** — confirm all required business objects are scoped and sequencing dependencies are documented.
+3. **Evaluate data quality gates** — confirm thresholds are defined and last validation run results meet or exceed thresholds.
+4. **Review mock run maturity** — confirm mock run stage (pre-mock / mock run 1 / mock run 2 / dress rehearsal) and assess documented results.
+5. **Evaluate cutover plan structure** — assess task list completeness, duration estimates, critical path, and downtime window.
+6. **Assess rollback plan viability** — check against viability criteria above.
+7. **Review reconciliation strategy** — confirm financial, master data, and inventory reconciliation checks are defined with sign-off process.
+8. **Validate go/no-go criteria** — confirm criteria are measurable, formally documented, and have named decision authority.
+9. **Assign overall readiness posture** — `cutover-ready` (all gates PASS) / `conditional` (minor gaps with mitigation) / `not-ready` (one or more gates FAIL or cutover-blocking gap).
+10. **Return output** per the output contract below.
+
+## Output contract
+
+Return:
+
+1. Migration approach classification and current readiness phase (mock run stage)
+2. Evidence label per dimension (documentation-based / user-provided evidence / inference)
+3. Readiness gate assessment table: gate name, status (PASS/PARTIAL/FAIL/NOT-YET-ASSESSED), gap description
+4. Overall readiness posture: cutover-ready / conditional / not-ready
+5. Risk level per gate (cutover-blocking / high / medium / low)
+6. Prioritized gap remediation recommendations with SAP Activate or Migration Cockpit reference
+7. Escalation trigger if live system data or additional mock run evidence is needed before readiness can be assessed
+8. Explicit advisory boundary reminder: this review does not authorize, execute, or assist in executing any migration or cutover action