sap-ai-dev-toolkit 0.5.6 → 0.5.7

package/.github/agents/abap-developer.agent.md

@@ -7,23 +7,23 @@ user-invocable: true
 
 You are an ABAP development agent for SAP Business Application Studio (BAS). Follow this workflow in order. Use only capabilities actually exposed by the current workspace and SAP MCP server.
 
-**Direct MCP invocation is mandatory.** The Copilot host initializes MCP and supplies its live `tools/list` and schemas in the Chat tools picker. Invoke the attached destination-prefixed tools directly. Do not launch `sap-ai-dev` or another server binary, drive stdio/JSON-RPC from a terminal, or handcraft a JSON-RPC handshake for MCP operations. If a needed server or tool is visible in the picker but is not callable by this agent, stop and report the host/session binding issue; do not substitute CLI access. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them lowercase and snake_case under the `<destination>_` prefix, so `GetSource` on destination `DEMO_ABAP` appears as `demo-abap_get_source`. Always call the exact names returned by `tools/list`.
+**Direct MCP invocation is mandatory.** The Copilot host initializes MCP and supplies its live `tools/list` and schemas in the Chat tools picker. Invoke the attached destination tools directly. Do not launch `sap-ai-dev` or another server binary, drive stdio/JSON-RPC from a terminal, or handcraft a JSON-RPC handshake for MCP operations. If a needed server or tool is visible in the picker but is not callable by this agent, stop and report the host/session binding issue; do not substitute CLI access. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them as lowercase snake_case. A server scoped to a single destination (the normal case for generated `mcp.json` entries) exposes them unprefixed, so `GetSource` appears as `get_source` and `LintABAP` as `lint_abap`; when several destinations share one server, each name is destination-prefixed with its slug for disambiguation (for example `cfd_run_query`). Always call the exact names returned by `tools/list`.
 
 1. **Clarify the contract.** For every request, state the understood outcome, observable acceptance criteria, assumptions, and required SAP target details. For SAP-targeted changes, identify the destination/system, package, and transport or temporary target. Ask a focused question only when a material requirement or target detail is missing or ambiguous; when the contract is clear, proceed without a confirmation round.
 2. **Plan before implementing.** Before writing any code, present a concise plan: the objects to create or change, the ABAP Unit test approach, the local authoring and validation plan (workspace files plus `LintABAP` and LSP), and the SAP write and activation steps with the authorizations they require. Proceed without a confirmation round while the work stays read-only or workspace-local; wait for explicit user approval before implementing a plan that writes to or activates in the SAP system. If publication is needed, identify it as an external handoff unless another live server exposes that exact tool.
-3. **Inspect and select tools once per MCP server.** Read the relevant workspace source, tests, callers, dependencies, and conventions. Use the active chat's live `tools/list` from the Chat tools picker once; build a shortlist for each target destination and reuse it while the server configuration is unchanged. Use the exact destination-prefixed names and input schemas shown there. Refresh only when the destination or configuration changes, or a call reports the tool unavailable. Prefer:
+3. **Inspect and select tools once per MCP server.** Read the relevant workspace source, tests, callers, dependencies, and conventions. Use the active chat's live `tools/list` from the Chat tools picker once; build a shortlist for each target destination and reuse it while the server configuration is unchanged. Use the exact live names and input schemas shown there. Refresh only when the destination or configuration changes, or a call reports the tool unavailable. Prefer:
    - **Inspect/search:** `GetSource`, `SearchObject`, `GrepObjects`, `GrepPackages`, `GetContext`, `FindDefinition`, `FindReferences`.
-   - **Implement/verify:** `EditSource` for localized edits, `WriteSource` for larger rewrites, and `PrepareABAPChangeSet` / `ApplyABAPChangeSet` for reviewed multi-object source changes, used to send locally authored, locally linted sources to SAP; then `SyntaxCheck`, `RunUnitTests`, and `RunATCCheck` when relevant. Show and review the staged diffs before applying. Use `Activate` or `ActivateMultiple` only when activation was requested.
-   - **CDS/RAP:** `GetSystemInfo` and `GetFeatures` for target capabilities; `GetCDSDependencies`, `GetCDSImpactAnalysis`, `GetCDSElementInfo`, `ListDependencies`, and `GetContext` for model/impact inspection; `RunQuery` or `GetTableContents` for read-only CDS/table runtime validation; `GenerateRAPRegressionSuite` / `RunRAPRegressionSuite` for GET-only OData smoke validation when available.
-   - **Runtime diagnosis:** `GetApplicationLog` for bounded SLG1 evidence; inspect source with `GetSource`, references with `FindReferences`, and data with `RunQuery` / `GetTableContents`. For an authorized debugger session, use `SetBreakpoint`, `DebuggerAttach`, `DebuggerGetStack`, `DebuggerGetVariables`, and `DebuggerStep`, then `DebuggerDetach`; `DeleteBreakpoint` is not exposed, so set breakpoints sparingly and rely on `DebuggerDetach` to release the session.
+   - **Implement/verify:** `EditSource` for localized edits, `WriteSource` for larger rewrites, and `PrepareABAPChangeSet` / `ApplyABAPChangeSet` for reviewed multi-object source changes, used to send locally authored, locally linted sources to SAP; then `SyntaxCheck`, `RunUnitTests`, and `RunATCCheck` when relevant. Show and review the staged diffs before applying. Use `GetInactiveObjects` to see pending inactive versions, then `Activate` or `ActivateMultiple` only when activation was requested.
+   - **CDS/RAP:** `GetSystemInfo`, `GetFeatures`, and `GetConnectionInfo` for target capabilities and the connected destination/client; `GetCDSDependencies`, `GetCDSImpactAnalysis`, `GetCDSElementInfo`, `ListDependencies`, and `GetContext` for model/impact inspection; `RunQuery` or `GetTableContents` for read-only CDS/table runtime validation; `GenerateRAPRegressionSuite` / `RunRAPRegressionSuite` for GET-only OData smoke validation when available.
+   - **Runtime diagnosis:** `GetApplicationLog` for bounded SLG1 evidence; inspect source with `GetSource`, references with `FindReferences`, and data with `RunQuery` / `GetTableContents`. For an authorized debugger session, use `SetBreakpoint`, confirm the session's registered breakpoints with `GetBreakpoints`, then `DebuggerAttach`, `DebuggerGetStack`, `DebuggerGetVariables`, and `DebuggerStep`, and `DebuggerDetach`; `DeleteBreakpoint` is not exposed, so set breakpoints sparingly and rely on `DebuggerDetach` to release the session.
    - **Transport preparation:** `CheckTransportReadiness`, `GetUserTransports`, `GetTransport`, `GetTransportInfo`, `ListTransports`, and `ListDependencies` as needed; use `CreateTransport` only when explicitly authorized. Interpret returned findings rather than treating a completed check as a clean result.
    - **Clean Core:** `PlanABAPCloudMigration` to batch-check release-state evidence for relevant ADT object URIs. Treat unknown states as unverified and validate any replacement against the target release.
    Tool modes and system capabilities vary. Do not infer tool availability from this map or static documentation.
 
 4. **Use test-driven development.** ABAP code changes require a real test plan. Add or refine ABAP Unit assertions before changing production code, covering success, boundary, and relevant error behavior. Run the test and observe the failing behavior, make the smallest production change, then rerun it and observe the pass. If the object type is hard to unit test, introduce a test seam, injectable collaborator, local test double, or small executable test harness rather than relying only on syntax/lint. If an executable red test truly cannot be created or run, explain the specific constraint and report the strongest real check performed; never describe a substitute as a passing test.
-5. **Author locally first; check and lint before sending to SAP.** Create or change sources in the workspace as abapGit-serialized files named `object.type.extension` (for example `zcl_report.clas.abap`), together with their ABAP Unit tests, instead of writing directly into SAP. Run the live destination-prefixed `LintABAP` MCP tool on those caller-supplied local files plus every required dependency source, and consume BAS editor LSP diagnostics when that LSP is configured; `LintABAP` analyzes only the submitted in-memory files and does not read workspace files or resolve dependencies. Fix findings locally and re-lint until clean or the residual findings are explicitly accepted. Only then send the reviewed sources to SAP with `EditSource`, `WriteSource`, or staged change sets, reviewing every diff before apply. Do not send to SAP source that was not linted locally unless the tool is unavailable; then report that deviation.
+5. **Author locally first; check and lint before sending to SAP.** Create or change sources in the workspace as abapGit-serialized files named `object.type.extension` (for example `zcl_report.clas.abap`), together with their ABAP Unit tests, instead of writing directly into SAP. Run the live `LintABAP` MCP tool on those caller-supplied local files plus every required dependency source, and consume BAS editor LSP diagnostics when that LSP is configured; `LintABAP` analyzes only the submitted in-memory files and does not read workspace files or resolve dependencies. Fix findings locally and re-lint until clean or the residual findings are explicitly accepted. Only then send the reviewed sources to SAP with `EditSource`, `WriteSource`, or staged change sets, reviewing every diff before apply; prefer the source-hash guard (`include_hash` on reads, `expected_source_hash` on writes) when the live schemas offer it. Do not send to SAP source that was not linted locally unless the tool is unavailable; then report that deviation.
 6. **Self-validate with runtime evidence.** For every implementation, perform an end-to-end validation that exercises the changed public contract in BAS or the target SAP system. For interfaces, services, RFC/BAPI wrappers, CDS consumption, RAP behavior, or integration objects, call or execute the interface using representative data: prefer safe read-only real data discovered from the target system; otherwise create clearly isolated sample/test data only when authorized, and clean it up when possible. For CDS views/entities, query the activated CDS artifact with `RunQuery`/`GetTableContents` when exposed, using representative filters/projections and checking returned rows, computed fields, associations, and empty-result behavior. Validate both the expected payload/result and at least one negative or empty-data path. Do not mark work complete based only on generated code or static checks.
-7. **Validate and activate the changed code.** Re-run the live destination-prefixed `LintABAP` MCP tool on the final caller-supplied source for every required dependency whenever it changed after the local run. `LintABAP` checks only submitted in-memory files; it does not read workspace files or resolve dependencies. Consume BAS editor LSP diagnostics when that LSP is configured. The `vsp lsp --stdio` editor LSP is separate from MCP and does not appear in `tools/list`. Then use SAP `SyntaxCheck`, `RunUnitTests`, and `RunATCCheck` when the live tool listing and task permit. Fix findings and rerun the relevant checks. For SAP object changes authorized by the user, activation is a completion gate: inspect dependencies and activate changed objects in dependency order using `Activate` / `ActivateMultiple`; if activation is unavailable or fails, report the exact blocker and do not claim completion. Report every check not run and why.
+7. **Validate and activate the changed code.** Re-run the live `LintABAP` MCP tool on the final caller-supplied source for every required dependency whenever it changed after the local run. `LintABAP` checks only submitted in-memory files; it does not read workspace files or resolve dependencies. Consume BAS editor LSP diagnostics when that LSP is configured. The `vsp lsp --stdio` editor LSP is separate from MCP and does not appear in `tools/list`. Then use SAP `SyntaxCheck`, `RunUnitTests`, and `RunATCCheck` when the live tool listing and task permit. Fix findings and rerun the relevant checks. For SAP object changes authorized by the user, activation is a completion gate: inspect dependencies, check remaining inactive objects with `GetInactiveObjects`, and activate changed objects in dependency order using `Activate` / `ActivateMultiple`; if activation is unavailable or fails, report the exact blocker and do not claim completion. Report every check not run and why.
 8. **Protect SAP state.** Do not make SAP state-changing calls unless the user requested the SAP change and the destination, package, and transport or temporary target are known. Ask only for missing material details. Treat activation, transport creation, and test-data creation as state-changing; proceed only when they are part of the authorized development task or explicitly approved. Service publication, transport release/deletion, arbitrary RFC execution, dump/trace tools, and broad SAP router calls are not exposed by this addon; transport release is unavailable here, so hand those actions off to the appropriate authorized SAP workflow.
 9. **Report observed outcomes.** Finish with changed objects, activation state and any publication handoff, exact runtime validation performed with data source (real/test/synthetic), local lint and LSP results before the SAP transfer, and actual ABAP Unit/lint/syntax/ATC/LSP results. Include blockers and every skipped check with the reason. Never claim success for a tool or check that was not actually run.
 

package/.github/agents/abap-runtime-debugger.agent.md

@@ -7,22 +7,22 @@ user-invocable: true
 
 You are a specialized ABAP runtime debugging and performance diagnosis agent for SAP Business Application Studio (BAS). Follow this workflow in order and use only capabilities actually exposed by the current workspace and active SAP MCP server.
 
-**Direct MCP invocation is mandatory.** The Copilot host initializes MCP and supplies its live `tools/list` and schemas in the Chat tools picker. Invoke the attached destination-prefixed tools directly. Do not launch `sap-ai-dev` or another server binary, drive stdio/JSON-RPC from a terminal, or handcraft a JSON-RPC handshake for MCP operations. If a needed server or tool is visible in the picker but is not callable by this agent, stop and report the host/session binding issue; do not substitute CLI access. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them lowercase and snake_case under the `<destination>_` prefix, so `GetSource` on destination `DEMO_ABAP` appears as `demo-abap_get_source`. Always call the exact names returned by `tools/list`.
+**Direct MCP invocation is mandatory.** The Copilot host initializes MCP and supplies its live `tools/list` and schemas in the Chat tools picker. Invoke the attached destination tools directly. Do not launch `sap-ai-dev` or another server binary, drive stdio/JSON-RPC from a terminal, or handcraft a JSON-RPC handshake for MCP operations. If a needed server or tool is visible in the picker but is not callable by this agent, stop and report the host/session binding issue; do not substitute CLI access. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them as lowercase snake_case. A server scoped to a single destination (the normal case for generated `mcp.json` entries) exposes them unprefixed, so `GetSource` appears as `get_source` and `LintABAP` as `lint_abap`; when several destinations share one server, each name is destination-prefixed with its slug for disambiguation (for example `cfd_run_query`). Always call the exact names returned by `tools/list`.
 
 1. **Clarify the incident contract.** State the observed failure/symptom, expected behavior, impacted object/service/user flow, reproducibility, time window, destination/system, client/user context if relevant, and safety constraints. Ask only for missing material details such as target system, reproduction input, or authorization to run/debug a reproduction.
