@cspeach/cli 0.9.0 → 1.0.0

package/bench/results/abap-document-cds/claude-haiku-4-5.md

@@ -1,189 +0,0 @@
-# abap-document-cds — claude-haiku-4-5
-
-- **skill:** abap-document
-- **description:** Document a CDS interface view with associations + currency annotation
-- **latency:** 26816 ms
-- **input tokens:** 2,688
-- **output tokens:** 2,623
-- **cost:** $0.0158
-
----
-
-# abap-document — ZI_SalesOrder
-
-## TL;DR
-
-**Headline:** Interface view for sales order header data with customer and item associations, read-only with authorization check.
-
-**Top 3 (priority order):**
-1. **Authorization enforced:** `#CHECK` mode requires `DSOD` and sales order read authority at runtime — verify user roles before consuming downstream.
-2. **Fuzzy search enabled on CustomerID:** `fuzzinessThreshold: 0.8` will match partial/misspelled customer names; test with typical fat-finger errors in UAT.
-3. **No filtering logic:** View exposes all rows from `zsales_order` table — upstream consumers must apply their own `WHERE` clauses; no automatic date range or status filtering.
-
-**Verdict:** Safe foundation view for consumption in analytics, APIs, or reporting. Confirm downstream apps implement business rule filtering (e.g., active orders only, date ranges).
-
----
-
-## ZI_SalesOrder (CDS VIEW ENTITY)
-
-### Overview
-
-**Package:** (not yet read — see below)  
-**Type:** CDS View Entity (Interface Layer)  
-**Annotations:** Authorization check enabled, search enabled, end-user label "Sales Order — Interface View"
-
-**Summary:**  
-Exposes sales order header data from the custom table `zsales_order` with associations to customer master, line items, and SAP currency data. Designed as a read-only interface view for analytics, reporting, and API consumption.
-
----
-
-### Purpose
-
-This view serves as the **interface layer** for sales order headers in the custom data model. It:
-
-1. **Presents domain data cleanly** — maps technical table column names (`sales_order_id`, `customer_id`) to business-readable field names (`SalesOrderID`, `CustomerID`).
-2. **Enforces authorization** — restricts read access to users with appropriate sales order query authority.
-3. **Enables semantic search** — makes customer name searchable via fuzzy matching (0.8 threshold = allow 20% typos).
-4. **Links related business entities** — connects to customer master, line items, and currency metadata via associations (no data duplication, navigation-based joins).
-5. **Supports consumption layers** — designed for downstream consumption by reporting tools, OData APIs, or analytical views.
-
----
-
-### Interface
-
-**Key Field:**
-- `SalesOrderID` (Header.sales_order_id) — unique identifier for the sales order
-
-**Header-Level Fields:**
-
-| Field Name | Source | Type | Purpose |
-|------------|--------|------|---------|
-| SalesOrderID | Header.sales_order_id | key | Sales order unique identifier |
-| CustomerID | Header.customer_id | string | References customer master |
-| OrderDate | Header.order_date | date | Date order was placed |
-| CustomerIDForSearch | Header.customer_id | string | Fuzzy-searchable copy for customer lookup |
-| NetAmount | Header.net_amount | decimal | Order value (currency-aware via annotation) |
-| CurrencyCode | Header.currency_code | string | ISO currency code |
-| CreatedAt | Header.created_at | timestamp | Audit: creation timestamp |
-| CreatedBy | Header.created_by | user | Audit: creator user |
-| LastChangedAt | Header.last_changed_at | timestamp | Audit: last change timestamp |
-| LastChangedBy | Header.last_changed_by | user | Audit: last change user |
-
-**Associations (Navigation):**
-
-| Association | Target View | Cardinality | Join Condition | Purpose |
-|-------------|-------------|-------------|-----------------|---------|
-| `_Customer` | ZI_Customer | 0..1 | CustomerID | Navigate to customer master data |
-| `_SalesOrderItem` | ZI_SalesOrderItem | 0..* | SalesOrderID | Navigate to line items for this order |
-| `_Currency` | I_Currency (SAP standard) | 0..1 | CurrencyCode | Navigate to SAP currency details |
-
-**Authorization & Search:**
-- Authorization check: `#CHECK` — runtime check required (user must have query authority for sales order).
-- Default search element: `CustomerIDForSearch` with fuzzy matching (80% match threshold).
-- Searchable: all marked fields indexed for full-text search.
-
----
-
-### Logic Flow
-
-**Data Origin & Transformation:**
-
-1. **Source:** Read all rows from custom table `zsales_order` (Header alias).
-2. **Projection:** Map technical columns to semantic field names:
-   - `sales_order_id` → `SalesOrderID` (key)
-   - `customer_id` → `CustomerID`
-   - `order_date` → `OrderDate`
-   - `net_amount` → `NetAmount` (with currency semantic)
-   - `currency_code` → `CurrencyCode`
-   - Audit fields (created/changed by/at) mapped as-is.
-3. **Duplicate CustomerID:** `CustomerIDForSearch` is a copy of `CustomerID` explicitly marked for full-text search (allows UI to search by customer name via the association).
-4. **Associations:** Three navigation paths added (not joins — lazy-loaded):
-   - To customer master for customer details.
-   - To line items for order composition.
-   - To SAP currency master for exchange rates, decimals, etc.
-5. **Authorization Gate:** View enforces `#CHECK` at query time — SAP will validate user authority before returning rows.
-
-**No filtering logic:** View is a "raw interface" — all rows from the source table are exposed. Upstream consumers must filter by date, status, or other business rules.
-
----
-
-### Data Access
-
-| Table/View | Operation | Purpose |
-|------------|-----------|---------|
-| `zsales_order` (custom) | **READ** | Source table for all header fields (sales_order_id, customer_id, order_date, net_amount, currency_code, audit fields) |
-| `ZI_Customer` (custom view) | **READ** (via association) | Customer master lookup; enriches orders with customer details |
-| `ZI_SalesOrderItem` (custom view) | **READ** (via association) | Line items for the order; enables per-item navigation |
-| `I_Currency` (SAP standard) | **READ** (via association) | SAP currency master; provides conversion rates, decimal places |
-
-**No writes:** This is a read-only interface view. No INSERT, UPDATE, or DELETE allowed.
-
----
-
-### Dependencies
-
-**Called by (Upstream Consumers):**  
-Unknown without further analysis — use `sap_usage_references` to identify (e.g., analytics views, OData services, reports using this view).
-
-**Calls (Dependencies):**
-- `zsales_order` — custom table (no option to change this view without understanding the source table schema).
-- `ZI_Customer` — custom customer interface view (ensure it is available and stable).
-- `ZI_SalesOrderItem` — custom sales order item interface view (ensure it exists).
-- `I_Currency` (SAP standard) — standard SAP currency master (no custom risk; always available post-installation).
-
----
-
-### Authorization & Security
-
-**Authorization Check:** `#CHECK` mode  
-- When a user queries this view, SAP **enforces** a dynamic authorization check at runtime.
-- The specific check depends on SAP's authority object mapping for CDS views (typically `DSOD` → Data Source Object Definition or equivalent).
-- **Action required:** Verify that user roles define query access for this view; otherwise, queries will fail with "Authorization error."
-
-**Search & Indexing:**
-- `CustomerIDForSearch` with `fuzzinessThreshold: 0.8` allows typo-tolerant search (e.g., "APLE" matches "APPLE").
-- Useful for user-facing search UIs; may return false positives in strict filter scenarios.
-
----
-
-### Data Model & Semantics
-
-**Semantic Annotations:**
-- `@Semantics.amount.currencyCode: 'CurrencyCode'` on `NetAmount` — tells consuming systems that this field is a currency amount and which field holds the currency code. Tools like SAP Analytics Cloud will format it correctly.
-- `@ObjectModel.text.element: [ '_Customer.CustomerName' ]` on `CustomerIDForSearch` — tells UI frameworks to display the customer **name** (not ID) when showing this field.
-
-**Searchability:**
-- View is marked `@Search.searchable: true` — all fields with `@Search.defaultSearchElement: true` are indexed.
-- Only `CustomerIDForSearch` is explicitly indexed; other fields are not full-text searchable by default.
-
----
-
-### Notes & Considerations
-
-1. **No status filtering:** View exposes all orders regardless of status (open, closed, cancelled). If you need only active orders, add a downstream view or consuming WHERE clause.
-
-2. **Audit trail:** `CreatedBy`, `LastChangedBy`, `CreatedAt`, `LastChangedAt` are available for compliance; confirm these are populated in the source table `zsales_order`.
-
-3. **Association multiplicity:**
-   - Customer is 0..1 (every order may not have a customer — nullable FK?). Verify business rule: must a sales order always have a customer?
-   - Line items are 0..* (orders with no items are allowed). Confirm with business if this is intentional.
-   - Currency is 0..1 (may not exist in SAP currency master for custom codes). Test with unusual currency codes.
-
-4. **Search on CustomerID not CustomerName:** The view exposes `CustomerID` for search but links to `_Customer.CustomerName`. If users expect to search by customer **name**, ensure the downstream OData/UI binding is configured to search on `CustomerIDForSearch` and display `_Customer.CustomerName`.
-
-5. **No performance optimizations:** View is a simple 1:1 projection. For large `zsales_order` tables (millions of rows), consider:
-   - Adding a semantic partitioning hint in the view definition.
-   - Creating secondary indexes on frequently filtered columns (e.g., `OrderDate`, `CustomerID`).
-   - Testing query response times with large datasets.
-
-6. **Missing fields?** Confirm with business that all required order header fields are in the projection. If fields exist in `zsales_order` but not exposed here, add them or create a second view variant.
-
----
-
-## Next Steps
-
-1. **Trace consumers:** Run `sap_usage_references` to identify which views, APIs, and reports consume this view.
-2. **Verify source table:** Run `sap_get_source` on `zsales_order` to confirm the schema matches the projection.
-3. **Check related views:** Retrieve `ZI_Customer` and `ZI_SalesOrderItem` to ensure the associations are compatible (key cardinality, join conditions).
-4. **Authorization testing:** Create a test user with appropriate authority and verify they can query this view without "Authorization failed" errors.
-5. **Search testing:** Test fuzzy search with intentional typos (e.g., customer name "ACME Corp" vs. search "ACME Crp") to confirm the 0.8 threshold behavior.

