sap-ai-dev-toolkit 0.6.7 → 0.7.1

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

@@ -14,14 +14,14 @@ You are an ABAP development agent for SAP Business Application Studio (BAS). Fol
 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 `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.
+   - **CDS/RAP:** `GetSystemInfo`, `GetFeatures`, `GetInstalledComponents`, 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 plain source 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.
+5. **Author locally first; check and lint before sending to SAP.** Create or change sources in the workspace as plain source files named `object.type.extension` (for example `zcl_report.clas.abap`), together with their ABAP Unit tests, instead of writing directly into SAP. Author only the plain source files; do not generate XML or other object-metadata sidecar files. 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 `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.

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

@@ -22,7 +22,7 @@ You are a specialized SAP RAP service development agent for SAP Business Applica
    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 plain source 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.
+6. **Author locally first; check and lint before sending to SAP.** Create or change the RAP artifacts in the workspace as plain source 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. Author only the plain source files; do not generate XML or other object-metadata sidecar files. 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

@@ -22,7 +22,7 @@ Follow this workflow in order and use only capabilities actually exposed by the
 3. **Evaluate SAP standard and recommend APIs first.** Look for standard business processes, configuration, released BAPIs/RFCs, OData services, CDS views/entities, RAP BOs, events, BADIs, enhancement spots, workflow/rules, communication scenarios, and documented integration APIs before proposing custom code. Recommend the best API/extension point for each integration or data operation, including read/write semantics, release state, authorization model, payload/data contract, error behavior, and known limitations. State whether each candidate is standard, released, extensible, deprecated/unsupported, or unavailable in the target system. Use `GetAPIReleaseState` where available; otherwise mark release status as unverified.
 4. **Apply Clean Core and side-by-side rules.** Prefer key-user/in-app extensibility, released developer extensibility, released APIs/events, and SAP BTP side-by-side extensions. Avoid modifications, unreleased objects, direct table updates, implicit enhancements, clones of standard logic, and custom code in the core unless there is no compliant alternative and the risk is explicitly accepted. Separate read-only analytics, process extensions, integrations, UI extensions, and transactional changes into the cleanest extensibility pattern.
 5. **Design the target solution with best practices.** Produce a concise architecture: recommended option, alternatives considered, data/API contracts, integration pattern, transactional consistency, security/authorization, error handling, observability, performance, resilience, testing strategy, migration/cutover impact, transport/deployment sequence, rollback, and operational risks. Include exact objects/APIs inspected and gaps/blockers. Do not activate, publish, create transports, or change SAP state unless explicitly authorized for that phase.
-6. **Automate and orchestrate the SDLC lifecycle.** Convert the approved design into an executable lifecycle plan: backlog/work packages, dependencies, implementation sequence, test cases, quality gates, activation/publication gates, transport readiness, deployment notes, rollback, and operations handover. Require a planning phase before implementation for every work package: each package starts with a presented plan of objects, tests, and validation steps, and no SAP state-changing package proceeds before the user approves it. Include a local quality gate in every implementation package: ABAP/RAP sources are authored locally as plain workspace source files (`object.type.extension`) and must pass `LintABAP` plus LSP checks before they are sent to the SAP system; CAP/HANA work follows the HANA specialist's local build and user-run deployment handoff, including `cds build --for hana` when applicable. Automate every safe step exposed by the live MCP tools: inspect, analyze, delegate, validate, collect evidence, iterate on findings, and prepare release readiness. Keep all state-changing gates explicit and authorized.
+6. **Automate and orchestrate the SDLC lifecycle.** Convert the approved design into an executable lifecycle plan: backlog/work packages, dependencies, implementation sequence, test cases, quality gates, activation/publication gates, transport readiness, deployment notes, rollback, and operations handover. Require a planning phase before implementation for every work package: each package starts with a presented plan of objects, tests, and validation steps, and no SAP state-changing package proceeds before the user approves it. Include a local quality gate in every implementation package: ABAP/RAP sources are authored locally as plain workspace source files (`object.type.extension`; do not generate XML or other object-metadata sidecar files) and must pass `LintABAP` plus LSP checks before they are sent to the SAP system; CAP/HANA work follows the HANA specialist's local build and user-run deployment handoff, including `cds build --for hana` when applicable. Automate every safe step exposed by the live MCP tools: inspect, analyze, delegate, validate, collect evidence, iterate on findings, and prepare release readiness. Keep all state-changing gates explicit and authorized.
 7. **Plan delegation to implementation agents.** When implementation is requested, break the work into safe, ordered work packages. If the Copilot client supports subagents/delegation, hand off implementation packages to the specialized agents; otherwise provide ready-to-paste briefs for:
    - **ABAP Developer** for ABAP classes, reports, interfaces, tests, quality checks, and transport preparation.
    - **RAP Service Developer** for RAP BOs, CDS/projections, behavior, service definitions, bindings, and OData validation.

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

