[FEATURE] A dev branch stages each release; main holds the last release #95

Is Your Feature Request Related to a Problem?

Every pull request merges straight into main, so main is the release and the work in progress at once. Since 0.2.0 (2026-07-17), main has taken 26 commits and 35 changelog entries under Unreleased, and none of them has been through a release. Consumers install from main: agent-ui's traces extra is dsagt @ git+https://github.com/AI-ModCon/dsagt.git, which installs whatever merged last. dsagt has no place to collect and test changes before consumers get them.

Describe the Solution You'd Like

A dev branch that stages each release. main holds the last release.

• Branches. dev starts at the current main. Feature and fix pull requests target dev. main changes only by a release from dev or a hotfix.

• Release.

  1. A pull request into dev bumps the version and moves the changelog's Unreleased section under the version and date.
  2. A pull request from dev to main, titled Release <version>, gets review and CI.
  3. A maintainer with a bypass on main's ruleset fast-forwards main to dev (git push origin dev:main). GitHub marks the pull request merged when its head reaches main.
  4. The release is tagged on main and a GitHub release is made from the tag.

  A fast-forward keeps the same commits on both branches and satisfies main's linear-history rule. A squash or rebase-merge would give main new commit hashes, and dev and main would diverge after the first release.

• Hotfix. A branch from main, a pull request into main, a patch release, then main merged into dev.

• CI and docs. ci.yml and docs.yml add dev to their push and pull-request triggers, so pull requests into dev get the same checks and previews. The site still deploys from main, so the published docs describe the release.

• Consumers install a tag (git+https://github.com/AI-ModCon/dsagt.git@0.2.0) or main.

• Open pull requests are retargeted to dev: dsagt sets no MLflow active model #88, The knowledge tools name the collection one way, and say what a collection holds #92, The headless driver resumes a long walkthrough and may fetch what it grounds on #93, and The prerequisite names no platform #94. Add JSON output for reconstruction pipeline provenance #52 is also retargeted: it is the bottom of the Add JSON output for reconstruction pipeline provenance #52 → 45 sample contract #53 → Add skill for validating generated dataset #69 stack, and 45 sample contract #53 and Add skill for validating generated dataset #69 keep their bases.

This needs an admin for three settings:

1. A ruleset on dev matching main's review rule: a pull request with one approval, no deletion, no force-push.
2. A bypass on main's ruleset for whoever makes releases, so they can fast-forward.
3. main stays the default branch, so a clone or an unpinned pip install git+... gets the release. CONTRIBUTING.md then says pull requests target dev.

Describe Alternatives You've Considered

• main only, with release tags. Simpler. main then carries unreleased work, and a consumer is safe only when pinned to a tag.
• Release by merge commit, as neuromancer does with develop and master. This needs main's linear-history rule dropped, plus a merge of main back into dev after every release. neuromancer's master holds two hotfix commits that develop does not, which is the step this approach depends on.
• dev as the default branch. New pull requests would target dev automatically, but clones and unpinned installs would get unreleased code.

Additional Context

Once dev exists, a pull request into dev adds it to the workflow triggers and states the release steps in CONTRIBUTING.md. The retargeting follows that merge, so no pull request loses its checks.

An agent (Claude Code) drafted this issue; Aaron Tuor reviewed it.