# 02 — Branching/Release — Plan
# Status: Pending Proposal Approval — do not execute until 02-branching proposal is approved (“Approved for Plan”).

Purpose: Keep `main` production-ready and clean while enabling fast, safe iteration via short-lived branches and CI protections.

## Chosen Model
- Trunk-based development:
  - `main` is always green and production-ready (zero technical debt).
  - Work happens on short-lived branches by type: `feat/*`, `fix/*`, `chore/*`, `docs/*`, `ci/*`, `refactor/*`.
  - Optional `next` integration branch only if batching risky changes is necessary.

## Repo Content on `main`
- Full repository (code, prompts, templates, docs). Every merge must pass audits and Docker-based CI.
- Releases tagged `YYYY-MM-DD-HHMM` on `main` only.

## CI/Gitea Protections
- Required checks on `main`: scripts/audit.sh and Docker test job.
- Require PRs to merge; block direct pushes.
- Enforce linear history (no merge commits) or squash-merge per preference.
- Enforce Conventional Commits in PR titles.

## Migration Steps
1) Tag current baseline on `main` (e.g., `YYYY-MM-DD-HHMM`).
2) Create `wip/phase1` from current `main`; continue TDD work there.
3) Configure Gitea branch protection for `main` with required checks and PR requirement.
4) Add `docs/branching.md` describing this policy; link from README.
5) Optionally create `next` if multiple risky features need integration before `main`.

## Acceptance Criteria
- `main` is protected in Gitea with required audit/test checks and PR-only merges.
- `wip/phase1` branch exists and becomes the target for ongoing work until Phase 1 is complete.
- Tags are created only on `main` for release-ready states.
- `docs/branching.md` added and referenced by README.

## Notes
- Keep branches short-lived; delete after merge.
- If policy changes, update `docs/branching.md`, AGENTS templates, and prompts/global to propagate.