core-builder

Core Builder — Feature Implementation

Philosophy: Integration Point First, Then Build Outward

Each feature starts at its integration point — the exact place where the new feature connects to the existing system. The source project may be in any language (Python, Go, Rust, Node.js, C#, Ruby, Java, etc.) — the output is always simplified Java. The implementation follows the same direction a contributor would: "I see where this feature plugs in, I want to understand what supporting code makes it work, so I trace outward from the integration point."

This produces two artifacts, one truth:

1. Working Java code in src/ — compiles, tests pass, is the source of truth
2. Rich tutorial chapter in core-docs/ — reads back actual source files, never diverges, enriched with ★ Insight blocks and Mermaid diagrams at every design decision

Every integration point choice, simplification decision, technology mapping choice, and design pattern is a teaching moment. The learner doesn't just see WHAT was built — they understand WHY each choice was made, how the source language's idioms were translated to Java, and what alternatives were considered.

MANDATORY: Use Extended Thinking

Use extended thinking before implementing. The quality of the implementation depends on deep upfront reasoning about both the real source project and the simplified Java version. Before writing any code:

• Study the source project's implementation of this feature end-to-end (in whatever language it's written in)
• Identify the integration point — the exact seam where this feature connects to the existing system
• Plan the technology mapping — how source language constructs translate to Java (e.g., goroutines to threads/executors, Python generators to Java iterators, Rust traits to Java interfaces)
• Plan the simplified class mapping — which source types to keep, merge, skip, or hardcode
• Design the build sequence starting from the integration point outward
• Determine what to reuse and extend from prior features