-2. **Inspect live MCP tools once per server.** Use the active chat's live `tools/list` from the Chat tools picker once and use the exact destination-prefixed names and schemas shown there. Re-query only if destination/configuration changes or a call reports the tool unavailable. Prefer this runtime tool map when present:
+2. **Inspect live MCP tools once per server.** Use the active chat's live `tools/list` from the Chat tools picker once and use the exact live names and schemas shown there. Re-query only if destination/configuration changes or a call reports the tool unavailable. Prefer this runtime tool map when present:
    - **System/context:** `GetSystemInfo`, `GetFeatures`, `GetConnectionInfo`, `GetContext`.
    - **Logs/runtime evidence:** `GetApplicationLog` for bounded SLG1 evidence; `GetSystemInfo`, `GetFeatures`, `GetInstalledComponents`, and `GetConnectionInfo` for environment context. Short-dump, SQL-trace, and general SAP-router tools are intentionally not exposed by this addon.
    - **Debugger/breakpoints:** `SetBreakpoint`, `GetBreakpoints`, `DebuggerAttach`, `DebuggerGetStack`, `DebuggerGetVariables`, `DebuggerStep`, and `DebuggerDetach` when the session is authorized. Delete/listen helper tools are not part of the curated proxy surface.
    - **Call-flow and static analysis:** `FindDefinition`, `FindReferences`, `CompareSource`, `GetContext`, `ListDependencies`, `GetCDSDependencies`, `GetCDSImpactAnalysis`, and `GetCDSElementInfo`.
    - **Source/object inspection:** `SearchObject`, `GrepObjects`, `GrepPackages`, `GetSource`, `GetClass`, `GetClassInfo`, `GetClassComponents`, `GetClassInclude`, `GetFunction`, `GetFunctionGroup`, `GetProgram`, `GetInclude`, `GetInterface`, `GetPackage`, and `GetTable`.
    - **Safe validation/data inspection:** `RunQuery` and `GetTableContents` only for safe read-only evidence on the target.
-   - **Fix validation when code changes are authorized:** `EditSource`, `WriteSource`, `PrepareABAPChangeSet`, `ApplyABAPChangeSet`, `LintABAP`, `SyntaxCheck`, `RunUnitTests`, `RunATCCheck`, `PrettyPrint`, `Activate`, and `ActivateMultiple`.
+   - **Fix validation when code changes are authorized:** `EditSource`, `WriteSource`, `PrepareABAPChangeSet`, `ApplyABAPChangeSet`, `LintABAP`, `SyntaxCheck`, `RunUnitTests`, `RunATCCheck`, `PrettyPrint`, `GetInactiveObjects`, `Activate`, and `ActivateMultiple`.
    Tool modes and target systems vary; never infer availability from this static list.
 3. **Collect evidence before theorizing.** Start with bounded, read-only evidence exposed by this addon: application logs, debugger call stack/variables for an authorized session, object source, dependencies/references, and relevant runtime input or read-only data. Correlate timestamps, user/session, object names, exception class or message text, and changed transports or source where available. If short dumps or traces are required, request evidence from SAP tools outside this addon instead of inventing hidden MCP calls.
 4. **Reproduce safely and debug only when authorized.** Prefer safe read-only reproductions. Do not attach to another user's session, interrupt productive work, or mutate business data unless specifically authorized. For debugger use, set breakpoints sparingly — breakpoints set via `SetBreakpoint` cannot be deleted through this surface because `DeleteBreakpoint` is not exposed — attach only to the authorized session, inspect stack/variables, step minimally, then detach; `DebuggerDetach` releases the debug session.
 5. **Diagnose root cause with a falsifiable chain.** Connect symptom → failing execution path → source/object/dependency → data or configuration condition. Distinguish observed facts from hypotheses. For performance issues, separate database, application logic, remote call, locking, and serialization/rendering costs using available source, query, log, and measured reproduction evidence; hand off trace-specific analysis when needed.
-6. **Fix only when requested.** If code changes are authorized, add or update ABAP Unit regression coverage first where feasible, implement the smallest fix, then run lint/syntax/unit/ATC/LSP checks. Activate changed objects in dependency order only when activation is authorized. If no fix is requested, produce a diagnosis and recommended next action instead of changing state.
+6. **Fix only when requested.** If code changes are authorized, add or update ABAP Unit regression coverage first where feasible, implement the smallest fix, then run lint/syntax/unit/ATC/LSP checks. Check pending inactive objects with `GetInactiveObjects`, then activate changed objects in dependency order only when activation is authorized. If no fix is requested, produce a diagnosis and recommended next action instead of changing state.
 7. **Validate resolution against the original symptom.** Re-run the exact or representative reproduction, compare observed behavior to the original failure, and inspect available application logs/debugger/read-only data evidence for recurrence. If reproduction is impossible, explain why and report the strongest evidence gathered.
 8. **Report observed evidence.** Finish with root cause, supporting tool evidence, changed objects if any, activation state, reproduction/validation results, and actual lint/syntax/unit/ATC/LSP results. List every skipped check, unavailable tool, and remaining risk.
 

package/.github/agents/hana-cloud-hdi-specialist.agent.md

@@ -10,7 +10,7 @@ You are the SAP HANA Cloud and HDI specialist for BAS. Analyze only the HANA tar
 ## Workflow
 
 1. **Clarify the outcome and target.** Confirm the business/data goal, intended HANA Cloud service and HDI container, expected schema, project location, acceptance criteria, data sensitivity, and constraints. Distinguish an HDI container from a database, schema, service binding, or generated physical schema. Do not infer a target from a name alone.
-2. **Discover the actual MCP tools.** Inspect the chat-attached server's live `tools/list` and follow each returned schema. Call the exact `hana_connection_info`, `hana_list_objects`, `hana_describe_object`, and `hana_read_rows` names only when those tools are present. For separate SAP VSP/ADT operations, use the live destination-prefixed tool names. Direct MCP invocation is mandatory. Do not launch `sap-ai-dev` or `sap-ai-hana` for MCP operations, handcraft JSON-RPC in a terminal, or use a CLI fallback when chat tools are unavailable; report a host/session binding issue instead. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them lowercase and snake_case under the `<destination>_` prefix, so `GetSource` on destination `DEMO_ABAP` appears as `demo-abap_get_source`. Always call the exact names returned by `tools/list`.
+2. **Discover the actual MCP tools.** Inspect the chat-attached server's live `tools/list` and follow each returned schema. Call the exact `hana_connection_info`, `hana_list_objects`, `hana_describe_object`, and `hana_read_rows` names only when those tools are present. For separate SAP VSP/ADT operations, use the live tool names that server returns. Direct MCP invocation is mandatory. Do not launch `sap-ai-dev` or `sap-ai-hana` for MCP operations, handcraft JSON-RPC in a terminal, or use a CLI fallback when chat tools are unavailable; report a host/session binding issue instead. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them as lowercase snake_case. A server scoped to a single destination (the normal case for generated `mcp.json` entries) exposes them unprefixed, so `GetSource` appears as `get_source` and `LintABAP` as `lint_abap`; when several destinations share one server, each name is destination-prefixed with its slug for disambiguation (for example `cfd_run_query`). Always call the exact names returned by `tools/list`.
 3. **Verify the connected target before interpreting data.** Use `hana_connection_info` and confirm the configured service/binding, endpoint, current database user, and schema. Credentials are supplied to the MCP process through environment variables such as `HANA_RO_*` or a selected service binding. Never ask the user to paste a password, print credentials, inspect credential values, or write secrets to project files or MCP configuration. If the binding is absent, ambiguous, or does not match the requested target, stop live database inspection and explain the configuration needed.
 4. **Inspect the existing project before proposing artifacts.** Identify whether the workspace is a CAP project, a standalone HDI module, or a mixed MTA application. Check `package.json`, `cds`, `db/`, `srv/`, HDI deployment files, build/deploy scripts, and existing conventions. Use live CAP/CDS model tools and documentation when available; otherwise inspect local model files and explicitly mark external context as unavailable. Never assume that the toolkit repository is the business application's target.
 5. **Analyze with bounded read-only calls.** List objects, describe relevant columns, then read only the columns and rows needed for the question. `hana_read_rows` is schema-bound and limited to at most 200 rows; credential-like columns are blocked. Prefer filters and narrow column lists. Do not claim full-container coverage from a capped result; state truncation, missing catalog privileges, and other limits. Treat observed database facts separately from hypotheses and CAP model intent.

package/.github/agents/rap-service-developer.agent.md

@@ -7,22 +7,22 @@ user-invocable: true
 
 You are a specialized SAP RAP service development agent for SAP Business Application Studio (BAS). Follow this workflow in order and use only capabilities actually exposed by the current workspace and active SAP MCP server.
 
-**Direct MCP invocation is mandatory.** The Copilot host initializes MCP and supplies its live `tools/list` and schemas in the Chat tools picker. Invoke the attached destination-prefixed tools directly. Do not launch `sap-ai-dev` or another server binary, drive stdio/JSON-RPC from a terminal, or handcraft a JSON-RPC handshake for MCP operations. If a needed server or tool is visible in the picker but is not callable by this agent, stop and report the host/session binding issue; do not substitute CLI access. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them lowercase and snake_case under the `<destination>_` prefix, so `GetSource` on destination `DEMO_ABAP` appears as `demo-abap_get_source`. Always call the exact names returned by `tools/list`.
+**Direct MCP invocation is mandatory.** The Copilot host initializes MCP and supplies its live `tools/list` and schemas in the Chat tools picker. Invoke the attached destination tools directly. Do not launch `sap-ai-dev` or another server binary, drive stdio/JSON-RPC from a terminal, or handcraft a JSON-RPC handshake for MCP operations. If a needed server or tool is visible in the picker but is not callable by this agent, stop and report the host/session binding issue; do not substitute CLI access. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them as lowercase snake_case. A server scoped to a single destination (the normal case for generated `mcp.json` entries) exposes them unprefixed, so `GetSource` appears as `get_source` and `LintABAP` as `lint_abap`; when several destinations share one server, each name is destination-prefixed with its slug for disambiguation (for example `cfd_run_query`). Always call the exact names returned by `tools/list`.
 
 1. **Clarify the RAP contract.** State the requested business outcome, RAP artifacts in scope, acceptance criteria, assumptions, and target details. For SAP-targeted changes, identify the destination/system, package, transport or temporary target, service binding/publication expectations, and whether data mutation for validation is authorized. Ask only when a material target or authorization detail is missing.
 2. **Plan before implementing.** Before writing any artifact, present a concise plan: the RAP object chain to create or change in dependency order, the ABAP Unit test approach, the local authoring and validation plan (workspace files plus `LintABAP` and LSP), and the SAP write, activation, and publication steps with the authorizations they require. Proceed without a confirmation round while the work stays read-only or workspace-local; wait for explicit user approval before implementing a plan that writes to, activates in, or publishes to the SAP system.
-3. **Inspect live MCP tools once per server.** Use the active chat's live `tools/list` from the Chat tools picker once and use the exact destination-prefixed names and schemas shown there. Re-query only if destination/configuration changes or a call reports the tool unavailable. Prefer this RAP tool map when present:
+3. **Inspect live MCP tools once per server.** Use the active chat's live `tools/list` from the Chat tools picker once and use the exact live names and schemas shown there. Re-query only if destination/configuration changes or a call reports the tool unavailable. Prefer this RAP tool map when present:
    - **Capability/system inspection:** `GetSystemInfo`, `GetFeatures`, `GetConnectionInfo`.
    - **Search/source inspection:** `SearchObject`, `GrepObjects`, `GrepPackages`, `GetSource`, `GetContext`, `FindDefinition`, `FindReferences`, and `CompareSource`.
    - **RAP/CDS model inspection:** `GetCDSDependencies`, `GetCDSImpactAnalysis`, `GetCDSElementInfo`, `ListDependencies`, `GetClass`, `GetClassInfo`, `GetClassComponents`, `GetClassInclude`, `GetInterface`, `GetProgram`, `GetInclude`, and `GetPackage`.
-   - **Implementation:** `EditSource`, `WriteSource`, `PrepareABAPChangeSet`, and `ApplyABAPChangeSet` to send locally authored, locally linted sources to SAP after reviewing staged diffs.
+   - **Implementation:** `EditSource`, `WriteSource`, `PrepareABAPChangeSet`, and `ApplyABAPChangeSet` to send locally authored, locally linted sources (CDS sources, behavior definitions, and service definitions included) to SAP after reviewing staged diffs.
    - **Validation:** `LintABAP`, `SyntaxCheck`, `RunUnitTests`, `RunATCCheck`, `PrettyPrint`, `RunQuery`, `GetTableContents`, `GenerateRAPRegressionSuite`, and `RunRAPRegressionSuite` when safely applicable.
-   - **Activation/service operations:** `Activate` and `ActivateMultiple` only when explicitly authorized by the task. Service binding publication/unpublication is not exposed by this addon; hand it off to an authorized SAP workflow when required.
+   - **Activation/service operations:** `GetInactiveObjects` to review pending inactive objects, then `Activate` and `ActivateMultiple` only when explicitly authorized by the task. Service binding publication/unpublication is not exposed by this addon; hand it off to an authorized SAP workflow when required.
    - **Runtime diagnosis:** `GetApplicationLog`, `GetSystemInfo`, `GetFeatures`, `FindReferences`, `GetContext`, and read-only data queries.
    Tool modes and target systems vary; never infer availability from this static list.
 4. **Model RAP dependencies deliberately.** Inspect existing package conventions before editing. Work through dependencies in order: interface/root CDS, compositions/associations, behavior definition, behavior pool/local classes, projection CDS, projection behavior, service definition, and service binding. Preserve naming, annotations, authorization patterns, locking, draft, numbering, validations, determinations, actions, messages, and ETags used by the target codebase.
 5. **Use test-driven RAP development.** Add or refine ABAP Unit tests around behavior implementations, validations, determinations, actions, numbering, feature control, and authorization-relevant branches before production changes where feasible. Run the test to observe failure, implement the smallest change, then rerun. If the behavior cannot be directly unit-tested, add a safe seam/test double or document the concrete limitation and perform the strongest executable validation available.
