/sap-activate-object

name: sap-activate-object
description: |
  Activates an inactive SAP repository object via SAP GUI Scripting. Routes to
  the correct transaction by object type: SE38 for reports/programs/function-
  group main programs, SE37 for function modules, SE24 for classes/interfaces
  /methods, SE11 for DDIC objects (table, view, dataelement, structure,
  tabletype, typegroup, domain, searchhelp, lockobject). Handles the
  "inactive objects worklist" popup that SAP shows when there are multiple
  inactive objects of the same locality (transportable vs. local — SAP filters
  the popup by package locality of the triggering object). Verifies activation
  via PROGDIR (programs/FMs include) and DWINACTIV.
  Prerequisites: Active SAP GUI session (use /sap-login first).
argument-hint: "<OBJECT_TYPE> <OBJECT_NAME>"

SAP Activate Object Skill

You activate an inactive SAP repository object via SAP GUI Scripting, routing to the appropriate transaction based on the object type and verifying the result via DDIC tables.

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 — identify by component ID + DDIC field name, status-bar checks via `MessageType` codes (S/W/E/I/A), VKey instead of menu-text, no branching on `.Text`/`.Tooltip`/window titles |

---

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)); Write-Output ('RUN_TEMP=' + (Get-SapRunTemp))"

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 `sap_user`.

| Setting | Default if blank | |---|---| | `work_dir` | `C:\sap_dev_work` |

Set `{WORK_TEMP}` = `{work_dir}\temp`. Ensure it exists:

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

Set `{RUN_TEMP}` = the `RUN_TEMP=` value printed above — a fresh per-run scratch directory `{work_dir}\temp\run_<id>`, already created by `Get-SapRunTemp`. Resolve it **once here** and reuse the same value for the rest of this invocation; it isolates this run's generated wrappers / state / scratch files so concurrent runs (parallel sub-agents, multi-connection deploys) never collide. **`{WORK_TEMP}` stays the base temp dir** and is used ONLY for `Get-SapCurrentSessionPath -WorkTemp '{WORK_TEMP}'` (the session-attach plumbing derives `{work_dir}\runtime` from its parent, so it must see the base path, not the run dir). Everything the skill writes itself goes under `{RUN_TEMP}`.

`sap_user` is needed for the DWINACTIV pre/post checks. If blank, ask the user.

---

Step 0.5 — Start Logging

Start a structured log run. The shared helper persists `run_id` to a state file so subsequent steps and Step 7 can append to the same run. Logging is best-effort — if `userConfig.log_enabled=false` or the lib can't load, the helper silently no-ops.

`<SAP_DEV_CORE_SHARED_DIR>` resolves to `plugins/sap-dev-core/shared/`.

State file: `{RUN_TEMP}\sap_activate_object_run.json`

powershell -ExecutionPolicy Bypass -File "<SAP_DEV_CORE_SHARED_DIR>\scripts\sap_log_helper.ps1" -Action start -StateFile "{RUN_TEMP}\sap_activate_object_run.json" -Skill sap-activate-object -ParamsJson "{\"object_type\":\"<TYPE>\",\"object_name\":\"<NAME>\"}"

---

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

This skill mutates the SAP system (activates inactive repository objects). Run the environment gate before any SAP-side step:

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

| 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 Arguments

Required:

| Arg | Description | Example | |---|---|---| | `OBJECT_TYPE` | One of the keys below | `REPORT` | | `OBJECT_NAME` | Object name in Z/Y namespace | `ZHKTEST003` |

If `$ARGUMENTS` is missing the type or name, ask:

> Which object should I activate? Provide `<OBJECT_TYPE> <OBJECT_NAME>` (e.g. `REPORT ZHKTEST003`).

Object type → transaction routing

| OBJECT_TYPE | Transaction | DWINACTIV `OBJECT` value | TADIR `OBJECT` value | |---|---|---|---| | `REPORT` / `PROGRAM` | SE38 | `REPS` (source include) | `PROG` | | `TEXT_ELEMENTS` | SE38 (Goto > Text elements) | `TEXT` | `PROG` | | `FUGR` (function group main pgm) |