governance: enforce strict Questions→Proposal→Plan gates with explicit approval phrases; add branching proposal; mark plan pending; audit checks sequencing

collab/questions/02-branching.md

@@ -18,6 +18,8 @@ simplify consumption by other projects
 
 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.
@@ -30,25 +32,38 @@ simplify consumption by other projects
    - `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?
+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.
-