CaltechExperimentalGravity / CaltechExperimentalGravity/system_ident
Does the trunk-based rule still hold for parallel (multi-developer, multi-agent) development?
- Dominant language
- Python
- Stars
- 0
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Description
[`CLAUDE.md:41`](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/CLAUDE.md#L41) states:
> **Trunk-based:** commit and push to `main` (no PRs/branches).
and CI has no `pull_request` trigger ([`.github/workflows/ci.yml`](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/.github/workflows/ci.yml)), consistent with that.
The CDS hardware campaign is running on a **long-lived branch**
([`feat/cds-hardware-backend`](https://github.com/CaltechExperimentalGravity/system_ident/tree/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`](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/notes/cds-hardware-bringup-2026-08.md) §Open questions.
---
**Campaign:** CDS hardware backend · branch [`feat/cds-hardware-backend`](https://github.com/CaltechExperimentalGravity/system_ident/tree/feat/cds-hardware-backend)
· [spec](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/docs/superpowers/specs/2026-08-03-cds-hardware-backend-design.md) · [plan](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/docs/superpowers/plans/2026-08-03-cds-hardware-backend.md) · [handoff](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/notes/cds-hardware-bringup-2026-08.md)
*Code is deferred until the plan and issues have been reviewed.*
Contributor guide
No contributing guide indexed for this repository
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.
Assessment
- Tech stack
- git, github-actions
- Domain
- ci-cd, developer-experience
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100