# Repository Overview

Welcome to the **KOPT** project — a Java-based library built as part of the Optage platform. This repository contains a collection of modules handling batch operations, Start-of-Day (SOD) processing coordination, contract processing, and service control. If you're new here, you've come to the right place: this page will orient you to the codebase structure, explain how the pieces fit together, and point you toward the best places to start reading.

## Overview

This project is a Maven-based Java library (`com.optage.kopt:optage-mini-fixture`) that provides scaffolding and fixture classes for the KOPT system. The codebase is organized under the `com.optage.kopt` package and covers several functional areas:

- **Batch processing** — entry-point classes invoked by schedulers to kick off operations
- **SOD (Start of Day) coordination** — dispatching, validation, and helper logic for daily batch workflows
- **Contract processing** — entry points for contract-related operations with downstream notification
- **Data transfer objects** — lightweight request/response structures for SOD operations
- **Service control** — utility classes for service-level management

All classes in this repository are currently auto-generated test fixtures (marked with `SPEC-SCOPED-WIKI`), meaning they serve as structural scaffolds for testing and documentation generation rather than production-ready business logic.

## Technology Stack

| Category | Technology |
|---|---|
| **Language** | Java |
| **Build Tool** | Maven (no dependencies declared — this is a standalone fixture) |
| **Testing** | JUnit 4 (used by `JKKHakkoSODCCTest`) |
| **Packaging** | JAR |

No well-known external frameworks were detected from import analysis. This is a minimal, self-contained codebase.

## Architecture

The KOPT system follows a modular architecture with clear separation of concerns. Each package under `com.optage.kopt` owns a specific functional domain and communicates with others through explicit cross-package references.

```mermaid
flowchart TD
    subgraph KOPT["com.optage.kopt"]
        B["batch<br/>Batch entry points"]
        BP["bp<br/>SOD processing"]
        DTO["dto<br/>Data objects"]
        EKK["ekk<br/>Contract processing"]
        ESC["esc<br/>Service control"]
        KKW["kkw<br/>Batch trigger"]
    end
    B -->|"invokes"| EKK
    BP -->|"dispatches"| SOD["JKKSodSendCC"]
    BP -->|"validates via"| KKPRC["KKPRC14901"]
    KKPRC -.->|"also in"| B
    EKK -->|"notifies"| KKW
    DTO -->|"consumed by"| BP
    DTO -->|"consumed by"| KKW
```

### Key architectural notes

- **Entry-point pattern.** The `batch` package provides classes with `run()` methods designed to be invoked externally by a scheduler or job framework.
- **Delegation over monoliths.** Each class owns a single responsibility and delegates to others — for example, `JKKHakkoSODCC` orchestrates SOD operations by delegating to `JKKSodSendCC` (dispatch) and `KKPRC14901` (validation).
- **DTOs are shared.** The `dto` package defines lightweight data structures consumed across multiple modules.
- **Cross-module links are intentional but minimal.** The graph shows 58 edges across 65 nodes, indicating a well-connected but not overly coupled design.

## Module Guide

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

This package contains three batch runner classes: `KKPRC14901`, `KKPRC24901`, and `KKPRC34901`. These serve as the top-level execution points for batch operations, each exposing a `run()` method designed to be invoked by an external scheduler.

`KKPRC14901` is the only wired runner — its `run()` method instantiates `EKK0301A010` and delegates to its `process()` method, bridging the batch layer to the contract processing logic. It also provides a `check()` method intended as a pre-flight validation hook (currently a no-op). The other two classes (`KKPRC24901` and `KKPRC34901`) are stub scaffolds awaiting future implementation.

### `com.optage.kopt.bp` — Start of Day Processing

The `bp` package handles SOD processing coordination. Its central class, `JKKHakkoSODCC`, acts as a facade: `dispatch()` creates a `JKKSodSendCC` instance and calls `send()`, while `validate()` delegates to `KKPRC14901.check()` for batch validation.

Supporting classes include `JKKBpServiceBase` (a base class providing shared initialization via `baseInit()`), `JKKSodSendCC` (owning the sending mechanics), and `JKKHakkoSODHelper` (providing utility methods like string formatting). A JUnit 4 test fixture, `JKKHakkoSODCCTest`, exercises this module.

### `com.optage.kopt.ekk` — Contract Processing

The `ekk` package provides fixture classes for contract processing: `EKK0301A010` and `EKK0301A020`. Both expose a `process()` method (currently a no-op stub). `EKK0301A010` also has a `notify()` method that reaches into the `kkw` package to trigger `KKW0100B001`, establishing the primary cross-module call chain in the codebase.

### `com.optage.kopt.kkw` — Batch Trigger

This package contains `KKW0100B001`, a minimal fixture class with a single `trigger()` method. It is the leaf node in the module dependency tree — imported by `ekk` but importing nothing itself. Classes here follow a `KKW<Spec><Instance>` naming convention.

### `com.optage.kopt.dto` — Data Transfer Objects

Defined in the sibling `dto` package and consumed by `bp` and `kkw`, this module provides two lightweight structures:

- `JKKSodRequestDTO` — carries SOD request data (`tenantId`, `serviceId`)
- `JKKSodResponseDTO` — carries SOD response data (`status`, `message`)

### `com.optage.kopt.esc` — Service Control

The `esc` package contains `ESC0101B001`, a class with a `control()` method for service-level management. This is a standalone fixture with no detected dependencies on or from other modules.

## Getting Started

If you're new to this codebase, here is a recommended reading order:

1. **`pom.xml`** — Confirms this is a Maven project, artifact `optage-mini-fixture`, with no external dependencies.
2. **`com.optage.kopt.batch/KKPRC14901.java`** — The most complete batch entry point; shows how schedulers invoke the system.
3. **`com.optage.kopt.ekk/EKK0301A010.java`** — The contract processing class that `KKPRC14901` delegates to; follows the same lightweight pattern.
4. **`com.optage.kopt.bp/JKKHakkoSODCC.java`** — The SOD orchestrator; demonstrates the delegation pattern used across the codebase.
5. **`com.optage.kopt.bp/JKKSodSendCC.java`** — The dedicated sending logic, showing how concerns are separated.
6. **`com.optage.kopt.dto/JKKSodRequestDTO.java`** and **`JKKSodResponseDTO.java`** — The shared data structures.
7. **`com.optage.kopt.kkw/KKW0100B001.java`** — The leaf trigger class, completing the call chain from `batch` -> `ekk` -> `kkw`.
8. **Test class `JKKHakkoSODCCTest.java`** — Shows how tests are structured in this repository.

### Class relationships at a glance

```mermaid
flowchart LR
    Sched["External Scheduler"] --> BP["JKKHakkoSODCC"]
    BP -->|"dispatch"| Send["JKKSodSendCC"]
    BP -->|"validate"| KKP["KKPRC14901"]
    KKP -->|"runs"| EKK["EKK0301A010"]
    EKK -->|"notify"| KKW["KKW0100B001"]
```

### Key classes to know

| Class | Location | Role |
|---|---|---|
| `KKPRC14901` | `batch` | Primary batch entry point, invokes contract processing |
| `JKKHakkoSODCC` | `bp` | SOD orchestrator (dispatch + validate) |
| `JKKSodSendCC` | `bp` | SOD dispatch logic |
| `EKK0301A010` | `ekk` | Contract processing entry point |
| `KKW0100B001` | `kkw` | Downstream batch trigger |
| `JKKSodRequestDTO` | `dto` | SOD request data carrier |
| `JKKSodResponseDTO` | `dto` | SOD response data carrier |