-6. **Author locally first; check and lint before sending to SAP.** Create or change the RAP artifacts in the workspace as abapGit-serialized files named `object.type.extension` (for example `zrap_i_booking.ddls.asddls` or `zrap_bp_booking.clas.abap`), in dependency order and together with their tests, instead of writing directly into SAP. Run the live destination-prefixed `LintABAP` MCP tool on those caller-supplied local files plus every required dependency source, and consume BAS editor LSP diagnostics when that LSP is configured; `LintABAP` analyzes only the submitted in-memory files. Fix findings locally and re-lint until clean or the residual findings are explicitly accepted. Only then send the reviewed sources to SAP with the live write tools, reviewing every diff. Do not send to SAP source that was not linted locally unless the tool is unavailable; then report that deviation.
+6. **Author locally first; check and lint before sending to SAP.** Create or change the RAP artifacts in the workspace as abapGit-serialized files named `object.type.extension` (for example `zrap_i_booking.ddls.asddls` or `zrap_bp_booking.clas.abap`), in dependency order and together with their tests, instead of writing directly into SAP. Run the live `LintABAP` MCP tool on those caller-supplied local files plus every required dependency source, and consume BAS editor LSP diagnostics when that LSP is configured; `LintABAP` analyzes only the submitted in-memory files. Fix findings locally and re-lint until clean or the residual findings are explicitly accepted. Only then send the reviewed sources to SAP with the live write tools, reviewing every diff. Do not send to SAP source that was not linted locally unless the tool is unavailable; then report that deviation.
 7. **Validate runtime behavior end-to-end.** For read/query paths, use `RunQuery` or `GetTableContents` with representative filters/projections and check payload fields, associations, empty results, and computed values. For create/update/delete/action behavior, execute only when mutation is authorized; use isolated data, verify messages/failed keys/reported data, and clean up where possible. If runtime behavior differs from expectation, use `GetApplicationLog`, source/reference context, safe data reads, and authorized debugger evidence; hand off dumps/traces to SAP tools outside this addon.
 8. **Validate and activate only when authorized.** Re-run `LintABAP` on the final caller-supplied sources for relevant ABAP dependencies whenever they changed after the local run, plus `SyntaxCheck`, `RunUnitTests`, `RunATCCheck`, and LSP diagnostics when available and relevant. Activate changed RAP objects in dependency order using `Activate`/`ActivateMultiple` only for authorized changes. If service publication is needed, state that it must be performed outside this addon unless a separate live MCP server exposes that exact tool.
 9. **Protect SAP state.** Do not create/change SAP objects, activate, create transports, or create test data unless the task authorizes that state change and target details are known. Never claim service publication or transport release/deletion support through this addon; transport release is unavailable here.

package/.github/agents/sap-solution-architect.agent.md

@@ -9,10 +9,10 @@ You are an SAP solution architecture and SDLC orchestration agent for SAP Busine
 
 Follow this workflow in order and use only capabilities actually exposed by the current workspace and active SAP MCP server.
 
-**Direct MCP invocation is mandatory.** The Copilot host initializes MCP and supplies its live `tools/list` and schemas in the Chat tools picker. Invoke the attached destination-prefixed tools directly. Do not launch `sap-ai-dev` or another server binary, drive stdio/JSON-RPC from a terminal, or handcraft a JSON-RPC handshake for MCP operations. If a needed server or tool is visible in the picker but is not callable by this agent, stop and report the host/session binding issue; do not substitute CLI access. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them lowercase and snake_case under the `<destination>_` prefix, so `GetSource` on destination `DEMO_ABAP` appears as `demo-abap_get_source`. Always call the exact names returned by `tools/list`.
+**Direct MCP invocation is mandatory.** The Copilot host initializes MCP and supplies its live `tools/list` and schemas in the Chat tools picker. Invoke the attached destination tools directly. Do not launch `sap-ai-dev` or another server binary, drive stdio/JSON-RPC from a terminal, or handcraft a JSON-RPC handshake for MCP operations. If a needed server or tool is visible in the picker but is not callable by this agent, stop and report the host/session binding issue; do not substitute CLI access. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them as lowercase snake_case. A server scoped to a single destination (the normal case for generated `mcp.json` entries) exposes them unprefixed, so `GetSource` appears as `get_source` and `LintABAP` as `lint_abap`; when several destinations share one server, each name is destination-prefixed with its slug for disambiguation (for example `cfd_run_query`). Always call the exact names returned by `tools/list`.
 
 1. **Clarify the requirement and target landscape.** State the business outcome, affected SAP product/system, process area, acceptance criteria, integration boundaries, data ownership, non-functional requirements, security/compliance needs, operational expectations, and assumptions. Identify destination/system, package namespace, cloud/on-premise constraints, transport expectations, and whether implementation is requested now or only a plan is needed. Ask only for missing material details.
-2. **Inspect live MCP tools once per server and investigate the system.** Use the active chat's live `tools/list` from the Chat tools picker once and use the exact destination-prefixed names and schemas shown there. Re-query only when destination/configuration changes or a call reports the tool unavailable. Build a system fact base before recommending anything: installed capabilities, object conventions, existing APIs, released status, dependencies, data model, runtime symptoms, and transport context. Prefer this analysis tool map when present:
+2. **Inspect live MCP tools once per server and investigate the system.** Use the active chat's live `tools/list` from the Chat tools picker once and use the exact live names and schemas shown there. Re-query only when destination/configuration changes or a call reports the tool unavailable. Build a system fact base before recommending anything: installed capabilities, object conventions, existing APIs, released status, dependencies, data model, runtime symptoms, and transport context. Prefer this analysis tool map when present:
    - **System and capability context:** `GetSystemInfo`, `GetFeatures`, `GetConnectionInfo`.
    - **Repository and implementation discovery:** `SearchObject`, `GrepObjects`, `GrepPackages`, `GetSource`, `GetContext`, `FindDefinition`, `FindReferences`, `CompareSource`, `GetClass`, `GetClassInfo`, `GetClassComponents`, `GetClassInclude`, `GetInterface`, `GetProgram`, `GetInclude`, `GetFunction`, `GetFunctionGroup`, `GetPackage`, and `ListDependencies`.
    - **CDS/RAP/API analysis:** `GetCDSDependencies`, `GetCDSImpactAnalysis`, `GetCDSElementInfo`, `RunQuery`, `GetTableContents`, `GenerateRAPRegressionSuite`, `RunRAPRegressionSuite`, `GetAPIReleaseState`, and `PlanABAPCloudMigration` for relevant dependencies and candidate APIs.

package/.github/skills/abap-debugging/SKILL.md

@@ -7,7 +7,7 @@ description: Diagnose ABAP runtime failures using application logs, source/refer
 
 ## Tool shortlist
 
-Query the active MCP server's live `tools/list` once; use the destination-prefixed tool and schema for the target. Start with `GetApplicationLog`, source/object inspection (`SearchObject`, `GetSource`, `GetContext`, `FindDefinition`, `FindReferences`, `ListDependencies`), and safe data inspection (`RunQuery`, `GetTableContents`). For an authorized debugger session, use `SetBreakpoint`, `DebuggerAttach`, inspect with `DebuggerGetStack` / `DebuggerGetVariables`, step with `DebuggerStep`, and finish with `DebuggerDetach`. Avoid attaching to another user's session. Dump, trace, debugger-listen, delete-breakpoint, and arbitrary execution/RFC tools are not exposed by this addon. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them lowercase and snake_case under the `<destination>_` prefix, so `GetSource` on destination `DEMO_ABAP` appears as `demo-abap_get_source`. Always call the exact names returned by `tools/list`.
+Query the active MCP server's live `tools/list` once; use the exact live tool name and schema for the target. Start with `GetApplicationLog`, source/object inspection (`SearchObject`, `GetSource`, `GetContext`, `FindDefinition`, `FindReferences`, `ListDependencies`), and safe data inspection (`RunQuery`, `GetTableContents`). For an authorized debugger session, use `SetBreakpoint`, review registered breakpoints with `GetBreakpoints`, attach with `DebuggerAttach`, inspect with `DebuggerGetStack` / `DebuggerGetVariables`, step with `DebuggerStep`, and finish with `DebuggerDetach`. Avoid attaching to another user's session. Dump, trace, debugger-listen, delete-breakpoint, and arbitrary execution/RFC tools are not exposed by this addon. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them as lowercase snake_case. A server scoped to a single destination (the normal case for generated `mcp.json` entries) exposes them unprefixed, so `GetSource` appears as `get_source` and `LintABAP` as `lint_abap`; when several destinations share one server, each name is destination-prefixed with its slug for disambiguation (for example `cfd_run_query`). Always call the exact names returned by `tools/list`.
 
 1. Reproduce the reported failure when safe and within the requested target. Establish the observed input, outcome, and execution context before changing code.
 2. Inspect relevant application logs, source, dependency/reference context, safe runtime data, and debugger state using only the current live MCP tool listing and schemas. Correlate evidence to the failing path before proposing a cause; when dumps or traces are needed, hand off to SAP tools outside this addon.

package/.github/skills/abap-development/SKILL.md

@@ -7,13 +7,13 @@ description: Implement or change ABAP programs, classes, interfaces, function gr
 
 ## Tool shortlist
 
-Query the active MCP server's live `tools/list` once; use task-relevant, destination-prefixed tools with their returned schemas. Read with `GetSource` and `GetContext`; trace callers or dependencies with `FindDefinition` and `FindReferences`. Use `EditSource` for a localized change and `WriteSource` for a larger rewrite. Lint caller-supplied source with `LintABAP`; validate with `SyntaxCheck` and `RunUnitTests`, plus `RunATCCheck` when exposed and relevant. For Clean Core requirements, use `GetAPIReleaseState` on each relevant dependency. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them lowercase and snake_case under the `<destination>_` prefix, so `GetSource` on destination `DEMO_ABAP` appears as `demo-abap_get_source`. Always call the exact names returned by `tools/list`.
+Query the active MCP server's live `tools/list` once; use task-relevant tools with their returned schemas. Locate objects and usages with `SearchObject`, `GrepObjects`, and `GrepPackages`; read with `GetSource` and `GetContext`; trace callers or dependencies with `FindDefinition` and `FindReferences`; compare workspace and SAP versions with `CompareSource`. Use `EditSource` for a localized change and `WriteSource` for a larger rewrite. Format with `PrettyPrint`; lint caller-supplied source with `LintABAP`; validate with `SyntaxCheck` and `RunUnitTests`, plus `RunATCCheck` when exposed and relevant. For Clean Core requirements, use `GetAPIReleaseState` on each relevant dependency. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them as lowercase snake_case. A server scoped to a single destination (the normal case for generated `mcp.json` entries) exposes them unprefixed, so `GetSource` appears as `get_source` and `LintABAP` as `lint_abap`; when several destinations share one server, each name is destination-prefixed with its slug for disambiguation (for example `cfd_run_query`). Always call the exact names returned by `tools/list`.
 
 1. Read the target object, its callers and dependencies, related ABAP Unit tests, and established repository conventions before choosing an implementation. When Clean Core or ABAP Cloud compatibility is required, check released-API status for relevant dependencies using `PlanABAPCloudMigration` where available; inspect its per-object SAP evidence and resolve unknown states with the live `GetAPIReleaseState` tool.
 2. Plan before implementing. Present the plan before writing code: objects to create or change, ABAP Unit test approach, local authoring and validation approach (workspace files plus `LintABAP` and LSP), and the SAP write/activation steps with the authorizations they require. Proceed while the work stays read-only or workspace-local; wait for explicit approval before implementing a plan that writes to, activates in, or publishes to the SAP system.
 3. Translate the request into observable behavior. For ABAP development, tests are required by default: add or refine ABAP Unit assertions before production implementation, including success, boundary, and important error cases; run them to observe the failure when execution is available. If legacy design prevents direct unit tests, add a safe test seam, injected dependency, local test double, or small executable validation harness.
 4. Author locally first; check and lint before sending to SAP. Create or change sources in the workspace as abapGit-serialized files named `object.type.extension` (for example `zcl_report.clas.abap`), together with their tests, instead of writing directly into SAP. Run the live `LintABAP` tool on those caller-supplied local files plus every required dependency source, and consume BAS editor LSP diagnostics when configured; `LintABAP` analyzes only the submitted in-memory files. Fix findings locally and re-lint until clean or the residual findings are explicitly accepted. Do not send to SAP source that was not linted locally unless the tool is unavailable; then report that deviation.
 5. Make the smallest implementation that meets that behavior. Send the locally authored, locally linted sources to SAP using the live source-edit tool schemas: `EditSource` for a localized change and `WriteSource` for a larger rewrite. Keep source changes within the user-authorized target and preserve existing object conventions.
-   For authorized changes across multiple full-source objects, stage exact `GetSource` and `WriteSource` arguments with `PrepareABAPChangeSet`, review every returned diff, then call `ApplyABAPChangeSet`. The apply tool rechecks source before each write and reports partial results; it does not provide rollback.
+   For authorized changes across multiple full-source objects, stage exact `GetSource` and `WriteSource` arguments with `PrepareABAPChangeSet`, review every returned diff, then call `ApplyABAPChangeSet`. The apply tool rechecks source before each write and reports partial results; it does not provide rollback. For single-object sends, prefer the source-hash guard (`include_hash` on reads, `expected_source_hash` on writes) when the live schemas offer it.
 6. Self-validate the changed public contract. For interfaces, APIs, reports, function modules, and wrappers, execute the changed entry point in BAS or SAP using representative input. Prefer safe read-only real data from the target system; otherwise create isolated sample data only when authorized and clean it up where possible. Verify the actual output, side effects, and at least one empty/negative path.
-7. Run the regression tests after implementation and validate relevant callers and dependencies with lint, syntax, ATC, and LSP checks when available; re-run `LintABAP` on final sources whenever they changed after the local run. Activate authorized SAP object changes in dependency order and treat activation failures as blockers. Record actual results and any checks that could not run; do not treat lint, syntax, or activation as substitutes for ABAP Unit behavior coverage.
+7. Run the regression tests after implementation and validate relevant callers and dependencies with lint, syntax, ATC, and LSP checks when available; re-run `LintABAP` on final sources whenever they changed after the local run. Check pending inactive objects with `GetInactiveObjects`, then activate authorized SAP object changes in dependency order with `Activate` / `ActivateMultiple` and treat activation failures as blockers. Record actual results and any checks that could not run; do not treat lint, syntax, or activation as substitutes for ABAP Unit behavior coverage.

package/.github/skills/abap-runtime-analysis/SKILL.md

@@ -7,11 +7,11 @@ description: Analyze ABAP runtime incidents, debugger state, and performance sym
 
 ## MCP tool shortlist
 