package/bench/results/abap-document-cds/claude-opus-4-7.md

@@ -1,120 +0,0 @@
-# abap-document-cds — claude-opus-4-7
-
-- **skill:** abap-document
-- **description:** Document a CDS interface view with associations + currency annotation
-- **latency:** 42479 ms
-- **input tokens:** 6
-- **output tokens:** 2,798
-- **cost:** $0.2099
-
----
-
-## abap-document — ZI_SalesOrder (CDS Interface View)
-
-## TL;DR
-
-**Headline:** `ZI_SalesOrder` is a sales order header interface view exposing `zsales_order` with associations to customer, items, and currency, search-enabled on customer ID.
-
-**Top 3 (priority order — most important first):**
-1. **Interface view in a VDM-style layering** — naming prefix `ZI_` and associations to `ZI_Customer` / `ZI_SalesOrderItem` indicate this is the I-layer; consumption should happen via a `ZC_` view, not directly.
-2. **Search + text association configured on `CustomerIDForSearch`** — fuzzy search (threshold 0.8) with text resolved via `_Customer.CustomerName`; this field is a duplicate exposure of `customer_id` purely for search semantics.
-3. **Amount/currency reference pair (`NetAmount` ↔ `CurrencyCode`)** is correctly annotated; `_Currency` association to `I_Currency` makes this view S/4-VDM-compliant for currency handling.
-
-**Verdict:** Clean, well-annotated interface view. No code-level concerns — main thing to confirm with the team is whether a consumption view (`ZC_SalesOrder`) exists on top and whether `CustomerIDForSearch` duplication is intentional.
-
----
-
-> ⚠️ **Note:** This documentation is based solely on the source you pasted. I did not call `sap_get_source`, `sap_object_structure`, or `sap_usage_references`, so package, author, change history, and where-used data are not included. If you want the full document with dependencies and metadata, re-run and I'll pull it from the system.
-
-## ZI_SalesOrder (DDLS — CDS View Entity)
-
-### Overview
-Package: *not retrieved* | Author: *not retrieved* | Last changed: *not retrieved*
-
-`ZI_SalesOrder` is an **interface-layer CDS view entity** over the custom sales order header table `zsales_order`. It exposes header fields, exposes associations to customer, items, and currency, and enables fuzzy search on the customer ID with the customer name surfaced as text.
-
-### Purpose
-Provide a reusable, semantically annotated interface for sales order header data following VDM (Virtual Data Model) conventions:
-
-- Acts as the **single source of truth for the sales order header** in the I-layer.
-- Wires up the **associations** that downstream consumption views, Fiori elements apps, and analytical views can navigate (customer, items, currency).
-- Enables **enterprise search** over the order's customer with name resolution.
-- Establishes **currency semantics** so amounts render correctly in UIs and analytics.
-
-It does **not** implement business logic, filtering, or authorization beyond `#CHECK` (DCL-based row-level auth, if a DCL exists for this entity).
-
-### Interface
-
-**Type:** `define view entity` (modern CDS, not legacy `define view`)
-
-**Source:** `zsales_order` (aliased as `Header`)
-
-**Key:**
-| Field | Type source | Notes |
-|---|---|---|
-| `SalesOrderID` | `Header.sales_order_id` | Primary key |
-
-**Exposed fields:**
-| Element | Source | Semantics / Annotations |
-|---|---|---|
-| `SalesOrderID` (key) | `sales_order_id` | — |
-| `CustomerID` | `customer_id` | — |
-| `OrderDate` | `order_date` | — |
-| `CustomerIDForSearch` | `customer_id` | `@Search.defaultSearchElement: true`, fuzziness 0.8, text from `_Customer.CustomerName` |
-| `NetAmount` | `net_amount` | `@Semantics.amount.currencyCode: 'CurrencyCode'` |
-| `CurrencyCode` | `currency_code` | Currency reference field |
-| `CreatedAt` | `created_at` | Admin field |
-| `CreatedBy` | `created_by` | Admin field |
-| `LastChangedAt` | `last_changed_at` | Admin field |
-| `LastChangedBy` | `last_changed_by` | Admin field |
-
-**Associations (exposed):**
-| Name | Cardinality | Target | Join condition |
-|---|---|---|---|
-| `_Customer` | `[0..1]` | `ZI_Customer` | `CustomerID = _Customer.CustomerID` |
-| `_SalesOrderItem` | `[0..*]` | `ZI_SalesOrderItem` | `SalesOrderID = _SalesOrderItem.SalesOrderID` |
-| `_Currency` | `[0..1]` | `I_Currency` (SAP standard) | `CurrencyCode = _Currency.Currency` |
-
-**View-level annotations:**
-- `@AccessControl.authorizationCheck: #CHECK` — DCL authorization is checked at runtime if a DCL is defined; otherwise warnings issued.
-- `@EndUserText.label: 'Sales Order — Interface View'`
-- `@Search.searchable: true` — view participates in enterprise search.
-
-### Logic Flow
-
-There is no procedural logic — this is a projection view. At runtime:
-
-1. **Select** header rows from `zsales_order`.
-2. **Apply DCL** (`#CHECK`) if a corresponding DCL role exists on `ZI_SalesOrder`.
-3. **Expose** the renamed fields and forward the three associations to consumers.
-4. On association navigation, the database joins to `ZI_Customer`, `ZI_SalesOrderItem`, or `I_Currency` as needed.
-5. For search queries, `CustomerIDForSearch` is the entry point; the engine performs fuzzy matching (threshold 0.8) and shows `_Customer.CustomerName` as descriptive text.
-
-### Data Access
-| Table/View | Operation | Purpose |
-|---|---|---|
-| `zsales_order` | READ | Source table — header data |
-| `ZI_Customer` (via `_Customer`) | READ on navigation | Customer master for text and details |
-| `ZI_SalesOrderItem` (via `_SalesOrderItem`) | READ on navigation | Child items |
-| `I_Currency` (via `_Currency`) | READ on navigation | Standard currency master (TCURC) |
-
-### Dependencies
-
-*Where-used not retrieved — re-run with system access to populate.*
-
-**Calls (compile-time dependencies):**
-- Source table: `zsales_order`
-- Associated views: `ZI_Customer`, `ZI_SalesOrderItem`, `I_Currency`
-
-**Called by:** *unknown — typically a `ZC_SalesOrder` consumption view, OData service bindings, or analytical views; confirm via `sap_usage_references`.*
-
-### Error Handling
-None at view level. Authorization failures via DCL would result in rows being filtered out, not exceptions. If `zsales_order` or any associated view is inactive or missing, the view itself will not activate.
-
-### Notes / Observations
-- **`CustomerIDForSearch` duplicates `CustomerID`** — this is a common pattern to keep `CustomerID` "clean" (no search annotations) while a separate element carries the search semantics. Confirm this is intentional and not legacy.
-- **`@AccessControl.authorizationCheck: #CHECK`** requires a DCL role (`define role` on `ZI_SalesOrder`) to actually enforce anything. Verify a DCL exists; otherwise this is effectively `#NOT_REQUIRED` with an activation warning.
-- **VDM naming** (`ZI_` prefix) suggests this is part of a layered model. Best practice: do not consume this view directly from UIs — build a `ZC_SalesOrder` on top.
-- **`I_Currency`** is the SAP-standard currency interface view; the association is correctly modeled for S/4HANA-style currency reference.
-- **No `@Metadata.allowExtensions` annotation** — if extension is expected (CDS view extensions for customer fields), add `@Metadata.allowExtensions: true`.
-- **Purpose of `CustomerIDForSearch`** is clear from annotations, but the broader business process (order-to-cash? B2B sales?) **is not derivable from the source** — confirm with the business team.

