# Development Workflow Overview

## Bug Status Flow
```
created → analyzed → in-progress → resolved → closed
                                           ↘ rejected
```

**Important:** Agents should NEVER set status to `closed` - only users can close bugs after verification.

## RC Versioning Convention

**ALWAYS start from rc.0**

- First RC: `0.3.14-rc.0` ✅
- After failure: `0.3.14-rc.1`, `rc.2`, ...
- Never start with rc.1 ❌

## RC Release Process

1. **Merge**: All `resolved` bugs → `release/X.X.X-rc.0` branch
2. **Test**: QA team runs integration tests
3. **Decision**:
   - ✅ **PASS**: Merge to `develop` → npm publish
   - ❌ **FAIL**: Exclude failed bugs → `rc.1`, `rc.2`, ... (retry)

## Branch Strategy

```
Individual bugs:     bugfix/bug-XXXXX
Integration testing: release/X.X.X-rc.N
Stable development:  develop
Production:          main
```

**Workflow:**
```
bugfix/bug-XXXXX → release/X.X.X-rc.N → develop → main
```

## Release Plan Structure

Each release should have a plan document defining:
- Target version
- Included bugs (with `target_release` field)
- Test report location
- Expected timeline

See: Release Plan Template in agents.yaml documents section