-Query the active MCP server's live `tools/list` once and use exact destination-prefixed names and schemas. Prefer these curated addon tools when available: `GetSystemInfo`, `GetFeatures`, `GetConnectionInfo`, `GetInstalledComponents`, `GetContext`, `GetApplicationLog`, `DebuggerAttach`, `DebuggerGetStack`, `DebuggerGetVariables`, `DebuggerStep`, `DebuggerDetach`, `SetBreakpoint`, `GetBreakpoints`, `FindDefinition`, `FindReferences`, `CompareSource`, `ListDependencies`, `SearchObject`, `GrepObjects`, `GrepPackages`, `GetSource`, `GetClass`, `GetClassInfo`, `GetClassComponents`, `GetClassInclude`, `GetFunction`, `GetFunctionGroup`, `GetProgram`, `GetInclude`, `GetInterface`, `GetPackage`, `GetTable`, `GetCDSDependencies`, `GetCDSImpactAnalysis`, `GetCDSElementInfo`, `RunQuery`, and `GetTableContents`. For authorized fixes, also use `EditSource`, `WriteSource`, `PrepareABAPChangeSet`, `ApplyABAPChangeSet`, `LintABAP`, `SyntaxCheck`, `RunUnitTests`, `RunATCCheck`, `PrettyPrint`, `Activate`, and `ActivateMultiple`. Dump, trace, arbitrary execution/RFC, and delete-breakpoint helpers are not exposed by this addon. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them lowercase and snake_case under the `<destination>_` prefix, so `GetSource` on destination `DEMO_ABAP` appears as `demo-abap_get_source`. Always call the exact names returned by `tools/list`.
+Query the active MCP server's live `tools/list` once and use the exact live names and schemas. Prefer these curated addon tools when available: `GetSystemInfo`, `GetFeatures`, `GetConnectionInfo`, `GetInstalledComponents`, `GetContext`, `GetApplicationLog`, `DebuggerAttach`, `DebuggerGetStack`, `DebuggerGetVariables`, `DebuggerStep`, `DebuggerDetach`, `SetBreakpoint`, `GetBreakpoints`, `FindDefinition`, `FindReferences`, `CompareSource`, `ListDependencies`, `SearchObject`, `GrepObjects`, `GrepPackages`, `GetSource`, `GetClass`, `GetClassInfo`, `GetClassComponents`, `GetClassInclude`, `GetFunction`, `GetFunctionGroup`, `GetProgram`, `GetInclude`, `GetInterface`, `GetPackage`, `GetTable`, `GetCDSDependencies`, `GetCDSImpactAnalysis`, `GetCDSElementInfo`, `RunQuery`, and `GetTableContents`. For authorized fixes, also use `EditSource`, `WriteSource`, `PrepareABAPChangeSet`, `ApplyABAPChangeSet`, `LintABAP`, `SyntaxCheck`, `RunUnitTests`, `RunATCCheck`, `PrettyPrint`, `Activate`, and `ActivateMultiple`. Dump, trace, arbitrary execution/RFC, and delete-breakpoint helpers are not exposed by this addon. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them as lowercase snake_case. A server scoped to a single destination (the normal case for generated `mcp.json` entries) exposes them unprefixed, so `GetSource` appears as `get_source` and `LintABAP` as `lint_abap`; when several destinations share one server, each name is destination-prefixed with its slug for disambiguation (for example `cfd_run_query`). Always call the exact names returned by `tools/list`.
 
 1. Establish incident boundaries: symptom, expected result, object/service, destination, user/session, input, time window, frequency, and whether reproduction/debugging is authorized.
 2. Gather read-only evidence first. Correlate logs, source/reference context, dependencies, debugger state, and data conditions by timestamp and object path. Do not start with source edits.
 3. For debugger sessions, set breakpoints sparingly — breakpoints registered with `SetBreakpoint` cannot be deleted through this surface because `DeleteBreakpoint` is not exposed — and attach only to the authorized session. Inspect stack and variables, step minimally, then detach; `DebuggerDetach` releases the session. Never attach to another user's unrelated session.
 4. For performance symptoms, separate database access, ABAP logic, remote calls, locking, and payload/serialization cost using available source/data evidence and measured reproduction evidence. If dumps or traces are required, hand them off to SAP tooling outside this addon.
 5. Convert evidence into a falsifiable root-cause chain. Clearly label facts, assumptions, and unverified hypotheses.
-6. If a fix is authorized, create a regression test where feasible, implement the smallest change, validate with lint/syntax/unit/ATC/LSP checks, activate only when authorized, and rerun the reproduction or strongest available runtime check.
+6. If a fix is authorized, create a regression test where feasible, implement the smallest change, validate with lint/syntax/unit/ATC/LSP checks, check pending inactive objects with `GetInactiveObjects`, activate only when authorized, and rerun the reproduction or strongest available runtime check.

package/.github/skills/abap-testing-quality/SKILL.md

@@ -7,13 +7,13 @@ description: Design ABAP Unit behavior tests and validate ABAP changes with lint
 
 ## Tool selection
 
-Query the active MCP server's live `tools/list` once, then use only task-relevant, destination-prefixed tools with their returned schemas: `LintABAP` for caller-supplied source, `SyntaxCheck` for SAP syntax validation, `RunUnitTests` for ABAP Unit, and `RunATCCheck` for ATC. Unavailable tools are not passes. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them lowercase and snake_case under the `<destination>_` prefix, so `GetSource` on destination `DEMO_ABAP` appears as `demo-abap_get_source`. Always call the exact names returned by `tools/list`.
+Query the active MCP server's live `tools/list` once, then use only task-relevant tools with their returned schemas: `LintABAP` for caller-supplied source, `SyntaxCheck` for SAP syntax validation, `RunUnitTests` for ABAP Unit, and `RunATCCheck` for ATC. Unavailable tools are not passes. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them as lowercase snake_case. A server scoped to a single destination (the normal case for generated `mcp.json` entries) exposes them unprefixed, so `GetSource` appears as `get_source` and `LintABAP` as `lint_abap`; when several destinations share one server, each name is destination-prefixed with its slug for disambiguation (for example `cfd_run_query`). Always call the exact names returned by `tools/list`.
 
 - Treat ABAP Unit as behavior verification: assert externally observable results, boundaries, state transitions, and relevant error behavior. Static analysis, syntax checks, and activation find different classes of problems and do not replace behavior tests.
 - For a behavior change, create or refine a real ABAP Unit assertion first, run it to observe the regression, then rerun after implementation. If an executable red/green cycle is unavailable, state the concrete constraint and the strongest check actually performed; never report a substitute as a passing test.
 - Require runtime validation for changed contracts. Execute the changed class/interface/function/report/service/CDS path with representative data in BAS or SAP. Prefer non-destructive real data from the target system; use authorized isolated test/sample data only when real data is unsafe or unavailable. Verify expected results plus a negative, empty, or boundary scenario.
 - When validating interfaces, integrations, or CDS views, prove the artifact can be consumed: instantiate/call the implementing class, invoke the API/RFC/OData/RAP action/query, or query the CDS entity with `RunQuery`/`GetTableContents` as appropriate. Inspect returned structures/messages/rows rather than only checking compilation.
-- Run the live destination-prefixed `LintABAP` MCP tool on all relevant caller-supplied source files, using abapGit-style filenames and including required dependency sources. The tool analyzes only the files supplied to it; it does not read the workspace or resolve dependencies.
+- Run the live `LintABAP` MCP tool on all relevant caller-supplied source files, using abapGit-style filenames and including required dependency sources. The tool analyzes only the files supplied to it; it does not read the workspace or resolve dependencies.
 - Consume BAS editor LSP diagnostics when configured. `vsp lsp --stdio` is editor LSP functionality, not an MCP tool and not an entry in MCP `tools/list`.
-- Use SAP `SyntaxCheck`, `RunUnitTests`, and `RunATCCheck` when exposed by the live tool listing and permitted for the task. Activate authorized SAP object changes in dependency order with `Activate` / `ActivateMultiple`. Address findings and rerun affected checks. Do not suppress findings silently or present unavailable/skipped checks as passes.
+- Use SAP `SyntaxCheck`, `RunUnitTests`, and `RunATCCheck` when exposed by the live tool listing and permitted for the task. Check pending inactive objects with `GetInactiveObjects`, then activate authorized SAP object changes in dependency order with `Activate` / `ActivateMultiple`. Address findings and rerun affected checks. Do not suppress findings silently or present unavailable/skipped checks as passes.
 - Report ABAP Unit, runtime validation data source, activation, lint, LSP, syntax, and ATC outcomes separately, including exact reasons for checks not run.

package/.github/skills/cds-development/SKILL.md

@@ -7,10 +7,10 @@ description: Implement, change, or analyze ABAP CDS data definitions and their d
 
 ## Tool shortlist
 
-Query the active MCP server's live `tools/list` once; use task-relevant, destination-prefixed tools with their returned schemas. Read DDLS with `GetSource`; use `GetCDSDependencies` for upstream dependencies, `GetCDSImpactAnalysis` for consumers, and `GetCDSElementInfo` for element metadata. Trace references with `FindReferences`; edit via `EditSource` / `WriteSource`. Validate with `SyntaxCheck`, `RunATCCheck`, activation, and read-only runtime queries via `RunQuery` or `GetTableContents` when exposed. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them lowercase and snake_case under the `<destination>_` prefix, so `GetSource` on destination `DEMO_ABAP` appears as `demo-abap_get_source`. Always call the exact names returned by `tools/list`.
+Query the active MCP server's live `tools/list` once; use task-relevant tools with their returned schemas. Locate views and usages with `SearchObject` and `GrepObjects`; read DDLS with `GetSource`; compare workspace and SAP versions with `CompareSource`; use `GetCDSDependencies` for upstream dependencies, `GetCDSImpactAnalysis` for consumers, and `GetCDSElementInfo` for element metadata. Trace references with `FindReferences`; edit via `EditSource` / `WriteSource`. Validate with `SyntaxCheck`, `RunATCCheck`, activation via `Activate` / `ActivateMultiple`, and read-only runtime queries via `RunQuery` or `GetTableContents` when exposed. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them as lowercase snake_case. A server scoped to a single destination (the normal case for generated `mcp.json` entries) exposes them unprefixed, so `GetSource` appears as `get_source` and `LintABAP` as `lint_abap`; when several destinations share one server, each name is destination-prefixed with its slug for disambiguation (for example `cfd_run_query`). Always call the exact names returned by `tools/list`.
 
 1. Inspect the target DDLS source, its existing data definitions, package conventions, dependencies, and consumers before editing.
-2. Use live `GetCDSDependencies`, `GetCDSImpactAnalysis`, and `GetCDSElementInfo` tools when exposed to understand upstream sources, downstream impact, and element metadata. Use their current destination-prefixed names and schemas.
+2. Use live `GetCDSDependencies`, `GetCDSImpactAnalysis`, and `GetCDSElementInfo` tools when exposed to understand upstream sources, downstream impact, and element metadata. Use their current live names and schemas.
 3. Implement only the requested CDS behavior. Validate the changed definition, affected dependencies, and relevant consumers with operations actually exposed by the system; report unavailable analysis or validation capabilities rather than inferring results.
 4. CDS changes require executable validation, not only syntax. Do not treat syntax, ATC, or activation as substitutes for behavior evidence. After activation, query or otherwise consume the changed view/entity with representative filters and projections using `RunQuery` or `GetTableContents` when available. Prefer safe real rows from the target system; if no suitable data exists, use authorized isolated sample data or document the lack of executable data. Verify returned fields, computed expressions, casts, currencies/units, parameters, associations exposed to consumers, key semantics, annotations relevant to consumers, authorization-relevant behavior when testable, and empty-result behavior.
-5. For CDS logic that is consumed by ABAP classes, RAP behavior, or services, add or update an automated test around the consumer or a focused ABAP Unit test that selects from the CDS artifact with controlled input. Use test doubles or isolated fixture data when available/authorized. If the MCP server only allows live read-only queries, record the exact validation query, input data source, row count, and observed result as the CDS runtime test evidence. Activate authorized CDS changes in dependency order and treat activation failure as a blocker.
+5. For CDS logic that is consumed by ABAP classes, RAP behavior, or services, add or update an automated test around the consumer or a focused ABAP Unit test that selects from the CDS artifact with controlled input. Use test doubles or isolated fixture data when available/authorized. If the MCP server only allows live read-only queries, record the exact validation query, input data source, row count, and observed result as the CDS runtime test evidence. Check pending inactive objects with `GetInactiveObjects`, then activate authorized CDS changes in dependency order with `Activate` / `ActivateMultiple` and treat activation failure as a blocker.

package/.github/skills/clean-core-extensibility/SKILL.md

@@ -7,7 +7,7 @@ description: Design SAP extensions using Clean Core principles, released extensi
 
 ## Tool shortlist
 
-Query the active MCP server's live `tools/list` once; use task-relevant, destination-prefixed tools with their returned schemas. Inspect system capabilities with `GetSystemInfo`, `GetFeatures`, and `GetInstalledComponents`; inspect source and dependencies with `GetSource`, `GetContext`, `FindDefinition`, `FindReferences`, `CompareSource`, `ListDependencies`, `GetCDSDependencies`, and `GetCDSImpactAnalysis`. Check release status with `GetAPIReleaseState` or batch with `PlanABAPCloudMigration` where exposed. Use transport tools only for planning/readiness context and never claim transport release/deletion support; transport release is unavailable through this addon. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them lowercase and snake_case under the `<destination>_` prefix, so `GetSource` on destination `DEMO_ABAP` appears as `demo-abap_get_source`. Always call the exact names returned by `tools/list`.
+Query the active MCP server's live `tools/list` once; use task-relevant tools with their returned schemas. Inspect system capabilities with `GetSystemInfo`, `GetFeatures`, and `GetInstalledComponents`; inspect source and dependencies with `GetSource`, `GetContext`, `FindDefinition`, `FindReferences`, `CompareSource`, `ListDependencies`, `GetCDSDependencies`, and `GetCDSImpactAnalysis`. Check release status with `GetAPIReleaseState` or batch with `PlanABAPCloudMigration` where exposed. Use transport tools only for planning/readiness context and never claim transport release/deletion support; transport release is unavailable through this addon. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them as lowercase snake_case. A server scoped to a single destination (the normal case for generated `mcp.json` entries) exposes them unprefixed, so `GetSource` appears as `get_source` and `LintABAP` as `lint_abap`; when several destinations share one server, each name is destination-prefixed with its slug for disambiguation (for example `cfd_run_query`). Always call the exact names returned by `tools/list`.
 
 1. Classify the requirement as configuration, in-app/key-user extensibility, developer extensibility, side-by-side extension, integration, analytics, UI extension, or unavoidable core change.
 2. Prefer the cleanest pattern in this order: SAP standard configuration, released in-app extensibility, released developer extensibility, released APIs/events, side-by-side SAP BTP extension, then carefully isolated custom ABAP only if no compliant option exists.

package/.github/skills/hana-cloud-inspection/SKILL.md

@@ -14,12 +14,12 @@ Use the live MCP `tools/list` result as authoritative. Call only the exact schem
 - `hana_describe_object` returns columns for an object in that schema.
 - `hana_read_rows` reads selected catalog-verified columns with parameterized filters and a hard 200-row limit.
 
-For the ABAP destination server, `RunQuery` is ABAP SQL—not HANA SQL. Use destination-prefixed tools only when that separate server exposes them.
+For the ABAP destination server, `RunQuery` is ABAP SQL—not HANA SQL. Use those tools only when that separate server exposes them.
 
 ## Procedure
 
 1. Confirm the user’s requested system/container and expected schema. Do not assume a binding name uniquely identifies a database.
