From cfcdd8b8a81d80b1c015e99fd41babb4372ce298 Mon Sep 17 00:00:00 2001 From: Kamil Krzywda Date: Sun, 11 Oct 2026 16:15:00 +0000 Subject: [PATCH] docs: clarify Gitea issue convention (reference filed issues; no redundant changelog issue) --- AGENTS.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/AGENTS.md b/AGENTS.md index 753fb50..b7bc25a 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -14,7 +14,7 @@ renders territorial ownership; the whole thing persists to SQLite and streams ov ## Change process (mandatory) 1. **Small, incremental, well-tested changes** — work is done one change at a time, in smaller parts; each part is tested before moving on. Connected tasks that touch the same area of code MAY be done together on one branch/PR with a single version bump (e.g. two tweaks to the same panel). -2. **Gitea issue first** — file an issue on Gitea (`https://git.kkhost.pl`, repo `OpenCode/History`) describing the change (title, scope, acceptance criteria) before or alongside creating the branch. The issue is the single source of intent; the PR references it. +2. **Gitea issue + `Fixes #N` in the PR** — the PR references (and, via `Fixes #N`, closes) the Gitea issue(s) the work addresses (`https://git.kkhost.pl`, repo `OpenCode/History`). If the user has already filed issue(s) for the change, reference those directly in the PR — no separate changelog issue is created; only file a fresh issue when the work has none pre-filed (e.g. a fix originating purely from chat feedback). `CHANGELOG.md` is always the durable changelog of what shipped. 3. **Feature branch + PR** — every change lands on a feature branch off `master` (no direct pushes to `master`). Open a pull request against `master` on Gitea; reference the issue in the PR description. 4. **Changelog entry** — every change is listed in `CHANGELOG.md` with a version, date and time (format: `## v — YYYY-MM-DD HH:MM`, then bullet points of what changed). 5. **Version bump** — the version is updated in `package.json`.