[jakob1379]

Summary

The hand-edited CHANGELOG.md is replaced by a weekly GitHub Release. Every PR edited [Unreleased], so every PR after the first conflicted on it, and only Mads could cut a release.

every Monday 06:00 UTC (or Run workflow)              .github/workflows/release.yml
  skip unless repo == ai-job-search-dev/ai-job-search
  last = latest GitHub Release                         v1.7.3 today
  skip if master == last
  next = cz bump --get-next (commitizen via setup-uv)   or the manual override
           any `type!:` / BREAKING CHANGE: -> major
           any `feat`                       -> minor
           any `fix` / `refactor` / `perf`  -> patch
           only docs / chore / ci / ...     -> skip the week
  fail unless ci.yml passed on master HEAD
  fail if next exists or is not newer than last
  gh release create next --generate-notes              same format as pingdotgg/t3code

 .github/
+├── workflows/release.yml          # weekly tag + generated notes, no commit to master
 ├── PULL_REQUEST_TEMPLATE.md       # + "PR title is the release note and sets the version"
+.cz.toml                           # commitizen: conventional commits, versions from v* tags
 tests/
+├── test_release_workflow.py       # fork guard, job-scoped write access, SHA-pinned actions
 ├── test_changelog_structure.py    # [Unreleased] structure checks -> content pin (upstream only)
 CHANGELOG.md                       # [Unreleased] -> [1.7.4], intro points at Releases, frozen
 CONTRIBUTING.md / README.md / SETUP.md   # releases are weekly checkpoints that passed CI

The CHANGELOG's [Unreleased] entries become its last section, [1.7.4], in this PR instead of a separate hand-cut release. The heading has no date because the tag doesn't exist yet.

Evidence

• Before: stale PRs that add a changelog entry mid-section would merge cleanly into a frozen section. Nothing chose the version.
  After: commitizen 4.19.3 replayed on our own tags:

  cz bump --get-next   (run at each next release commit)
  v1.6.0 -> 1.7.0   (Mads: 1.7.0)
  v1.7.0 -> 1.8.0   (Mads: 1.7.1, feat shipped as patch)
  v1.7.1 -> 1.8.0   (Mads: 1.7.2, 7 feats)
  v1.7.2 -> 1.8.0   (Mads: 1.7.3)
  v1.7.3 -> 1.7.4   (master today: 64 commits, 53 fix, 0 feat)
  

• Tests: tests/test_release_workflow.py (3) and tests/test_changelog_structure.py (1) pass, and the guard skips with GITHUB_REPOSITORY=someone/fork.

  • Full suite: 879 tests, 3 failures in test_check_framework_version. The same 3 fail on master without this change in this environment (environmental).
  • lint_skills, check_framework_version and security_guards are OK.

• Review: approved by Mads. converge-review ran with 4 independent seats, then a scoped re-review by 2 fresh seats.

  • Both re-review seats verdicted all 10 accepted findings addressed, except one deferred by design (below), and found no new breakage.
  • Fixes from the review:
    • write permission moved to the job;
    • the manual override rejects existing or older versions;
    • tests pin the fork guard and the SHA-pinned checkout;
    • the hash guard skips on forks;
    • a missing tag gives a clean error instead of a traceback;
    • the date written ahead of the release was dropped.

Merge Danger

Door: two-way for the code; one-way for every release it publishes.

A published tag can be deleted, but forks may already have fetched it. Reverting this PR restores the old process apart from the frozen hash and the [1.7.4] heading.

Blast Radius: releases

• Right after merging, run the workflow manually with version = 1.7.4. The frozen [1.7.4] section and its compare link assume that tag. A feat or ! merged before the first Monday run would otherwise make it v1.8.0.
• Stale PRs that still edit CHANGELOG.md: master's ruleset has strict up-to-date checks off (strict_required_status_checks_policy: false), so a pre-freeze PR can merge on its old green CI. Master CI then fails the hash guard, and the release refuses to run until the edit is reverted. Turn on "require branches to be up to date", or re-run CI on those PRs before merging. To resolve the conflict: git checkout origin/master -- CHANGELOG.md.
• PR titles now decide the version. A feature titled fix: ships as a patch, and a docs:/chore:/ci: or untyped title doesn't trigger a release on its own.
  • The repo's squash title setting is COMMIT_OR_PR_TITLE (confirmed via the API), so a single-commit PR's version comes from its commit subject while the notes show the PR title. Set it to Pull request title (Settings → General → Pull Requests) so the bump and the notes use the same text.
  • Merge commits are also enabled: a merge-committed PR's own commits count towards the bump.
• Untested on GitHub itself: the workflow never ran (no actionlint, no live gh). A tag ruleset that blocks GITHUB_TOKEN would make the first run fail loudly.