# Com / Optage / Kopt

## Overview

The `com.optage.kopt` package serves as the root namespace for a batch processing subsystem within the Optage platform. It encompasses automated start-of-day (SOD) generation and dispatch workflows, general-purpose batch entry points, and the scaffolding for future batch processing categories. The code is organized under two sibling sub-packages — `com.optage.kopt.batch` and `com.optage.kopt.bp` — each with distinct responsibilities.

At a high level, this module appears to be a fixture layer for the SPEC-SCOPED-WIKI test framework. The classes are auto-generated stubs that model the structure and execution flow of a production batch system rather than implementing substantive business logic themselves. The `bp` package (short for Batch Processing) focuses on the SOD generation and dispatch lifecycle, while the `batch` package provides generic batch orchestrators that delegate to domain-specific handlers in sibling packages like `ekk` and `kkw`.

## Sub-module Guide

### `com.optage.kopt.bp` — Batch Processing (SOD Flow)

This package is the more functionally developed of the two. It centers on **Start of Day (SOD) generation and dispatch** — a common pattern in financial systems where end-of-day processes produce data that must be validated, formatted, and dispatched at the start of the next business day.

The package contains five classes:

- **`JKKHakkoSODCC`** — The central controller ("Hakko" means "generation" in Japanese). It orchestrates the entire SOD workflow by delegating to a send controller, a validation handler, and a formatting helper. This is the entry point callers interact with.
- **`JKKSodSendCC`** — The send controller responsible for the actual SOD dispatch logic. Currently a stub, but designed to carry the core business logic for transmitting or writing out SOD results.
- **`JKKHakkoSODHelper`** — A utility class providing string formatting (currently just whitespace trimming).
- **`JKKBpServiceBase`** — A base service class with a protected `baseInit()` method intended to be overridden by subclasses in the broader batch processing hierarchy.
- **`JKKHakkoSODCCTest`** — A JUnit test stub exercising the controller.

The SOD flow proceeds as: `dispatch()` triggers `JKKSodSendCC.send()`, while `validate()` delegates to `KKPRC14901.check()` in the sibling `batch` package.

### `com.optage.kopt.batch` — Batch Entry Points

This package provides lightweight, auto-generated batch entry points following a delegator pattern. Three classes exist:

- **`KKPRC14901`** — The primary batch handler with meaningful logic. Its `run()` method instantiates `EKK0301A010` from the `com.optage.kopt.ekk` package and calls `process()`, making it the main orchestrator that funnels work to contract processing logic. It also has a `check()` method that is currently a no-op stub.
- **`KKPRC24901`** — A secondary batch placeholder. The `run()` method is empty and reserved for future secondary batch processing.
- **`KKPRC34901`** — A tertiary batch placeholder with an identical empty `run()` method.

The batch classes follow a naming convention: `KKPRC` followed by a numeric suffix where `1xx01` encodes the primary role, `2xx01` the secondary, and `3xx01` the tertiary.

### How the Sub-modules Relate

The two packages form a layered architecture where `bp` sits conceptually above `batch`:

1. The `bp` package's `JKKHakkoSODCC` delegates validation to `KKPRC14901` in the `batch` package. This creates a cross-package flow from the SOD controller down into the batch orchestrator.
2. The `batch` package, in turn, delegates actual processing work to even lower-level packages (`ekk` for contract processing, `kkw` for downstream handlers).
3. `JKKBpServiceBase` in `bp` provides a base class hook that the broader batch processing framework can extend, tying the SOD-specific logic back into the general batch infrastructure.

This creates a cascading delegation chain:

```
JKKHakkoSODCC (bp - SOD controller)
    ├── dispatch() → JKKSodSendCC (bp - send logic)
    ├── validate() → KKPRC14901 (batch - validation)
    │                     └── run() → EKK0301A010 (ekk - contract processing)
    │                                   └── notify() → KKW0100B001 (kkw - downstream handler)
    └── formatting → JKKHakkoSODHelper (bp - string utilities)
```

## Key Patterns and Architecture

### Delegator / Facade Pattern

Both packages employ a thin delegator pattern. Classes act as facades or entry points that hand off work to domain-specific handlers rather than containing business logic themselves. This keeps each layer focused on orchestration while delegating substantive work to dedicated subpackages (`ekk`, `kkw`).

### Auto-Generated Fixture Classes

All classes in both packages carry the Javadoc annotation "auto-generated fixture class(es) for SPEC-SCOPED-WIKI tests." They are structural scaffolding — minimal stubs designed to exercise the documentation and test generation pipeline, not production code. Manual edits to class bodies will be overwritten by regeneration. Comments around stubs are acceptable for documenting intended behavior.

### SOD-Centric Workflow in `bp`

