Release 2.1.2

CHANGELOG.md

@@ -7,6 +7,47 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [2.1.2] - 2026-01-13
+
+### Added
+- **jbct-designer Agent** - new AI agent for JBCT-based architecture design
+  - Use *before* implementation to validate architecture and select patterns
+  - 8-step design methodology with gap detection
+  - Discovery questions by pattern
+  - Output format for implementation-ready designs
+  - Workflow: jbct-designer → jbct-coder → jbct-reviewer
+- **Common Language: Developer-Business Vocabulary** - patterns as shared language
+  - CODING_GUIDE.md: New section in Foundational Concepts
+  - series/part-01-foundations.md: Added paragraph with translation examples
+  - book/ch01-introduction.md: Added paragraph
+  - Key insight: "First we verify, then we process, then we notify" = Sequencer
+- **Gap Detection Through Patterns** - systematic requirement discovery
+  - CODING_GUIDE.md: New section in Patterns Reference
+  - series/part-05-basic-patterns.md: New section with discovery questions
+  - series/part-06-advanced-patterns.md: Discovery questions for advanced patterns
+  - book/ch07-basic-patterns.md: New section
+  - book/ch08-advanced-patterns.md: New section
+  - jbct-reviewer.md: Step 7 added to Review Methodology
+- **Discovery Questions by Pattern** - questions each pattern generates
+  - Per-pattern tables: Leaf, Sequencer, Fork-Join, Condition, Iteration, Aspects
+  - Gap signal → Question to raise mapping
+  - Added to CODING_GUIDE.md, series, book, and jbct-reviewer
+- **The Six Patterns That Cover Everything** - follow-up article
+  - Articles: `articles/six-patterns-that-cover-everything.md`
+  - Common language concept, gap detection, right questions
+  - Before/after example showing precision gain
+- **Request Processing as Data Transformation** - foundational concept
+  - Articles: `articles/underlying-process.md` (full article)
+  - Articles: `articles/linkedin-data-transformation.md` (LinkedIn post)
+  - CODING_GUIDE.md: New section in Foundational Concepts
+  - Book: ch01-introduction.md expanded with new section
+  - Key insight: sync/async and parallel/sequential are execution details, not structural concerns
+  - JBCT patterns as universal primitives for data flow
+
+### Changed
+- **jbct-coder.md** - Added Related Agents section with workflow context
+- **jbct-reviewer.md** - Added Related Agents section, gap detection step, output format section
+
 ## [2.1.1] - 2026-01-08
 
 ### Added

CODING_GUIDE.md

@@ -305,6 +305,78 @@ The second version **chains** operations. Each step takes the output of the prev
 
 Composition lets you **build complex logic from simple pieces** without intermediate variables or explicit error checking at each step. The structure itself handles error propagation.
 