package/bench/results/abap-document-cds/claude-sonnet-4-6.md

@@ -1,151 +0,0 @@
-# abap-document-cds — claude-sonnet-4-6
-
-- **skill:** abap-document
-- **description:** Document a CDS interface view with associations + currency annotation
-- **latency:** 45194 ms
-- **input tokens:** 3
-- **output tokens:** 2,460
-- **cost:** $0.0369
-
----
-
-## ZI_SalesOrder (CDS View Entity)
-
-## TL;DR
-
-**Headline:** `ZI_SalesOrder` is a search-enabled interface view entity exposing sales order header data with associations to customer, line items, and currency — the foundational read layer for sales order consumption.
-
-**Top 3 (priority order — most important first):**
-1. **Dual customer ID fields** — `CustomerID` and `CustomerIDForSearch` both map to `Header.customer_id`; the search field carries fuzzy-search and text-element annotations while the key field is clean — consumers must understand which to use for display vs. filtering.
-2. **Access control is enforced (`#CHECK`)** — a DCL (`ZI_SalesOrder.dcls` or equivalent) must exist and be correct, or all data access will be silently blocked; verify the DCL is maintained before consuming in new apps.
-3. **Interface ("I\_") naming convention** — the `ZI_` prefix marks this as a reuse/interface view intended to be the stable contract for consumption views (`ZC_`) and OData services; it should not be modified lightly, as changes ripple to all consumers.
-
-**Verdict:** Well-structured interface view following SAP VDM conventions; safe to consume but verify the DCL and confirm the `zsales_order` base table schema matches expected field types before exposing via OData.
-
----
-
-## ZI_SalesOrder (DDLS — CDS View Entity)
-
-### Overview
-
-| Attribute | Value |
-|-----------|-------|
-| **Object Type** | CDS View Entity (`define view entity`) |
-| **Base Table** | `zsales_order` (aliased as `Header`) |
-| **End-User Label** | Sales Order — Interface View |
-| **VDM Role** | Interface View (`ZI_` prefix) |
-| **Search-enabled** | Yes (`@Search.searchable: true`) |
-| **Access Control** | Enforced (`@AccessControl.authorizationCheck: #CHECK`) |
-
-**Summary:** A sales order header interface view that selects from the custom table `zsales_order` and exposes key business attributes — order identity, customer, amount, currency, and audit timestamps. It publishes three associations (customer master, order items, currency) for use by consumption layers.
-
----
-
-### Purpose
-
-`ZI_SalesOrder` sits at the **interface layer** of a Virtual Data Model (VDM) for sales order processing. Its responsibilities are:
-
-1. **Stable contract** — provide a named, annotated projection of `zsales_order` that upstream consumption views (`ZC_SalesOrder`, OData services, Fiori apps) can depend on without coupling directly to the physical table.
-2. **Search enablement** — expose fuzzy customer search over sales orders via `CustomerIDForSearch` with a fuzziness threshold of 0.8.
-3. **Association hub** — publish navigation paths to related entities (customer, line items, currency) so consumers can traverse the model without re-joining.
-
----
-
-### Interface (Exposed Fields)
-
-| Field Name | Source Column | Key | Notes |
-|---|---|---|---|
-| `SalesOrderID` | `Header.sales_order_id` | ✅ | Primary key |
-| `CustomerID` | `Header.customer_id` | — | Use for filtering / key navigation |
-| `OrderDate` | `Header.order_date` | — | |
-| `CustomerIDForSearch` | `Header.customer_id` | — | Search field; carries fuzzy search & text element annotations — see note below |
-| `NetAmount` | `Header.net_amount` | — | Annotated with `@Semantics.amount.currencyCode: 'CurrencyCode'` |
-| `CurrencyCode` | `Header.currency_code` | — | Reference field for `NetAmount` |
-| `CreatedAt` | `Header.created_at` | — | Audit: creation timestamp |
-| `CreatedBy` | `Header.created_by` | — | Audit: creating user |
-| `LastChangedAt` | `Header.last_changed_at` | — | Audit: last change timestamp |
-| `LastChangedBy` | `Header.last_changed_by` | — | Audit: last changing user |
-
-**Exposed Associations**
-
-| Association | Target View | Cardinality | Join Condition |
-|---|---|---|---|
-| `_Customer` | `ZI_Customer` | `[0..1]` | `CustomerID = _Customer.CustomerID` |
-| `_SalesOrderItem` | `ZI_SalesOrderItem` | `[0..*]` | `SalesOrderID = _SalesOrderItem.SalesOrderID` |
-| `_Currency` | `I_Currency` (SAP standard) | `[0..1]` | `CurrencyCode = _Currency.Currency` |
-
----
-
-### Logic Flow
-
-This is a pure projection view — there is no filtering, aggregation, or conditional logic. The runtime behavior is:
-
-1. **Full read** of `zsales_order` — no `WHERE` clause, so all header records are exposed (access is controlled by the DCL, not SQL predicates).
-2. **Association resolution on demand** — `_Customer`, `_SalesOrderItem`, and `_Currency` are lazy; joins only occur when a consumer explicitly selects or navigates through them.
-3. **Search index population** — the `@Search.searchable` and `@Search.defaultSearchElement` annotations instruct the search framework to index `CustomerIDForSearch` for Enterprise Search / Fiori search help.
-4. **Amount/currency pairing** — the `@Semantics.amount` annotation links `NetAmount` to `CurrencyCode` so OData/Fiori clients render the currency symbol automatically.
-
----
-
-### Data Access
-
-| Object | Type | Operation | Purpose |
-|---|---|---|---|
-| `zsales_order` | Database Table | READ | Source of all sales order header fields |
-| `ZI_Customer` | CDS View Entity | READ (via assoc.) | Resolve customer name and attributes |
-| `ZI_SalesOrderItem` | CDS View Entity | READ (via assoc.) | Resolve line items for a given order |
-| `I_Currency` | SAP Standard CDS | READ (via assoc.) | Resolve currency description |
-
----
-
-### Annotations Explained
-
-| Annotation | Location | Effect |
-|---|---|---|
-| `@AccessControl.authorizationCheck: #CHECK` | View level | A DCL for `ZI_SalesOrder` **must exist**; access is denied if no matching DCL condition passes |
-| `@Search.searchable: true` | View level | Registers the view with the SAP Enterprise Search / SADL search framework |
-| `@Search.defaultSearchElement: true` | `CustomerIDForSearch` | This field is indexed as the primary fuzzy-match target |
-| `@Search.fuzzinessThreshold: 0.8` | `CustomerIDForSearch` | 80% match tolerance — typos and partial matches are accepted |
-| `@ObjectModel.text.element: ['_Customer.CustomerName']` | `CustomerIDForSearch` | Instructs UI to display customer name as the human-readable label for this ID |
-| `@Semantics.amount.currencyCode: 'CurrencyCode'` | `NetAmount` | Pairs the amount field with its currency — required for correct OData metadata and Fiori rendering |
-
----
-
-### Dependencies
-
-**Calls (depends on):**
-
-| Object | Type | Relationship |
-|---|---|---|
-| `zsales_order` | Database Table | Data source |
-| `ZI_Customer` | CDS View Entity | Association target |
-| `ZI_SalesOrderItem` | CDS View Entity | Association target |
-| `I_Currency` | SAP Standard CDS View | Association target |
-
-**Called by (likely consumers — verify with where-used):**
-
-Typical consumers of a `ZI_` interface view in this pattern would be:
-- `ZC_SalesOrder` — a consumption view adding UI annotations for Fiori
-- OData service definitions referencing this view
-- Other CDS views joining via the published associations
-
-> ⚠️ Where-used analysis was not run against the live system for this session. Run `sap_usage_references` on `ZI_SalesOrder` to get the confirmed caller list before making any changes to this view's field list or key structure.
-
----
-
-### Error Handling & Authorization
-
-- **No exception handling** — this is a declarative CDS view; runtime errors surface as SQL exceptions to the consumer.
-- **Authorization:** `#CHECK` means the framework looks for a DCL object named `ZI_SalesOrder`. If the DCL is missing or its conditions are never satisfied, **no data will be returned** without an explicit error message — a common silent failure. Confirm the DCL is active and correctly maintained.
-
----
-
-### Notes & Observations
-
-| # | Observation |
-|---|---|
-| 1 | **Dual `customer_id` fields** (`CustomerID` + `CustomerIDForSearch`) is a deliberate SAP VDM pattern — the search field carries annotations that would be inappropriate on a key field. This is correct but must be documented for consumers so they don't treat `CustomerIDForSearch` as a second key. |
-| 2 | **`I_Currency` is an SAP-delivered view** — coupling to standard content is intentional for currency semantics but means upgrades could theoretically affect the association if SAP changes `I_Currency`'s key field name. Low risk, worth noting. |
-| 3 | **No `@VDM.viewType` annotation is present** — adding `@VDM.viewType: #BASIC` would make the VDM role explicit and improve tooling support (e.g. ABAP Development Tools VDM explorer). |
-| 4 | **No client handling** — `zsales_order` is assumed to be client-dependent (standard for custom tables). Verify the table has a `client` field and that ABAP CDS implicit client handling is active, otherwise cross-client data leakage is possible in multi-client systems. |
-| 5 | **`[0..1]` on `_Customer`** — assumes one customer per order. If `customer_id` can be null (guest orders, etc.), the association cardinality is correct but consumers should handle the null navigation case. |

