* ci: publish a weekly SemVer release with GitHub-generated notes
Every Monday at 06:00 UTC the workflow tags master and publishes a GitHub
Release whose notes list the merged PR titles. tools/next_version.py picks the
version from the commits since the last release: type!: or a BREAKING CHANGE
footer is major, feat is minor, anything else is patch. A manual run can
override it. Weeks without commits are skipped, a master commit whose CI did
not pass is never released, and forks never run it.
* docs: point contributors and forks at weekly GitHub Releases
PR titles are now the release notes and their type sets the version, so
CONTRIBUTING and the PR template say so. README and SETUP describe releases
as weekly checkpoints that passed CI instead of pointing at CHANGELOG.md.
* chore(changelog): freeze at 1.7.4 and fail PRs that still edit it
Rolls [Unreleased] into [1.7.4] and rewrites the intro to point at GitHub
Releases. The structure test becomes a content pin: stale PRs carry entries
that git would merge cleanly into the frozen section, so any edit now fails
CI with a pointer to the PR title.
* fix(release): address review findings on the weekly release
Write access moves to the job; the override rejects existing or older
versions; next_version.py reports a missing tag instead of a traceback and
drops the unused rev argument; tests pin the fork guard and SHA-pinned
checkout. The frozen changelog drops the date written ahead of the release,
describes its guard accurately, and the guard skips on forks.
* chore(changelog): re-pin the frozen hash after rebasing onto master
* ci(release): compute the version with commitizen via setup-uv instead of an in-repo script
A week of only docs, chore or ci commits now ships nothing on its own, matching commitizen's conventional-commit bump rules; fix, refactor and perf bump patch.
The repository is moving from the MadsLorentzen personal account to the
ai-job-search-dev organization. GitHub redirects the old slug, but the
upstream-watch guard compares github.repository against the literal slug
and would start running the fork-only triage job on upstream itself, and
the upstream-check tool and its tests pin the slug too. README, CONTRIBUTING,
SECURITY, SETUP, the CI workflow, the issue-template config and the
CHANGELOG links follow.
Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
An explicit maintainer invitation to a named contributor reserves the
implementation for them (default seven days, longer on request); duplicates
filed inside the window close in the invitee's favor. Prospective policy,
prompted by the second race on invited work in two weeks.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The list omitted security_guards.py and the exact unittest invocation;
the one recent contributor CI failure fitting #262's description (#238)
failed on precisely the omitted script. Reported by @jakob1379.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Addresses #213 (how to keep up with a fast-moving upstream) and closes the
verification loophole surfaced in the 2026-07-22 triage audit.
- Add CHANGELOG.md (Keep a Changelog + semver), with v1.0.0 as the first
tagged baseline and an Unreleased section for going forward.
- SETUP.md section 8: recommend updating to a tagged release (a vetted,
described checkpoint) over pulling raw master; fetch --tags and merge a tag.
- README: add a "Staying up to date" pointer to Releases, the CHANGELOG, and
check_upstream_updates.py.
- CONTRIBUTING.md: sharpen "Claims get verified" - a test that distinguishes
master from the fix is necessary but not sufficient; the failing input must
be one the workflow actually produces, not one the test hand-builds. Fixes
demonstrated only through a synthetic input the real code path never receives
get declined even when their test is green.
Note: the git tag / GitHub Release for v1.0.0 is intentionally left for the
maintainer to cut.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Three personalized-fork PRs (#155, #162, #165) were filed against
upstream by accident in one week - GitHub points new fork PRs at the
upstream repo by default, and nothing warned about it at the moment of
filing. Adds a PR template with the heads-up in the compose box (plus
the review norms the process asks for anyway) and one sentence in
CONTRIBUTING's fork section naming the mechanism.
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Writes down the architecture decision from the #78 discussion (2026-07-15):
Claude Code is the reference runtime; other agent runtimes are supported at
the edges via the portable portal skills in .agents/skills/, the root
AGENTS.md signpost, and thin-pointer community forks. Per-runtime command
trees stay in forks for the same reason market portals do.
README gets one line in Prerequisites; CONTRIBUTING gets the policy section
beside the market-skills rule it mirrors, including the explicit revisit
conditions.
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* Add framework_version markers to assistant skills and implement CI version guard and update checker
* Address review feedback: update ci.yml based on latest upstream, gate CI version guard to upstream repo, and remove non-ASCII characters from check_upstream_updates.py
GitHub auto-links #N only in issue/PR comments and commit messages, not
in rendered markdown files - so all 26 precedent references in
CONTRIBUTING.md ((#30), (#55, #56), ...) render as plain text, and the
reader can't jump to the precedent being cited.
Converted every bare #N to a reference-style link ([#N] in prose, URL
definitions collected at the bottom of the file). Definitions use the
/issues/N form, which GitHub redirects to /pull/N when the number is a
PR, so each link resolves correctly whether it points at an issue or a
pull request. No prose changed; existing inline links (the Discussions
URLs) untouched.
Co-authored-by for incorporated code; named commit/PR mention for
independently written fixes derived from reports. Prompted by the
question in #66.
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Codifies what has so far lived in PR closing comments: the universal-
template rule, merge/decline criteria with precedent links, the
feature-complete command bar, the empirical-verification standard,
and the fork path via /add-portal and the community forks discussion.
GitHub auto-surfaces CONTRIBUTING.md on new PRs and issues; README
gets a one-line pointer for browsers.
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Jakob Stender Guldberg