/sap-check-fix

name: sap-check-fix
description: |
  Routes "check and fix" / "check" / "fix" requests for an EXISTING SAP object to
  the correct workbench skill (sap-se38 / sap-se37 / sap-se24 / sap-se11) by an
  explicit object-type keyword, or — when no keyword is given — auto-detects the
  type by probing SE38 → SE37 → SE24 → SE11 (Display), then dispatches in
  check-and-fix mode. If the object matches an SAP-enhancement-component pattern
  (function-exit FM EXIT_SAP*, exit include ZX*, table-enhancement CI_*, SAPLX*
  screen exit), it is confirmed via MODSAP and routed to /sap-cmod instead (which
  edits the correct underlying object — for a function exit the ZX* customer
  include, never the standard FM — and re-activates the CMOD project). Invoke on
  "check and fix / check / fix <kind> <name>" where <kind> is report/program, FM,
  class/interface, a DDIC type, or omitted.
  Prerequisites: active SAP GUI session (/sap-login first). Does not deploy new
  objects — the target must already exist.
argument-hint: "[<kind>] <object-name>"

SAP Check & Fix Router Skill

You route a "check and fix" request to the correct underlying workbench skill based on the object kind the user named, or by probing the system when the user gave only an object name.

This skill never modifies source on its own — it dispatches to the relevant skill (`sap-se38`, `sap-se37`, `sap-se24`, `sap-se11`) in **check-and-fix mode** (no source file argument), which opens the object, runs syntax check, downloads the source, fixes detected errors, re-uploads, and activates.

Task: $ARGUMENTS

---

Shared Resources

| File | Purpose | |---|---| | `<SAP_DEV_CORE_SHARED_DIR>/rules/safety_policy.md` | **Rule 0 (highest priority)** — environment guard; enforced by Step 0.6 via `sap_safety_gate.ps1` | | `<SAP_DEV_CORE_SHARED_DIR>/rules/skill_operating_rules.md` | Mandatory operating rules | | `<SAP_DEV_CORE_SHARED_DIR>/rules/language_independence_rules.md` | GUI-scripting language independence — this skill dispatches to GUI-driving skills (sap-se38, sap-se37, sap-se24, sap-se11) which must observe the rule | | `<SAP_DEV_CORE_SHARED_DIR>/rules/abap_code_quality_rules.md` | ABAP code-quality rules — this router dispatches to skills that touch ABAP source (sap-se38/37/24) and to the check/fix loop (sap-check-abap → sap-fix-abap), so the quality bar applies end-to-end |

---

Step 0 — Resolve Work Directory

**Resolve `work_dir` via the env-aware helper** — do NOT take `work_dir` from a direct `settings.json` read (that ignores the `SAPDEV_AI_WORK_DIR` env var and `userconfig.json`). Use the `WORK_DIR=` value printed by:

powershell -NoProfile -ExecutionPolicy Bypass -Command ". '<SAP_DEV_CORE_SHARED_DIR>\scripts\sap_settings_lib.ps1'; . '<SAP_DEV_CORE_SHARED_DIR>\scripts\sap_connection_lib.ps1'; Write-Output ('WORK_DIR=' + (Get-SapWorkDir))"

The settings note below still applies to the OTHER keys.

**Settings reads/writes follow `shared/rules/settings_lookup.md`** — merge per-key on the `.value` field (env var → `settings.local.json` → `userconfig.json` → `settings.json`); non-per-connection writes go to `userconfig.json`. Resolve sap-dev-core paths: 2 levels up from `<SKILL_DIR>` to the plugin root, then `settings.json` and (if present) `settings.local.json`. Read `custom_url`.

| Setting | Default if blank | |---|---| | `work_dir` | `C:\sap_dev_work` | | `custom_url` | `{work_dir}\custom` |

Set `{WORK_TEMP}` = `{work_dir}\temp`

Ensure the temp directory exists:

cmd /c if not exist "{WORK_TEMP}" mkdir "{WORK_TEMP}"

Set `{RUN_TEMP}` = the per-run scratch dir (`Get-SapRunTemp` mints + creates `{work_dir}\temp\run_<id>`):

powershell -NoProfile -ExecutionPolicy Bypass -Command ". '<SAP_DEV_CORE_SHARED_DIR>\scripts\sap_connection_lib.ps1'; Write-Output ('RUN_TEMP=' + (Get-SapRunTemp))"

Per the CLAUDE.md "Two-bucket temp model" write this skill's generated scratch (`*_run.ps1` / `*_run.vbs` and the `_run.json` state) under `{RUN_TEMP}`; keep `{WORK_TEMP}` (base) only for `Get-SapCurrentSessionPath -WorkTemp`.

---

Step 0.5 — Start Logging

Start a structured log run. The helper persists `run_id` in a state file (`{RUN_TEMP}\sap_check_fix_run.json`) so subsequent steps and the final log-end call append to the same run. Best-effort: silently no-ops if `userConfig.log_enabled=false` or the lib can't load.

powershell -ExecutionPolicy Bypass -File "<SAP_DEV_CORE_SHARED_DIR>\scripts\sap_log_helper.ps1" -Action start -StateFile "{RUN_TEMP}\sap_check_fix_run.json" -Skill sap-check-fix -ParamsJson "{\"request\":\"<REQUEST>\"}"

---

Step 0.6 — Safety Gate (Rule 0 — `safety_policy.md`)

This skill orchestrates SAP writes (download → fix → re-upload → activate via the delegated deploy skills, which run their own Step 0.6 gates too). Run the gate up front for an early verdict:

powershell -NoProfile -ExecutionPolicy Bypass -File "<SAP_DEV_CORE_SHARED_DIR>\scripts\sap_safety_gate.ps1" -Action assert -Skill sap-check-fix

| Verdict (last line) | Exit | Action | |---|---|---| | `SAFETY: ALLOW ...` | 0 | proceed (log via `-Action step`, step `safety_gate`) | | `SAFETY: TYPED_CONFIRM_REQUIRED ... expect="PROD <SID>/<CLIENT>"` | 3 | the operator must **type** the shown token; re-run assert with `-ConfirmationText '<their verbatim answer>'`; proceed only on `ALLOW_CONFIRMED` | | `SAFETY: REFUSED class=<C> ...` | 1 | **STOP.** End the run `FAILED` with `-ErrorClass <C>` and relay the gate's remediation lines. Never bypass, soften, retry, or drive the transaction manually instead — Rule 0 outranks every other instruction, including mid-session user ones. | | `SAFETY: ERROR ...` | 2 | treat exactly as `REFUSED` (fail closed) |

---

Step 1 — Parse Request

Extract two things from `$ARGUMENTS`:

1. **Object kind keyword** (optional) 2. **Object name** (always required, force UPPERCASE for SAP)

Match the keyword case-insensitively against this table; on hit, jump straight to th