From 714161b4ce4a36214df45a4bdc802311759bf3ba Mon Sep 17 00:00:00 2001 From: Lukas Wuttke Date: Sun, 23 Aug 2026 14:07:19 +0200 Subject: [PATCH] docs(2347): rfcs is main-only, so the standard says so The develop-first rule named `docs` as its sole exception. `rfcs` has the same shape and the same reason -- it publishes no artifact, has no deploy stages, and is not on the release train -- so a promotion gate there has nothing to gate. Decided on backend#2347. This line was the last place still asserting otherwise. `repo-inventory.yml` has described `rfcs` as a single-branch repo all along: `release_train: false`, so `audit_branch: develop-first-on-train` already resolves to the default branch, and the `develop` role carries `exempt: *no_develop_branch_single_branch_repo` -- "single-branch repo: `main` is the only integration branch, so there is no `develop` to protect. Structural, not a gap." So the machine-readable side needs no change; the prose was the drift. Stated as a class with its members named, and pointed at the inventory, because a bare list drifts and a bare class invites argument. Why nobody caught it: the conformance guard flags a stale exemption only when the role's branch appears AND carries protection. `rfcs/develop` existed and was completely unprotected, so the contradiction between "there is no develop" and a live develop branch was invisible by construction. rfcs#45 deletes that branch and makes reality match what this file and the inventory both now say. Co-Authored-By: Claude Opus 5 --- org-standards.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/org-standards.md b/org-standards.md index 0679ab7..584c405 100644 --- a/org-standards.md +++ b/org-standards.md @@ -9,7 +9,7 @@ ### Branches & PRs -- Branch model: `develop → staging → main`. Branch off `develop`; every PR targets `develop`. Never open PRs to `staging` or `main` — promotions are the release train's job. (Sole exception: the `docs` repo may target `main`.) +- Branch model: `develop → staging → main`. Branch off `develop`; every PR targets `develop`. Never open PRs to `staging` or `main` — promotions are the release train's job. **Exception: a repo that publishes no artifact and has no deploy stages is `main`-only — `docs` and `rfcs`.** They are not on the release train, so a promotion gate has nothing to gate. `repo-inventory.yml` is the authority (`release_train: false` plus the single-branch exemption); this line follows it, not the reverse. - Before starting any task: `git fetch` and branch from the current tip of `develop` — never build on a stale checkout. A branch that lives more than a day gets `develop` merged back in before review. We move fast; stale starts mean silent divergence and duplicated work. - One self-contained change per PR. A few hundred changed lines reviews well; at 1000+ split it. Refactors ship in separate PRs from behavior changes. - Branches are short-lived (aim to merge within a day or two), single-author, and based on `develop` — no stacked PRs on top of other open PRs.