sap-ai-dev-toolkit 0.3.1 → 0.3.3

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

@@ -8,19 +8,21 @@ 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.
 
 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. **Inspect and select tools once per MCP server.** Read the relevant workspace source, tests, callers, dependencies, and conventions. Query the active MCP server's live `tools/list` 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 returned. Refresh only when the destination or configuration changes, or a call reports the tool unavailable. Prefer:
+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, activates in, or publishes to the SAP system.
+3. **Inspect and select tools once per MCP server.** Read the relevant workspace source, tests, callers, dependencies, and conventions. Query the active MCP server's live `tools/list` 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 returned. 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; then `SyntaxCheck`, `RunUnitTests`, and `RunATCCheck` when relevant. Show and review the staged diffs before applying. Use `Activate` or `ActivateMultiple` only when activation was requested.
+   - **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`, and `GetObjectStructure` for model/impact inspection; `RunQuery` or `GetTableContents` for read-only CDS/table runtime validation. Use `PublishServiceBinding` only when publication was requested.
    - **Runtime diagnosis:** `ListDumps` and `GetDump`; add `GetApplicationLog` or `GetTrace` when relevant. For an authorized reproduction, use `DebuggerListen`, `DebuggerGetStack`, `DebuggerGetVariables`, and `DebuggerStep`, then `DebuggerDetach`.
    - **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.
 
-3. **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.
-4. **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.
-5. **Validate and activate the changed code.** Call the live destination-prefixed `LintABAP` MCP tool with abapGit-style filenames and caller-supplied source for every required dependency. `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.
-6. **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, publication, transport creation, and test-data creation as state-changing; proceed only when they are part of the authorized development task or explicitly approved. Never claim transport release or deletion support: this addon filters `ReleaseTransport` and `DeleteTransport`.
-7. **Report observed outcomes.** Finish with changed objects, activation or publication state, exact runtime validation performed with data source (real/test/synthetic), 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.
+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.
+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.
+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, publication, transport creation, and test-data creation as state-changing; proceed only when they are part of the authorized development task or explicitly approved. Never claim transport release or deletion support: this addon filters `ReleaseTransport` and `DeleteTransport`.
+9. **Report observed outcomes.** Finish with changed objects, activation or publication state, 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.
 
 Use the focused skills under `.github/skills/` when relevant: ABAP implementation and quality, RAP, CDS, debugging, or transport preparation. Their task-specific guidance supplements this workflow.

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

@@ -8,20 +8,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.
 
 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. **Inspect live MCP tools once per server.** Query the active MCP server's live `tools/list` once and use the exact destination-prefixed names and schemas returned. Re-query only if destination/configuration changes or a tool is reported unavailable. Prefer this RAP tool map when present:
+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.** Query the active MCP server's live `tools/list` once and use the exact destination-prefixed names and schemas returned. Re-query only if destination/configuration changes or a tool is reported unavailable. Prefer this RAP tool map when present:
    - **Capability/system inspection:** `GetSystemInfo`, `GetFeatures`, `GetConnectionInfo`.
    - **Search/source inspection:** `SearchObject`, `GrepObjects`, `GrepPackages`, `GrepObject`, `GrepPackage`, `GetSource`, `GetContext`, `FindDefinition`, `FindReferences`.
    - **RAP/CDS model inspection:** `GetObjectStructure`, `GetCDSDependencies`, `GetCDSImpactAnalysis`, `GetCDSElementInfo`, `GetClass`, `GetClassComponents`, `GetClassInclude`, `GetInterface`, `GetTypeInfo`, `GetTypeHierarchy`.