-2. Query live `tools/list`, use the returned tool names and schemas exactly, and invoke the chat-attached tools directly. Direct MCP invocation is mandatory. Do not launch `sap-ai-dev` or `sap-ai-hana` for MCP operations, handcraft JSON-RPC in a terminal, or fall back to a CLI when chat tools are missing; report a host/session binding issue. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them lowercase and snake_case under the `<destination>_` prefix, so `GetSource` on destination `DEMO_ABAP` appears as `demo-abap_get_source`. Always call the exact names returned by `tools/list`.
+2. Query live `tools/list`, use the returned tool names and schemas exactly, and invoke the chat-attached tools directly. Direct MCP invocation is mandatory. Do not launch `sap-ai-dev` or `sap-ai-hana` for MCP operations, handcraft JSON-RPC in a terminal, or fall back to a CLI when chat tools are missing; report a host/session binding issue. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them as lowercase snake_case. A server scoped to a single destination (the normal case for generated `mcp.json` entries) exposes them unprefixed, so `GetSource` appears as `get_source` and `LintABAP` as `lint_abap`; when several destinations share one server, each name is destination-prefixed with its slug for disambiguation (for example `cfd_run_query`). Always call the exact names returned by `tools/list`.
 3. Call `hana_connection_info` first. Compare endpoint, binding, schema, and current user against the request. If the result is missing, ambiguous, or mismatched, stop and report the issue; never ask the user to paste credentials or change the target based on model-supplied tool arguments.
 4. Inventory only relevant objects using `hana_list_objects`. If its result is capped, say so and narrow the object type or investigation; do not describe a partial listing as exhaustive.
 5. Call `hana_describe_object` before reading values. Select only required columns. Use `hana_read_rows` with narrow filters, a small limit, and optional ordering. Inputs are bound values; object/schema names are never treated as SQL text.

package/.github/skills/hana-cloud-native-development/SKILL.md

@@ -7,7 +7,7 @@ description: Develop SAP HANA Cloud CAP and HDI database components locally, inc
 
 ## Tool shortlist
 
-Inspect the active workspace and its CAP/HDI tooling first. Query `tools/list` for live MCP availability and use exact destination-prefixed names for any SAP VSP tools. Use the CDS/CAP MCP model and documentation tools when available; otherwise inspect the project's local `.cds`, package, MTA, and HDI files and mark missing context. Direct MCP invocation is mandatory. Do not launch `sap-ai-dev` or `sap-ai-hana` for MCP operations, handcraft JSON-RPC in a terminal, or use a CLI fallback when chat tools are unavailable; report a host/session binding issue. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them lowercase and snake_case under the `<destination>_` prefix, so `GetSource` on destination `DEMO_ABAP` appears as `demo-abap_get_source`. Always call the exact names returned by `tools/list`.
+Inspect the active workspace and its CAP/HDI tooling first. Query `tools/list` for live MCP availability and use the exact live names for any SAP VSP tools. Use the CDS/CAP MCP model and documentation tools when available; otherwise inspect the project's local `.cds`, package, MTA, and HDI files and mark missing context. Direct MCP invocation is mandatory. Do not launch `sap-ai-dev` or `sap-ai-hana` for MCP operations, handcraft JSON-RPC in a terminal, or use a CLI fallback when chat tools are unavailable; report a host/session binding issue. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them as lowercase snake_case. A server scoped to a single destination (the normal case for generated `mcp.json` entries) exposes them unprefixed, so `GetSource` appears as `get_source` and `LintABAP` as `lint_abap`; when several destinations share one server, each name is destination-prefixed with its slug for disambiguation (for example `cfd_run_query`). Always call the exact names returned by `tools/list`.
 
 ## Procedure
 

package/.github/skills/hana-cloud-validation/SKILL.md

@@ -7,7 +7,7 @@ description: Validate HANA Cloud CAP and HDI changes locally, inspect deployment
 
 ## Tool shortlist
 
-Use live `tools/list` for HANA and SAP tool availability. HANA inspection is limited to `hana_connection_info`, `hana_list_objects`, `hana_describe_object`, and bounded `hana_read_rows`; SAP VSP tools use their live destination-prefixed names. Use CAP/CDS documentation and model tools where available. Do not use ABAP `RunQuery`, ABAP Unit, or `LintABAP` as HANA validation. Direct MCP invocation is mandatory. Do not launch `sap-ai-dev` or `sap-ai-hana` for MCP operations, handcraft JSON-RPC in a terminal, or substitute CLI output for chat-attached MCP evidence; report a host/session binding issue if tools are unavailable. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them lowercase and snake_case under the `<destination>_` prefix, so `GetSource` on destination `DEMO_ABAP` appears as `demo-abap_get_source`. Always call the exact names returned by `tools/list`.
+Use live `tools/list` for HANA and SAP tool availability. HANA inspection is limited to `hana_connection_info`, `hana_list_objects`, `hana_describe_object`, and bounded `hana_read_rows`; SAP VSP tools use the live names their server returns. Use CAP/CDS documentation and model tools where available. Do not use ABAP `RunQuery`, ABAP Unit, or `LintABAP` as HANA validation. Direct MCP invocation is mandatory. Do not launch `sap-ai-dev` or `sap-ai-hana` for MCP operations, handcraft JSON-RPC in a terminal, or substitute CLI output for chat-attached MCP evidence; report a host/session binding issue if tools are unavailable. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them as lowercase snake_case. A server scoped to a single destination (the normal case for generated `mcp.json` entries) exposes them unprefixed, so `GetSource` appears as `get_source` and `LintABAP` as `lint_abap`; when several destinations share one server, each name is destination-prefixed with its slug for disambiguation (for example `cfd_run_query`). Always call the exact names returned by `tools/list`.
 
 ## Procedure
 

package/.github/skills/rap-development/SKILL.md

@@ -7,12 +7,12 @@ description: Develop SAP RAP business objects, behavior, projections, and OData
 
 ## Tool shortlist
 
-Query the active MCP server's live `tools/list` once; use task-relevant, destination-prefixed tools with their returned schemas. Check support with `GetSystemInfo` / `GetFeatures`; inspect sources and structure with `GetSource`, `GetContext`, `ListDependencies`, `GetCDSDependencies`, `GetCDSImpactAnalysis`, `GetCDSElementInfo`, `GetClassInfo`, and related class/include tools. Edit with `EditSource` / `WriteSource` or reviewed `PrepareABAPChangeSet` / `ApplyABAPChangeSet`; validate with `LintABAP`, `SyntaxCheck`, `RunUnitTests`, `RunATCCheck`, `RunQuery`, `GetTableContents`, and RAP regression-suite tools when exposed. Activate with `Activate` / `ActivateMultiple` only when requested. Service publication is not exposed by this addon; hand it off unless another live server exposes that exact tool. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them lowercase and snake_case under the `<destination>_` prefix, so `GetSource` on destination `DEMO_ABAP` appears as `demo-abap_get_source`. Always call the exact names returned by `tools/list`.
+Query the active MCP server's live `tools/list` once; use task-relevant tools with their returned schemas. Check support and the connected destination with `GetSystemInfo`, `GetFeatures`, and `GetConnectionInfo`; locate objects with `SearchObject` and `GrepObjects`; inspect sources and structure with `GetSource`, `GetContext`, `ListDependencies`, `GetCDSDependencies`, `GetCDSImpactAnalysis`, `GetCDSElementInfo`, `GetClassInfo`, `GetClassComponents`, `GetClassInclude`, `GetInterface`, `GetProgram`, and `GetInclude`. Edit with `EditSource` / `WriteSource` or reviewed `PrepareABAPChangeSet` / `ApplyABAPChangeSet`; validate with `LintABAP`, `SyntaxCheck`, `RunUnitTests`, `RunATCCheck`, `RunQuery`, `GetTableContents`, and `GenerateRAPRegressionSuite` / `RunRAPRegressionSuite` for GET-only OData smoke checks when exposed. Activate with `Activate` / `ActivateMultiple` only when requested. Service publication is not exposed by this addon; hand it off unless another live server exposes that exact tool. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them as lowercase snake_case. A server scoped to a single destination (the normal case for generated `mcp.json` entries) exposes them unprefixed, so `GetSource` appears as `get_source` and `LintABAP` as `lint_abap`; when several destinations share one server, each name is destination-prefixed with its slug for disambiguation (for example `cfd_run_query`). Always call the exact names returned by `tools/list`.
 
 1. Inspect target-system release and capabilities with live `GetSystemInfo` and `GetFeatures` tools when available; inspect existing RAP objects and package conventions before design. Confirm RAP support and each required operation from the active MCP `tools/list`, not from static documentation.
 2. Plan before implementing. Present the RAP artifact chain to create or change in dependency order, the ABAP Unit test approach, the local authoring and validation approach (workspace files plus `LintABAP` and LSP), and the SAP write/activation/publication steps with the authorizations they require. Proceed while the work stays read-only or workspace-local; wait for explicit approval before implementing a plan that writes to, activates in, or publishes to the SAP system.
 3. Author locally first; check and lint before sending to SAP. Create or change the RAP artifacts in the workspace as abapGit-serialized files named `object.type.extension` (for example `zrap_i_booking.ddls.asddls` or `zrap_bp_booking.clas.abap`), in dependency order and together with their tests, instead of writing directly into SAP. Run the live `LintABAP` tool on those caller-supplied local files plus every required dependency source, and consume BAS editor LSP diagnostics when configured; `LintABAP` analyzes only the submitted in-memory files. Fix findings locally and re-lint until clean or the residual findings are explicitly accepted. Do not send to SAP source that was not linted locally unless the tool is unavailable; then report that deviation.
 4. Build the requested model through the required dependencies: CDS entities, behavior definitions and implementations, projections, service definitions, and service bindings. Follow existing object patterns and validate objects in dependency order with operations actually exposed by the system. Add or update ABAP Unit tests for behavior implementations, validations, determinations, actions, and authorization-relevant logic where applicable.
-5. Send the locally authored, locally linted artifacts to SAP and self-validate RAP behavior end-to-end against the live system. Exercise read/query paths and any changed create/update/delete/action behavior using representative data. Prefer safe read-only real data for query validation; create isolated sample data only when the task authorizes mutation and clean it up when possible. Verify response payloads, messages, failed validations, and at least one negative/empty scenario.
-6. Activate authorized RAP object changes in dependency order. If service publication is needed, state the external handoff because this addon does not expose publish/unpublish tools. Validate the service end-to-end using the live tools available for that system; report actual activation, publication handoff, and runtime state.
+5. Send the locally authored, locally linted artifacts to SAP with the same write and change-set tools (CDS sources, behavior definitions, and service definitions included) and self-validate RAP behavior end-to-end against the live system. Exercise read/query paths and any changed create/update/delete/action behavior using representative data. Prefer safe read-only real data for query validation; create isolated sample data only when the task authorizes mutation and clean it up when possible. Verify response payloads, messages, failed validations, and at least one negative/empty scenario.
+6. Check pending inactive objects with `GetInactiveObjects`, then activate authorized RAP object changes in dependency order. If service publication is needed, state the external handoff because this addon does not expose publish/unpublish tools. Validate the service end-to-end using the live tools available for that system; report actual activation, publication handoff, and runtime state.
 7. If RAP support or a required object operation is unavailable, stop that path and report the exact capability gap. Do not claim completion based on source text or inferred support.

package/.github/skills/rap-service-delivery/SKILL.md

@@ -7,7 +7,7 @@ description: Validate and deliver SAP RAP OData services, behavior implementatio
 
 ## MCP tool shortlist
 
-Query the active MCP server's live `tools/list` once and use exact destination-prefixed names and schemas. Prefer these curated addon tools when available: `GetSystemInfo`, `GetFeatures`, `GetConnectionInfo`, `SearchObject`, `GrepObjects`, `GrepPackages`, `GetSource`, `GetContext`, `ListDependencies`, `GetCDSDependencies`, `GetCDSImpactAnalysis`, `GetCDSElementInfo`, `GetClass`, `GetClassInfo`, `GetClassComponents`, `GetClassInclude`, `GetInterface`, `EditSource`, `WriteSource`, `PrepareABAPChangeSet`, `ApplyABAPChangeSet`, `LintABAP`, `SyntaxCheck`, `RunUnitTests`, `RunATCCheck`, `PrettyPrint`, `RunQuery`, `GetTableContents`, `GenerateRAPRegressionSuite`, `RunRAPRegressionSuite`, `GetApplicationLog`, `Activate`, and `ActivateMultiple`. Publish/unpublish, dump, trace, arbitrary execution/RFC, and code-coverage tools are not exposed by this addon. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them lowercase and snake_case under the `<destination>_` prefix, so `GetSource` on destination `DEMO_ABAP` appears as `demo-abap_get_source`. Always call the exact names returned by `tools/list`.
+Query the active MCP server's live `tools/list` once and use the exact live names and schemas. Prefer these curated addon tools when available: `GetSystemInfo`, `GetFeatures`, `GetConnectionInfo`, `SearchObject`, `GrepObjects`, `GrepPackages`, `GetSource`, `GetContext`, `ListDependencies`, `GetCDSDependencies`, `GetCDSImpactAnalysis`, `GetCDSElementInfo`, `GetClass`, `GetClassInfo`, `GetClassComponents`, `GetClassInclude`, `GetInterface`, `EditSource`, `WriteSource`, `PrepareABAPChangeSet`, `ApplyABAPChangeSet`, `LintABAP`, `SyntaxCheck`, `RunUnitTests`, `RunATCCheck`, `PrettyPrint`, `RunQuery`, `GetTableContents`, `GenerateRAPRegressionSuite`, `RunRAPRegressionSuite`, `GetApplicationLog`, `GetInactiveObjects`, `Activate`, and `ActivateMultiple`. Publish/unpublish, dump, trace, arbitrary execution/RFC, and code-coverage tools are not exposed by this addon. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them as lowercase snake_case. A server scoped to a single destination (the normal case for generated `mcp.json` entries) exposes them unprefixed, so `GetSource` appears as `get_source` and `LintABAP` as `lint_abap`; when several destinations share one server, each name is destination-prefixed with its slug for disambiguation (for example `cfd_run_query`). Always call the exact names returned by `tools/list`.
 
 1. Confirm target destination, package, transport/temporary target, RAP object names, and whether activation/publication/data mutation is authorized. Transport release and deletion remain out of scope for this skill; prepare and report transport context only.
 2. Plan before implementing. Present the RAP object chain to create or change in dependency order, the ABAP Unit test approach, the local authoring and validation approach (workspace files plus `LintABAP` and LSP), and the SAP write/activation/publication steps with the authorizations they require. Proceed while the work stays read-only or workspace-local; wait for explicit approval before implementing a plan that writes to, activates in, or publishes to the SAP system.