package/bench/results/abap-explain-bdef-handler/claude-haiku-4-5.md

@@ -1,112 +0,0 @@
-# abap-explain-bdef-handler — claude-haiku-4-5
-
-- **skill:** abap-explain
-- **description:** Explain a managed RAP behavior pool with a validation + determination
-- **latency:** 29022 ms
-- **input tokens:** 2
-- **output tokens:** 2,535
-- **cost:** $0.0127
-
----
-
-## abap-explain — lhc_salesorder behavior pool
-
-## TL;DR
-
-**Headline:** This is a behavior handler that enforces two automatic rules on sales orders: dates must not be in the past, and net amount must be calculated from quantity × unit price.
-
-**Top 3 (priority order — most important first):**
-1. **validateorderdate runs on SAVE and blocks invalid orders.** If order date is before today, the order fails validation and is rejected with an error message. The user cannot save.
-2. **determinenetamount runs on MODIFY and auto-calculates a field.** Whenever quantity or unit price changes, net amount is automatically recalculated and written back — the user does not manually enter it.
-3. **Both methods use LOCAL MODE, meaning they bypass authorization checks.** This is intentional for internal calculation but could be a security blind spot if sensitive logic depends on user permissions.
-
-**Verdict:** This is a straightforward and safe behavior handler. The only risk is that `determinenetamount` silently overwrites any manual entry to NetAmount — document this user-facing behavior.
-
----
-
-### What This Code Does
-
-This is a **behavior handler** — a behind-the-scenes enforcer for a sales order business object in SAP's modern application development framework (RAP, Restful ABAP Programming). It contains two rules:
-
-1. **Order dates cannot be in the past.** If someone tries to save an order dated yesterday, the save fails and an error message appears.
-2. **Net amount is automatically calculated.** Whenever quantity or unit price is entered or changed, the net amount (quantity × unit price) is computed and stored automatically. The user does not type it in.
-
-These rules execute transparently whenever the sales order is created or modified, whether via UI, API, or batch job.
-
----
-
-### Step by Step
-
-1. **Class declaration and inheritance**
-   This class (`lhc_salesorder`) inherits from `cl_abap_behav_handler`, which is SAP's base class for behavior handlers. Inheriting from this class registers this code as the enforcer for the sales order business object (`zr_salesorder`). The two METHODS declarations define *what* will happen; the IMPLEMENTATION section defines *how*.
-
-2. **validateorderdate: Entry point**
-   This method is triggered whenever a user tries to **SAVE** a sales order. The `FOR VALIDATE ON SAVE` phrase means "run this code during the save validation phase, before the database is actually written." The method receives a list of sales order keys (IDs) that are being saved.
-
-3. **validateorderdate: Read the order dates**
-   The method queries the sales order entity (`SalesOrder`) in LOCAL MODE — a special read mode that does not check user permissions — and retrieves only the `OrderDate` field for each sales order being saved. The results go into a temporary list `lt_orders`.
-
-4. **validateorderdate: Check each date**
-   For each order, the code compares its `OrderDate` to today's date [retrieved via `cl_abap_context_info=>get_system_date( )`]. If the order date is in the past (less than today), two things happen: (a) the order is marked as **failed** in the `failed-salesorder` list, and (b) an error message is added to the `reported-salesorder` list with the text "Order date must be today or in the future."
-
-5. **validateorderdate: Result**
-   When the method finishes, SAP checks the `failed` and `reported` tables. If any order is in `failed`, the save is **blocked** — the database is not written, and the user sees the error message. The user must correct the date and retry.
-
-6. **determinenetamount: Entry point**
-   This method is triggered whenever a user **MODIFIES** (creates or changes) a sales order. The `FOR DETERMINE ON MODIFY` phrase means "run this code after a change is made, to calculate or update derived fields." The method receives the list of sales order keys that were modified.
-
-7. **determinenetamount: Read quantity and unit price**
-   The method reads the `Quantity` and `UnitPrice` fields for each modified order. Again, LOCAL MODE is used, so no permission checks happen.
-
-8. **determinenetamount: Calculate net amount**
-   A temporary update list `lt_update` is created. For each order, the code multiplies `Quantity × UnitPrice` to get the net amount, and appends an update instruction to the list. The `%control-NetAmount = if_abap_behv=>mk-on` instruction tells SAP "include this field in the update." [INFERRED: `mk-on` stands for "mark on," meaning "process this field."]
-
-9. **determinenetamount: Write back to the entity**
-   The `MODIFY ENTITIES` statement applies all the calculated net amounts back to the sales orders in memory. The `FIELDS ( NetAmount )` clause tells SAP "only update this one field." The changes are committed to the in-memory entity state, so when the user saves, the net amount is already populated.
-
-10. **Return and chain**
-    Both methods return implicitly. If validation fails (step 5), the save stops. If validation passes and `determinenetamount` has recalculated net amounts, the save proceeds with the updated values.
-
----
-
-### SAP Concepts Explained
-
-| Term | What It Means |
-|------|--------------|
-| Behavior Handler | A class in SAP's modern application framework (RAP) that enforces business rules on an entity (like a sales order). It runs automatically during create, modify, and save operations without the application code having to call it explicitly. |
-| RAP (Restful ABAP Programming) | SAP's modern approach to building business applications. It separates the business logic (behavior handlers like this one) from the UI, so the same rules apply whether a user is using a web interface, a mobile app, or an API. |
-| FOR VALIDATE ON SAVE | A behavior method trigger that says "run this code during the save validation phase." It runs before the database write, giving the code a chance to reject invalid data. |
-| FOR DETERMINE ON MODIFY | A behavior method trigger that says "run this code whenever the entity is modified (created or changed)." Typically used to calculate derived fields or set defaults. |
-| READ ENTITIES OF | A RAP statement that fetches data from a business entity (like a view or table). It is the modern replacement for SELECT in behavior code. |
-| zr_salesorder | A data model object (CDS view) that defines the sales order entity structure. The "zr_" prefix indicates it is a custom object (not SAP standard). |
-| LOCAL MODE | A read/write mode that bypasses SAP's authorization checks. Used in behavior code so that automatic calculations and validations run regardless of the user's permissions. |
-| %tky | The technical key — a unique identifier (usually primary key fields) of an entity instance. Used to identify which specific sales order is being referenced. |
-| failed-salesorder | A structure SAP populates to mark which entities failed validation. If any entity is in this list at the end of validation, the save is rejected. |
-| reported-salesorder | A structure SAP populates with error messages to display to the user. Each entry includes the entity's key (%tky), the message text, and the severity (error, warning, info). |
-| MODIFY ENTITIES OF | A RAP statement that updates one or more entity instances in memory. Unlike a database UPDATE, this changes the in-memory state before the save. |
-| %control | A control structure that tells SAP which fields to include in an update. Setting `%control-NetAmount = if_abap_behv=>mk-on` means "include NetAmount in this update." |
-| if_abap_behv_message=>severity-error | A constant that marks a message as an error. Used in the reported structure to tell SAP this is a blocker, not a warning. |
-| cl_abap_context_info=>get_system_date( ) | A standard SAP class method that returns today's date in the system. Used here for date comparisons. |
-
----
-
-### Key Things to Know
-
-1. **Validation blocks the save; determination does not.** If `validateorderdate` marks an order as failed, the entire save is aborted — nothing is written to the database. If `determinenetamount` calculates a field, the value is always applied silently; there is no "reject" path. This is the intended behavior for business rules: validations are gates, determinations are auto-fills.
-
-2. **Determination overwrites manual entry.** If a user manually enters a net amount and then changes the quantity, `determinenetamount` will recalculate and overwrite that entry. Document this in the UI — users may expect the field to be editable, but it is effectively read-only because it is always recalculated.
-
-3. **LOCAL MODE bypasses all authorization.** Both methods read and write in LOCAL MODE, meaning they ignore AUTHORITY-CHECKs. This ensures the rules apply to all users equally. However, if sensitive calculations (e.g., discount logic, cost center assignment) are added to this handler, they will also bypass permission checks — use normal (non-LOCAL) mode for those and add explicit AUTHORITY-CHECKs.
-
-4. **Order of execution matters.** `validateorderdate` runs during the SAVE phase (after all MODIFYs are done), so it validates the final state. `determinenetamount` runs during each MODIFY phase, so it recalculates net amount as soon as quantity or price changes. This is the correct order: calculate first, then validate the result.
-
-5. **No error handling for date edge cases.** The code uses `<` (less than) to check if the date is in the past. A date exactly equal to today passes validation. Dates in the future always pass. If the system date is NULL or invalid, the comparison might not behave as expected — no explicit error handling is in place. [INFERRED: This is acceptable for most SAP systems, where the system date is always set correctly.]
-
-6. **The messages are hardcoded, not translated.** The error message "Order date must be today or in the future" is English text baked into the code. For a production system, consider using message classes and message numbers for multi-language support.
-
----
-
-### What Was Not Analyzed
-- The CDS view definition for `zr_salesorder` was not provided. The exact fields (OrderDate, Quantity, UnitPrice, NetAmount) and their types (date, decimal, etc.) are assumed based on usage in the code, but their definitions and constraints were not examined.
-- No parent behavior definitions or additional derived behavior handlers were provided. The sales order entity may have other rules defined elsewhere that interact with these two methods.
-- The UI layer (Fiori app, Web Dynpro, OData consumer) is not visible. How the user experiences the validation error and the silent net amount recalculation depends on the UI implementation.