feat: improve version bump overall (#100)

Author: wislertt

.dev/15-implementation-todo-plan.md

@@ -22,7 +22,7 @@ This document outlines the implementation plan to transform the current additive
 
 ## Implementation Phases
 
-### Phase 1: Core Infrastructure Changes
+### Phase 1: Core Infrastructure Changes ✅
 
 #### 1.1 Update Component Precedence System ✅
 
@@ -532,7 +532,7 @@ pub mod reset;
 - `src/cli/version/args.rs` - Remove override processing (move to ZervVars)
 - All test files - Update method calls to use `process_*` methods
 
-### Phase 2: Pre-release Component Enhancements
+### Phase 2: Pre-release Component Enhancements ✅
 
 #### 2.1 Add `--bump-pre-release-label` Flag ✅
 
@@ -778,7 +778,7 @@ let label = PreReleaseLabel::from_str_or_alpha(pre_l.as_str());
 - **Consistency**: Same patterns across codebase
 - **Maintainability**: Single source of truth for label handling
 
-#### 2.2 Update Pre-release Creation Logic
+#### 2.2 Update Pre-release Creation Logic ✅
 
 **Priority**: High
 **Effort**: Low
@@ -794,9 +794,9 @@ let label = PreReleaseLabel::from_str_or_alpha(pre_l.as_str());
 - `src/version/zerv/bump/vars_secondary.rs` - Update `bump_pre_release` method
 - `src/error.rs` - Add validation error types
 
-### Phase 3: Reset Behavior Implementation
+### Phase 3: Reset Behavior Implementation ✅
 
-#### 3.1 Implement Version Component Reset Logic
+#### 3.1 Implement Version Component Reset Logic ✅
 
 **Priority**: High
 **Effort**: High
@@ -949,7 +949,7 @@ mod tests {
 - Test files - Add reset behavior tests using process\_\* methods
 - This phase mainly adds comprehensive testing for the reset behavior
 
-#### 3.2 Implement Epoch Reset Logic
+#### 3.2 Implement Epoch Reset Logic ✅
 
 **Priority**: Medium
 **Effort**: Medium

.dev/16-reset-logic-schema-component-issue.md

@@ -0,0 +1,90 @@
+# Reset Logic Schema Component Issue
+
+## Issue Summary
+
+During test refactoring in `src/version/zerv/bump/vars_primary.rs`, we discovered a design flaw in the reset logic for version bumping.
+
+## Problem Description
+
+When bumping major/minor/patch versions, the current reset logic only resets `ZervVars` fields but doesn't handle schema components that depend on those fields.
+
+### Current Behavior
+
+- `ZervVars.pre_release` gets reset to `None` ✅
+- `Component::VarField("pre_release")` in schema remains untouched ❌
+- Build metadata and other non-ZervVars components persist ❌
+
+### Expected Behavior (Semantic Versioning)
+
+- Major bump: `1.5.2-rc.1+build.456` → `2.0.0` (all lower precedence removed)
+- Minor bump: `1.5.2-rc.1+build.456` → `1.6.0` (patch, pre-release, build removed)
+
+## Technical Details
+
+### Components Affected
+
+- `Component::String(String)` - static, should remain
+- `Component::Integer(u64)` - static, should remain
+- `Component::VarField(String)` - **ISSUE**: should be reset when referenced ZervVar is reset
+- `Component::VarTimestamp(String)` - static pattern, should remain
+
+### Current Reset Implementation
+
+Located in `/src/version/zerv/bump/reset.rs`:
+
+- Only resets `ZervVars` fields (major, minor, patch, pre_release, post, dev, epoch)
+- Doesn't touch schema components in `extra_core` or `build`
+
+## Test Cases That Revealed the Issue
+
+```rust
+// These tests currently fail due to the bug:
+#[case("1.0.0+build.123", 1, "2.0.0")]           // Expected: no build metadata
+#[case("1.5.2-rc.1+build.456", 1, "2.0.0")]      // Expected: no pre-release or build
+
+// Current (incorrect) behavior:
+#[case("1.0.0+build.123", 1, "2.0.0+build.123")] // Build metadata persists
+#[case("1.5.2-rc.1+build.456", 1, "2.0.0+build.456")] // Build metadata persists
+```
+
+## Proposed Solutions
+
+### Option A: Extend Reset Logic
+
+Modify `reset_lower_precedence_components` to also clean schema components:
+
+- Remove `VarField` components that reference reset ZervVars
+- Keep static `String`/`Integer` components
+
+### Option B: Schema-Aware Reset
+
+Create separate method to reset schema components based on precedence rules.
+
+### Option C: Architectural Change
+
+Move all dynamic data into `ZervVars` so reset logic is centralized.
+
+## Impact
+
+This affects semantic versioning compliance and could lead to incorrect version strings being generated during automated bumping.
+
+## Status
+
+- **Discovered**: During test refactoring
+- **Severity**: Medium (affects SemVer compliance)
+- **Complexity**: High (requires careful design consideration)
+- **Decision**: Deferred for later architectural review
+
+## Files Involved
+
+- `src/version/zerv/bump/reset.rs` - Current reset implementation
+- `src/version/zerv/bump/vars_primary.rs` - Test cases that revealed issue
+- `src/version/zerv/components.rs` - Component definitions
+- `src/version/semver/from_zerv.rs` - Conversion logic that shows the problem
+
+## Next Steps
+
+1. Review overall reset architecture
+2. Decide on approach (A, B, or C above)
+3. Implement solution with comprehensive tests
+4. Ensure SemVer compliance across all scenarios