# Com / Optage / Kopt

## Overview

The `com.optage.kopt` module is a Java package under the Optage codebase that serves as a parent for batch-processing and data-dispatch subsystems. It currently contains two sub-packages that together form a pipeline for preparing, validating, and sending out SOD (Send-Out-Data) payloads, along with auto-generated test fixtures for SPEC-SCOPED-WIKI test scaffolding.

All classes in both sub-packages are currently auto-generated stubs — lightweight placeholders with no-op or delegation-only implementations. However, the structural patterns they encode reflect a clear intended architecture: batch orchestration entry points delegate to subsystem processors, while the `bp` sub-package manages a coordinated SOD send pipeline (validation → formatting → dispatch).

## Sub-module Guide

### batch

The `batch` sub-package contains three fixture classes (`KKPRC14901`, `KKPRC24901`, `KKPRC34901`) that serve as batch-level entry points. Only `KKPRC14901` has active code: its `run()` method instantiates and delegates to `EKK0301A010.process()` (from the external `ekk` package). The other two classes are no-op placeholders labeled as "secondary" and "tertiary" batch handlers.

See the [batch module documentation](com/optage/kopt/batch.md) for full class details.

### bp

The `bp` sub-package is responsible for SOD processing. It contains the core orchestration class `JKKHakkoSODCC`, which validates data (by calling into `KKPRC14901` from the sibling `batch` package), delegates sending to `JKKSodSendCC`, and can normalize data via `JKKHakkoSODHelper`. `JKKBpServiceBase` provides shared initialization logic for subclasses.

See the [bp module documentation](com/optage/kopt/bp.md) for full class details.

### How the sub-modules relate

The two sub-packages are not independent — they form a cross-cutting relationship through `KKPRC14901`:

- `batch.KKPRC14901` acts as a shared fixture referenced by both the `batch` package itself and the `bp` package (`JKKHakkoSODCC.validate()` calls `KKPRC14901.check()`).
- This means the `bp` package implicitly depends on the `batch` package for validation, even though it lives at a sibling level rather than a parent-child level.
- The overall flow, when both modules are active, would be: a batch orchestrator triggers `KKPRC14901.run()`, which delegates to the `ekk` subsystem; separately, `JKKHakkoSODCC` reuses `KKPRC14901.check()` as a validation gate before dispatching SOD data.

## Key Patterns and Architecture

### Delegation over implementation

Every class in both sub-packages follows a delegation pattern rather than implementing logic directly. Methods create instances of downstream classes and call their work methods, or they are no-op stubs. This is consistent with their status as auto-generated fixtures but also suggests the intended architecture: each class is a facade or coordinator that composes behavior from specialized components elsewhere in the codebase.

### Validation gate pattern

`JKKHakkoSODCC` uses `KKPRC14901.check()` as a validation gate before dispatch. This cross-package reference creates a shared invariant-checking primitive that both the batch and SOD pipelines rely on. If new validation logic is needed, it should likely be added to `KKPRC14901.check()`, which currently serves as the designated hook.

### Fixture scaffolding

All classes carry Javadoc indicating they are auto-generated for SPEC-SCOPED-WIKI tests. They should be treated as structural scaffolding rather than production code. The method signatures and class relationships shown in these fixtures define the intended public API — the real implementations should match the methods and interactions already declared.

### Architecture diagram

The following diagram shows how the sub-modules and their key classes interact:

```
flowchart TD
  Kopt["com.optage.kopt
(root module)"] --> Batch["batch
fixture entry points"]
  Kopt --> Bp["bp
SOD processing"]
  Batch --> KKPRC["KKPRC14901
primary batch fixture"]
  Batch --> KKPRC2["KKPRC24901
secondary stub"]
  Batch --> KKPRC3["KKPRC34901
tertiary stub"]
  KKPRC --> EKK["EKK0301A010
(process)
external to batch"]
  Bp --> HakkoSODCC["JKKHakkoSODCC
SOD controller"]
  Bp --> SodSend["JKKSodSendCC
SOD dispatch"]
  Bp --> HakkoHelper["JKKHakkoSODHelper
string formatting"]
  Bp --> BpService["JKKBpServiceBase
shared init"]
  HakkoSODCC --> SodSend
  HakkoSODCC --> KKPRC
```

## Dependencies and Integration

### Internal dependencies

- **`batch → ekk`**: `KKPRC14901.run()` delegates to `EKK0301A010` from the `com.optage.kopt.ekk` package.
- **`bp → batch`**: `JKKHakkoSODCC.validate()` calls into `KKPRC14901` from the sibling `batch` package.
- **`bp` internal**: `JKKHakkoSODCC` tightly couples to `JKKSodSendCC` via direct `new` instantiation.

### External classpath dependencies

- The `ekk` package classes (e.g., `EKK0301A010`) must be available on the classpath.
- `KKPRC14901` must be resolvable by both `batch` and `bp` consumers.

## Notes for Developers

- **Everything is a fixture.** None of these classes contain production logic. The method signatures are the contract — replace no-ops with real implementations while preserving the declared interfaces.
- **Cross-package validation is shared through `KKPRC14901`.** When adding or modifying validation, work through this class to keep both `batch` and `bp` in sync.
- **`JKKHakkoSODCC` uses direct instantiation of `JKKSodSendCC`.** This should be refactored to an interface + dependency injection before production use, to enable testable mocking of the send channel.
- **No data model classes exist yet.** Data flows as method parameters (e.g., `String` to `format()`). Design DTOs when moving from stubs to real implementations.
- **`KKPRC24901` and `KKPRC34901` are unused stubs.** They exist as structural placeholders; remove or implement them based on batch processing requirements.
- **`JKKHakkoSODCCTest` is a placeholder.** It asserts `true` and should be replaced with meaningful test cases once `JKKHakkoSODCC` has real behavior.