+### Request Processing as Data Transformation
+
+Every request your system handles follows the same fundamental process—regardless of language or framework. It mirrors how humans naturally solve problems: take input, gradually collect necessary pieces of knowledge, and produce a correct answer.
+
+**The Universal Pattern:**
+```
+Input → Parse → Gather → Process → Respond → Output
+```
+
+Each stage transforms data. Each stage may need additional data. Each stage may fail. The entire flow is a data transformation pipeline.
+
+**Why Async Looks Like Sync:**
+
+When you think in terms of data transformation, the sync/async distinction disappears:
+
+```java
+// These are structurally identical
+Result<User> user = database.findUser(userId);   // "sync"
+Promise<User> user = httpClient.fetchUser(userId); // "async"
+```
+
+Both take a user ID, both produce a User (or failure). The only difference is *when* the result becomes available—an execution detail, not a structural concern. Your business logic doesn't care whether data came from local memory or crossed an ocean.
+
+**Parallel Execution Becomes Transparent:**
+
+You don't decide "this should be parallel." You express data dependencies. The execution strategy follows from the structure:
+
+```java
+// Sequential: each step needs previous result
+return validateInput(request)
+    .flatMap(this::createUser)
+    .flatMap(this::sendWelcomeEmail);
+
+// Parallel: steps are independent
+return Promise.all(
+    fetchUserProfile(userId),
+    loadAccountSettings(userId),
+    getRecentActivity(userId)
+).map(this::buildDashboard);
+```
+
+If operations share no data dependencies, they're naturally parallelizable. If one needs another's output, they're naturally sequential. The patterns in this technology—Leaf, Sequencer, Fork-Join, Condition, Iteration, Aspects—are the fundamental ways data can flow through any system. They're not arbitrary design choices; they're the vocabulary for describing data transformation.
+
+### Common Language: Developer-Business Vocabulary
+
+The six patterns don't just describe code structure—they describe business processes. This creates a shared vocabulary between developers and business stakeholders.
+
+**Watch the precision gain:**
+
+> **Before:** "Get the user's stuff and show it"
+>
+> **After:** "Fork-Join: fetch profile, preferences, and history in parallel, then combine into dashboard view"
+
+Same requirement. One is vague. One is implementable.
+
+**The translation is mechanical:**
+
+- "Check if..." → **Leaf** → Single validation
+- "First... then... then..." → **Sequencer** → `.flatMap()` chain
+- "Get X and Y and Z, then..." → **Fork-Join** → `Promise.all()`
+- "If... otherwise..." → **Condition** → Ternary/switch
+- "For each..." → **Iteration** → `.map()` / loop
+- "Always log/retry/timeout..." → **Aspects** → Wrapper function
+
+When a developer asks "Can these operations run in parallel?" they're really asking "Do these steps depend on each other's results?"
+
+When business says "First we verify, then we process, then we notify"—that's a Sequencer. Directly translatable to code.
+
+When business says "We need the user's profile, their preferences, and their history to show the dashboard"—that's a Fork-Join. Three independent fetches, one combined result.
+
+**Why this matters:** Requirements discussions become technical design sessions. Gaps surface during conversation, not during implementation. Code structure mirrors business process because they're the same thing.
+
 ### Smart Wrappers (Monads)
 
 This technology uses **Smart Wrappers**—types that wrap values and control how operations are applied to them.