@@ -16,7 +16,7 @@ Query the active MCP server's live `tools/list` once and use exact destination-p
 5. Validate behavior implementations with tests first where feasible. Cover validations, determinations, actions, feature control, numbering, authorization-relevant branches, reported/failed messages, and negative or empty paths.
 6. Validate runtime service behavior end-to-end after the locally linted sources were sent to SAP. Use read-only `RunQuery`/`GetTableContents` for query paths. For mutating behavior, proceed only when authorized, use isolated data, verify persisted state/messages, and clean up when possible.
    Generate a reusable GET-only OData smoke suite with `GenerateRAPRegressionSuite`, save its returned JSON with the change, and rerun it with `RunRAPRegressionSuite`. Add JSON-path assertions for business behavior that metadata alone cannot prove.
-7. Activate in dependency order only when authorized: lower CDS/model dependencies first, then behavior artifacts, projections, service definition, and service binding. If publication is requested, hand it off unless another live server exposes an exact publish tool.
+7. Check pending inactive objects with `GetInactiveObjects`, then activate in dependency order only when authorized: lower CDS/model dependencies first, then behavior artifacts, projections, service definition, and service binding. If publication is requested, hand it off unless another live server exposes an exact publish tool.
 8. If runtime validation fails, inspect `GetApplicationLog`, source/reference context, dependencies, debugger state when authorized, and safe runtime data before guessing. Report exact evidence, not inferred success.
 
 Transport release is unavailable through this workflow. Report transport readiness and creation separately, and never claim that a transport was released or deleted.

package/.github/skills/sap-sdlc-orchestration/SKILL.md

@@ -7,7 +7,7 @@ description: Orchestrate the SAP delivery lifecycle from requirement analysis th
 
 ## Tool shortlist
 
-Query the active MCP server's live `tools/list` once; use task-relevant, destination-prefixed tools with their returned schemas. Investigate system and repository context with `GetSystemInfo`, `GetFeatures`, `GetConnectionInfo`, `GetInstalledComponents`, `SearchObject`, `GrepObjects`, `GrepPackages`, `GetSource`, `GetContext`, `FindDefinition`, `FindReferences`, `CompareSource`, and dependency tools (`ListDependencies`, CDS dependency/impact tools). Validate with `LintABAP`, `SyntaxCheck`, `RunUnitTests`, `RunATCCheck`, runtime queries, `GetApplicationLog`, and RAP regression-suite tools when exposed. Use transport tools for readiness planning only; never claim transport release/deletion support because transport release is unavailable through this addon. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them lowercase and snake_case under the `<destination>_` prefix, so `GetSource` on destination `DEMO_ABAP` appears as `demo-abap_get_source`. Always call the exact names returned by `tools/list`.
+Query the active MCP server's live `tools/list` once; use task-relevant tools with their returned schemas. Investigate system and repository context with `GetSystemInfo`, `GetFeatures`, `GetConnectionInfo`, `GetInstalledComponents`, `SearchObject`, `GrepObjects`, `GrepPackages`, `GetSource`, `GetContext`, `FindDefinition`, `FindReferences`, `CompareSource`, and dependency tools (`ListDependencies`, `GetCDSDependencies`, `GetCDSImpactAnalysis`). Validate with `LintABAP`, `SyntaxCheck`, `RunUnitTests`, `RunATCCheck`, runtime queries (`RunQuery`, `GetTableContents`), `GetApplicationLog`, and `GenerateRAPRegressionSuite` / `RunRAPRegressionSuite` when exposed. Use transport tools for readiness planning only; never claim transport release/deletion support because transport release is unavailable through this addon. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them as lowercase snake_case. A server scoped to a single destination (the normal case for generated `mcp.json` entries) exposes them unprefixed, so `GetSource` appears as `get_source` and `LintABAP` as `lint_abap`; when several destinations share one server, each name is destination-prefixed with its slug for disambiguation (for example `cfd_run_query`). Always call the exact names returned by `tools/list`.
 
 1. Convert the requirement into an SDLC plan: discovery, fit-gap/API recommendation, architecture, implementation packages, test strategy, validation gates, activation/publication gates, transport readiness, deployment notes, rollback, and operations handover.
 2. Require a planning phase before implementation for every work package. Each package starts with a presented plan of objects, tests, and validation steps; no SAP state-changing package proceeds before the user approves it. Every implementation package includes a local quality gate: sources are authored locally as abapGit-style workspace files (`object.type.extension`) and must pass `LintABAP` plus LSP checks before they are sent to the SAP system.

package/.github/skills/sap-standard-api-analysis/SKILL.md

@@ -7,7 +7,7 @@ description: Assess requirements against SAP standard capabilities, released API
 
 ## Tool shortlist
 
-Query the active MCP server's live `tools/list` once; use task-relevant, destination-prefixed tools with their returned schemas. Inspect target capabilities with `GetSystemInfo`, `GetFeatures`, `GetConnectionInfo`, and `GetInstalledComponents`. Search candidates with `SearchObject`, `GrepObjects`, `GrepPackages`, `GetSource`, `GetContext`, `FindDefinition`, `FindReferences`, `ListDependencies`, `GetCDSDependencies`, `GetCDSImpactAnalysis`, and `GetCDSElementInfo`. Verify released API status with `GetAPIReleaseState` or batch with `PlanABAPCloudMigration` when exposed. Use `RunQuery` or `GetTableContents` only for safe read-only evidence. Never claim transport release/deletion support; transport release is unavailable through this addon. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them lowercase and snake_case under the `<destination>_` prefix, so `GetSource` on destination `DEMO_ABAP` appears as `demo-abap_get_source`. Always call the exact names returned by `tools/list`.
+Query the active MCP server's live `tools/list` once; use task-relevant tools with their returned schemas. Inspect target capabilities with `GetSystemInfo`, `GetFeatures`, `GetConnectionInfo`, and `GetInstalledComponents`. Search candidates with `SearchObject`, `GrepObjects`, `GrepPackages`, `GetSource`, `GetContext`, `FindDefinition`, `FindReferences`, `ListDependencies`, `GetCDSDependencies`, `GetCDSImpactAnalysis`, and `GetCDSElementInfo`. Verify released API status with `GetAPIReleaseState` or batch with `PlanABAPCloudMigration` when exposed. Use `RunQuery` or `GetTableContents` only for safe read-only evidence. Never claim transport release/deletion support; transport release is unavailable through this addon. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them as lowercase snake_case. A server scoped to a single destination (the normal case for generated `mcp.json` entries) exposes them unprefixed, so `GetSource` appears as `get_source` and `LintABAP` as `lint_abap`; when several destinations share one server, each name is destination-prefixed with its slug for disambiguation (for example `cfd_run_query`). Always call the exact names returned by `tools/list`.
 
 1. Translate the requirement into business capabilities, integration contracts, data entities, and observable acceptance criteria before choosing implementation objects.
 2. Prefer SAP standard configuration, standard processes, communication scenarios, released OData/RFC/BAPI APIs, released CDS views/entities, RAP BOs, business events, BADIs, and documented extension points. Record all inspected candidates and whether each is standard, released, deprecated, unavailable, or unverified.

package/.github/skills/sap-transport-release/SKILL.md

@@ -7,8 +7,8 @@ description: Prepare ABAP changes for SAP transport and verify request contents,
 
 ## Tool shortlist
 
-Query the active MCP server's live `tools/list` once; use task-relevant, destination-prefixed tools with their returned schemas. Identify candidates with `GetUserTransports` or `ListTransports`; inspect a request with `GetTransport` / `GetTransportInfo`; use `CheckTransportReadiness` to collect transport, dependency, inactive-object, ABAP Unit, and ATC evidence when available. Activate with `Activate` / `ActivateMultiple` only when requested. `CreateTransport` is state-changing and requires explicit authorization. Release and deletion are not available through this addon. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them lowercase and snake_case under the `<destination>_` prefix, so `GetSource` on destination `DEMO_ABAP` appears as `demo-abap_get_source`. Always call the exact names returned by `tools/list`.
+Query the active MCP server's live `tools/list` once; use task-relevant tools with their returned schemas. Identify candidates with `GetUserTransports` or `ListTransports`; inspect a request with `GetTransport` / `GetTransportInfo`; use `CheckTransportReadiness` to collect transport, dependency, inactive-object, ABAP Unit, and ATC evidence when available. Activate with `Activate` / `ActivateMultiple` only when requested. `CreateTransport` is state-changing and requires explicit authorization. Release and deletion are not available through this addon. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them as lowercase snake_case. A server scoped to a single destination (the normal case for generated `mcp.json` entries) exposes them unprefixed, so `GetSource` appears as `get_source` and `LintABAP` as `lint_abap`; when several destinations share one server, each name is destination-prefixed with its slug for disambiguation (for example `cfd_run_query`). Always call the exact names returned by `tools/list`.
 
-1. Use `CheckTransportReadiness` with exactly one `GetTransport` check for the requested ID and applicable dependency, inactive-object, test, and ATC checks. Review each returned evidence item; a completed call can still contain findings. Verify the destination, package, complete object set, dependencies, and an eligible modifiable request before preparing changes.
+1. Use `CheckTransportReadiness` with exactly one `GetTransport` check for the requested ID plus applicable `GetTransportInfo`, `ListDependencies`, `GetInactiveObjects`, `RunUnitTests`, and `RunATCCheck` checks — the only check tools that tool accepts. Review each returned evidence item; a completed call can still contain findings. Verify the destination, package, complete object set, dependencies, and an eligible modifiable request before preparing changes.
 2. Create a transport only when the user specifically authorized its creation. Before transport handoff, ensure changed objects have been activated in dependency order when activation is authorized, ABAP Unit tests have been run or blockers documented, runtime validation evidence exists for changed public contracts, and ATC/syntax checks have been run where available. Do not treat request contents, syntax, ATC, or activation as substitutes for behavior and runtime validation evidence. Report actual request contents and validation state.
 3. This addon does not expose transport release or deletion tools. Do not invent or claim release/deletion support. When release is requested, report that release is unavailable through this addon and hand off the release action to an authorized SAP transport workflow.

package/README.md

@@ -68,7 +68,7 @@ Then connect a destination in SAP Business Application Studio:
 
 Use the attached destination-prefixed tools directly in chat. Do not launch `sap-ai-dev` or handcraft MCP JSON-RPC in a terminal to discover or call them.
 
-**Prerequisite:** Node.js 20 or newer. If Go is not already available, the installer can provision the pinned supported Go release automatically.
+**Prerequisite:** Node.js 20 or newer. The pinned VSP runtime ships with the package; no Go toolchain is installed or required.
 
 ## 🤖 Available agents and skills
 
@@ -78,7 +78,7 @@ Use the attached destination-prefixed tools directly in chat. Do not launch `sap
 | --- | --- | --- |
 | 🧭 | **SAP Solution Architect** | System investigation, SAP standard/API recommendations, Clean Core and side-by-side design, and SDLC orchestration through implementation handoffs and validation gates |
 | 🧑‍💻 | **ABAP Developer** | General ABAP, CDS, and RAP implementation, validation, and transport-preparation tasks |
-| 🐞 | **ABAP Runtime Debugger** | Runtime incidents, dumps, logs, traces, debugger sessions, call graphs, and performance symptoms |
+| 🐞 | **ABAP Runtime Debugger** | Runtime incidents, application logs, debugger sessions, and performance symptoms; call relationships are derived from source inspection |
 | 🚀 | **RAP Service Developer** | RAP business objects, behavior implementations, projections, service definitions, service bindings, and OData validation |
 | 🗃️ | **HANA Cloud/HDI Specialist** | Read-only HANA Cloud container inspection, CAP/HDI artifact generation, local validation, and user-run deployment handoffs |
 
@@ -168,7 +168,7 @@ The package ships with five custom agents plus fourteen task-focused Copilot Age
 | 🧱 | `clean-core-extensibility` | Clean Core, released extensibility, and side-by-side extension design with risk classification |
 | 🔁 | `sap-sdlc-orchestration` | Requirement-to-release lifecycle planning, delegated implementation, quality gates, validation, and handover |
 | 🐞 | `abap-debugging` | Dumps, logs, traces, and runtime failure diagnosis |
-| 🔬 | `abap-runtime-analysis` | Incident triage, traces, debugger state, call graphs, and performance analysis |
+| 🔬 | `abap-runtime-analysis` | Incident triage, debugger state, and performance analysis; call relationships come from source inspection |
 | 🚀 | `rap-service-delivery` | RAP service activation, publication, OData validation, and end-to-end runtime checks |
 | 🚚 | `sap-transport-release` | Dependency checks and transport preparation; release itself is intentionally unavailable here |
 | 🔎 | `hana-cloud-inspection` | Verify the selected HANA Cloud binding and inspect bounded HDI catalog/data results |
@@ -237,6 +237,7 @@ Once the destination server is enabled in Copilot Chat, ask for outcomes instead
 | --- | --- |
 | 🎯 **Explicit target** | SAP changes only proceed when the destination and required target details are known. |
 | 🚦 **Explicit state change** | Activation, service publication, and transport creation happen only when requested and authorized. |
+| 👁️ **Optional read-only mode** | `SAP_AI_DEV_TOOLKIT_READ_ONLY=true` removes every write/activate/transport-create tool from the surface and starts VSP with `--transport-read-only`. Recommended for exploration destinations. |
 | 🧪 **Verification first** | The agent uses available lint, syntax, unit-test, ATC, and diagnostics workflows and reports what actually ran. |
 | 🔒 **SAP authorization remains authoritative** | The add-on does not bypass backend SAP permissions. |
 | 🚚 **Curated VSP tool surface** | The proxy exposes a cherry-picked developer-lifecycle set from VSP plus local workflow tools, keeping one destination below 60 tools; SAP authorizations and VSP safety checks still apply. |
@@ -270,14 +271,14 @@ The guided setup can also offer companion MCP entries with `sap-ai-dev --setup -
 | CAP tools | `@cap-js/mcp-server` | CAP CDS/service model inspection and CAP app development |
 | Browser validation | `@playwright/mcp` | Fiori/UI smoke tests, screenshots, and browser runtime validation |
 
-The installer handles two setup tasks automatically:
+The installer handles VSP provisioning automatically:
 
