ChatGPTScaffolding/collab/questions/02-branching.md

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.