@@ -12,7 +12,7 @@ Query the active MCP server's live `tools/list` once; use task-relevant tools wi
 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 plain source 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.
+4. Author locally first; check and lint before sending to SAP. Create or change sources in the workspace as plain source files named `object.type.extension` (for example `zcl_report.clas.abap`), together with their tests, instead of writing directly into SAP. Author only the plain source files; do not generate XML or other object-metadata sidecar files. 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 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.

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

@@ -5,7 +5,7 @@ description: Analyze ABAP runtime incidents, debugger state, and performance sym
 
 # ABAP runtime analysis
 
-## MCP tool shortlist
+## Tool shortlist
 
 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`.
 

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

@@ -19,7 +19,7 @@ For the ABAP destination server, `RunQuery` is ABAP SQL—not HANA SQL. Use thos
 ## 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 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`.
+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 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`.
 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-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 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`.
+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 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/rap-development/SKILL.md

@@ -11,7 +11,7 @@ Query the active MCP server's live `tools/list` once; use task-relevant tools wi
 
 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 plain source 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.
+3. Author locally first; check and lint before sending to SAP. Create or change the RAP artifacts in the workspace as plain source 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. Author only the plain source files; do not generate XML or other object-metadata sidecar files. 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 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.

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

@@ -5,17 +5,17 @@ description: Validate and deliver SAP RAP OData services, behavior implementatio
 
 # RAP service delivery
 
-## MCP tool shortlist
+## Tool shortlist
 
 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.
 3. Inspect the full RAP object chain before changing anything: interface/root CDS, child/composition CDS, behavior definition, behavior pool/local handlers, projection CDS, projection behavior, service definition, service binding, tests, and package conventions.
-4. Author locally first; check and lint before sending to SAP. Create or change the RAP artifacts in the workspace as plain source 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. Author locally first; check and lint before sending to SAP. Create or change the RAP artifacts in the workspace as plain source 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. Author only the plain source files; do not generate XML or other object-metadata sidecar files. 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. 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.
+   - 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. 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.
 

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

@@ -10,7 +10,7 @@ description: Orchestrate the SAP delivery lifecycle from requirement analysis th
 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 plain workspace source files (`object.type.extension`) and must pass `LintABAP` plus LSP checks before they are sent to the SAP system.
+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 plain workspace source files (`object.type.extension`; do not generate XML or other object-metadata sidecar files) and must pass `LintABAP` plus LSP checks before they are sent to the SAP system.
 3. Automate what the active MCP tools safely allow. Read and analyze the system, propose standard APIs and extension points, generate implementation briefs, request or delegate coding work, run checks, collect evidence, and iterate until acceptance criteria are met or a blocker is proven.
 4. Keep state-changing gates explicit. Do not edit source, activate, publish, create transports, create test data, or execute mutating scenarios unless the user authorized that phase and the target destination/package/transport context is known.
 5. Enforce quality gates: unit or executable behavior tests, syntax, lint, ATC where available, runtime validation, security/authorization review, Clean Core/released API check, transport dependency check, and documented skipped checks with reasons.

package/README.md

@@ -813,7 +813,8 @@ NPM_PUBLISH_TOKEN=npm_...
 
 - `npm run publish:npm` publishes the version already set in `package.json`.
 - To publish a patch bump, run `npm run publish:npm -- --patch`; it updates `package.json` and `package-lock.json` before publishing. If publishing fails after the bump, retry without `--patch`.
