Update PR description to clarify validation-time only storage

- Clarified that we store ONLY validation-time values (not both)
- Removed fallback logic from code examples
- Added table showing what gets stored vs. logged
- Fixed alternatives section - removed contradiction
- Changed exception type to AssertionError for programming bugs

Author: cowwoc

PR_DESCRIPTION.md

@@ -49,48 +49,47 @@ The problem: **validation reads BEFORE injection, storage reads AFTER injection*
 
 ## Solution
 
-Capture properties at **validation time** for ALL builds (even when no cache exists). This ensures both validation and storage read at the same lifecycle point.
+Capture properties at **validation time** for ALL builds (even when no cache exists). Store ONLY validation-time values in the cache. This ensures both validation and storage read at the same lifecycle point.
 
 ### Implementation
 
 1. **Modified `CacheResult`** to store validation-time mojo events
 2. **Modified `BuildCacheMojosExecutionStrategy`** to capture properties immediately after `findCachedBuild()`
-3. **Modified `save()`** to use validation-time events instead of execution-time events
+3. **Modified `save()`** to store ONLY validation-time events (fails with `AssertionError` if missing)
 
 ### Key Code Changes
 
 ```java
 // In BuildCacheMojosExecutionStrategy.execute():
 result = cacheController.findCachedBuild(session, project, mojoExecutions, skipCache);
 
-// NEW: Capture validation-time properties for ALL mojos
-Map<String, MojoExecutionEvent> validationTimeEvents =
-    captureValidationTimeProperties(session, project, mojoExecutions);
-
-// Store in result
-result = CacheResult.rebuilded(result, validationTimeEvents);
+// NEW: Always capture validation-time properties when cache is enabled
+if (cacheState == INITIALIZED) {
+    Map<String, MojoExecutionEvent> validationTimeEvents =
+        captureValidationTimeProperties(session, project, mojoExecutions);
+    result = CacheResult.rebuilded(result, validationTimeEvents);
+}
 ```
 
 ```java
 // In save():
-// Use validation-time events instead of execution-time events
-Map<String, MojoExecutionEvent> propertyEvents =
-    cacheResult.getValidationTimeEvents() != null
-        ? cacheResult.getValidationTimeEvents()  // Use validation-time
-        : executionEvents;                        // Fallback to execution-time
-
-List<CompletedExecution> completedExecution =
-    buildExecutionInfo(mojoExecutions, propertyEvents);
+// Validation-time events MUST exist - no fallback to execution-time
+if (result.getValidationTimeEvents() == null || result.getValidationTimeEvents().isEmpty()) {
+    throw new AssertionError("Validation-time properties not captured - this is a bug");
+}
+cacheController.save(result, mojoExecutions, result.getValidationTimeEvents());
 ```
 
+**Note:** Execution-time values are still captured by `MojoParametersListener` for logging/debugging during the build, but are NOT stored in the cache.
+
 ### New Timeline (Both Builds)
 
 ```
 First Build:
   1. findCachedBuild() → no cache
   2. captureValidationTimeProperties() → reads WITHOUT injection
-  3. Mojos execute → Maven 4 injects (but we don't use these values)
-  4. save() uses validation-time properties → stores WITHOUT injection
+  3. Mojos execute → Maven 4 injects (logged but not stored)
+  4. save() stores ONLY validation-time properties → WITHOUT injection
 
 Second Build:
   1. findCachedBuild() → cache found
@@ -99,6 +98,15 @@ Second Build:
   4. Compares to first build → BOTH without injection → MATCH!
 ```
 
+### What Gets Stored vs. Logged
+
+| Data | Stored in Cache | Available in Logs |
+|------|-----------------|-------------------|
+| Validation-time properties (no injection) | ✅ Yes | ✅ Yes |
+| Execution-time properties (with injection) | ❌ No | ✅ Yes |
+
+This approach ensures cache consistency while preserving debugging information in build logs.
+
 ## Benefits Over PR #391
 
 | Aspect | PR #391 (`ignorePattern`) | This PR (Validation-Time Capture) |
@@ -132,11 +140,11 @@ All tests verify:
 
 ## Alternative Approaches Considered
 
-1. **Store validation-time values only** ❌ - Would lose auditability of what actually executed
-2. **Delay validation until execution** ❌ - Would lose early cache-miss detection performance
-3. **Pattern-based filtering (PR #391)** ❌ - Treats symptom, not root cause
-4. **Maven core changes** ❌ - Outside our control
-5. **Validation-time capture (this PR)** ✅ - Fixes root cause, no configuration needed
+1. **Delay validation until execution** ❌ - Would lose early cache-miss detection performance benefit
+2. **Pattern-based filtering (PR #391)** ❌ - Treats symptom (value mismatch) instead of root cause (timing mismatch)
+3. **Maven core changes** ❌ - Outside our control, would take years to deploy
+4. **Store both validation-time and execution-time** ❌ - Unnecessary complexity, doesn't solve the consistency problem
+5. **Validation-time capture + storage (this PR)** ✅ - Fixes root cause, no configuration needed, preserves logging for debugging
 
 ## Related Issues