-   - **Implementation:** `EditSource`, `WriteSource`, `UpdateSource`, `UpdateClassInclude`, `WriteClass`, `CreateObject`, `CreateClassWithTests`, `CreateTestInclude`, `RecoverFailedCreate`.
+   - **Implementation:** `EditSource`, `WriteSource`, `UpdateSource`, `UpdateClassInclude`, `WriteClass`, `CreateObject`, `CreateClassWithTests`, `CreateTestInclude`, `RecoverFailedCreate` to send locally authored, locally linted sources to SAP.
    - **Validation:** `LintABAP`, `SyntaxCheck`, `RunUnitTests`, `RunATCCheck`, `GetCodeCoverage`, `AnalyzeABAPCode`, `RunQuery`, `GetTableContents`, `ExecuteABAP`, `CallRFC` when safely applicable.
    - **Activation/service operations:** `Activate`, `ActivateMultiple`, `PublishServiceBinding`, `UnpublishServiceBinding` only when explicitly authorized by the task.
    - **Runtime diagnosis:** `ListDumps`, `GetDump`, `GetApplicationLog`, `GetTrace`, `GetSQLTraceState`, `AnalyzeCallGraph`, `GetCallGraph`, `GetCallersOf`, `GetCalleesOf`.
    Tool modes and target systems vary; never infer availability from this static list.
-3. **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.
-4. **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.
-5. **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. Use dumps/logs/traces if runtime behavior differs from expectation.
-6. **Validate, activate, and publish only when authorized.** Run `LintABAP` with caller-supplied source for relevant ABAP dependencies, plus `SyntaxCheck`, `RunUnitTests`, `RunATCCheck`, LSP diagnostics, and coverage when available and relevant. Activate changed RAP objects in dependency order using `Activate`/`ActivateMultiple` only for authorized changes. Publish or unpublish service bindings only when requested.
-7. **Protect SAP state.** Do not create/change SAP objects, activate, publish, unpublish, create transports, or create test data unless the task authorizes that state change and target details are known. Never claim transport release or deletion support; this addon filters `ReleaseTransport` and `DeleteTransport`.
-8. **Report observed evidence.** Finish with changed RAP objects, activation/publication state, exact runtime validation performed, data source used, and actual lint/syntax/unit/ATC/LSP/coverage results. List every skipped check and blocker with the reason.
+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.
+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. Use dumps/logs/traces if runtime behavior differs from expectation.
+8. **Validate, activate, and publish 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`, LSP diagnostics, and coverage when available and relevant. Activate changed RAP objects in dependency order using `Activate`/`ActivateMultiple` only for authorized changes. Publish or unpublish service bindings only when requested.
+9. **Protect SAP state.** Do not create/change SAP objects, activate, publish, unpublish, create transports, or create test data unless the task authorizes that state change and target details are known. Never claim transport release or deletion support; this addon filters `ReleaseTransport` and `DeleteTransport`.
+10. **Report observed evidence.** Finish with changed RAP objects, activation/publication state, exact runtime validation performed, data source used, local lint and LSP results before the SAP transfer, and actual lint/syntax/unit/ATC/LSP/coverage results. List every skipped check and blocker with the reason.
 
 Use the focused skills under `.github/skills/` when relevant, especially `rap-development` and `rap-service-delivery`. Their task-specific guidance supplements this workflow.

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

@@ -20,12 +20,12 @@ 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. 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: 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. 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.
    - **ABAP Runtime Debugger** for dumps, logs, traces, reproductions, performance symptoms, and runtime root cause analysis.
-   Each brief must include destination, scope, objects, acceptance criteria, state-changing permissions, required validations, and Clean Core constraints.
+   Each brief must include destination, scope, objects, acceptance criteria, state-changing permissions, required validations, and Clean Core constraints, and must mandate a planning step before implementation plus local-first authoring: create and lint sources locally (`LintABAP`, LSP) before sending anything to the SAP system.
 8. **Report decision and SDLC evidence.** Finish with the chosen approach, recommended APIs/extension points, why SAP standard/released APIs were or were not sufficient, Clean Core and side-by-side compliance status, required implementation packages, actual MCP evidence gathered, validation gates passed/skipped, release readiness, and open questions/blockers. Report every check not run and why.
 
 Use the focused skills under `.github/skills/`, especially `sap-standard-api-analysis`, `clean-core-extensibility`, and `sap-sdlc-orchestration`. Their task-specific guidance supplements this workflow.

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

@@ -10,8 +10,10 @@ description: Implement or change ABAP programs, classes, interfaces, function gr
 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.
 
 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. 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.
-3. Make the smallest implementation that meets that behavior. Use 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.
+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.
-4. 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.
-5. Run the regression tests after implementation and validate relevant callers and dependencies with lint, syntax, ATC, and LSP checks when available. 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.
+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.

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

@@ -10,7 +10,9 @@ description: Develop SAP RAP business objects, behavior, projections, and OData
 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`, `GetObjectStructure`, `GetCDSDependencies`, `GetCDSImpactAnalysis`, and `GetCDSElementInfo`. Edit with `EditSource` / `WriteSource`; validate with `SyntaxCheck`, `RunUnitTests`, and `RunATCCheck` when exposed. Activate with `Activate` / `ActivateMultiple` only when requested. Use `PublishServiceBinding` only when publication was requested and authorized.
 
 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. 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.
