governance: add .gitignore housekeeping and regular audits; implement audit script and CI step; update templates, proposal, and docs
Some checks failed
ci / test (push) Has been cancelled
Some checks failed
ci / test (push) Has been cancelled
This commit is contained in:
20
collab/questions/02-branching.llm.md
Normal file
20
collab/questions/02-branching.llm.md
Normal file
@@ -0,0 +1,20 @@
|
||||
# 02 — Branching/Release — Confirm (LLM)
|
||||
|
||||
- Goals: top 3 drivers for change? [ ]
|
||||
- Stability: main = always green release-ready OR docs-only? [ ]
|
||||
- Consumption: what must be on main for bootstrap? [ ]
|
||||
|
||||
- Choose model:
|
||||
- Trunk-based (main green; short-lived branches) [ ]
|
||||
- WIP branch (main release-only; WIPhax/wip/*) [ ]
|
||||
- GitFlow (main/develop/release/hotfix) [ ]
|
||||
|
||||
- Repo content on main: A full repo [ ] / B no code/prompts [ ] / C minimal bootstrap [ ]
|
||||
- If B/C: where do code/prompts live? naming? [ ]
|
||||
|
||||
- Protections: require CI checks on main [ ]; PR reviews [ ]; Conventional Commits [ ]; tags only for release-ready [ ]
|
||||
|
||||
- Migration: baseline commit/tag [ ]; create branches [ ]; update CI protections [ ]; add docs/branching.md [ ]
|
||||
|
||||
Final: Reply “Approved for Branching Plan” with choices to proceed.
|
||||
|
54
collab/questions/02-branching.md
Normal file
54
collab/questions/02-branching.md
Normal file
@@ -0,0 +1,54 @@
|
||||
# 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?
|
||||
|
||||
## 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.
|
||||
|
||||
## 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`.
|
||||
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?
|
||||
10) Require PR reviews and enforce Conventional Commits? Approve?
|
||||
11) Tagging: continue `YYYY-MM-DD-HHMM`. Should `main` tags correspond only to 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.
|
||||
|
||||
## 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.
|
||||
|
Reference in New Issue
Block a user