From 0973d4ecbeff92cfbc0bd7df7166c41b1441b8bf Mon Sep 17 00:00:00 2001
From: fylorn <249551762+fylorn@users.noreply.github.com>
Date: Sun, 20 Sep 2026 11:55:33 +0800
Subject: [PATCH] chore: make `main` the branch the contract describes
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Every pull request since 17 September has been opened against `main` and
merged there, and `dev` has not moved since 15 September — by the time
v0.9.1 was tagged it was thirty-five commits behind. The documents still
described the opposite: CONTRIBUTING and the pull request template told
contributors to retarget onto `dev`, and a workflow commented on every
PR to say the base was wrong when it was in fact the one being used.

With one person merging and a tag per release, the second branch never
bought anything. It carried the same commits a day later, and the only
thing it produced was a bot arguing with the actual workflow on every
pull request.

So `main` is the contract now: PRs open against it, releases are tags on
it. The retarget workflow is gone, CI no longer watches a branch that
does not exist, and the pull request template says the pre-filled base
is the right one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---
 .github/PULL_REQUEST_TEMPLATE.md    |  7 ++---
 .github/workflows/ci.yml            |  2 +-
 .github/workflows/pr-base-guard.yml | 49 -----------------------------
 CONTRIBUTING.md                     | 18 ++++++-----
 4 files changed, 14 insertions(+), 62 deletions(-)
 delete mode 100644 .github/workflows/pr-base-guard.yml

diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
index fd2493c7..8e17c485 100644
--- a/.github/PULL_REQUEST_TEMPLATE.md
+++ b/.github/PULL_REQUEST_TEMPLATE.md
@@ -1,9 +1,6 @@
 <!--
-Base branch: `dev`, not `main`.
-
-GitHub pre-fills the base with this repo's default branch (`main`), the
-release line. Use the "Edit" button next to the title to switch the base
-to `dev`; with the CLI, pass `--base dev`.
+Base branch: `main`, which is what GitHub pre-fills. It is the only
+long-lived branch here; a release is a tag on it.
 
 Before writing: this repository is a set of crates, not an application.
 The desktop app lives in ThinkWatch-Lite. See CONTRIBUTING.md.
diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
index 0fa5624a..72403713 100644
--- a/.github/workflows/ci.yml
+++ b/.github/workflows/ci.yml
@@ -7,7 +7,7 @@ name: CI
 
 on:
   push:
-    branches: [main, dev]
+    branches: [main]
   pull_request:
 
 env:
diff --git a/.github/workflows/pr-base-guard.yml b/.github/workflows/pr-base-guard.yml
deleted file mode 100644
index f8d98791..00000000
--- a/.github/workflows/pr-base-guard.yml
+++ /dev/null
@@ -1,49 +0,0 @@
-# Nudge PRs that were opened against `main` toward `dev`.
-#
-# GitHub pre-fills a new PR's base with the repo's default branch, which
-# here is `main`, the release line.
-# A contributor following the UI therefore lands on the wrong branch by
-# default, and the first signal they get today is a human asking them to
-# retarget. This says it immediately instead.
-#
-# `pull_request_target` rather than `pull_request` because a PR from a
-# fork gets a read-only token under the latter, so it could not comment
-# — and a fork PR is exactly the case this exists for. That trigger runs
-# with the base repository's token, so this workflow **must never check
-# out or execute PR code**. It doesn't: no actions/checkout, no build,
-# nothing but one API call against metadata GitHub already gave us.
-name: PR base guard
-
-on:
-  pull_request_target:
-    types: [opened, reopened]
-    branches: [main]
-
-permissions:
-  pull-requests: write
-
-jobs:
-  nudge:
-    runs-on: ubuntu-latest
-    # The two legitimate ways to target `main`: the release PR (`dev` ->
-    # `main`) and a hotfix branch. Everything else is a mis-targeted
-    # contribution.
-    if: >-
-      github.event.pull_request.head.ref != 'dev' &&
-      !startsWith(github.event.pull_request.head.ref, 'hotfix/') &&
-      !startsWith(github.event.pull_request.head.ref, 'release/')
-    steps:
-      - name: Ask for a retarget to dev
-        env:
-          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-          PR: ${{ github.event.pull_request.number }}
-          REPO: ${{ github.repository }}
-        run: |
-          gh pr comment "$PR" --repo "$REPO" --body \
-          'Thanks for the PR. One thing before review: **this targets `main`, and it should target `dev`.**
-
-          `main` is a release-only line — branch-protected, linear history, and every commit on it is a tagged release snapshot. Routine work lands on `dev` and reaches `main` with the next release. GitHub pre-filled `main` here because it is the default branch, so this is our defaults being unhelpful rather than anything you did wrong.
-
-          No need to close and reopen: click **Edit** next to the PR title and change the base branch to `dev`. The commits and the discussion carry over.
-
-          See [CONTRIBUTING.md](../blob/main/CONTRIBUTING.md) and [CONTRIBUTING.md](../blob/main/CONTRIBUTING.md) for the branch contract.'
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 1f136f17..655fcd6f 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,16 +1,20 @@
 # Contributing to ThinkWatch Core
 
-## Open PRs against `dev`
+## Open PRs against `main`
 
 ```bash
-gh pr create --base dev --head your-branch
+gh pr create --base main --head your-branch
 ```
 
-`main` is the release line; `dev` is where routine work lands. GitHub
-pre-fills a new PR's base with the repo's default branch, which is
-`main`, so **the default is not the one you want**. If you already
-opened against `main`, click *Edit* next to the PR title and change the
-base — the commits and the discussion carry over. A bot will remind you.
+`main` is the only long-lived branch. Every PR lands on it, and a
+release is a tagged commit on it rather than a separate line, so the
+base GitHub pre-fills is the one you want.
+
+There used to be a `dev` branch in between, and a bot that asked you to
+retarget onto it. Both are gone. With one branch there is nothing to
+keep in sync and no window in which a fix is merged but not yet
+releasable; the `dev` branch's last act was to sit still for five days
+while thirty-five commits landed on `main` without it.
 
 ## What this repository is