-- Preview the package without publishing or changing its version with `npm run publish:npm -- --dry-run`.
+- npm's `prepublishOnly` hook builds the pinned VSP binaries for all platforms (including the Go toolchain if missing) and refuses to ship a tarball whose `dist/checksums.txt` does not list all five assets; it guards `npm run publish:npm` and a plain `npm publish` alike. Pass `--skip-build` to republish an already-built `dist/` without rebuilding.
+- Preview the package without publishing, changing its version, or building with `npm run publish:npm -- --dry-run`.
 
 The token is not printed or stored in the repository.
 

package/dist/checksums.txt

@@ -0,0 +1,5 @@
+8ab555658815db7de670b956dafe0f12d6a249e4f1e1cbbb058deb658a89a37d  vsp-linux-x64
+7011b716e295ce2cecc40b9a56e57d9a1ec24c2b9d6aa25ab46e5cde0ec23998  vsp-linux-arm64
+5c240a6b53e15ebaae817612aed1c5b95624a99adfc38e6abb9afa377de30d1a  vsp-darwin-x64
+28032c4d331253808ec9318e6db570420c6c9308935964de665e34374465d89f  vsp-darwin-arm64
+5bb45857489bbe5d57587d9abda0b768d3a1b352d89a2a6bf13b23af8d2fd45e  vsp-win32-x64.exe

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "sap-ai-dev-toolkit",
-  "version": "0.6.7",
+  "version": "0.7.1",
   "description": "SAP AI development toolkit for BAS, ABAP, RAP, CAP, HANA Cloud, Fiori, UI5, and MCP",
   "author": "Gurkan Yilmaz",
   "type": "module",
@@ -27,6 +27,7 @@
     "test:visibility": "node --test test/setup.test.mjs test/terminal-ui.test.mjs",
     "test:mutation": "node scripts/mutation-terminal-ui.mjs",
     "publish:npm": "node scripts/publish-npm.mjs",
+    "publish": "node scripts/build-vsp.mjs && node scripts/publish-npm.mjs",
     "ensure:go": "node scripts/ensure-go.mjs",
     "build:vsp": "node scripts/build-vsp.mjs"
   },

package/scripts/publish-npm.mjs

@@ -1,12 +1,14 @@
 import { spawn } from 'node:child_process';
 import { mkdtemp, readFile, rm, writeFile } from 'node:fs/promises';
-import { dirname, join } from 'node:path';
+import { realpathSync } from 'node:fs';
+import { dirname, join, resolve } from 'node:path';
 import { fileURLToPath } from 'node:url';
 import { tmpdir } from 'node:os';
+import { packagedBinaryAssets } from '../src/binary.mjs';
 
 const root = dirname(dirname(fileURLToPath(import.meta.url)));
 const args = new Set(process.argv.slice(2));
-const allowedArgs = new Set(['--patch', '--dry-run']);
+const allowedArgs = new Set(['--patch', '--dry-run', '--skip-build', '--verify-only']);
 
 function parseToken(value) {
   const tokenValue = value.trim();
@@ -57,6 +59,23 @@ function runNpm(npmArgs, env) {
   });
 }
 
