# Com / Optage / Kopt / Ekk

## Overview

The `com.optage.kopt.ekk` package provides contract processing capabilities for the Optage Kopt module. It contains fixture classes that handle contract-related operations, with one class responsible for primary contract processing and triggering downstream notifications to the `kkw` package, and another providing a secondary contract handling path.

## Key Classes and Interfaces

### [EKK0301A010](src/main/java/com/optage/kopt/ekk/EKK0301A010.java)

The primary contract processing class in the EKK package. It serves two responsibilities:

- **Contract processing** via `process()` — the entry point for handling a contract. This is a no-op placeholder that represents where contract processing logic would be implemented.

- **Notification** via `notify()` — triggers a downstream operation by instantiating and calling `KKW0100B001.trigger()` from the `com.optage.kopt.kkw` package. This class acts as the bridge between EKK contract operations and the KKW subsystem.

```java
public class EKK0301A010 {

  public void process() { /* Contract processing */ }

  public void notify() {
    new KKW0100B001().trigger();
  }
}
```

### [EKK0301A020](src/main/java/com/optage/kopt/ekk/EKK0301A020.java)

The secondary contract handling class. It provides an independent contract processing path via its `process()` method, described in-code as "Secondary EKK contract." Unlike EKK0301A010, this class does not depend on or trigger any downstream subsystems.

```java
public class EKK0301A020 {

  public void process() { /* Secondary EKK contract */ }
}
```

## How It Works

A typical contract processing flow through the EKK package follows one of two paths:

1. **Primary flow** (`EKK0301A010`):
   - `process()` is called to begin contract processing.
   - `notify()` is called to alert downstream systems by triggering `KKW0100B001`.
   - The `KKW0100B001` class (in `com.optage.kopt.kkw`) handles the notification externally.

2. **Secondary flow** (`EKK0301A020`):
   - `process()` is called to handle a secondary contract independently, with no downstream side effects.

Both classes are currently auto-generated fixture stubs for SPEC-SCOPED-WIKI testing. The actual contract processing logic is expected to be implemented in these methods as development progresses.

## Dependencies and Integration

This package depends on:

- **`com.optage.kopt.kkw`** — The `KKW0100B001` class is imported and instantiated by `EKK0301A010.notify()`. This creates a unidirectional dependency from EKK to KKW.

```mermaid
flowchart LR
    subgraph EKK["EKK Package"]
        EKK0301A010["EKK0301A010"]
        EKK0301A020["EKK0301A020"]
    end
    subgraph KKW["KKW Package (com.optage.kopt.kkw)"]
        KKW0100B001["KKW0100B001"]
    end
    EKK0301A010 -->|triggers| KKW0100B001
```

## Notes for Developers

- These classes are auto-generated fixture stubs for SPEC-SCOPED-WIKI tests. The method bodies are currently empty placeholders (comments only), so real business logic needs to be added during implementation.
- The naming convention `EKK0301A010` and `EKK0301A020` follows a structured identifier pattern consistent with the rest of the Kopt module.
- **Extension point**: New contract processing logic should be added to the `process()` methods of both classes. If additional downstream integrations are needed, follow the pattern used in `EKK0301A010.notify()` by instantiating the target class and calling its entry method.
- **No child subpackages**: This package contains only these two classes and does not branch into further submodules.