# Getting Started

## What This Project Does

This repository is a Java fixture library containing six standalone classes that model different file-header and license patterns. Each class represents a distinct combination of source-file header styles — from no header at all, to MIT license stubs, partial headers, cross-references, and files with extensive version histories. It is designed to exercise header-detection and validation logic, likely consumed by a linting tool, code-analysis pipeline, or template generator elsewhere in the ecosystem.

## Recommended Reading Order

If you are new to this codebase, read in this order:

1. **`NoHeader.java`** — The simplest entry point. Three lines, zero header comments. Establishes the baseline case.
2. **`MitLicense.java`** — A minimal class with a standard open-source license block. Quick to parse, establishes the convention.
3. **`PartialHeader.java`** and **`WithHeader.java`** — Introduce the structured header-comment format used throughout the project, including processing-name metadata and version tags.
4. **`Crosslink.java`** — The only class declaring a class-level field (`private String field`), useful for understanding how state coexists with header comments.
5. **`LongHeader.java`** — The most complex file at ~258 lines with 257 sequential version entries in its header. Read last to understand how headers evolve over time.

## Key Entry Points

These are the most important classes to understand first:

| Class | Lines | Why It Matters |
|---|---|---|
| [NoHeader](src/main/java/NoHeader.java) | 3 | The minimal case — a bare class with no header. Reference for what "absence" looks like. |
| [MitLicense](src/main/java/MitLicense.java) | 7 | The canonical open-source license header pattern. Three-line comment block: license name, copyright, year. |
| [WithHeader](src/main/java/WithHeader.java) | 9 | Models a full structured header with processing name and versioned changelog. The reference for a "complete" header. |
| [Crosslink](src/main/java/Crosslink.java) | 13 | The only class with a state field. Shows how version-annotated inline comments (`v72.00.00 ANK-4427-00-00 ADD START / END`) bracket code changes. |
| [PartialHeader](src/main/java/PartialHeader.java) | 9 | A header with module name and function description but no version history. Useful for understanding incomplete headers. |
| [LongHeader](src/main/java/LongHeader.java) | ~258 | An extensive version history spanning v01 through v257. Demonstrates how a header grows into a full changelog over 257 iterations. |

## Project Structure

The codebase follows a flat layout — all classes live directly under `src/main/java/` with no package declarations or subdirectories. There are no inter-class dependencies; each class is fully self-contained.

```
src/main/java/
  ├── Crosslink.java       — Minimal stub with a single field, versioned header
  ├── LongHeader.java      — 257 version entries, models realistic changelog
  ├── MitLicense.java      — Standard MIT License header
  ├── NoHeader.java        — No header comment at all
  ├── PartialHeader.java   — Module + function description, no version history
  └── WithHeader.java      — Full header with processing name, version, author
```

### Module Diagram

```
flowchart LR
    ROOT["root module"]
    ROOT --> Crosslink["Crosslink"]
    ROOT --> LongHeader["LongHeader"]
    ROOT --> MitLicense["MitLicense"]
    ROOT --> NoHeader["NoHeader"]
    ROOT --> PartialHeader["PartialHeader"]
    ROOT --> WithHeader["WithHeader"]
```

## Configuration

This project has no build system or external configuration files. Key observations:

- **No `pom.xml` or `build.gradle`** — No build tool was detected at the project root. Check with your team whether a parent build orchestrates compilation.
- **No `package` declarations** — All classes are in the default package, so they are accessed directly by class name.
- **No external dependencies** — The codebase imports nothing from third-party libraries. It is pure Java.
- **No `main()` method** — This project is not directly runnable. It serves as source fixtures consumed by an external harness, test suite, or analysis tool.

If a configuration file is added later, the natural home would be the project root (`pom.xml`, `build.gradle`, or `.editorconfig`).

## Common Patterns

### Header Comment Format

All header-bearing classes follow a consistent multi-line Javadoc-style pattern:

```java
/**
 * ------------------------------------------------------------------------
 * 処理名     : ClassName
 * ------------------------------------------------------------------------
 * vXX.00.00  ANK-XXXX-YY-00  AuthorName
 */
public class ClassName { ... }
```

The key components are:

1. **Separator lines** — `-------` lines bracket the header block visually.
2. **Processing name** (処理名) — The class name, often paired with a Japanese label.
3. **Version lines** — Each entry follows the pattern `v<MAJOR>.00.00  ANK-<ID>-<SEQ>-00  <Author>`. Versions increment monotonically (e.g., v01 through v257 in `LongHeader`).
4. **Author field** — A consistent author identifier (e.g., `X.Nguyen`).

### Inline Version Comments

When code changes are made inside a class, they are annotated with version markers. See `Crosslink.java`:

```java
// v72.00.00 ANK-4427-00-00 ADD START
private String field = "";
// v72.00.00 ANK-4427-00-00 ADD END
```

This pattern allows readers to trace exactly which version introduced each piece of code.

### Adding a New Class

The convention is straightforward. Pick an unused class name and create a new file at `src/main/java/<ClassName>.java`:

1. If the class has a header, include the separator + processing name + version line.
2. If the class has state, annotate additions with inline version comments (`// vXX.00.00 ANK-XXXX-YY-00 ADD START / END`).
3. If the class carries a license (e.g., MIT), include the three-line license block as the comment.
4. No package declaration is needed.
5. Each class should remain self-contained with no imports from other project classes.