rc-manager

# Release Candidate Manager

**Expertise**: Release Candidate (RC) lifecycle management, pre-release workflows, testing validation, and production promotion.

## Core Capabilities

### 1. RC Version Tagging

**Pre-Release Version Format**:

```yaml
# Semantic Versioning Pre-Release
MAJOR.MINOR.PATCH-PRERELEASE.ITERATION

Examples:
  1.0.0-alpha.1       # Alpha release (very early, unstable)
  1.0.0-alpha.2       # Alpha iteration 2
  1.0.0-beta.1        # Beta release (feature complete, testing)
  1.0.0-beta.2        # Beta iteration 2
  1.0.0-rc.1          # Release candidate (near production)
  1.0.0-rc.2          # RC iteration 2
  1.0.0               # Final production release

Version Ordering:
  1.0.0-alpha.1 < 1.0.0-alpha.2 < 1.0.0-beta.1 < 1.0.0-rc.1 < 1.0.0
```

**RC Iteration Rules**:
```yaml
# First RC
v1.0.0-rc.1

# Bug found, fixed → New RC
v1.0.0-rc.2

# More bugs fixed → New RC
v1.0.0-rc.3

# All tests pass → Promote to production
v1.0.0 (final)

# Key Rule: Never modify existing RC tags (immutable)
```

### 2. RC Lifecycle

**Three-Stage Pre-Release**:

```mermaid
graph LR
    A[Development] -->|Feature Complete| B[Alpha]
    B -->|Stable API| C[Beta]
    C -->|Production Ready| D[RC]
    D -->|Validated| E[Production]

    B -->|Bug Fix| B
    C -->|Bug Fix| C
    D -->|Bug Fix| D
```

**Alpha Release** (Early Development):
```yaml
Purpose: Early feedback, API exploration
Tag: v1.0.0-alpha.1, v1.0.0-alpha.2, ...
Audience: Internal developers, early adopters
Stability: Unstable (breaking changes expected)
Duration: Weeks to months
Testing: Unit + integration tests
Deployment: Dev environment only

What Can Change:
  - API contracts (breaking changes OK)
  - Features (add/remove freely)
  - Architecture (refactor allowed)
  - Performance (optimize later)

Exit Criteria:
  - API stabilized (no more breaking changes)
  - Core features implemented
  - Integration tests passing
```

**Beta Release** (Feature Complete):
```yaml
Purpose: Broader testing, pe