# 02 — Branching/Release — Questions

Purpose: Align on a clean, sustainable branch and release strategy before any changes. We will not implement until you approve.

Context: You suggested moving active work to a `WIPhax` branch and keeping `main` limited to non-code assets (docs/collab/.gitea). Below are options and tradeoffs to decide together.

## Goals & Constraints
1) Primary goals: What are the top 3 goals driving this change? (e.g., keep `main` always pristine, minimize merge noise, avoid half-baked code on main, simplify consumption by other projects, etc.)

main pristine
avoid half-baked code on main
simplify consumption by other projects


2) Stability bar: Should `main` be “always green + release-ready” with protected branch/required CI? Or “docs-only” as you proposed?

"always green + release ready" 

3) Consumption: Will external automation/scripts rely on cloning `main` to bootstrap? If yes, what assets must be present on `main` (templates, prompts, wrapper) to keep bootstrapping simple?

No. I don't believe this will ever be automatically cloned to bootstrap. I expect that to be only done by a human. I can't control what people do of course, it's a public repo.

## Branching Models (pick one or adjust)
4) Trunk-based (recommended):
   - `main` = always green, release-ready. All commits pass CI (Docker) and TDD.
   - Work happens on short-lived feature branches `feat/*`, `fix/*` merged via PR.
   - Optional long-lived integration branch `next` for batching risky changes.
5) WIP branch variant:
   - `main` = release-ready only; heavy ongoing work on `WIPhax` (or `wip/*`), merged back via PR when green.
   - Risk: drift between `WIPhax` and `main`, elevated merge pain if long-lived.
6) GitFlow:
   - `main` for releases; `develop` for integration; feature branches; release/hotfix branches.
   - Heavier process; likely overkill unless multiple contributors and scheduled releases.

   Trunk based sounds perfect

## Repo Content Policy
7) What exactly belongs on `main`? Options:
   - A) Full repo (code + prompts + templates + docs) — but always green.
   - B) Everything except code/prompts (your suggestion) — use branches/tags for code.
   - C) Minimal bootstrap subset (AGENTS seeds, prompts/global, templates/_shared) + docs.
   Please choose and list mandatory directories for `main`.

   A

8) If B or C: where do code/prompts live (branch names/tags)? How will downstream projects fetch them reliably?

## CI/Gitea Protections
9) Protect `main` with required checks (Docker tests) and linear history? Approve? 
yes I approve

10) Require PR reviews and enforce Conventional Commits? Approve?

Yes I approve

11) Tagging: continue `YYYY-MM-DD-HHMM`. Should `main` tags correspond only to release-ready points?

Hmmm.... I was using tags/releases as a kind of "hack" or "snapshots" and that's not the practice I want to have. Yes the tags should only be release-ready points.

## Migration Plan (once we choose)
12) Baseline selection: pick commit/tag for the new `main` baseline.
13) Branch ops: create `WIPhax`/`next`/`develop` as chosen; move ongoing TDD work there.
14) CI updates: confirm branch protections and required checks in Gitea.
15) Docs: add `docs/branching.md` describing the policy; update README.

Do you need anything from me for this section? It's statements not questions, but that plan looks good to me.

## Decision
16) Please pick one model (4/5/6) and option (7 A/B/C), then reply “Approved for Branching Plan” (or edit inline). I’ll draft `collab/plan/02-branching.md` for review.