Does the trunk-based rule still hold for parallel (multi-developer, multi-agent) development?
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Documentation
- Clarity
- Needs clarification
- Activity status
- Quiet
- Tech stack
- git, github-actions
- Domain
- ci-cd, developer-experience
Research direction
Read CLAUDE.md:41, .github/workflows/ci.yml, and the Open questions section in notes/cds-hardware-bringup-2026-08.md. Compare the current trunk-based rule with the proposed branch and pull-request alternative, including the acknowledged CDS exception. Done means the team chooses and records a convention, with any required CI trigger change identified.
Written by the indexing model from the issue text.
Description
CLAUDE.md:41 states:
Trunk-based: commit and push to
main(no PRs/branches).
and CI has no pull_request trigger (.github/workflows/ci.yml), consistent with that.
The CDS hardware campaign is running on a long-lived branch
(feat/cds-hardware-backend) as an explicit, acknowledged exception — the work touches
loop.py, safety.py, config.py, cli.py and base.py and is not safe to land incrementally on main
while it is half-wired.
The rule reads as written for a single-developer, single-agent workflow. It is not obvious it is still
the right default now that several people are working here, each driving their own agents: concurrent
pushes to main from independent agent sessions have no review point and no way to detect a semantic
conflict.
The rule has deliberately not been changed — only annotated with a dated note pointing here.
Question for whoever owns the convention: should it stay as-is (with branches as case-by-case exceptions),
or be relaxed to "branch for anything spanning more than one module, PR-review before merge", which would
also mean adding a pull_request CI trigger?
Context: notes/cds-hardware-bringup-2026-08.md §Open questions.
Campaign: CDS hardware backend · branch feat/cds-hardware-backend
· spec · plan · handoff
Code is deferred until the plan and issues have been reviewed.
- Dominant language
- Python
- Stars
- 0
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from CaltechExperimentalGravity/system_ident
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 15/100
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 25/100
All issues in CaltechExperimentalGravity/system_ident
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
pydot/pydot#601 · 4 comments ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
letsencrypt/cp-cps#361 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
CI: startup_failure because callers grant fewer permissions than ledger-app-workflows@v1 declaresPossibly taken @maykonmichel claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
LedgerHQ/app-boilerplate-rust#227 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
linuxmint/mintupdate#1107 ·