Standardize issue-linked branches and release tagging #48

Closed
opened 2026-07-02 02:36:47 -05:00 by jcwalker3 · 0 comments
Owner

Problem

Issue-first work + isolated worktrees are in place, but the branch↔issue linkage and release/version tagging policy aren't formalized. A branch should be traceable across issue number → branch name → worktree folder → PR → cleanup, and releases need a consistent, auditable versioning/tagging policy.

Scope

  1. Enforce issue-linked branches in scripts/worktree-start: implementation branches must match (fix|feat|docs|chore)/issue-<n>-<slug>; review branches review/pr-<n>-<slug>; reject untraceable names; --allow-unlinked override; preserve --dry-run.
  2. Document the issue→branch→worktree→PR→cleanup flow (runbook + portable SKILL).
  3. Versioning policy (SemVer vMAJOR.MINOR.PATCH; v0.x.y while unstable; PATCH/MINOR/MAJOR bump rules).
  4. Tagging policy: annotated tags only, from clean/tested remote master, with release notes referencing merged PRs/issues; never tag feature branches / dirty trees / unreviewed-or-self-authored work / commits not on remote master.
  5. Release runbook + skills/llm-project-workflow/templates/release-tag.md.

Gitea branch/tag ↔ issue association

Gitea has no native issue→branch field via the API (only PR head-branch linkage). Document that branch linkage is enforced through branch name + claim comment + PR body (Closes #n / Refs #n) + cleanup. No API change.

Tests

worktree-start branch validation: accept fix|feat|docs|chore/issue-123-... + review/pr-456-...; reject fix/random-name, my-branch; preserve --dry-run; --allow-unlinked bypass. Full suite + git diff --check + secret scan.

Non-goals

No release-automation script yet (document tagging; leave automation to a later issue). No change to MCP runtime, Gitea API ops, credential storage, retry/backoff, audit, or config profiles.

## Problem Issue-first work + isolated worktrees are in place, but the branch↔issue linkage and release/version tagging policy aren't formalized. A branch should be traceable across issue number → branch name → worktree folder → PR → cleanup, and releases need a consistent, auditable versioning/tagging policy. ## Scope 1. **Enforce issue-linked branches** in `scripts/worktree-start`: implementation branches must match `(fix|feat|docs|chore)/issue-<n>-<slug>`; review branches `review/pr-<n>-<slug>`; reject untraceable names; `--allow-unlinked` override; preserve `--dry-run`. 2. **Document** the issue→branch→worktree→PR→cleanup flow (runbook + portable SKILL). 3. **Versioning policy** (SemVer `vMAJOR.MINOR.PATCH`; `v0.x.y` while unstable; PATCH/MINOR/MAJOR bump rules). 4. **Tagging policy**: annotated tags only, from clean/tested remote `master`, with release notes referencing merged PRs/issues; never tag feature branches / dirty trees / unreviewed-or-self-authored work / commits not on remote `master`. 5. **Release runbook** + `skills/llm-project-workflow/templates/release-tag.md`. ## Gitea branch/tag ↔ issue association Gitea has no native issue→branch field via the API (only PR head-branch linkage). Document that branch linkage is enforced through branch name + claim comment + PR body (`Closes #n` / `Refs #n`) + cleanup. No API change. ## Tests `worktree-start` branch validation: accept `fix|feat|docs|chore/issue-123-...` + `review/pr-456-...`; reject `fix/random-name`, `my-branch`; preserve `--dry-run`; `--allow-unlinked` bypass. Full suite + `git diff --check` + secret scan. ## Non-goals No release-automation script yet (document tagging; leave automation to a later issue). No change to MCP runtime, Gitea API ops, credential storage, retry/backoff, audit, or config profiles.
jcwalker3 added the status:in-progress label 2026-07-02 02:36:56 -05:00
Sign in to join this conversation.