ABAP-AI-CODE-TOOLS

ABAP AI Code — write tools

Optional write / code-mutation add-on for ABAP AI Code.

The base platform is deliberately read-only: it can read, explain and review ABAP code, but it cannot change a single line. This package is what turns it into an assistant that creates, modifies and deletes ABAP repository objects — and it is a separate abapGit repository precisely so that granting that power is an explicit, per-system decision.

Start with the base repository: https://github.com/ysichov/ABAP-AI-Code Installation, provider setup, API-key encryption, the UI and the tool-plugin pattern are all documented there. This README only covers what the add-on adds.

Table of contents

• 1. Why it is a separate package
• 2. What you get
• 3. How it plugs in — the plugin pattern
• 4. Installation
  • 4.1 Install order
  • 4.2 Companion prompt files
• 5. Contents
• 6. The write flow, end to end
• 7. Safety rails
• 8. Removing write access again
• 9. Known gaps
• 10. Links and license

1. Why it is a separate package

"AI can read my code" and "AI can rewrite my code" are two very different conversations with a security officer. Splitting them into two repositories means the answer can be different per system:

The split is not just packaging. Because the base has no compile-time dependency on this package, a system without it is not a system with a disabled feature — it is a system where the capability does not exist. The LLM is never told about create_sap_object, modify_sap_object or delete_sap_object, so it never proposes them and never fails trying.

2. What you get

• Create a new program or class from a natural-language requirement.
• Modify an existing object: add a method, change a signature, refactor a block, remove a FORM, strip header comments — anything that leaves the object in place.
• Delete a whole program or class, with a mandatory confirmation.
• All of it through standard SAP APIs, with a syntax check before saving, a normal transport entry (RS_CORR_INSERT) and activation (RS_WORKING_OBJECTS_ACTIVATE) — the same path a human developer's change takes.
• All of it behind the base platform's per-hunk diff review: nothing is written until you approve it.

3. How it plugs in — the plugin pattern

Every tool in ABAP AI Code is a three-layer plugin, and this package simply ships three more of them:

Layer 1  <tool_name>.json   OpenAI function definition — the contract the LLM sees
Layer 2  <tool_name>.md     prompt fragment — behaviour rules for that tool
Layer 3  ZCL_AITOOL_<X>     ABAP class (ZIF_AI_TOOL via ZCL_AITOOL_BASE) — does the work

ZCL_AI_TOOL_FACTORY in the base discovers implementers at runtime through SEOMETAREL, and builds both the tools JSON array and the tool section of the system prompt from the same registry. Consequences:

• Installing this package is all it takes. No core class is modified, no CASE branch is extended, no prompt in the base is edited.
• Uninstalling it removes the capability from the toolset and from the prompt in one step.
• The runner and the code UI call the saver only by dynamic name (CALL METHOD ('ZCL_CODE_OBJECT_SAVER')=>…), so the base compiles and runs perfectly without this repository; write paths simply report "read-only platform".

Full description of the pattern, including how to write your own tool: base README §3 and §8.

4. Installation

4.1 Install order

abapGit does not resolve dependencies, so the order matters:

1. ABAP-AI-Code — the read-only base (core, engine, UI, read/review tools). Required. Pull and activate first.
2. ABAP-AI-CODE-TOOLS — this repository, into a second Z package.

Installing this package first will not activate: its classes inherit from ZCL_AITOOL_BASE and call ZCL_AI_CODE_READER, both of which live in the base.

4.2 Companion prompt files

Each tool needs its <tool_name>.json (schema) and <tool_name>.md (prompt fragment) copied into the same frontend folder the base already uses (p_tools on the Z_ABAP_AI_CODE2 selection screen):

Registration is fail-closed: if either companion file is missing, the factory refuses to register the tool and issues a message naming the missing file. A forgotten copy shows up as an explicit warning, never as a tool that silently misbehaves.

modify_user_template.md and delete_misuse_redirect.md are read by the modify tool and by the runner directly (not by the factory), so they are not covered by that guard — copy them too.

5. Contents

6. The write flow, end to end

Taking "add a method CALCULATE to ZCL_MATH" as the example:

1. The orchestrator picks modify_sap_object (the base prompt forces a read_sap_object first, and forbids delete_sap_object for partial changes).
2. ZCL_AITOOL_MODIFY reads the current class source.
3. A focused sub-agent LLM call returns a <code_modified> envelope with only the changed section and method blocks.
4. Those blocks are merged into the full current source. Both versions — original_source and final_source — go back to the runner.
5. The runner shows a diff in the right pane. Each hunk has approve / decline, a note field, and an AI thread for arguing about that specific hunk.
6. On approval, ZCL_CODE_OBJECT_SAVER runs a syntax check, writes through the SAP APIs, records the transport entry and activates.
7. Everything above — every LLM call, every tool call, the diff, the save result — lands in the session log folder.

create_sap_object follows the same path minus the read and merge; delete_sap_object skips the LLM entirely and goes straight to confirmation.

7. Safety rails

• Nothing writes without approval. save_required only requests the review; the runner owns confirmation and saving. A tool cannot bypass it.
• Delete is narrow by design. Only CLAS and PROG are accepted, and only for a whole object. A request to remove something inside an object (a FORM, a method, comments, lines) is redirected to modify_sap_object through delete_misuse_redirect.md — the base prompt states this rule three separate ways because it is the single most damaging thing an LLM could get wrong here.
• Syntax check before save. A source that does not compile is rejected before it reaches the repository.
• Normal transport and activation. Changes are visible to SE03, to your colleagues and to your release process like any other change — no side channel.
• Merge, not overwrite. modify_sap_object merges changed blocks into the current source read moments earlier, rather than letting the LLM re-emit a whole object from memory.

8. Removing write access again

Delete the package (or just this repository's objects) via abapGit. The base keeps working unchanged: the dynamic saver calls fail gracefully, and the three write tools disappear from both the LLM toolset and the system prompt on the next run. Optionally remove the create_* / modify_* / delete_* files from the frontend prompt folder as well — with the classes gone they are inert either way.

9. Known gaps

• delete_sap_object.md is not shipped. The schema (delete_sap_object.json) exists in the base repository's TOOLS folder, but the prompt fragment does not. Under the fail-closed rule, ZCL_AITOOL_DELETE therefore refuses to register until that file is created. Add it (or accept that delete is unavailable — an acceptable default for many systems).
• Supported object types are PROG and CLAS. Function groups, DDIC objects, CDS and BDEF are not handled by the saver.

10. Links and license

• Base platform (required): https://github.com/ysichov/ABAP-AI-Code
• Plugin pattern and how to add your own tool: base README §8
• Architecture design doc: FABLE_NEW_ARCHITECTURE.md
• License: MIT