governance: enforce strict Questions→Proposal→Plan gates with explicit approval phrases; add branching proposal; mark plan pending; audit checks sequencing
Some checks failed
ci / test (push) Has been cancelled

This commit is contained in:
2025-09-17 11:25:05 -05:00
parent 1eaa2f7997
commit e925e6ebca
11 changed files with 167 additions and 3 deletions

View File

@@ -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.