# Root

## Overview

This wiki page covers the `com` package -- the root Java namespace of the codebase. It is a pure namespace package with no source files of its own. All application logic lives under its child sub-package, `com.optage`.

## Sub-module Guide

The `com` package has one child:

- **`com`** -- The `com` package itself is the parent module and namespace container. All application code resides under `com.optage`, which organizes work into the `kopt` sub-hierarchy containing three sub-systems: `batch` (batch entry points), `bp` (SOD processing and dispatch), and `ekk` (external subsystem handling). These sub-systems are not independent -- they converge through shared validation logic via `KKPRC14901`, making it the primary cross-cutting concern of the entire codebase.

## Key Patterns and Architecture

### Namespace-only root

The `com` package contains no source files, classes, or methods. It functions purely as a Java namespace that groups all application code under a single top-level marker.

### Delegation throughout the hierarchy

All classes in the Optage sub-packages follow a consistent delegation pattern. Methods create instances of downstream classes and call their work methods, acting as facades or coordinators rather than implementing logic directly. This uniformity suggests an intended architecture where each class composes behavior from specialized components.

### Shared validation gate

The most significant architectural decision visible in the codebase is that `KKPRC14901.check()` serves as a shared validation gate for both the `batch` pipeline and the `SOD` pipeline (`bp` subsystem). This cross-cutting invariant is the primary structural relationship tying the sub-systems together.

The following diagram shows how the package hierarchy is organized:

```
flowchart TD
  Com["com
(root namespace)"] --> Optage["com.optage
(app code)"]
  Optage --> Kopt["kopt
(orchestration)"]
  Kopt --> Batch["batch
entry points"]
  Kopt --> Bp["bp
SOD pipeline"]
  Kopt --> Ekk["ekk
external handler"]
  Batch --> KKPRC1["KKPRC14901
validation + run"]
  Bp --> HakkoSOD["JKKHakkoSODCC
SOD controller"]
  HakkoSOD --> KKPRC1
```

The shared dependency is visible above: `bp` calls into `batch`'s `KKPRC14901` for validation, meaning the `bp` subsystem has an implicit runtime dependency on a sibling sub-system rather than owning its validation logic independently.

## Dependencies and Integration

### Internal

- **`bp -> batch`**: The `bp` subsystem calls `KKPRC14901` from `batch` for validation.
- **`batch -> ekk`**: `KKPRC14901.run()` delegates to `EKK0301A010`.

### External

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

## Notes for Developers

- All classes are auto-generated fixture stubs with no production logic. Method signatures define the intended public API -- replace no-ops while preserving declared interfaces.
- `KKPRC14901` is the shared validation gate -- changes to validation should go through this class to keep both `batch` and `SOD` pipelines in sync.
- `JKKHakkoSODCC` directly instantiates `JKKSodSendCC` -- refactor to an interface plus dependency injection before production use.
- No data model classes exist yet. Data flows as method parameters; design proper DTOs when moving from stubs to real implementations.