@@ -2008,6 +2080,58 @@ private Promise<User> recoverNetworkError(Cause cause) {
 
 ## Patterns Reference
 
+### Gap Detection Through Patterns
+
+When you model business processes using these patterns, **gaps become visible**. The patterns don't just implement requirements—they validate them.
+
+**Missing validation:**
+You're building a Sequencer: verify → process → notify. But what validates the input before "verify"? The pattern demands something produces the input for step one. If nothing does, you've found a gap.
+
+**Unclear dependencies:**
+Business describes five things that need to happen. Are they a Sequencer (dependent chain) or Fork-Join (independent operations)? If they can't tell you which outputs feed which inputs, the process isn't fully defined.
+
+**Missing error handling:**
+Every Leaf can fail. Every step in a Sequencer can fail. When you map business process to patterns, you naturally ask: "What happens when this fails?" If they don't know, you've found a gap.
+
+**Inefficient flows:**
+Business describes a sequential process: get A, then get B, then get C, then combine. But if A, B, and C don't depend on each other, this should be Fork-Join, not Sequencer. The pattern reveals the inefficiency.
+
+### Discovery Questions by Pattern
+
+Each pattern generates specific questions. You're not inventing questions—the patterns generate them.
+
+**Leaf questions:**
+- "What exactly does this operation do?"
+- "Can it fail? What failures are possible?"
+- "Is it sync (`Result`) or async (`Promise`)?"
+
+**Sequencer questions:**
+- "What do we need from step 1 to perform step 2?"
+- "Can step 3 ever happen if step 2 fails?"
+- "Is this order fixed, or could steps be reordered?"
+
+**Fork-Join questions:**
+- "Do these operations depend on each other?"
+- "Can we fetch X while also fetching Y?"
+- "What do we do if one succeeds and another fails?"
+
+**Condition questions:**
+- "What determines which path we take?"
+- "Are these paths mutually exclusive?"
+- "Is there a default path?"
+
+**Iteration questions:**
+- "Do we process all items or stop at first failure?"
+- "Does order matter?"
+- "Can items be processed independently (in parallel)?"
+
+**Aspects questions:**
+- "Should we retry on failure? How many times?"
+- "Is there a timeout?"
+- "What needs to be logged/measured?"
+
+---
+
 ### Leaf
 
 **Definition:** A Leaf is the smallest unit of processing - a function that does one thing and has no internal steps. It's either a business leaf (pure computation) or an adapter leaf (I/O or side effects).

README.md

@@ -1,6 +1,6 @@
 # Java Backend Coding Technology
 
-> **Version 2.1.1** | [Full Changelog](CHANGELOG.md)
+> **Version 2.1.2** | [Full Changelog](CHANGELOG.md)
 
 A framework-agnostic methodology for writing predictable, testable Java backend code optimized for human-AI collaboration.
 
@@ -231,7 +231,7 @@ void email_acceptsValidFormat() {
 ### Changelog & Versioning
 
 - **[CHANGELOG.md](CHANGELOG.md)** - Version history following [Keep a Changelog](https://keepachangelog.com/)
-  - Current version: 2.1.1 (2026-01-08)
+  - Current version: 2.1.2 (2026-01-12)
   - Golden formatting patterns, Pragmatica Lite 0.9.10, 36 lint rules
   - Semantic versioning for documentation releases
 
@@ -392,6 +392,6 @@ If you find this useful, consider [sponsoring](https://github.com/sponsors/siy).
 
 ---
 
-**Version:** 2.1.1 | **Last Updated:** 2026-01-08 | **[Full Changelog](CHANGELOG.md)**
+**Version:** 2.1.2 | **Last Updated:** 2026-01-12 | **[Full Changelog](CHANGELOG.md)**
 
 **Copyright © 2025 Sergiy Yevtushenko. Released under the [MIT License](LICENSE).**

ai-tools/agents/jbct-coder.md

@@ -1,7 +1,7 @@
 ---
 name: jbct-coder
 title: Java Backend Coding Technology Agent
-description: Specialized agent for generating business logic code using Java Backend Coding Technology v2.1.1 with Pragmatica Lite Core 0.9.10. Produces deterministic, AI-friendly code that matches human-written code structurally and stylistically. Includes evolutionary testing strategy guidance.
+description: Specialized agent for generating business logic code using Java Backend Coding Technology v2.1.2 with Pragmatica Lite Core 0.9.10. Produces deterministic, AI-friendly code that matches human-written code structurally and stylistically. Includes evolutionary testing strategy guidance.
 tools: Read, Write, Edit, MultiEdit, Grep, Glob, LS, Bash, TodoWrite, Task, WebSearch, WebFetch
 ---
 
@@ -1762,7 +1762,9 @@ public class JooqUserRepository implements SaveUser {
 
 ## References
 
-- **Full Guide**: `CODING_GUIDE.md` - Comprehensive explanation of all patterns and principles (v2.1.1)
+- **Full Guide**: `CODING_GUIDE.md` - Comprehensive explanation of all patterns and principles (v2.1.2)
+- **Design Agent**: `ai-tools/agents/jbct-designer.md` - Use for architecture design and planning before coding
+- **Review Agent**: `ai-tools/agents/jbct-reviewer.md` - Use for code review after implementation
 - **Testing Strategy**: `series/part-05-testing-strategy.md` - Evolutionary testing approach, integration-first philosophy, test organization
 - **Systematic Application**: `series/part-10-systematic-application.md` - Checkpoints for coding and review
 - **API Reference**: `CLAUDE.md` - Complete Pragmatica Lite API documentation