From ae10b2861b37642a5b543047879c40b3f26d4406 Mon Sep 17 00:00:00 2001 From: Matysh Date: Fri, 14 Aug 2026 10:50:56 +0300 Subject: [PATCH] chore: drop Project v2 from the process, the docs and the release script MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The owner stopped using GitHub Projects. Most of this is wording, but one part was not: release-prerelease.mjs talked to the Project in code. finishIssues looked up the project id, listed its items and its Status=Done option, and threw when an issue was missing from the board — so the first release that closed an issue would have died on a step with nothing to do with publishing. Found by reading rather than by releasing, which was luck. Closing issues stays, and now strips the status label first. That order is not cosmetic: the invariant that a closed issue carries no status label has broken twice already, both times because a manual step did it the other way round. The close-merged job already does it in this order. The documents now say labels and only labels. The explicit "no longer used" lines are kept on purpose, in PROCESS.md and next to the code that used to sync: a decision that vanishes quietly gets reintroduced a month later by someone who never knew it was made. Issue: #139 User-Visible: no --- AGENTS.md | 3 +-- CONTRIBUTING.md | 13 ++++++------- 2 files changed, 7 insertions(+), 9 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index fd6e29ca..1495b972 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -38,8 +38,7 @@ task records: problem, scope, acceptance criteria and discussion. **Status lives in labels:** `S1-new`, `S2-analysis`, `S3-spec`, `S4-spec-review`, `S5-ready`, `S6-in-progress`, `S7-code-review`, `S8-merged`, plus `blocked` on top of a status and `rejected` on a closed issue. Exactly one `S*` label per open -issue. [GitHub Projects (v2)](https://github.com/users/Matysh/projects/1) is a -human-facing view synchronised from the labels, not the source of truth. +issue. Labels are the whole of it: GitHub Projects is no longer used. Two shortcuts exist for small work. `small` — the light track: the spec lives in the issue body and its review is a comment. `trivial` — the short track: no spec diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index c5b65d3a..54c224a6 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -18,13 +18,12 @@ requests still belong in [issues](https://github.com/Matysh/houseplan-card/issue ## Backlog and work status -[GitHub Issues](https://github.com/Matysh/houseplan-card/issues) and the linked -[GitHub Project v2](https://github.com/users/Matysh/projects/1) are the -only active project backlog. Issues own scope and acceptance criteria; Project -v2 owns prioritization and workflow status. Before starting planned work, link -it to an existing issue or create one, add it to the Project, and keep both -surfaces current until the verified result is closed. Design specs and ADRs may -support an issue, but they do not replace it or maintain a separate checklist. +[GitHub Issues](https://github.com/Matysh/houseplan-card/issues) are the only +active backlog. An issue owns scope and acceptance criteria; its **labels** own +priority and workflow status — `PROCESS.md` §9 holds the vocabulary. Before +starting planned work, link it to an existing issue or create one, and keep it +current until the verified result is closed. Design specs and ADRs may support an +issue, but they do not replace it or maintain a separate checklist. ## Five-minute setup