-3. Self-validate RAP behavior end-to-end. 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.
-4. Activate authorized RAP object changes in dependency order. Publish a service only when the user requested and authorized publication. Validate the service end-to-end using the live tools available for that system; report actual activation, publication, and runtime state.
-5. 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.
+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. Publish a service only when the user requested and authorized publication. Validate the service end-to-end using the live tools available for that system; report actual activation, publication, 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

@@ -10,11 +10,13 @@ description: Validate and deliver SAP RAP OData services, behavior implementatio
 Query the active MCP server's live `tools/list` once and use exact destination-prefixed names and schemas. Prefer these tools when available: `GetSystemInfo`, `GetFeatures`, `GetConnectionInfo`, `SearchObject`, `GrepObjects`, `GrepPackages`, `GetSource`, `GetObjectStructure`, `GetCDSDependencies`, `GetCDSImpactAnalysis`, `GetCDSElementInfo`, `EditSource`, `WriteSource`, `UpdateSource`, `UpdateClassInclude`, `CreateClassWithTests`, `CreateTestInclude`, `LintABAP`, `SyntaxCheck`, `RunUnitTests`, `RunATCCheck`, `GetCodeCoverage`, `RunQuery`, `GetTableContents`, `ExecuteABAP`, `GenerateRAPRegressionSuite`, `RunRAPRegressionSuite`, `ListDumps`, `GetDump`, `GetApplicationLog`, `GetTrace`, `Activate`, `ActivateMultiple`, and `PublishServiceBinding`. Use `UnpublishServiceBinding` only when explicitly requested.
 
 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. 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.
-3. 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.
-4. Validate runtime service behavior end-to-end. 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.
+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 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.
+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.
-5. Activate in dependency order only when authorized: lower CDS/model dependencies first, then behavior artifacts, projections, service definition, and service binding. Publish only when explicitly requested.
-6. If runtime validation fails, inspect dumps/logs/traces with `ListDumps`, `GetDump`, `GetApplicationLog`, and `GetTrace` before guessing. Report exact evidence, not inferred success.
+7. Activate in dependency order only when authorized: lower CDS/model dependencies first, then behavior artifacts, projections, service definition, and service binding. Publish only when explicitly requested.
+8. If runtime validation fails, inspect dumps/logs/traces with `ListDumps`, `GetDump`, `GetApplicationLog`, and `GetTrace` 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