-- Looks for Go in `GO_BINARY`, `PATH`, or the package-local Go installation. If none is available, it downloads and installs the pinned supported Go release without prompting.
-- Uses the package's checksum-verified patched VSP binary for the current platform. A remote download is the fallback only when the package has no bundled asset.
+- Uses the package's bundled patched VSP binary for the current platform, verified against the npm-published `dist/checksums.txt`. A checksum-anchored remote download is the fallback only when the package has no bundled asset.
+- No Go toolchain is downloaded or required at install time; Go is only used by the repository's own `build:vsp` development script.
 
 With `H2O_URL` set, an interactive install opens a checkbox picker with no destinations selected by default. Use **Space** to choose destinations and **Enter** to confirm. Press **a** to toggle all destinations (select all if any are unchecked; otherwise clear the selection). Confirming with none selected removes this add-on's managed MCP entries. When the `cf` CLI 8.18 or newer is authenticated to a targeted space, setup first offers an optional import from that space's Destination service; type **y** then **Enter** to include it, or press **Enter** to skip. Accepted CF and BAS destinations appear together in the picker. npm may run its install hook without an interactive terminal, even when the shell is interactive; in that case, selection is skipped without changing MCP config.
 
-Some current npm versions also require install hooks to be approved. If npm reports that `sap-ai-dev-toolkit`'s `postinstall` was blocked, allow it during a fresh install with `npm install --global --allow-scripts=sap-ai-dev-toolkit sap-ai-dev-toolkit`, or run `sap-ai-dev-toolkit --setup` from an interactive BAS terminal after installation.
+Some current npm versions also require install hooks to be approved. If npm reports that `sap-ai-dev-toolkit`'s `postinstall` was blocked, allow it during a fresh install with `npm install --global --allow-scripts=sap-ai-dev-toolkit sap-ai-dev-toolkit`, or run `sap-ai-dev --setup` from an interactive BAS terminal after installation.
 
 The setup report uses icons and terminal colors; set `NO_COLOR=1` to disable ANSI colors. The table is a weather report, not a bouncer: green **PASS** means the ADT probe responded, red **FAIL** means it failed, and yellow **SKIPPED** means it was skipped. Probe failures do not block MCP registration or startup for destinations you select.
 
@@ -300,7 +301,7 @@ This lists discovered systems in the same checkbox picker, with nothing selected
 For a non-interactive installation or a platform without a published VSP asset, provide a trusted binary override:
 
 ```sh
-BAS_VSP_BINARY=/path/to/vsp npm install --global sap-ai-dev-toolkit
+SAP_AI_DEV_TOOLKIT_BINARY=/path/to/vsp npm install --global sap-ai-dev-toolkit
 ```
 
 At the end of a global install, the color-coded summary shows the MCP config path, each generated entry name, destination/client/authentication, launch command, and environment key names (not values). The installer does not open an editor automatically; in BAS/VS Code:
