Decision needed: how obot.agent ships a release candidate (R1–R4)

[obotclaw[bot]]

The question. You set the rule tonight that a release candidate is a PR — assignee obotclaw[bot], reviewer @jwildfire, review formally requested — and that only RCs reach your queue. obot.agent cannot satisfy it: its integration branch is main, so work merges straight there and no branch is left to open a release PR from. The v0.4.0 draft release is the RC framework's own documented answer for that case, and you are right that it is not an RC. Which gives way — the roles rule, or the branch model?

The options, one line each.

R1 — change the rule, not the repo. Amend the roles rule so a draft GitHub release counts as an RC vehicle for single-branch repos. Ships v0.4.0 tonight, but "an RC is a PR" stops being an invariant and every consumer handles two shapes forever.

R2 (recommended) — add one lagging release branch. Create stable at the v0.3.0 commit; work keeps landing on main; each release is a main → stable PR whose diff is exactly the release window. One array edited in policy.json, reusing the shape demo-301 already runs.

R3 — the full safety.viz model. Create dev, switch the default branch, main becomes the release branch. Symmetric with every other repo, but a default-branch switch silently re-points 47 hard-coded blob/main links across 40 files, and obot.agent has no CI to catch what a reference sweep misses.

R4 — a throwaway release/vX.Y.Z base per release. Same review experience as R2 with a branch to create and delete every time. Worth knowing: the intuitive form — cutting the branch from main and PR-ing it back — produces an empty diff.

Recommendation: R2. It is the only option that satisfies the rule you set without changing how obot.agent is worked on. Strict superset of today, ~15 minutes, and v0.4.0 reaches you as a real RC PR the same night. R3 stays available later if two-branch bookkeeping ever earns its keep.

Full argument, costs, and what unblocks on each answer: https://jwildfire.github.io/obot.roadmap/reports/decisions/2026-08-14-obot-agent-rc-shape/

Until you answer, v0.4.0 stays an unpublished draft. Its notes, demo page and diff are all ready — only the vehicle is undecided.

---

This post was drafted by Claude Code using Opus 5 (👯🤖 oa-rc sibling session) and awaits @jwildfire's decision

[obotclaw[bot]]

Decision recorded: R2 accepted — @jwildfire, 2026-08-15, in a message to 🎩🤖 obot-prime. Verbatim:

I'm good with R2. Here's my general approach: I want to give agents a lot of space to self-improve on operational tasks, but maintain strict control of user-facing clinical work. So for obot repos, I'm good with agents proactively (and automatically) merging to production (aka main) and then fixing issues as they appear. periodic (weekly??) releases to 'stable' for housekeeping purposes (and to keep me fully in the loop) sound fine. For clinical work, I should review everything before it's pushed to prod. and releases should be formally documented as soon as they go live. One change i do want to make - every repo gets a news.md and it always stays updated in main. That way the obot repos have a running list of whats new and un-released. Unreleased items in news.md should just be listed under 'vX.X.X (Upcoming)' until the release is made in stable.

Implementation (in flight tonight, 👯🤖 gov session):

• stable branch cut at the v0.3.0 commit (bc9255a); releases become main → stable PRs on the attested lane.

• policy.json: obot.agent gains "release": ["stable"] — the one-array edit the artifact named, covered by this approval (the file is inside its own carve-out).

• docs/rc-framework.md corrected: obot.agent leaves the draft-release workaround; the demo-301 line-26/line-80 inconsistency the artifact flagged is fixed in the same pass.

• v0.4.0 then reaches you as a real RC PR — base stable, head main, RC roles (assignee obotclaw[bot], reviewer @jwildfire), body from NEWS.md, demo linked. It will not be merged, tagged, or published by an agent — that PR is your gate.

The rest of your message spawns two follow-ups, posted separately per the one-artifact-per-decision rule:

• The operational-vs-clinical classification of every repo — the clear cases recorded, the ambiguous ones (open.csr, open.gismo, demo-301) put to you as a numbered decision.

• A CI prerequisite flag: obot.agent currently has no CI at all, which matters before "automatically merging to production and fixing issues as they appear" goes live. Recommendation and minimum gate in the classification artifact.

• The NEWS.md + vX.X.X (Upcoming) convention lands in skills/rc-release-notes and docs/rc-framework.md, and the missing NEWS.md files are being seeded.

• Weekly-release cadence: noted as a dependency for the session-model design (Q&A #158) rather than designed twice — that thread reconciles the trigger.

---

This comment was drafted by Claude Code using Fable 5 (👯🤖 gov sibling session), recording @jwildfire's 2026-08-15 decision verbatim.