+// dist/ is gitignored, so a publish from a clean checkout silently ships no
+// VSP binaries and every `npm install` of it fails (the 0.7.0 incident):
+// postinstall only downloads from a GitHub release as a fallback. The
+// prepublishOnly hook in package.json builds the binaries and re-invokes this
+// script with --verify-only, so an incomplete dist/ can never be published —
+// through publish:npm or a plain `npm publish` alike.
+export async function missingDistBinaries(directory = root) {
+  let text;
+  try {
+    text = await readFile(join(directory, 'dist', 'checksums.txt'), 'utf8');
+  } catch {
+    return packagedBinaryAssets();
+  }
+  const listed = new Set(text.split(/\r?\n/).map(line => line.trim().split(/\s+/)[1]).filter(Boolean));
+  return packagedBinaryAssets().filter(asset => !listed.has(asset));
+}
+
 async function main() {
   for (const argument of args) {
     if (!allowedArgs.has(argument)) throw new Error(`Unknown option: ${argument}`);
@@ -65,6 +84,20 @@ async function main() {
   const patch = args.has('--patch');
   if (dryRun && patch) throw new Error('--dry-run cannot be combined with --patch; it never changes the package version');
 
+  // Second half of the prepublishOnly hook (after build-vsp.mjs ran): refuse
+  // to let an incomplete dist/ reach the registry.
+  if (args.has('--verify-only')) {
+    const missing = await missingDistBinaries();
+    if (missing.length > 0) throw new Error(`dist/checksums.txt is missing ${missing.join(', ')}; run npm run build:vsp first`);
+    console.error('dist/checksums.txt lists every pinned VSP binary.');
+    return;
+  }
+
+  if (dryRun) {
+    const missing = await missingDistBinaries();
+    if (missing.length > 0) console.error(`Dry-run note: dist/ is missing ${missing.join(', ')}; a real publish builds them via the prepublishOnly hook.`);
+  }
+
   let authDirectory;
   try {
     let env = { ...process.env };
@@ -83,7 +116,10 @@ async function main() {
 
     if (patch) await runNpm(['version', 'patch', '--no-git-tag-version'], env);
     const packageJson = JSON.parse(await readFile(join(root, 'package.json'), 'utf8'));
-    const publishArgs = ['publish', '--access', 'public', ...(dryRun ? ['--dry-run'] : [])];
+    // --dry-run and --skip-build bypass lifecycle scripts so neither waits
+    // through the prepublishOnly build; a real publish always runs it.
+    const bypassScripts = dryRun || args.has('--skip-build');
+    const publishArgs = ['publish', '--access', 'public', ...(bypassScripts ? ['--ignore-scripts'] : []), ...(dryRun ? ['--dry-run'] : [])];
     console.error(`${dryRun ? 'Dry-running' : 'Publishing'} ${packageJson.name}@${packageJson.version}${dryRun ? '' : ' to npm'}...`);
     await runNpm(publishArgs, env);
   } finally {
@@ -91,7 +127,9 @@ async function main() {
   }
 }
 
-main().catch(error => {
-  console.error(`publish:npm: ${error.message}`);
-  process.exitCode = 1;
-});
+if (process.argv[1] && realpathSync(fileURLToPath(import.meta.url)) === realpathSync(resolve(process.argv[1]))) {
+  main().catch(error => {
+    console.error(`publish:npm: ${error.message}`);
+    process.exitCode = 1;
+  });
+}

package/src/binary.mjs

@@ -15,7 +15,7 @@ const platformMap = {
   'linux:arm64': ['linux', 'arm64', ''],
   'darwin:x64': ['darwin', 'x64', ''],
   'darwin:arm64': ['darwin', 'arm64', ''],
-  'win32:x64': ['windows', 'x64', '.exe']
+  'win32:x64': ['win32', 'x64', '.exe']
 };
 
 export function binaryTarget(platform = process.platform, arch = process.arch) {
@@ -24,6 +24,12 @@ export function binaryTarget(platform = process.platform, arch = process.arch) {
   return { os: target[0], arch: target[1], extension: target[2], asset: `vsp-${target[0]}-${target[1]}${target[2]}` };
 }
 
+// Every VSP asset the npm tarball must bundle; publish:npm refuses to ship a
+// package whose dist/checksums.txt does not list all of them.
+export function packagedBinaryAssets() {
+  return Object.keys(platformMap).map(key => binaryTarget(...key.split(':')).asset);
+}
+
 export function bundledBinaryPath(platform = process.platform, arch = process.arch) {
   return join(packageRoot, 'dist', binaryTarget(platform, arch).asset);
 }

package/tools.md

@@ -1,6 +1,6 @@
 # Curated VSP tools exposed through the BAS proxy
 
-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 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 61 tools when all curated VSP capabilities are registered).
 
 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.
 
@@ -51,6 +51,7 @@ Hidden upstream VSP tools are not directly callable through the proxy. Local wor
 - `GrepPackages`
 - `ListDependencies`
 - `ListTransports`
+- `LockObject`
 - `PrettyPrint`
 - `RunATCCheck`
 - `RunQuery`
@@ -58,6 +59,7 @@ Hidden upstream VSP tools are not directly callable through the proxy. Local wor
 - `SearchObject`
 - `SetBreakpoint`
 - `SyntaxCheck`
+- `UnlockObject`
 - `WriteSource`
 
 ## Hidden from direct proxy calls