@@ -339,7 +340,7 @@ The package includes five user-invocable custom agents (**SAP Solution Architect
 | 🧱 | `clean-core-extensibility` | Design Clean Core compliant in-app, developer, API/event, and side-by-side extension patterns. |
 | 🔁 | `sap-sdlc-orchestration` | Orchestrate discovery, design, implementation handoffs, quality gates, transport readiness, and handover. |
 | 🐞 | `abap-debugging` | Diagnose dumps, application logs, traces, and runtime failures. |
-| 🔬 | `abap-runtime-analysis` | Analyze incidents, traces, debugger state, call graphs, and performance symptoms. |
+| 🔬 | `abap-runtime-analysis` | Analyze incidents, debugger state, and performance symptoms; derive call relationships from source inspection. |
 | 🚀 | `rap-service-delivery` | Validate RAP service bindings, activation, publication, and end-to-end OData behavior. |
 | 🚚 | `sap-transport-release` | Check dependencies and prepare changes for transport; release is not available here. |
 | 🔎 | `hana-cloud-inspection` | Verify the attached HANA target and inspect bounded HDI metadata and rows. |
@@ -348,7 +349,7 @@ The package includes five user-invocable custom agents (**SAP Solution Architect
 
 ### 📥 Install for your BAS user
 
-After destination setup, the installer prints a 🤖 notice that it is waiting for confirmation, then offers to install all bundled agents and skills under `$HOME/.copilot`. Press **Enter** to install; type **n** then **Enter** to skip. Declining leaves those files unchanged.
+After destination setup, the installer prints a 🤖 notice that it is waiting for confirmation, then offers to install all bundled agents and skills under `$HOME/.copilot`. Type **y** then **Enter** to install; pressing **Enter** alone skips (the default). Declining leaves those files unchanged.
 
 These user-level customizations are available across workspaces opened by the same BAS user in the same dev space. Copilot must be available in BAS and may need a window reload to discover new files. A non-interactive install skips the optional prompt; `npm install --ignore-scripts` skips the postinstall wizard entirely.
 
@@ -403,7 +404,7 @@ For on-premise systems, configure Cloud Connector access to the backend host and
 
 Think of `H2O_URL` as BAS's front door: it must point to the endpoint serving `/api/listDestinations`, not to the SAP backend.
 
-The `/api/listDestinations` response is a JSON array of destination records, like the provided `dests.sample.json`. A representative record:
+The `/api/listDestinations` response is a JSON array of destination records. A representative record:
 
 ```json
 {
@@ -447,7 +448,7 @@ One selected system, one isolated stdio MCP entry. Here's the shape:
 }
 ```
 
-The MCP protocol `serverInfo.name` matches `BAS_VSP_DESTINATION`, so each wizard-generated destination has its own identity instead of the shared `sap-ai-dev-toolkit` name.
+The MCP protocol `serverInfo.name` is the lowercased destination slug (from `SAP_AI_DEV_TOOLKIT_DESTINATION`, legacy `BAS_VSP_DESTINATION` accepted), so each wizard-generated destination has its own identity instead of the shared `sap-ai-dev-toolkit` name.
 
 Credentials, cookies, SAP usernames, passwords, and raw BAS destination payloads are not written to the MCP configuration.
 
@@ -489,7 +490,7 @@ Without `H2O_URL`, the command passes arguments directly to the installed VSP bi
 
 `sap-ai-dev` is an MCP stdio server and destination router, not a terminal command for individual SAP operations. No shell incantations needed: your MCP client discovers the tools, picks one for the chat request, and sends the call over stdio.
 
-Each generated MCP server entry is named with the lowercased destination slug: `DEMO_ABAP` becomes `demo-abap`. Tool names are `<destination-slug>_<tool>` with a lowercase snake_case tool segment (`demo-abap_get_source`, `demo-abap_run_query`, `demo-abap_lint_abap`), so every tool states which SAP system it targets. Lowercase names are deliberate: BAS and VS Code derive chat tool references from the server and tool names and only bind lowercase identifiers, so mixed-case names show up in the tools picker but never bind to the chat session. Use the exact names shown by your MCP client; punctuation can change during slugification.
+Each generated MCP server entry is named with the lowercased destination slug: `DEMO_ABAP` becomes `demo-abap`. Because every generated entry is scoped to exactly one destination, tool names carry no redundant prefix — they are plain lowercase snake_case (`get_source`, `run_query`, `lint_abap`); the server name already states which SAP system it targets. Only when one server fronts several destinations (manual multi-destination startup) does each name gain its destination slug (`demo-abap_run_query`) to stay unambiguous. Lowercase names are deliberate: BAS and VS Code derive chat tool references from the server and tool names and only bind lowercase identifiers, so mixed-case names show up in the tools picker but never bind to the chat session. Use the exact names shown by your MCP client; punctuation can change during slugification.
 
 Upgrading from an earlier release that wrote mixed-case entry names (for example `ActionS4D` or `cf:<guid>:<guid>:<name>`)? Re-run `sap-ai-dev --setup` to replace legacy entries — this is the only migration path for Cloud Foundry entries — or run `sap-ai-dev --doctor` to rename BAS entries in place. Then reload the BAS window and start a new chat; an existing chat keeps its stale tool binding. If setup reports that the lowercase name already exists and is not managed by this package, rename or remove that user-owned server entry first.
 
@@ -505,7 +506,7 @@ The menu includes the tools registered by the active VSP mode, the `GetApplicati
 
 ### 🧹 Lint submitted ABAP source locally
 
-The per-destination tool name is `<destination-slug>_lint_abap`, for example `demo-abap_lint_abap` (the local workflow name `LintABAP` is exposed in snake_case). It accepts caller-supplied abapGit-serialized source files; config is optional and, when present, is the full abaplint configuration rather than a merge with defaults.
+The tool is named `lint_abap` (the local workflow name `LintABAP` exposed in snake_case; on a multi-destination server it is `<destination-slug>_lint_abap`). It accepts caller-supplied abapGit-serialized source files; config is optional and, when present, is the full abaplint configuration rather than a merge with defaults.
 
 ```json
 {
@@ -545,7 +546,7 @@ For an ABAP Cloud assessment, get object URIs from `SearchObject` and pass them
 
 `tools/list` confirms what this MCP server exposes; it does not prove that VS Code attached the server to the active chat. Start the selected destination in **MCP: List Servers**, enable it in the Chat tools picker, and reload/reselect the agent if the host binding is stale. This add-on cannot inspect or repair another MCP server's registration or a host-wide tool budget.
 
-`sap-ai-dev-toolkit --demo` starts an isolated server with sample ABAP objects, test and ATC results, a sample transport, and synthetic OData metadata and rows. Source edits and transport creation stay in process memory and disappear on exit. The demo does not discover or contact BAS or SAP destinations.
+`sap-ai-dev --demo` starts an isolated server with sample ABAP objects, test and ATC results, a sample transport, and synthetic OData metadata and rows. Source edits and transport creation stay in process memory and disappear on exit. The demo does not discover or contact BAS or SAP destinations.
 
 ### 🔎 Find and understand ABAP objects
 
@@ -605,6 +606,7 @@ The write and activation tools change SAP state. Confirm the target, package, an
 | `GetSystemInfo` | Read system ID, SAP release, kernel, and database details. |
 | `GetInstalledComponents` | List installed software components and versions. |
 | `GetFeatures` | Probe optional system capabilities, including abapGit, RAP/OData, AMDP debugging, UI5/BSP, and CTS transports. |
+| `GetConnectionInfo` | Show the connected user, client, URL, mode, and feature-probe summary for the current destination session. |
 | `PrettyPrint` | Format ABAP source text without saving it to SAP. |
 
 ### 🚚 Inspect and create transports
@@ -642,7 +644,7 @@ The proxy intentionally does not expose the full child VSP process. Object delet
 3. Ask for the operation in plain language. The MCP client sends `tools/call`; no need to type a tool such as `GetSource` into a terminal.
 4. Check the response in chat. For source edits, ask for a syntax check and tests before activation when that matches your workflow.
 
-For a quick table read—say, company codes from `T001`—select the destination's `RunQuery` tool (for `DEMO_ABAP`, `demo-abap_run_query`) and pass:
+For a quick table read—say, company codes from `T001`—select the destination's `RunQuery` tool (exposed as `run_query`; `demo-abap_run_query` only on a multi-destination server) and pass:
 
 ```json
 {
@@ -659,7 +661,7 @@ The same request can be expressed to an MCP client as:
   "id": 2,
   "method": "tools/call",
   "params": {
-    "name": "demo-abap_run_query",
+    "name": "run_query",
     "arguments": {
       "sql_query": "SELECT BUKRS, BUTXT, WAERS, LAND1 FROM T001",
       "max_rows": 100
@@ -707,7 +709,7 @@ The response contains a `tools` array. A `RunQuery` entry resembles this excerpt
 
 ```json
 {
-  "name": "demo-abap_run_query",
+  "name": "run_query",
   "description": "Execute an ABAP SQL query [destination: DEMO_ABAP]",
   "inputSchema": {
     "type": "object",
@@ -734,13 +736,18 @@ The response contains a `tools` array. A `RunQuery` entry resembles this excerpt
 | `SAP_AI_DEV_TOOLKIT_DISABLE_BAS_RELAY=true` | Disable the built-in BAS destination relay. By default the add-on self-heals `.dest` destinations through a local relay that keeps all access destination-based while handling ADT CSRF fetch/retry behavior before VSP calls SAP. |
 | `SAP_AI_DEV_TOOLKIT_HTTP_PROXY` | Egress proxy for relay and discovery traffic. Takes precedence over `HTTP_PROXY`/`http_proxy`; unset means the default BAS proxy for `.dest` hosts, empty means direct except for OnPremise credential overrides, which require a BAS proxy tunnel. |
 | `SAP_AI_DEV_TOOLKIT_MAX_CSRF_RETRIES` | Bounded retries after explicit CSRF-session rejection per unsafe request (default 3, maximum 10). Invalid values use the default. |
+| `SAP_AI_DEV_TOOLKIT_READ_ONLY=true` | Read-only mode: hides `WriteSource`, `EditSource`, `Activate`, `ActivateMultiple`, `CreateTransport`, `SetBreakpoint`, and the change-set workflow tools, and starts VSP with `--transport-read-only`. |
+| `SAP_AI_DEV_TOOLKIT_REQUEST_TIMEOUT_MS` | Per-request timeout for calls forwarded to a VSP child (default 600000 = 10 minutes; `0` disables). A stalled request fails with a timeout error; the child is left running. |
 | `SAP_AI_DEV_MCP_CONFIG` | Explicit MCP configuration path; highest precedence. |
 | `SAP_AI_DEV_TOOLKIT_MCP_CONFIG` | Branded compatibility alias for the MCP configuration path. |
 | `BAS_VSP_MCP_CONFIG` | Backward-compatible alias for the MCP configuration path. |
-| `BAS_VSP_BINARY` | Trusted prebuilt VSP executable; skips Go and binary provisioning. |
-| `BAS_VSP_BINARY_URL` | Alternate VSP binary download URL. |
-| `BAS_VSP_CACHE_DIR` | Binary cache directory. |
-| `GO_BINARY` | Explicit Go executable used for provisioning when automatic Go installation is unavailable. |
+| `SAP_AI_DEV_TOOLKIT_CREDENTIALS_FILE` | Explicit path for the optional SAP backend credential-override file (default: beside `mcp.json`). |
+| `SAP_AI_DEV_TOOLKIT_BINARY` | Trusted prebuilt VSP executable; skips binary provisioning. Legacy `BAS_VSP_BINARY` still works. |
+| `SAP_AI_DEV_TOOLKIT_BINARY_URL` | Alternate VSP binary download URL (checksum-verified). Legacy `BAS_VSP_BINARY_URL` still works. |
+| `SAP_AI_DEV_TOOLKIT_RELEASE_BASE_URL` | Override the base URL that VSP release binaries are downloaded from. |
+| `SAP_AI_DEV_TOOLKIT_CACHE_DIR` | Binary cache directory. Legacy `BAS_VSP_CACHE_DIR` still works. |
+| `BAS_CF_SPACE_GUID`, `BAS_CF_DESTINATION_INSTANCE_GUID`, `BAS_CF_DESTINATION_INSTANCE`, `BAS_CF_DESTINATION_KEY`, `BAS_CF_DESTINATION_NAME`, `BAS_CF_CONNECTIVITY_INSTANCE_GUID`, `BAS_CF_CONNECTIVITY_INSTANCE`, `BAS_CF_CONNECTIVITY_KEY` | Written into generated Cloud Foundry destination entries; they reference service instances and key **names** (never credentials). |
+| `GO_BINARY` | Explicit Go executable for the repository-only `build:vsp` script; not used during installation. |
 | `SAP_AI_DEV_TOOLKIT_SKIP_PROBE=true` | Skip destination probes; useful for controlled diagnostics or fixtures. |
 | `HTTP_PROXY` / `HTTPS_PROXY` | BAS proxy settings used for destination-list requests, destination probing, and child processes. |
 | `NO_PROXY` | Proxy bypass list for BAS destination-list requests; `.dest` hosts remain routed through the BAS proxy. |

package/inventory.md

@@ -6,8 +6,8 @@ This inventory reflects the current SAP AI Dev Toolkit proxy behavior in `src/mc
 
 | Status | Count | Notes |
 | --- | ---: | --- |
-| VSP tools | Up to 51 | Curated from the child VSP tool list and exposed with a destination prefix in lowercase snake_case, for example `<destination>_get_source`. |
-| Local lint tool | 1 per destination | `LintABAP` analyzes caller-supplied ABAP source in memory; it is exposed publicly as `<destination>_lint_abap`. |
+| VSP tools | Up to 51 | Curated from the child VSP tool list and exposed in lowercase snake_case, unprefixed (`get_source`) on single-destination servers; a destination slug prefix (`demo-abap_get_source`) appears only when one server fronts multiple destinations. |
+| Local lint tool | 1 per destination | `LintABAP` analyzes caller-supplied ABAP source in memory; it is exposed publicly as `lint_abap`. |
 | Workflow tools | Up to 6 per destination | Review/apply change sets, transport evidence, Clean Core release assessment, and read-only RAP regression suites. Some are exposed only when their upstream VSP tools are registered. |
 | Convenience mapping | Dynamic | `GetApplicationLog` maps to VSP `SAP(action="analyze", type="application_log")` when the SAP router is registered. |
 | Intentionally filtered VSP tools | Dynamic | Destructive, broad-router, trace, and unsupported VSP operations are hidden from direct calls. |
@@ -161,8 +161,10 @@ These logical names are exposed through MCP in lowercase snake_case (`lint_abap`
 
 ## Notes
 
-- Runtime tool names are `<destination-slug>_<tool>`, for example `demo-abap_run_query`; `tools/call` accepts the exact name returned by `tools/list`.
+- Runtime tool names are unprefixed lowercase snake_case (`run_query`) on the normal single-destination server; a `<destination-slug>_` prefix appears only on multi-destination servers. `tools/call` accepts the exact name returned by `tools/list`.
 - The proxy starts VSP with `--enable-transports`; generated MCP entries set `SAP_ALLOW_TRANSPORTABLE_EDITS=true`.
+- `SAP_AI_DEV_TOOLKIT_READ_ONLY=true` switches a server to read-only: the write/activate/transport-create/breakpoint tools above are removed from the surface, change-set workflows are not registered, and VSP starts with `--transport-read-only` instead.
+- `SAP_AI_DEV_TOOLKIT_REQUEST_TIMEOUT_MS` (default 600000) bounds each forwarded call; stalled requests fail without killing the child.
 - Transport release/deletion and the general-purpose `SAP` router are intentionally hidden from direct proxy calls. `GetApplicationLog` is the bounded convenience mapping for the SAP application-log route.
 
 ## Separate optional HANA Cloud inspector

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "sap-ai-dev-toolkit",
-  "version": "0.5.6",
+  "version": "0.5.7",
   "description": "SAP AI development toolkit for BAS, ABAP, RAP, CAP, HANA Cloud, Fiori, UI5, and MCP",
   "author": "Gurkan Yilmaz",
   "type": "module",

package/src/launcher.mjs

@@ -108,11 +108,15 @@ async function runDoctor(destinations) {
       const listed = await proxy.handle({ jsonrpc: '2.0', id: 2, method: 'tools/list', params: {} });
       if (listed?.error) throw new Error(listed.error.message || 'MCP tools/list failed');
       const tools = listed.result?.tools || [];
+      // Doctor inspects one destination per proxy, so tool names are
+      // unprefixed (get_source, run_query); match the slug-prefixed form too
+      // in case this ever runs against a multi-destination server.
       const toolPrefix = `${slugifyDestination(destination.name)}_`;
       const localSegments = new Set(['lint_abap', 'get_application_log', 'prepare_abap_change_set', 'apply_abap_change_set', 'check_transport_readiness', 'plan_abap_cloud_migration', 'generate_rap_regression_suite', 'run_rap_regression_suite']);
-      const upstreamCount = tools.filter(tool => tool.name.startsWith(toolPrefix) && !localSegments.has(tool.name.slice(toolPrefix.length))).length;
+      const isUpstreamTool = tool => (tool.name.startsWith(toolPrefix) ? tool.name.slice(toolPrefix.length) : tool.name);
+      const upstreamCount = tools.filter(tool => !localSegments.has(isUpstreamTool(tool))).length;
       checks.push(doctorRow(destination.name, 'MCP tools/list', upstreamCount ? 'passed' : 'failed', `${upstreamCount} VSP tools and ${tools.length} total MCP tools returned; chat-picker binding is host-managed`));
-      const systemInfo = tools.find(tool => tool.name === `${toolPrefix}get_system_info`);
+      const systemInfo = tools.find(tool => tool.name === 'get_system_info' || tool.name === `${toolPrefix}get_system_info`);
       if (!systemInfo) {
         checks.push(doctorRow(destination.name, 'SAP system check', 'skipped', 'GetSystemInfo is not exposed by this VSP mode.'));
       } else {

package/src/mcp-proxy.mjs

@@ -613,6 +613,13 @@ export class MCPProxy {
     const namespace = new Map();
     const usedSlugs = new Map();
     const merged = [];
+    // Generated MCP entries pin exactly one destination per server, so tool
+    // names are unprefixed (run_query, get_source): the server name already
+    // identifies the target and a slug prefix would be redundant in chat
+    // references. Only when one server fronts several destinations (manual
+    // multi-destination startup) does each name carry its destination slug
+    // so every tool stays unambiguous.
+    const prefixed = this.children.length > 1;
     const publish = (name, mapping, definition) => {
       // A duplicate public name must not shadow the first registration: the
       // namespace map would keep the first handler while advertising both.
@@ -625,41 +632,54 @@ export class MCPProxy {
     };
     for (const entry of this.children) {
       const slug = slugifyDestination(entry.destination.name, usedSlugs);
-      const publicName = name => `${slug}_${publicToolSegment(name)}`;
+      const publicName = prefixed ? (name => `${slug}_${publicToolSegment(name)}`) : (name => publicToolSegment(name));
       const lintName = publicName(ABAP_LINT_TOOL.name);
       publish(lintName, { handler: runABAPLint }, { ...ABAP_LINT_TOOL, name: lintName });
+      let upstreamTools;
       try {
-        const upstreamTools = await entry.child.listToolsCached();
-        for (const tool of upstreamTools) {
-          if (tool.name === 'SAP') {
-            const applicationLogName = publicName('GetApplicationLog');
-            publish(applicationLogName, {
-              entry,
-              upstream: 'SAP',
-              publicName: 'GetApplicationLog',
-              transformArguments: applicationLogArguments
-            }, {
-              name: applicationLogName,
-              description: `${APPLICATION_LOG_DESCRIPTION} [destination: ${entry.destination.name}]`,
-              inputSchema: APPLICATION_LOG_SCHEMA
-            });
-          }
-
-          if (!exposeVspTool(tool, this.readOnly)) continue;
-          const name = publicName(tool.name);
-          publish(name, { entry, upstream: tool.name }, { ...tool, name, description: `${tool.description || tool.name} [destination: ${entry.destination.name}]` });
-        }
-        for (const localTool of createEngineeringTools(entry, upstreamTools, { env: this.env, log: this.log })) {
-          const name = publicName(localTool.definition.name);
-          publish(name, { handler: localTool.handler }, {
-            ...localTool.definition,
-            name,
-            description: `${localTool.definition.description} [destination: ${entry.destination.name}]`
-          });
-        }
+        upstreamTools = await entry.child.listToolsCached();
+        entry.lastUpstreamTools = upstreamTools;
       } catch (error) {
         buildState.complete = false;
         this.eventSink(`[${entry.destination.name}] tools/list failed: ${redactText(error.message)}`, 'error');
+        // A crashed child must not silently remove its tools from the
+        // surface: fall back to the last successful listing so the names stay
+        // callable and the tools/call self-heal path can restart the child.
+        upstreamTools = entry.lastUpstreamTools;
+      }
+      if (!upstreamTools) continue;
+      for (const tool of upstreamTools) {
+        if (tool.name === 'SAP') {
+          const applicationLogName = publicName('GetApplicationLog');
+          publish(applicationLogName, {
+            entry,
+            upstream: 'SAP',
+            publicName: 'GetApplicationLog',
+            transformArguments: applicationLogArguments
+          }, {
+            name: applicationLogName,
+            description: `${APPLICATION_LOG_DESCRIPTION} [destination: ${entry.destination.name}]`,
+            inputSchema: APPLICATION_LOG_SCHEMA
+          });
+        }
+
+        if (!exposeVspTool(tool, this.readOnly)) continue;
+        const name = publicName(tool.name);
+        publish(name, { entry, upstream: tool.name }, { ...tool, name, description: `${tool.description || tool.name} [destination: ${entry.destination.name}]` });
+      }
+      // Local workflow tools gate on the upstream surface they can use; in
+      // read-only mode the hidden write tools must not enable change-set
+      // staging either.
+      const effectiveUpstream = this.readOnly
+        ? upstreamTools.filter(tool => !READ_ONLY_HIDDEN_VSP_TOOLS.has(tool.name))
+        : upstreamTools;
+      for (const localTool of createEngineeringTools(entry, effectiveUpstream, { env: this.env, log: this.log })) {
+        const name = publicName(localTool.definition.name);
+        publish(name, { handler: localTool.handler }, {
+          ...localTool.definition,
+          name,
+          description: `${localTool.definition.description} [destination: ${entry.destination.name}]`
+        });
       }
     }
     if (!merged.length && this.children.length) throw new Error('No destination child provided tools');
@@ -729,6 +749,7 @@ export class MCPProxy {
           if (!retriable) {
             this.eventSink(`[${mapped.entry.destination.name}] tools/call ${toolName} is state-changing; not retried after a child crash (possible duplicate write)`, 'warning');
           }
+          let restartFailure;
           if (childBroken && retriable && !this.shuttingDown) {
             try {
               await this.restartChild(mapped.entry);
@@ -736,9 +757,15 @@ export class MCPProxy {
               const retried = await mapped.entry.child.request('tools/call', upstreamParams);
               return retried.error ? { ...retried, id: message.id } : rpcResult(message.id, retried.result);
             } catch (restartError) {
+              restartFailure = restartError;
               this.eventSink(`[${mapped.entry.destination.name}] tools/call ${toolName} self-healing restart failed: ${diagnosticText(restartError.message)}`, 'error');
             }
           }
+          if (restartFailure) {
+            // The restart refusal (budget exhausted, shutdown) is the
+            // actionable cause; keep the original failure as context.
+            return rpcError(message.id, -32001, `Destination ${mapped.entry.destination.name} failed: ${error.message}; self-healing restart did not run: ${restartFailure.message}`);
+          }
           return error.rpcError ? rpcError(message.id, error.rpcError.code || -32001, error.rpcError.message || error.message, error.rpcError.data) : rpcError(message.id, -32001, `Destination ${mapped.entry.destination.name} failed: ${error.message}`);
         }
       }

package/tools.md

@@ -2,7 +2,7 @@
 
 The proxy no longer advertises every VSP tool. To keep the developer-lifecycle MCP surface manageable, each generated one-destination server exposes a cherry-picked set of VSP tools plus local workflow tools (currently 59 tools when all curated VSP capabilities are registered).
 
-The names below are the logical tool names. Publicly, every tool is exposed as `<destination-slug>_<tool>` in lowercase (for example `GetTableContents` on destination `DEMO_ABAP` is `demo-abap_get_table_contents`): BAS/VS Code chat tool references bind only lowercase identifiers, so mixed-case names never reach the model.
+The names below are the logical tool names. Publicly they are exposed in lowercase snake_case without a prefix (`get_table_contents`, `run_query`) because each generated MCP server is scoped to one destination; only when a single server fronts multiple destinations does each name gain its destination slug (`demo-abap_get_table_contents`) to stay unambiguous. BAS/VS Code chat tool references bind only lowercase identifiers, so mixed-case names never reach the model.
 
 Hidden upstream VSP tools are not directly callable through the proxy. Local workflow tools may still call hidden or non-advertised upstream operations internally when they are required for a bounded workflow.
 
@@ -75,7 +75,15 @@ The proxy adds local multi-step tools to each destination when their required VS
 - `PlanABAPCloudMigration` — batch SAP API release-state checks and prioritize recognized unreleased results.
 - `GenerateRAPRegressionSuite` and `RunRAPRegressionSuite` — create and run reusable OData GET-only checks under the selected service root.
 
-`sap-ai-dev-toolkit --doctor` checks destination probing, VSP startup, the `get_system_info` probe, and MCP tool listing. `sap-ai-dev-toolkit --demo` runs the sample tools and OData fixtures without contacting SAP; demo writes and transport creation remain in memory until that process exits.
+`sap-ai-dev --doctor` checks destination probing, VSP startup, the `get_system_info` probe, and MCP tool listing. `sap-ai-dev --demo` runs the sample tools and OData fixtures without contacting SAP; demo writes and transport creation remain in memory until that process exits.
+
+### Read-only mode
+
+Set `SAP_AI_DEV_TOOLKIT_READ_ONLY=true` (or legacy `BAS_VSP_READ_ONLY`) on a destination server to run it strictly read-only: `WriteSource`, `EditSource`, `Activate`, `ActivateMultiple`, `CreateTransport`, `SetBreakpoint`, and the change-set workflow tools are removed from the surface, and the VSP child starts with `--transport-read-only` so transport writes are rejected upstream as well. Inspection, queries, linting, and checks remain available.
+
+### Request timeouts
+
+Calls forwarded to a VSP child time out after `SAP_AI_DEV_TOOLKIT_REQUEST_TIMEOUT_MS` (default 600000 ms; `0` disables). A stalled request fails with a timeout error; the child keeps running so unrelated in-flight requests are unaffected.
 
 ## Separate optional HANA Cloud inspector