CaltechExperimentalGravity / CaltechExperimentalGravity/system_ident

Does the trunk-based rule still hold for parallel (multi-developer, multi-agent) development?

Open
#25 0 comments 0 reactions 0 assignees View on GitHub
question
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.