@@ -10,7 +10,8 @@ description: Orchestrate the SAP delivery lifecycle from requirement analysis th
 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`, `SearchObject`, `GrepObjects`, `GrepPackages`, `GetSource`, `GetContext`, `FindDefinition`, `FindReferences`, and dependency tools. Validate with `LintABAP`, `SyntaxCheck`, `RunUnitTests`, `RunATCCheck`, runtime queries, dumps/logs/traces, and service validation tools when exposed. Use transport tools for readiness planning only; never claim transport release or deletion support because this addon filters `ReleaseTransport` and `DeleteTransport`.
 
 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. 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.
-3. 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.
-4. 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.
-5. Finish with an SDLC status report: requirement decision, selected APIs/extension pattern, implementation packages and owners/agents, validation evidence, deployment/transport readiness, risks, open items, and the next safe action.
+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.
+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.
+6. Finish with an SDLC status report: requirement decision, selected APIs/extension pattern, implementation packages and owners/agents, validation evidence, deployment/transport readiness, risks, open items, and the next safe action.

package/README.md

@@ -298,11 +298,12 @@ The package includes four user-invocable custom agents (**SAP Solution Architect
 
 1. **Start with architecture when requirements are open-ended.** Use **SAP Solution Architect** to investigate the SAP system, evaluate SAP standard solutions, recommend released APIs, apply Clean Core and side-by-side extensibility, create the solution design, and orchestrate the SDLC through implementation work packages and validation gates.
 2. **Understand the request.** Establish the expected behavior and, for SAP changes, the destination, package, and transport or temporary target. Ask only when a material detail is missing.
-3. **Inspect before editing.** Read relevant source, tests, callers, dependencies, standard APIs, release state, and conventions; query the active MCP server's live `tools/list` and use its exact destination-prefixed tools and schemas.
-4. **Implement with behavior in mind.** Add or refine an ABAP Unit assertion first when an executable regression test is available, then make the smallest change that meets the request.
-5. **Verify with available checks.** Use `LintABAP` for caller-supplied source, BAS editor LSP diagnostics when configured, and SAP `SyntaxCheck`, `RunUnitTests`, and `RunATCCheck` when exposed and relevant. Lint and syntax checks do not replace behavior tests.
-6. **Protect SAP state.** Only make requested changes. Activate objects or publish services only when asked; create transports only when explicitly authorized. Release and deletion of transports are unavailable through this add-on.
-7. **Report observed results.** Summarize architecture decisions, changed objects, implementation handoff or actual validation, activation, and publication outcomes. Identify skipped checks and exact blockers; never claim a check passed if it did not run.
+3. **Plan before implementing.** Every implementation task starts with a presented plan: objects to change, ABAP Unit test approach, local authoring/validation, and the SAP write/activation steps it requires. The agents proceed while work stays read-only or workspace-local and wait for explicit approval before any plan that writes to, activates in, or publishes to the SAP system.
+4. **Inspect before editing.** Read relevant source, tests, callers, dependencies, standard APIs, release state, and conventions; query the active MCP server's live `tools/list` and use its exact destination-prefixed tools and schemas.
+5. **Implement with behavior in mind, locally first.** Add or refine an ABAP Unit assertion first when an executable regression test is available, then make the smallest change that meets the request. Sources are authored locally as abapGit-serialized workspace files (`object.type.extension`), and checked and linted there before they are sent to SAP.
+6. **Check and lint before sending to SAP.** Run the local `LintABAP` tool on the caller-supplied files plus required dependencies and consume BAS editor LSP diagnostics when configured; fix findings locally and re-lint. Only then transfer the sources to SAP and use the remote `SyntaxCheck`, `RunUnitTests`, and `RunATCCheck` when exposed and relevant. Lint and syntax checks do not replace behavior tests.
+7. **Protect SAP state.** Only make requested changes. Activate objects or publish services only when asked; create transports only when explicitly authorized. Release and deletion of transports are unavailable through this add-on.
+8. **Report observed results.** Summarize architecture decisions, changed objects, implementation handoff or actual validation, activation, and publication outcomes. Identify skipped checks and exact blockers; never claim a check passed if it did not run.
 
 ### 🧩 Included Agent Skills
 
@@ -697,6 +698,19 @@ The response contains a `tools` array. A `RunQuery` entry resembles this excerpt
 | `SAP_AI_DEV_TOOLKIT_DESTINATION` | Comma-separated destination allowlist for normal runtime discovery. Setup clears this temporarily so it can display all eligible systems. |
 | `SAP_AI_DEV_TOOLKIT_MODE` | VSP child mode (`expert` by default; `focused` omits `ActivateMultiple`, `GetUserTransports`, and `GetTransportInfo`). The proxy exposes its curated tools plus tools listed in `tools.md` when registered by that mode, including local `LintABAP`. |
 | `SAP_ALLOW_TRANSPORTABLE_EDITS` | Generated MCP entries set this to `true` to permit source edits in transportable packages; VSP safety checks and SAP authorizations still apply. |
+| `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 (falls back to `HTTP_PROXY`/`http_proxy`; unset means the default BAS proxy for `.dest` hosts, empty means direct). |
+| `SAP_AI_DEV_TOOLKIT_MAX_CSRF_RETRIES` | Bounded CSRF/session self-healing retries per unsafe request (default 3). |
+
+#### Self-healing modes
+
+The relay between the VSP child and each BAS destination recovers from the failure modes that break ADT writes over `.dest` proxies:
+
+1. **CSRF session pairing** — every token is stored together with the `Set-Cookie` state SAP returned alongside it, and both are replayed on POST/PUT/PATCH/DELETE. This fixes `403 CSRF token validation failed` caused by token/session separation.
+2. **Session refresh** — when SAP rejects or rotates a session (401/403 after a token was already accepted), the cached session is dropped, a fresh token+cookie pair is fetched, and the request retried, bounded by the retry limit.
+3. **Proxy tunnel fallback** — when the BAS proxy refuses absolute-form requests (502/504 or transport errors), the relay switches to a CONNECT tunnel through the same proxy and keeps going.
+4. **Child crash recovery** — a crashed VSP child is restarted transparently, re-initialized, tools re-registered, and the interrupted `tools/call` retried once before any error reaches the client.
+5. **Direct connect for Internet destinations** — the BAS `.dest` proxy strips SAP `Set-Cookie` headers, which makes CSRF token/session binding impossible for ADT writes (`403 CSRF token validation failed`). When you select an Internet destination with basic authentication, setup prompts for a SAP user and password and stores them in `sap-ai-dev-toolkit-credentials.json` **next to** `mcp.json` (never inside it, permissions `0600`). The relay then connects straight to the backend host with Basic auth — cookies survive, CSRF pairing works, and writes behave like they do from Eclipse/ADT. Rerun `sap-ai-dev --setup` to change or clear stored credentials; re-selecting nothing removes stale entries.
 | `SAP_AI_DEV_MCP_CONFIG` | Explicit MCP user configuration path. |
 | `BAS_VSP_MCP_CONFIG` | Backward-compatible alias for the MCP user configuration path. |
 | `BAS_VSP_BINARY` | Trusted prebuilt VSP executable; skips Go and binary provisioning. |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "sap-ai-dev-toolkit",