The `bp` package is organized around the Start of Day lifecycle, a well-known pattern in financial systems. The separation of dispatch (`JKKSodSendCC`) from validation (`KKPRC14901`) and formatting (`JKKHakkoSODHelper`) follows the single-responsibility principle at the class level, with the controller (`JKKHakkoSODCC`) coordinating the steps.

### Hierarchical Service Base

`JKKBpServiceBase` in the `bp` package provides a protected initialization hook (`baseInit()`). The visibility modifier indicates it is intended to be subclassed — either within this package or by external code — suggesting the batch processing framework may grow a deeper inheritance hierarchy over time.

### Module Interaction Diagram

```mermaid
flowchart TD
    subgraph batch["com.optage.kopt.batch"]
        K1["KKPRC14901
Primary Batch"]
        K2["KKPRC24901
Secondary Batch"]
        K3["KKPRC34901
Tertiary Batch"]
    end
    subgraph bp["com.optage.kopt.bp"]
        HK["JKKHakkoSODCC
SOD Controller"]
        S["JKKSodSendCC
Send Controller"]
        V["JKKHakkoSODHelper
Formatting"]
        BS["JKKBpServiceBase
Base Service"]
    end
    subgraph ekk["com.optage.kopt.ekk"]
        E["EKK0301A010
Contract Processing"]
    end
    subgraph kkw["com.optage.kopt.kkw"]
        G["KKW0100B001
Downstream Handler"]
    end
    HK --> S
    HK --> V
    BS -.-> HK
    HK --> K1
    K1 --> E
    E --> G
```

The diagram shows the complete cross-package delegation chain: the SOD controller in `bp` coordinates internal send logic, formatting, and validation (via `batch`), while the batch layer further delegates to `ekk` for contract processing and ultimately `kkw` for downstream handling.

## Dependencies and Integration

### Internal Package Dependencies

| Dependency | Package | Role |
|---|---|---|
| `KKPRC14901` | `com.optage.kopt.batch` | Validation called by `JKKHakkoSODCC.validate()` |
| `JKKSodSendCC` | `com.optage.kopt.bp` | Send logic delegated by `JKKHakkoSODCC.dispatch()` |
| `JKKHakkoSODHelper` | `com.optage.kopt.bp` | String formatting utility |
| `JKKBpServiceBase` | `com.optage.kopt.bp` | Base service for subclassing |

### External Package Dependencies

| Dependency | Package | Role |
|---|---|---|
| `EKK0301A010` | `com.optage.kopt.ekk` | Contract processing — target of `KKPRC14901.run()` |
| `KKW0100B001` | `com.optage.kopt.kkw` | Downstream handler — triggered by `EKK0301A010.notify()` (transitive) |

### Integration Notes

- The `bp` package depends on `batch`, forming a one-directional cross-package dependency. There are no reverse dependencies.
- The `batch` package extends this chain further into `ekk` and `kkw`, creating a multi-level delegation architecture that cascades outward from this root package.
- No incoming dependencies from other modules were detected in the index, suggesting this is a leaf subsystem — work originates here and flows outward, not the reverse.

## Notes for Developers

- **These are fixture classes, not production code.** All classes are auto-generated for the SPEC-SCOPED-WIKI test framework. Do not manually edit class bodies; regenerations will overwrite them. Comments documenting intended behavior are acceptable.
- **Most methods are no-op stubs.** `KKPRC24901` and `KKPRC34901` have empty `run()` methods. `JKKSodSendCC.send()` is a placeholder. `JKKHakkoSODCCTest.testMain()` uses a no-op assertion. Implement actual logic when the corresponding business requirements materialize.
- **`KKPRC14901.check()` is a no-op.** If the test harness expects validation logic here, add it.
- **Instantiation is eager and un-injected.** `KKPRC14901.run()` creates `new EKK0301A010()` inline, and `JKKHakkoSODCC.dispatch()` creates `new JKKSodSendCC()` inline. If performance becomes an issue or mocking is needed for testing, consider making instances injectable.
- **Japanese naming convention.** The package follows a convention common in legacy financial systems: "Hakko" = generation, "SOD" = Start of Day, `CC` suffix = Controller/Command class.
- **Batch category numbering.** The `KKPRC` + numeric pattern encodes processing priority: `1xx01` is primary, `2xx01` secondary, `3xx01` tertiary. To add a new category, create a new class following the same pattern.
- **Extension point via `JKKBpServiceBase`.** If the batch processing framework grows a deeper inheritance hierarchy, `baseInit()` is the hook for custom initialization logic.
- **`batch` has three stubs; `bp` has five classes.** The `bp` package is more structurally developed, suggesting it may be closer to production readiness or represent a more mature area of the system.