Formatting and model updates

Author: wommel0

README.md

@@ -1,4 +1,21 @@
-# llm_coder
-LLM Coder package
+# ABAP AI LLM Coder
 
-Still trying out stuff.
+**Status**: Early preview, expect major changes (already planned). Focus is to show the [Documentation Showcase](https://abap-ai.github.io/llm_coder/).
+
+This repository will in future contain coder support related topics. Note you need the llm client and llm agent package to run this.
+
+## Showcase - Generated ABAP Documentation
+
+[Documentation Showcase](https://abap-ai.github.io/llm_coder/):
+
+* Generated documentation of the llm_client repo
+* Differnet models used to show differences
+* Focus on a simple overview and to give you an idea what to do with the llm client and agent
+* Simple, not yet optimized prompts.
+
+Early Learnings:
+
+* Promising - high level overview usually enough. While it would be possible to generate very detailed documentations this is usually not required. ABAP developers are used to look at code and have easy access --> focus on giving a high level overview only.
+* Agents are the preferred interface. Using the client directly is only relevant for special cases --> Plan is to merge the client and agent package.
+* Agents should have some default retry- and error correction logic to catch simple and common fails.
+* There are many simple markdown issues - not a big deal but the tool used to display the documentation takes this serious --> consider some automated corrections or do it later on github

docs/Claude 3.5 Haiku/FUGR/Z_LLM_CLIENT/TABLEFRAME_Z_LLM_CLIENT.md

@@ -8,10 +8,13 @@ parent_type: FUGR
 # Function Module TABLEFRAME_Z_LLM_CLIENT
 
 AI Generated documentation.
+
 ## Overview
+
 The function module `TABLEFRAME_Z_LLM_CLIENT` is a standard SAP view maintenance generator function designed to handle table frame operations for a custom client-related table. It appears to be an automatically generated function module used for managing view maintenance activities in an SAP ABAP system.
 
 ## Dependencies
+
 - Standard SAP View Maintenance Framework
 - Performs operations on predefined tables:
   - `X_HEADER`
@@ -21,6 +24,7 @@ The function module `TABLEFRAME_Z_LLM_CLIENT` is a standard SAP view maintenance
   - `EXCL_CUA_FUNCT`
 
 ## Details
+
 The function module utilizes the `PERFORM TABLEFRAME` statement, which is a standard SAP mechanism for view maintenance. It passes several key parameters:
 
 ```mermaid
@@ -37,10 +41,10 @@ graph TD
 ```
 
 Key characteristics:
+
 - Automatically generated on 02.01.2025
 - Part of view maintenance generator version #001407#
 - Handles table frame operations for a custom table related to LLM (likely Large Language Model) client configuration
 - Provides a standardized interface for view-based table maintenance in SAP
 
 The function is designed to be a generic handler for view-related operations, likely supporting standard CRUD (Create, Read, Update, Delete) actions on the associated table.
-

docs/Claude 3.5 Haiku/FUGR/Z_LLM_CLIENT/TABLEPROC_Z_LLM_CLIENT.md

@@ -8,14 +8,19 @@ parent_type: FUGR
 # Function Module TABLEPROC_Z_LLM_CLIENT
 
 AI Generated documentation.
+
 ## Overview
+
 The function module `TABLEPROC_Z_LLM_CLIENT` appears to be a generic table processing function generated on 02.01.2025. Its primary purpose seems to be executing a standard table procedure through the `TABLEPROC` perform, which suggests it is likely part of a generated view maintenance or table management framework.
 
 ## Dependencies
+
 No explicit dependencies are visible from the provided source code snippet. The function relies on a perform routine `TABLEPROC`, which is likely defined in a common include or standard SAP library.
 
 ## Details
+
 The function module is extremely minimal, containing only a single perform call to `TABLEPROC`. This suggests it is:
+
 - Likely part of an automated code generation process
 - Probably a wrapper or standardized entry point for table-related operations
 - Potentially used in view maintenance or data management scenarios for a client-related table (Z_LLM_CLIENT)
@@ -29,4 +34,3 @@ flowchart TD
 ```
 
 Without additional context from the common includes, the exact nature of the table processing cannot be definitively determined, but it appears to be a standardized approach to handling table-related operations.
-

docs/Claude 3.5 Haiku/ZCL_LLM_AUTH_DISABLED_CLAS.md

@@ -8,10 +8,13 @@ parent_type: DEVC
 # Class ZCL_LLM_AUTH_DISABLED
 
 AI Generated documentation.
+
 ## Overview
+
 The `zcl_llm_auth_disabled` class is an implementation of the `zif_llm_auth` interface that provides a permissive authorization mechanism. This class is designed to disable or bypass authorization checks for various cryptographic and client-related operations. It serves as a default or test implementation where no strict authorization restrictions are enforced.
 
 The class implements four key authorization methods:
+
 1. `check_decrypt()`: Authorization check for decryption operations
 2. `check_encrypt()`: Authorization check for encryption operations
 3. `check_get_client()`: Authorization check for client retrieval
@@ -20,11 +23,14 @@ The class implements four key authorization methods:
 Each method is intentionally left empty, effectively allowing all operations without raising authorization exceptions.
 
 ## Dependencies
+
 - Interface: `zif_llm_auth`
 - Potential Exception: `ZCX_LLM_AUTHORIZATION` (not raised in this implementation)
 
 ## Details
+
 The class represents a "disabled" authorization strategy, which is particularly useful in:
+
 - Testing scenarios
 - Development environments
 - Situations requiring unrestricted access to cryptographic methods
@@ -44,10 +50,10 @@ graph TD
 ```
 
 Key characteristics:
+
 - Provides a "pass-through" authorization mechanism
 - Marked as `FINAL` and `PUBLIC`, preventing further inheritance
 - Uses `#EC EMPTY_PROCEDURE` to suppress potential code inspector warnings about empty methods
 - Intended to be registered in a BADI (Business Add-In) named `ZLLM_DEFAULTS`
 
 The implementation suggests a flexible design where custom authorization logic can be easily plugged in by replacing this default implementation.
-

docs/Claude 3.5 Haiku/ZCL_LLM_CALL_LOGGER_CLAS.md

@@ -8,25 +8,31 @@ parent_type: DEVC
 # Class ZCL_LLM_CALL_LOGGER
 
 AI Generated documentation.
+
 ## Overview
+
 The `zcl_llm_call_logger` is a specialized ABAP class designed to log LLM (Large Language Model) call entries with configurable logging behavior. It implements the `zif_llm_call_logger` interface and provides a mechanism to conditionally log entries based on system settings and user filters.
 
 Key functionalities:
+
 - Conditional logging of LLM call entries
 - System-wide logging activation control
 - User-specific logging filter
 - Automatic configuration during object instantiation
 
 Public Methods:
+
 - `zif_llm_call_logger~add()`: Logs an entry to the `zllm_call_log` table if logging is active
 - `constructor()`: Initializes logging configuration by checking system settings
 
 ## Dependencies
+
 - Database Table: `zllm_system` (for system configuration)
 - Database Table: `zllm_call_log` (for storing log entries)
 - Interface: `zif_llm_call_logger`
 
 ## Details
+
 The logging mechanism follows a two-stage filtering process:
 
 ```mermaid
@@ -39,6 +45,7 @@ flowchart TD
 ```
 
 Logging Configuration Logic:
+
 1. During object creation, the constructor queries the `zllm_system` table
 2. Checks if system-wide logging is enabled (`save_calls = abap_true`)
 3. Validates user filter:
@@ -47,9 +54,9 @@ Logging Configuration Logic:
 4. Sets the `active` flag accordingly
 
 When `zif_llm_call_logger~add()` is called:
+
 - Checks the `active` flag
 - If active, inserts the entry into `zllm_call_log`
 - If inactive, silently returns without logging
 
 This design allows flexible, configurable logging with minimal performance overhead.
-

docs/Claude 3.5 Haiku/ZCL_LLM_CHAT_REQUEST_CLAS.md

@@ -8,15 +8,19 @@ parent_type: DEVC
 # Class ZCL_LLM_CHAT_REQUEST
 
 AI Generated documentation.
+
 ## Overview
+
 The `zcl_llm_chat_request` class is an implementation of the `zif_llm_chat_request` interface, designed to manage and manipulate chat requests for Large Language Model (LLM) interactions. It provides a comprehensive set of methods to:
+
 - Add and manage chat messages
 - Handle tools and tool results
 - Configure structured output
 - Manage tool choices
 - Retrieve internal request details
 
 Key public methods include:
+
 - `add_message`: Add a single message to the request
 - `add_messages`: Add multiple messages at once
 - `add_tool`: Add a tool to the request
@@ -28,11 +32,13 @@ Key public methods include:
 - `get_internal_request`: Retrieve the full internal request object
 
 ## Dependencies
+
 - `zif_llm_client`: Interface for role constants
 - `zcl_llm_common`: Utility class for JSON conversion
 - `zllm_request`: Custom data type for storing chat request details
 
 ## Details
+
 The class uses a central `request` attribute of type `zllm_request` to store and manage all request-related information. It acts as a builder/configuration class for preparing LLM chat requests with flexible options.
 
 ```mermaid
@@ -51,11 +57,11 @@ classDiagram
 ```
 
 Key design characteristics:
+
 - Implements a fluent interface for building chat requests
 - Supports dynamic addition of messages, tools, and tool results
 - Provides methods for configuring advanced LLM request features
 - Maintains a flexible internal request structure
 - Allows retrieval of the complete configured request object
 
 The class is designed to be used as a configuration builder before sending a request to an LLM client, providing a type-safe and structured approach to preparing chat interactions.
-

docs/Claude 3.5 Haiku/ZCL_LLM_CLIENT_BASE_CLAS.md

@@ -8,25 +8,31 @@ parent_type: DEVC
 # Class ZCL_LLM_CLIENT_BASE
 
 AI Generated documentation.
+
 ## Overview
+
 `zcl_llm_client_base` is an abstract base class for implementing Large Language Model (LLM) clients across different providers. It provides a standardized framework for:
+
 - Creating chat requests
 - Handling HTTP communication
 - Processing LLM responses
 - Managing tool calls and structured outputs
 
 Key public methods:
+
 - `chat()`: Sends a chat request to the LLM provider
 - `new_request()`: Creates a new chat request with default configurations
 - `get_client()`: Retrieves a provider-specific client implementation
 
 ## Dependencies
+
 - `zif_llm_client`: Main client interface
 - `zif_llm_http_client_wrapper`: HTTP communication wrapper
 - `zif_llm_tool_parser`: Tool parameter parsing
 - `zif_llm_statistics`: Statistics tracking
 
 ## Details
+
 The class implements a flexible and extensible architecture for LLM interactions with several key design aspects:
 
 ```mermaid
@@ -42,12 +48,14 @@ classDiagram
 ```
 
 Key architectural patterns:
+
 - Abstract methods for provider-specific implementations
 - Standardized response and request handling
 - Flexible tool call and structured output processing
 - Configurable via client and provider configurations
 
 Request processing flow:
+
 1. Create request via `new_request()`
 2. Configure request parameters
 3. Call `chat()` method
@@ -58,10 +66,10 @@ Request processing flow:
    - Tool call processing
 
 The class supports:
+
 - Multiple LLM providers
 - Structured output generation
 - Tool call execution
 - Detailed usage statistics tracking
 
 Extensibility is achieved through abstract methods like `get_chat_endpoint()`, `set_auth()`, allowing provider-specific implementations while maintaining a consistent interface.
-

docs/Claude 3.5 Haiku/ZCL_LLM_COMMON_CLAS.md

@@ -8,21 +8,27 @@ parent_type: DEVC
 # Class ZCL_LLM_COMMON
 
 AI Generated documentation.
+
 ## Overview
+
 The `zcl_llm_common` is a utility class designed to provide JSON serialization and deserialization functionality with dynamic JSON implementation resolution. It offers two primary public methods:
+
 - `to_json()`: Converts ABAP data structures to JSON strings
 - `from_json()`: Converts JSON strings back to ABAP data structures
 
 The class uses a dynamically resolved JSON implementation class and supports optional JSON compression.
 
 ## Dependencies
+
 - `/ui2/cl_json`: JSON serialization/deserialization utility
 - `zllm_implementation` Business Add-In (BADI) for JSON implementation configuration
 
 ## Details
+
 The class implements a flexible JSON conversion mechanism through several key design elements:
 
 ### Dynamic JSON Implementation Resolution
+
 ```mermaid
 sequenceDiagram
     participant Class Constructor
@@ -37,15 +43,18 @@ sequenceDiagram
 The `class_constructor` method dynamically retrieves the JSON implementation class through a BADI, allowing runtime configuration of the JSON serialization strategy.
 
 ### JSON Conversion Methods
+
 The `to_json()` and `from_json()` methods use dynamic method calls to the resolved JSON implementation class, with the following characteristics:
+
 - Supports low-case property naming
 - Optional JSON compression in `to_json()`
 - Handles various data structure types
 
 ### Configuration Persistence
+
 The class maintains two private class-level attributes:
+
 - `json_class`: Stores the dynamically resolved JSON implementation class name
 - `llm_badi`: Holds a reference to the LLM implementation BADI
 
 The `get_llm_badi()` method provides access to the BADI instance, enabling further configuration or interaction if needed.
-

docs/Claude 3.5 Haiku/ZCL_LLM_DEFAULT_IMPL_CLAS.md

@@ -8,24 +8,29 @@ parent_type: DEVC
 # Class ZCL_LLM_DEFAULT_IMPL
 
 AI Generated documentation.
+
 ## Overview
+
 The `zcl_llm_default_impl` class is a default implementation provider for various system components related to Large Language Model (LLM) interactions. It implements the `zif_llm_default_impl` interface and provides singleton-like access to key implementation classes for encryption, logging, statistics, and authorization.
 
 Public methods include:
+
 - `get_encryption_impl()`: Returns an encryption implementation
 - `get_json_impl()`: Returns a JSON handling class
 - `get_call_logger_impl()`: Returns a call logging implementation
 - `get_statistics_impl()`: Returns a statistics tracking implementation
 - `get_authorization_impl()`: Returns an authorization implementation
 
 ## Dependencies
+
 - `zif_llm_encryption`
 - `zif_llm_statistics`
 - `zif_llm_call_logger`
 - `zif_llm_auth`
 
 ## Details
-The class uses a lazy initialization pattern for its implementation classes, creating instances only when first requested. 
+
+The class uses a lazy initialization pattern for its implementation classes, creating instances only when first requested.
 
 ```mermaid
 classDiagram
@@ -44,10 +49,10 @@ classDiagram
 ```
 
 Key implementation details:
+
 - Uses class-level static references to cache implementation instances
 - Provides a centralized point for retrieving default implementations
 - Default authorization implementation uses a disabled authorization class
 - JSON implementation directly returns the standard SAP JSON class path
 
 The design allows for easy extension and replacement of core LLM interaction components through a centralized interface.
-