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

collab/plan/02-branching.llm.md

@@ -0,0 +1,24 @@
+# 02 — Branching/Release — Plan (LLM)
+
+- Model: Trunk-based with protected `main` (always green, production-ready) + short-lived feature branches (`feat/*`, `fix/*`, `chore/*`, `docs/*`, `ci/*`, `refactor/*`). Optional `next` integration branch only if batching risky work.
+- Repo content on `main`: Full repo (code, prompts, templates, docs) — must pass CI and audits on every merge.
+- Tags: `YYYY-MM-DD-HHMM` on release-ready commits.
+- CI protections: Required checks (audit + Docker tests), linear history, PR required, Conventional Commits.
+
+- Migration steps:
+  1) Tag current good baseline (e.g., `YYYY-MM-DD-HHMM`).
+  2) Create `wip/phase1` branch from current `main`; continue all WIP there under PRs to `main`.
+  3) Enable protections on `main` in Gitea: required checks (audit/test), PR reviews, linear history.
+  4) Document policy in `docs/branching.md` and update README.
+  5) Add templates/docs for downstream projects to adopt same policy (if needed).
+
+- Acceptance:
+  - `main` protected with required CI checks; PR required; Conventional Commits enforced.
+  - `wip/phase1` exists; ongoing work targets it.
+  - Tags used only for release-ready commits on `main`.
+  - `docs/branching.md` present and referenced by README.
+
+- Notes:
+  - Reassess `next` only if multiple parallel risky features emerge.
+  - Keep branches short-lived; delete after merge.
+

collab/plan/02-branching.md

@@ -0,0 +1,37 @@
+# 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.