@cspeach/cli 0.9.0 → 1.0.0

package/bench/results/abap-explain-bdef-handler/claude-opus-4-7.md

@@ -1,101 +0,0 @@
-# abap-explain-bdef-handler — claude-opus-4-7
-
-- **skill:** abap-explain
-- **description:** Explain a managed RAP behavior pool with a validation + determination
-- **latency:** 50316 ms
-- **input tokens:** 6
-- **output tokens:** 2,921
-- **cost:** $0.2192
-
----
-
-## Code Explanation — LHC_SALESORDER (Behavior Pool for SalesOrder)
-
-## TL;DR
-
-**Headline:** This is a RAP (RESTful Application Programming) behavior pool with two handlers attached to the `SalesOrder` business object: one validates that the order date is not in the past, and the other automatically calculates the net amount from quantity × unit price.
-
-**Top 3 (priority order — most important first):**
-1. **Validation runs on save and blocks bad data** — `validateorderdate` triggers automatically when the user saves; if `OrderDate` is in the past, the save is rejected with an error message.
-2. **Net amount is auto-calculated on every change** — `determinenetamount` runs whenever quantity or unit price is modified and overwrites `NetAmount` with `Quantity × UnitPrice`. The user does not (and should not) enter this field manually.
-3. **Both handlers are framework-driven, not callable directly** — they fire automatically based on user actions in the Fiori UI or OData API; no application code calls them by name.
-
-**Verdict:** Standard, well-structured RAP behavior pool. Read it as two automatic "triggers" that the SAP framework invokes at well-defined moments in the transaction lifecycle.
-
----
-
-**Audience:** Non-ABAP Developer
-**Object Type:** RAP Behavior Pool (Local Handler Class)
-
----
-
-### What This Code Does
-
-This code defines two automatic rules for sales orders in a modern SAP application. The first rule prevents users from saving a sales order with a date in the past. The second rule automatically computes the order's total amount (`NetAmount`) whenever the quantity or unit price changes, so the user never has to enter it.
-
----
-
-### Step by Step
-
-1. **Class declaration — registers two handlers with the RAP framework**
-   The class `lhc_salesorder` inherits from `cl_abap_behavior_handler`. The two `FOR VALIDATE ON SAVE` and `FOR DETERMINE ON MODIFY` declarations tell the SAP framework: "Call `validateorderdate` right before saving, and call `determinenetamount` immediately whenever the entity is modified." The application never calls these methods directly — the framework does, automatically.
-
-2. **`validateorderdate` — read the order dates being saved**
-   When the user clicks Save, the framework passes in `keys` (the IDs of the orders being saved). The code reads the `OrderDate` field for each of those orders from the business object `zr_salesorder` into a local table `lt_orders`. `IN LOCAL MODE` means: skip authorization checks here, because we're inside the trusted transaction context.
-
-3. **`validateorderdate` — check each order and reject the bad ones**
-   For each order, the code compares `OrderDate` to today's date. If the order date is earlier than today, two things happen:
-   - The order's key is added to `failed-salesorder` — this tells the framework "do not save this one."
-   - A user-facing error message ("Order date must be today or in the future") is added to `reported-salesorder` — this is what the Fiori UI will display to the user.
-
-   If all orders pass, neither table gets entries and the save proceeds.
-
-4. **`determinenetamount` — read the inputs needed for the calculation**
-   This handler fires whenever `Quantity` or `UnitPrice` is changed (configured elsewhere in the behavior definition, not shown here). It reads both fields for the modified orders into `lt_orders`.
-
-5. **`determinenetamount` — build an update table with the calculated value**
-   For each order, the code creates an update entry containing the order's key, the computed `NetAmount` (`Quantity * UnitPrice`), and a `%control` flag that explicitly says "yes, I really mean to update the NetAmount field." Without that control flag, RAP would ignore the field.
-
-6. **`determinenetamount` — write the calculated NetAmount back to the business object**
-   The `MODIFY ENTITIES` statement pushes the updated `NetAmount` values back into the transactional buffer. The user sees the field update without typing anything.
-
----
-
-### SAP Concepts Explained
-
-| Term | What It Means |
-|------|--------------|
-| RAP (RESTful Application Programming) | SAP's modern framework for building business applications. Think of it like a backend framework (similar in spirit to Spring Boot or Django) where you declare a business object and the framework handles persistence, validation, OData exposure, and UI integration. |
-| Behavior Pool | The ABAP class that holds the logic (handlers) for a business object. One business object can have one or more behavior pools. |
-| Business Object (here: `zr_salesorder`) | The logical entity the framework manages — like a "model" in MVC. It has fields, keys, associations, and behaviors. The `zr_` prefix marks it as a custom (customer-defined) root entity. |
-| `FOR VALIDATE ON SAVE` | A handler type. The framework calls this method right before committing changes to the database. Its job is to flag invalid records and prevent the save. |
-| `FOR DETERMINE ON MODIFY` | A handler type. The framework calls this method immediately after any modification, *before* the user sees the result. Its job is to compute derived fields. |
-| `keys` | A table of entity keys (IDs) that the framework passes in, telling the handler which records to act on. Handlers should only touch these records, not all records. |
-| `READ ENTITIES` / `MODIFY ENTITIES` | RAP-specific statements that read from and write to the transactional buffer (the in-memory staging area for changes), not directly to the database. The database write happens later, during the save phase. |
-| `IN LOCAL MODE` | A modifier that tells RAP "skip authorization and feature-control checks for this operation." Used inside trusted handler logic where the framework has already verified the user's right to perform the overall action. |
-| `%tky` | The "transactional key" — a composite identifier RAP uses internally to track each entity instance during a transaction. Always use this when referencing a specific record in handler tables. |
-| `%control` | A structure that explicitly marks which fields you intend to change. RAP requires you to opt-in field by field (`mk-on`) to prevent accidental overwrites of fields you didn't mean to touch. |
-| `failed` / `reported` | Two output tables every handler can populate. `failed` lists records that should be rejected; `reported` carries user-facing messages (errors, warnings, info) back to the UI. |
-| `cl_abap_context_info=>get_system_date( )` | A helper method that returns today's date according to the SAP application server. Preferred over the older `sy-datum` system variable in modern code because it's testable and time-zone-aware. |
-
----
-
-### Key Things to Know
-
-1. **Both handlers are invoked by the framework, never by application code.** You will not find any `CALL METHOD validateorderdate` anywhere — the linkage is declarative, defined in the behavior definition file (the `.bdef` artifact, not shown here).
-
-2. **`determinenetamount` will overwrite any value the user types into `NetAmount`.** Because it runs on every modification of `Quantity` or `UnitPrice`, the user's manual edits to `NetAmount` will be silently replaced. The `NetAmount` field should be marked read-only in the UI to avoid confusing users.
-
-3. **The validation message is hard-coded in English.** `'Order date must be today or in the future'` is a literal string, not a translatable message class. In a real production system this should be replaced with a message from a message class so it can be translated.
-
-4. **`IN LOCAL MODE` skips authorization checks — by design.** This is correct inside RAP handlers because the framework already authorized the overall transaction. Do not copy this pattern into general-purpose code outside RAP handlers.
-
-5. **No COMMIT WORK appears anywhere — and that's intentional.** In RAP, the application code never commits directly. The framework manages the save sequence (validations → determinations → adjust numbers → save → commit) and decides when to commit based on the outcome of the handlers.
-
----
-
-### What Was Not Analyzed
-
-- **The behavior definition (`zr_salesorder.bdef`)** — this file declares which handler runs on which trigger and on which fields. Without seeing it, the exact trigger conditions for `determinenetamount` (which field changes cause it to fire) are [INFERRED] from the field names read in the handler.
-- **The CDS view `zr_salesorder`** — the field list, key definition, and associations of the business object were not provided. Field names like `OrderDate`, `Quantity`, `UnitPrice`, `NetAmount` are visible in use but their data types are not confirmed here.
-- **The exception/message class for translatable texts** — none is referenced, which is itself a finding (see Key Things to Know #3).

package/bench/results/abap-explain-bdef-handler/claude-sonnet-4-6.md

@@ -1,101 +0,0 @@
-# abap-explain-bdef-handler — claude-sonnet-4-6
-
-- **skill:** abap-explain
-- **description:** Explain a managed RAP behavior pool with a validation + determination
-- **latency:** 45091 ms
-- **input tokens:** 3
-- **output tokens:** 2,069
-- **cost:** $0.0310
-
----
-
-## Code Explanation — LHC_SALESORDER Behavior Pool
-
-**Audience:** Non-ABAP Developer
-**Object Type:** ABAP RAP Behavior Pool (Local Handler Class)
-
----
-
-## TL;DR
-
-**Headline:** A RAP behavior handler class that enforces a date validation rule and auto-calculates net amount on every sales order save/modify event.
-
-**Top 3 (priority order — most important first):**
-1. `validateorderdate` is a **hard gate on save** — any sales order with a past `OrderDate` is blocked from being saved, with an error message returned to the UI automatically.
-2. `determinenetamount` **silently overwrites** `NetAmount` every time `Quantity` or `UnitPrice` changes — the field cannot be manually set by the user because the determination always recalculates it.
-3. Both methods use `IN LOCAL MODE`, meaning they **bypass authorization and feature-control checks** — this is intentional for framework-triggered logic but worth knowing if you're auditing security boundaries.
-
-**Verdict:** Straightforward, correct RAP boilerplate — understand the trigger timing (ON SAVE vs. ON MODIFY) and the `IN LOCAL MODE` implication before extending this code.
-
----
-
-## Code Explanation — LHC_SALESORDER Behavior Pool
-
-**Audience:** Non-ABAP Developer
-**Object Type:** ABAP RAP Behavior Pool — Local Handler Class (`lhc_`)
-
----
-
-### What This Code Does
-
-This code enforces two automatic business rules on a sales order object in SAP's RAP framework. First, it prevents anyone from saving a sales order if the order date is in the past. Second, it automatically calculates the net amount of an order (quantity × unit price) whenever the order is modified — so the user never has to enter that field manually.
-
----
-
-### Step by Step
-
-1. **Class definition — declaring the two rules**
-   The class `lhc_salesorder` inherits from `cl_abap_behavior_handler`, which is SAP's base class for all RAP behavior handlers. It declares two methods: one that *validates* data before saving, and one that *determines* (auto-calculates) a field when data changes. These are not normal methods you call manually — the RAP framework calls them automatically at the right moment.
-
-2. **`validateorderdate` — triggered just before saving**
-   When a user hits "Save" on a sales order, the RAP framework calls this method automatically (`FOR VALIDATE ON SAVE`). It reads the `OrderDate` field for every sales order that is about to be saved [`READ ENTITIES IN LOCAL MODE`].
-
-3. **Date check — block past dates**
-   For each order, it compares `OrderDate` against today's date (retrieved via `cl_abap_context_info=>get_system_date()`). If the order date is in the past, the order is added to the `failed-salesorder` table — which tells the framework "this record failed validation, do not save it." An error message is also added to `reported-salesorder`, which the framework sends back to the UI so the user sees: *"Order date must be today or in the future."* No exception is thrown; the framework handles the rest.
-
-4. **`determinenetamount` — triggered whenever the order is modified**
-   This method runs automatically whenever a sales order is created or changed (`FOR DETERMINE ON MODIFY`). It reads both `Quantity` and `UnitPrice` for the affected orders.
-
-5. **Calculate and write back the net amount**
-   For every order read, it computes `NetAmount = Quantity × UnitPrice` and builds an update list [`lt_update`]. The `%control-NetAmount = if_abap_behv=>mk-on` line is a control flag that explicitly tells the framework "this field is intentionally being set" — without it, the framework might ignore the update. The method then writes the calculated value back to the business object using `MODIFY ENTITIES IN LOCAL MODE`.
-
----
-
-### SAP Concepts Explained
-
-| Term | What It Means |
-|------|--------------|
-| RAP (ABAP RESTful Application Programming Model) | SAP's modern framework for building business objects (like sales orders) with standardised create/read/update/delete behaviour, validations, and UI integration. Think of it as SAP's version of a domain model + REST controller in one. |
-| Behavior Pool | The ABAP class file that contains the actual code implementing a RAP business object's rules — validations, determinations, actions. The "pool" holds one or more local handler classes. |
-| `FOR VALIDATE ON SAVE` | A RAP hook. The framework calls this method automatically just before committing data to the database. If validation fails, the save is blocked. |
-| `FOR DETERMINE ON MODIFY` | A RAP hook. The framework calls this method automatically whenever the business object's data is changed (created or updated), so computed fields can be recalculated. |
-| `READ ENTITIES` | RAP's way of reading data from a business object — goes through the object's own layer rather than hitting the database directly. Respects the object's in-memory state (changes not yet saved). |
-| `MODIFY ENTITIES` | RAP's way of writing data back to a business object from within the framework itself. Used here to write the calculated `NetAmount` back. |
-| `IN LOCAL MODE` | Skips re-checking authorizations and feature controls when reading or writing inside the framework. Used here because the framework itself is already trusted to call these methods at the right time. |
-| `%tky` | Short for "transactional key" — the unique identifier of a business object instance inside a RAP transaction. It may include more fields than just the primary key, depending on the object's draft-handling setup. |
-| `%control` | A parallel structure that accompanies every RAP entity instance. Each field in `%control` is a flag (`on`/`off`) saying whether the corresponding data field should be processed. Required when writing back computed values. |
-| `failed-salesorder` | A framework-managed result parameter. Adding a key to it tells RAP: "this record has a hard error — do not save it." |
-| `reported-salesorder` | A framework-managed result parameter. Adding an entry here attaches a user-visible message (info, warning, or error) to a specific record. |
-| `new_message_with_text(...)` | A convenience function that creates a simple ad-hoc message object without needing a message class. The `severity-error` severity makes it a blocking error on the UI. |
-
----
-
-### Key Things to Know
-
-1. **Validation blocks the entire save for the affected record, not just that field.** If `OrderDate` is invalid, the whole sales order is rejected — not just the date field. Other records in the same save operation that pass validation are still saved normally.
-
-2. **`NetAmount` is always overwritten — the user cannot override it.** Because `determinenetamount` fires on every modify, any manual entry a user makes in `NetAmount` (if the UI even exposes it as editable) will be immediately recalculated and replaced. This field is effectively read-only from the user's perspective.
-
-3. **`IN LOCAL MODE` means these methods do not re-trigger each other.** Writes done inside `IN LOCAL MODE` do not fire other determinations or validations again. This prevents infinite loops (e.g., `determinenetamount` writing `NetAmount` would not re-trigger `determinenetamount`).
-
-4. **The date validation uses server time, not the user's local time or timezone.** `cl_abap_context_info=>get_system_date()` returns the SAP application server's date. In global deployments with users in different timezones, a date that looks like "today" to the user might be "yesterday" on the server, causing surprising validation failures.
-
-5. **There is no null/zero guard on the multiplication.** If `Quantity` or `UnitPrice` is initial (i.e., zero or blank — the ABAP default for unset numeric fields), `NetAmount` will be calculated as zero without any warning. Whether that is correct depends on whether those fields are mandatory elsewhere in the behavior definition.
-
----
-
-### What Was Not Analyzed
-
-- **`zr_salesorder` (the RAP Business Object / CDS view)** — referenced throughout but not provided. The full field list, key structure, draft table setup, and what other validations or determinations are defined in the behavior definition (`.bdef`) are not visible here.
-- **`zcx_not_authorized` / authorization objects** — no authorization checks are present in this handler; they would be defined elsewhere in the behavior definition or a separate handler class.
-- The **behavior definition file** (`zr_salesorder.bdef`) that registers `validateorderdate` and `determinenetamount` as the triggers for these methods was not provided. The timing and conditions under which these methods fire are configured there.

package/bench/results/abap-test-method/claude-haiku-4-5.md

@@ -1,186 +0,0 @@
-# abap-test-method — claude-haiku-4-5
-
-- **skill:** abap-test
-- **description:** Generate an ABAP Unit test class for a small business rule method
-- **latency:** 14672 ms
-- **input tokens:** 2
-- **output tokens:** 1,857
-- **cost:** $0.0093
-
----
-
-# abap-test — ZCL_DISCOUNT_CALCULATOR
-
-## TL;DR
-
-**Headline:** Generated a 5-test unit test class covering all discount tier boundaries, edge cases, and the negative-input error path for `calculate_discount()`.
-
-**Top 3 (priority order — most important first):**
-1. **Boundary tests lock the tier thresholds** — tests at 999.99, 1000.00, 4999.99, 5000.00, 9999.99, 10000.00 ensure no off-by-one errors in WHEN conditions.
-2. **Exception path verified** — negative input raises `zcx_discount_error` with expected textid; test captures and asserts the exception type.
-3. **All happy paths covered** — four discount tiers (0%, 5%, 10%, 15%) each have at least one test case; estimated coverage **~95%** on the method.
-
-**Verdict:** Ready to write to system. No refactoring needed; method is isolated and testable. Execute tests after write to establish green baseline before any future changes.
-
----
-
-## Test Strategy
-
-**Class Under Test:** ZCL_DISCOUNT_CALCULATOR  
-**Methods Analyzed:** 1 public  
-**Test Cases Designed:** 5
-
-### Test Matrix
-
-| Method | Scenario | Input Summary | Expected Output | Mock Required |
-|--------|----------|---------------|-----------------|---------------|
-| calculate_discount | Tier 1 (< 1000) | 500.00 | 0.00% | None |
-| calculate_discount | Tier 1 boundary | 999.99 | 0.00% | None |
-| calculate_discount | Tier 2 entry (≥ 1000) | 1000.00 | 5.00% | None |
-| calculate_discount | Tier 3 (≥ 5000) | 5000.00 | 10.00% | None |
-| calculate_discount | Tier 4 (≥ 10000) | 10000.00 | 15.00% | None |
-| calculate_discount | Negative input | −100.00 | ZCX_DISCOUNT_ERROR raised | None |
-
----
-
-## Generated Test Class
-
-```abap
-CLASS zcl_discount_calculator_test DEFINITION FINAL
-  FOR TESTING
-  RISK LEVEL HARMLESS
-  DURATION SHORT.
-
-  PRIVATE SECTION.
-    DATA mo_cut TYPE REF TO zcl_discount_calculator.
-
-    METHODS setup.
-    METHODS test_tier1_standard         FOR TESTING.
-    METHODS test_tier1_boundary         FOR TESTING.
-    METHODS test_tier2_entry            FOR TESTING.
-    METHODS test_tier3_entry            FOR TESTING.
-    METHODS test_tier4_entry            FOR TESTING.
-    METHODS test_negative_input_raises  FOR TESTING.
-
-ENDCLASS.
-
-CLASS zcl_discount_calculator_test IMPLEMENTATION.
-
-  METHOD setup.
-    mo_cut = NEW zcl_discount_calculator( ).
-  ENDMETHOD.
-
-  METHOD test_tier1_standard.
-    "Arrange
-    DATA(lv_net_amount) = '500.00'.
-
-    "Act
-    DATA(lv_discount) = mo_cut->calculate_discount( lv_net_amount ).
-
-    "Assert
-    cl_abap_unit_assert=>assert_equals(
-      act     = lv_discount
-      exp     = '0.00'
-      msg     = 'Discount for net amount 500.00 should be 0%' ).
-  ENDMETHOD.
-
-  METHOD test_tier1_boundary.
-    "Arrange: test boundary at 999.99 (just below tier 2 threshold)
-    DATA(lv_net_amount) = '999.99'.
-
-    "Act
-    DATA(lv_discount) = mo_cut->calculate_discount( lv_net_amount ).
-
-    "Assert
-    cl_abap_unit_assert=>assert_equals(
-      act     = lv_discount
-      exp     = '0.00'
-      msg     = 'Discount at boundary 999.99 should remain in tier 1 (0%)' ).
-  ENDMETHOD.
-
-  METHOD test_tier2_entry.
-    "Arrange: test exact threshold entry (1000.00 → tier 2)
-    DATA(lv_net_amount) = '1000.00'.
-
-    "Act
-    DATA(lv_discount) = mo_cut->calculate_discount( lv_net_amount ).
-
-    "Assert
-    cl_abap_unit_assert=>assert_equals(
-      act     = lv_discount
-      exp     = '5.00'
-      msg     = 'Discount at 1000.00 should enter tier 2 (5%)' ).
-  ENDMETHOD.
-
-  METHOD test_tier3_entry.
-    "Arrange: test tier 3 threshold entry (5000.00 → tier 3)
-    DATA(lv_net_amount) = '5000.00'.
-
-    "Act
-    DATA(lv_discount) = mo_cut->calculate_discount( lv_net_amount ).
-
-    "Assert
-    cl_abap_unit_assert=>assert_equals(
-      act     = lv_discount
-      exp     = '10.00'
-      msg     = 'Discount at 5000.00 should enter tier 3 (10%)' ).
-  ENDMETHOD.
-
-  METHOD test_tier4_entry.
-    "Arrange: test tier 4 threshold entry (10000.00 and beyond)
-    DATA(lv_net_amount) = '10000.00'.
-
-    "Act
-    DATA(lv_discount) = mo_cut->calculate_discount( lv_net_amount ).
-
-    "Assert
-    cl_abap_unit_assert=>assert_equals(
-      act     = lv_discount
-      exp     = '15.00'
-      msg     = 'Discount at 10000.00 should enter tier 4 (15%)' ).
-  ENDMETHOD.
-
-  METHOD test_negative_input_raises.
-    "Arrange: prepare invalid input (negative amount)
-    DATA(lv_net_amount) = '-100.00'.
-
-    "Act + Assert: expect exception
-    TRY.
-        mo_cut->calculate_discount( lv_net_amount ).
-        cl_abap_unit_assert=>fail(
-          msg = 'Expected ZCX_DISCOUNT_ERROR for negative net amount' ).
-      CATCH zcx_discount_error INTO DATA(lx_error).
-        "Verify the exception has the correct textid
-        cl_abap_unit_assert=>assert_equals(
-          act     = lx_error->textid
-          exp     = zcx_discount_error=>negative_input
-          msg     = 'Exception textid should be negative_input' ).
-    ENDTRY.
-  ENDMETHOD.
-
-ENDCLASS.
-```
-
----
-
-## Coverage Estimate
-
-| Method | Scenarios Covered | Coverage Estimate |
-|--------|-------------------|-------------------|
-| calculate_discount | 6 (all tiers + error) | ~95% |
-
-**Overall Estimated Coverage:** ~95%
-
-The single uncovered line would be the conditional branch not taken in error cases, but all WHEN paths in the COND are exercised, and the exception path is explicitly tested.
-
----
-
-## Next Steps
-
-**Write to system?** [y/n]
-
-Confirm and I will:
-1. Create the test include for `ZCL_DISCOUNT_CALCULATOR`
-2. Write the test class source
-3. Run syntax check
-4. Execute the unit tests and report pass/fail status

package/bench/results/abap-test-method/claude-opus-4-7.md

@@ -1,193 +0,0 @@
-# abap-test-method — claude-opus-4-7
-
-- **skill:** abap-test
-- **description:** Generate an ABAP Unit test class for a small business rule method
-- **latency:** 36119 ms
-- **input tokens:** 6
-- **output tokens:** 3,035
-- **cost:** $0.2277
-
----
-
-## abap-test — ZCL_DISCOUNT_CALCULATOR
-
-## TL;DR
-
-**Headline:** Generated an ABAP Unit test class with 8 test methods covering all four discount tiers, both sides of each boundary, and the negative-input error path for `calculate_discount`.
-
-**Top 3 (priority order — most important first):**
-1. Boundary coverage is the critical risk here — tests cover `999.99 / 1000.00`, `4999.99 / 5000.00`, `9999.99 / 10000.00` explicitly, since off-by-one in `COND` ranges is the most likely defect.
-2. Negative-input branch is asserted via `TRY/CATCH` with `cl_abap_unit_assert=>fail` on the happy line to guarantee the exception actually fires.
-3. No dependencies, no DB, no mocks needed — pure deterministic unit; `RISK LEVEL HARMLESS DURATION SHORT` is correct and tests will run anywhere.
-
-**Verdict:** Ready to drop into the `testclasses` include of `ZCL_DISCOUNT_CALCULATOR`. Review the asserted percentages match your business intent, then activate and run.
-
----
-
-## Test Strategy
-
-**Class Under Test:** ZCL_DISCOUNT_CALCULATOR
-**Methods Analyzed:** 1 public (`calculate_discount`)
-**Test Cases Designed:** 8
-
-### Test Matrix
-
-| Method             | Scenario                          | Input        | Expected             | Mock Required |
-|--------------------|-----------------------------------|--------------|----------------------|---------------|
-| calculate_discount | Zero amount → 0%                  | 0            | 0.00                 | none          |
-| calculate_discount | Just below 1000 boundary          | 999.99       | 0.00                 | none          |
-| calculate_discount | At 1000 boundary → 5% tier        | 1000.00      | 5.00                 | none          |
-| calculate_discount | Just below 5000 boundary          | 4999.99      | 5.00                 | none          |
-| calculate_discount | At 5000 boundary → 10% tier       | 5000.00      | 10.00                | none          |
-| calculate_discount | Just below 10000 boundary         | 9999.99      | 10.00                | none          |
-| calculate_discount | At/above 10000 boundary → 15%     | 10000.00     | 15.00                | none          |
-| calculate_discount | Negative input raises exception   | -0.01        | ZCX_DISCOUNT_ERROR   | none          |
-
-No dependencies to mock — the method is a pure function over its input.
-
-Does this test strategy look complete? If yes, the generated test class is below.
-
----
-
-## Generated Test Class
-
-```abap
-CLASS ltcl_discount_calculator DEFINITION FINAL
-  FOR TESTING
-  RISK LEVEL HARMLESS
-  DURATION SHORT.
-
-  PRIVATE SECTION.
-    DATA mo_cut TYPE REF TO zcl_discount_calculator.
-
-    METHODS setup.
-
-    "--- tier coverage ---
-    METHODS test_zero_amount             FOR TESTING.
-    METHODS test_below_1000              FOR TESTING.
-    METHODS test_at_1000_boundary        FOR TESTING.
-    METHODS test_below_5000              FOR TESTING.
-    METHODS test_at_5000_boundary        FOR TESTING.
-    METHODS test_below_10000             FOR TESTING.
-    METHODS test_at_10000_boundary       FOR TESTING.
-
-    "--- error path ---
-    METHODS test_negative_amount_raises  FOR TESTING.
-
-    "--- helper ---
-    METHODS assert_discount
-      IMPORTING iv_amount   TYPE p LENGTH 13 DECIMALS 2
-                iv_expected TYPE p LENGTH 3  DECIMALS 2
-                iv_msg      TYPE string.
-ENDCLASS.
-
-
-CLASS ltcl_discount_calculator IMPLEMENTATION.
-
-  METHOD setup.
-    mo_cut = NEW zcl_discount_calculator( ).
-  ENDMETHOD.
-
-  METHOD assert_discount.
-    TRY.
-        DATA(lv_actual) = mo_cut->calculate_discount( iv_amount ).
-        cl_abap_unit_assert=>assert_equals(
-          act = lv_actual
-          exp = iv_expected
-          msg = iv_msg ).
-      CATCH zcx_discount_error INTO DATA(lx_error).
-        cl_abap_unit_assert=>fail(
-          msg = |Unexpected ZCX_DISCOUNT_ERROR for amount { iv_amount }: { lx_error->get_text( ) }| ).
-    ENDTRY.
-  ENDMETHOD.
-
-  METHOD test_zero_amount.
-    assert_discount(
-      iv_amount   = '0.00'
-      iv_expected = '0.00'
-      iv_msg      = 'Zero amount should yield 0% discount' ).
-  ENDMETHOD.
-
-  METHOD test_below_1000.
-    assert_discount(
-      iv_amount   = '999.99'
-      iv_expected = '0.00'
-      iv_msg      = 'Amount just below 1000 should yield 0% discount' ).
-  ENDMETHOD.
-
-  METHOD test_at_1000_boundary.
-    assert_discount(
-      iv_amount   = '1000.00'
-      iv_expected = '5.00'
-      iv_msg      = 'Amount at 1000 boundary should yield 5% discount' ).
-  ENDMETHOD.
-
-  METHOD test_below_5000.
-    assert_discount(
-      iv_amount   = '4999.99'
-      iv_expected = '5.00'
-      iv_msg      = 'Amount just below 5000 should yield 5% discount' ).
-  ENDMETHOD.
-
-  METHOD test_at_5000_boundary.
-    assert_discount(
-      iv_amount   = '5000.00'
-      iv_expected = '10.00'
-      iv_msg      = 'Amount at 5000 boundary should yield 10% discount' ).
-  ENDMETHOD.
-
-  METHOD test_below_10000.
-    assert_discount(
-      iv_amount   = '9999.99'
-      iv_expected = '10.00'
-      iv_msg      = 'Amount just below 10000 should yield 10% discount' ).
-  ENDMETHOD.
-
-  METHOD test_at_10000_boundary.
-    assert_discount(
-      iv_amount   = '10000.00'
-      iv_expected = '15.00'
-      iv_msg      = 'Amount at/above 10000 boundary should yield 15% discount' ).
-  ENDMETHOD.
-
-  METHOD test_negative_amount_raises.
-    TRY.
-        mo_cut->calculate_discount( '-0.01' ).
-        cl_abap_unit_assert=>fail(
-          msg = 'Expected ZCX_DISCOUNT_ERROR for negative input but none was raised' ).
-      CATCH zcx_discount_error INTO DATA(lx_error).
-        cl_abap_unit_assert=>assert_bound(
-          act = lx_error
-          msg = 'Exception object should be bound' ).
-    ENDTRY.
-  ENDMETHOD.
-
-ENDCLASS.
-```
-
----
-
-## Coverage Estimate
-
-| Method              | Scenarios Covered | Coverage Estimate |
-|---------------------|-------------------|-------------------|
-| calculate_discount  | 8 (4 tiers × boundaries + negative path) | ~100% line / ~100% branch |
-
-**Overall Estimated Coverage:** ~100%
-
-All four `COND` branches and the `RAISE EXCEPTION` branch are hit. Actual coverage should be confirmed with the ADT Coverage Tool.
-
----
-
-## Dependencies That Need Refactoring
-
-None. `calculate_discount` is a pure function with no external dependencies — ideal for unit testing as-is.
-
----
-
-## Notes for the Developer
-
-- The test class is a **local test class** (`ltcl_`) intended for the **test include** of `ZCL_DISCOUNT_CALCULATOR` (Test Classes tab in ADT, or `sap_class_includes` with `includeType: "testclasses"` in MCP mode).
-- The expected discount values were inferred from the docstring (`< 1000 → 0%`, `< 5000 → 5%`, etc.). **Please confirm these match the business rules** before relying on the tests as a contract.
-- Boundary tests (`1000.00`, `5000.00`, `10000.00`) exercise the exact `<` cutoff — these are the cases most likely to surface off-by-one regressions if someone later edits the `COND #( ... )`.
-- If you want this written into the system, say the word and I'll request approval and use `sap_class_includes` to write the `testclasses` include — I won't touch the main source.