[chezhj]

What

Sets up the release flow from release-flow-spec.md (reference: chezhj/weekmenu), adapted to this repo.

• ci.yaml (edited in place): job renamed to test; adds manage.py check; push trigger narrowed to master; adds workflow_call; permissions: contents: read; concurrency keyed on event_name and only cancelling PR runs, so a push to master can never cancel the Release's test. The js job is kept.
• pr-title.yml (new): cz check --message plus extra rules (no Merge*/Revert*/Pull request*/fixup!/squash!, lowercase subject, no trailing period, at most 72 characters). The title only reaches the script through an env var.
• release.yml (new): manual Release workflow with increment auto/PATCH/MINOR: test → bump (guard on master, fetch-depth: 0, warn-only step for unreadable commits, commitizen-action, "Nothing to release" handling) → deploy.
• release-deploy.yaml (edited in place, file name kept, display name now "Build & Deploy"): adds workflow_call with a version input and keeps the v* tag trigger as a manual fallback. TAG replaces every GITHUB_REF_NAME and every checkout uses ref: ${{ env.TAG }}.
• pyproject.toml: post_bump_hooks is now an echo. The old git push / git push --tags hooks would have pushed from inside the Actions bump. The message has no quotes or && (Windows cmd.exe would split on it).
• CLAUDE.md, docs/RELEASE.md: describe the new flow (the root CLAUDE.md said deploys come from cz bump pushing the tag; that is intentionally replaced).

Differences from the reference: the pr-title pattern is "Merge"*, not "Merge "*, because the reference let Merge: ... through (a real title in this repo's history).

The checks are not enforced, on purpose. The spec suggests a ruleset that requires test + pr-title and lets github-actions[bot] push the bump. github-actions[bot] cannot be added to a ruleset bypass list, and an enforced required_status_checks rule would (per GitHub's branch-protection docs; not verified for rulesets) reject the brand-new, untested bump commit pushed with GITHUB_TOKEN. So the existing "Check naming" ruleset stays without that rule. CLAUDE.md ("The checks") says so plainly and records what enforcing would take: a bypass user's token for the bump, and dropping the chained deploy job, because a token-pushed tag would also trigger the v* deploy. If the rule is ever enabled, the contexts are test and pr-title; the ruleset currently lists Tests, which no longer exists after the rename.

No version bump (ci: / docs(ci):).

Evidence

On GitHub, on this PR's head (360d851): test (Django system check + pytest, ~100 s), Browser helper unit tests and pr-title (both steps) all completed successfully; pr-title also re-ran green after the PR body was edited. The first push (bc1bdef) was green too.

Run locally before pushing (commands in the session):

CI steps in a fresh clone of this branch (poetry install, manage.py check, pytest, npm test): System check identified no issues, 545 passed (105.8 s), JS helper tests 20/20 pass. No frontend build is needed (no Vite in this repo).

pr-title script (both steps extracted from the YAML and run with the title only in PR_TITLE), 21/21 cases as expected: 5 valid titles pass; Follow-up: fix things, no prefix, Merge branch ..., Merge: ..., Merged ..., fixup! ..., squash! ..., Revert "...", Pull request #12 ..., capitalised subject, trailing period, 73 characters, and tools: type all fail. A title containing $(touch ...), backticks and quotes passes through without executing anything (no files created).
Against the last 25 real first-parent titles: 18 pass, 7 fail, all direct commits and not PR titles: 4 Merge... commits, tools: add a dry-run-only prune inspector... (unknown type, 75 chars), fix(maintenance): the dry run under-reported... (73 chars), docs: Phase 7 — README... (capitalised subject). PR-style titles such as fix(idle): keep screen on during the idle page too pass.

Warn step (extracted from release.yml, run in throwaway repos): no tag → "skipping", exit 0; clean range → "all readable", exit 0; mixed range → lists exactly the two bad commits in the step summary and a ::warning, exit 0.

YAML: ci.yaml, pr-title.yml, release.yml, release-deploy.yaml parse; exactly one ^on: line in each (re-checked after the last commit); triggers as intended (ci: pull_request/push/workflow_call; release: workflow_dispatch; deploy: push tags + workflow_call).

cz check: passes for both commit messages and for this PR title; cz check --rev-range d4b5818..HEAD passes.

Local cz bump (throwaway clone with a scratch bare remote): bumps 2.10.2 → 2.10.3, runs check_content_bump.py (OK), prints the echo, tags locally, and pushes nothing (remote HEAD and tag count unchanged). With no bumpable commit it exits 21 (NO_COMMITS_TO_BUMP).

Not verified (can only run after merge, on master)

• The Release workflow end to end: commitizen-action pinned at 0.27.1 treating exit 21 as "Nothing to release", the bump/tag push, increment: PATCH|MINOR, and the bumped / tag outputs.
• The deploy called through workflow_call (TAG / ref wiring, concurrency groups release vs production-deploy).
• Whether check_content_bump.py behaves in the Actions checkout (it needs the full fixture history; the bump job uses fetch-depth: 0).
• That an enforced ruleset would reject the bump push (inferred from the branch-protection docs).
• The weekmenu reference itself only proved test, pr-title and "Nothing to release" on GitHub, with checks unenforced.

Manual steps for the repo owner

1. Settings → General → Pull Requests: squash merging only, default message "Pull request title".
2. Confirm the deploy secrets exist (SSH_HOST, SSH_USER, SSH_PRIVATE_KEY, SSH_KNOWN_HOSTS, optional SSH_PORT). The v2.10.2 deploy ran green, so they should.
3. Leave the "Check naming" ruleset's required_status_checks rule off (it is currently disabled). deletion and non_fast_forward are safe to enable; they do not affect the bump push.
4. After merging: put a deliberately bad title on a throwaway PR and watch pr-title go red, then green after fixing it.
5. Run Actions → Release with increment: auto once. fix(idle) (fix(idle): keep screen on during the idle page too #38) is already unreleased, so expect a real 2.10.3 bump and deploy rather than "Nothing to release"; take a DB dump first only if migrations are pending.
6. Check the run's bump commit, v2.10.3 tag, new CHANGELOG.md section and the deploy smoke test.

🤖 Generated with Claude Code

https://claude.ai/code/session_01YJdTaQX9f79fBVtRXhPJQ7