-  "version": "0.3.1",
+  "version": "0.3.3",
   "description": "SAP AI development toolkit for BAS, ABAP, RAP, CAP, Fiori, UI5, and MCP",
   "author": "Gurkan Yilmaz",
   "type": "module",
@@ -17,6 +17,7 @@
   },
   "scripts": {
     "postinstall": "node scripts/postinstall.mjs",
+    "install:local": "node scripts/install-local.mjs",
     "test": "node --test test/*.test.mjs",
     "test:visibility": "node --test test/setup.test.mjs test/terminal-ui.test.mjs",
     "test:mutation": "node scripts/mutation-terminal-ui.mjs",

package/scripts/install-local.mjs

@@ -0,0 +1,115 @@
+import { spawn } from 'node:child_process';
+import { lstat } from 'node:fs/promises';
+import { readFile } from 'node:fs/promises';
+import { dirname, join, resolve as resolvePath } from 'node:path';
+import { fileURLToPath } from 'node:url';
+
+const root = dirname(dirname(fileURLToPath(import.meta.url)));
+const args = new Set(process.argv.slice(2));
+const allowedArgs = new Set(['--link', '--verify']);
+
+function usage() {
+  return [
+    'Usage: npm run install:local [-- --link] [--verify]',
+    '',
+    '  (default)  Packs the workspace and installs the tarball globally, then',
+    '             runs the normal postinstall wizard (binary provisioning,',
+    '             BAS destination setup, optional Copilot assets).',
+    '  --link     Installs with npm link instead of a tarball; edits to src/',
+    '             and scripts/ take effect immediately without reinstalling.',
+    '  --verify   Verifies the global sap-ai-dev command resolves to this',
+    '             workspace installation.'
+  ].join('\n');
+}
+
+function run(command, commandArgs, options = {}) {
+  return new Promise((resolve, reject) => {
+    const child = spawn(process.platform === 'win32' ? `${command}.cmd` : command, commandArgs, {
+      cwd: root,
+      env: process.env,
+      stdio: 'inherit',
+      ...(process.platform === 'win32' ? { shell: true } : {}),
+      ...options
+    });
+    child.once('error', reject);
+    child.once('close', (code, signal) => {
+      if (code === 0) resolve();
+      else reject(new Error(signal ? `${command} terminated by ${signal}` : `${command} exited with status ${code}`));
+    });
+  });
+}
+
+async function resolveGlobalBinaryPath() {
+  return new Promise((resolve, reject) => {
+    const child = spawn(process.platform === 'win32' ? 'npm.cmd' : 'npm', ['prefix', '-g'], {
+      cwd: root,
+      env: process.env,
+      ...(process.platform === 'win32' ? { shell: true } : {})
+    });
+    let stdout = '';
+    child.stdout.setEncoding('utf8');
+    child.stdout.on('data', chunk => { stdout += chunk; });
+    child.once('error', reject);
+    child.once('close', code => {
+      if (code === 0) resolve(stdout.trim());
+      else reject(new Error(`npm prefix -g exited with status ${code}`));
+    });
+  });
+}
+
+async function verify() {
+  const pkg = JSON.parse(await readFile(join(root, 'package.json'), 'utf8'));
+  const prefix = await resolveGlobalBinaryPath();
+  const expected = resolvePath(prefix, 'lib', 'node_modules', pkg.name);
+  const installedRoot = await new Promise((resolve, reject) => {
+    const child = spawn(process.platform === 'win32' ? 'npm.cmd' : 'npm', ['list', '-g', pkg.name, '--parseable'], {
+      cwd: root,
+      env: process.env,
+      ...(process.platform === 'win32' ? { shell: true } : {})
+    });
+    let stdout = '';
+    child.stdout.setEncoding('utf8');
+    child.stdout.on('data', chunk => { stdout += chunk; });
+    child.once('error', reject);
+    child.once('close', code => resolve(code === 0 ? stdout.trim().split('\n').filter(Boolean).pop() : null));
+  });
+  console.log(`Global prefix:      ${prefix}`);
+  console.log(`Installed location: ${installedRoot || '(not installed)'}`);
+  console.log(`Workspace root:     ${root}`);
+  if (!installedRoot) throw new Error(`${pkg.name} is not installed globally`);
+  if (installedRoot !== expected) {
+    console.log(`Expected location:  ${expected}`);
+    throw new Error('Global installation does not match the expected npm layout');
+  }
+  const stats = await lstat(installedRoot).catch(() => null);
+  console.log(`Install mode:       ${stats?.isSymbolicLink() ? 'npm link (live workspace)' : 'tarball (snapshot)'}`);
+  return 0;
+}
+
+async function main() {
+  for (const argument of args) {
+    if (!allowedArgs.has(argument)) throw new Error(`Unknown option: ${argument}\n\n${usage()}`);
+  }
+  if (args.has('--verify')) return verify();
+
+  const pkg = JSON.parse(await readFile(join(root, 'package.json'), 'utf8'));
+  if (args.has('--link')) {
+    console.error(`install:local: linking ${pkg.name}@${pkg.version} from this workspace...`);
+    await run('npm', ['link']);
+    console.error('install:local: npm link complete; src/ and scripts/ edits apply immediately');
+    return verify();
+  }
+
+  const tarball = `${pkg.name}-${pkg.version}.tgz`;
+  console.error(`install:local: packing ${pkg.name}@${pkg.version}...`);
+  await run('npm', ['pack', '--quiet']);
+  console.error(`install:local: installing ${tarball} globally...`);
+  await run('npm', ['install', '--global', join(root, tarball)]);
+  console.error('install:local: installation complete');
+  await verify();
+}
+
+main().catch(error => {
+  console.error(`install:local: ${error.message}`);
+  process.exitCode = 1;
+});