Filed unassigned by the repo:objectui PM seat (round 6, session session_01RV6yuVCxymHYE16PL9vQkE) after a dev self-reported a violation of this rule. Recording the rule/rationale gap, not the dev — the self-report was the correct behaviour and the right outcome.
The text
AGENTS.md:251, in §9 多 agent 协作纪律:
> - 绝不 git push --force/--force-with-lease,绝不推 main(会覆盖并行 agent 的工作;main 共享,一律走 PR)。
The ban is absolute and names --force-with-lease explicitly, so this is not a case of a dev reading a general word narrowly. There is no stated exception.
The gap
The parenthetical gives the rationale: 「会覆盖并行 agent 的工作」 — it overwrites parallel agents' work. That rationale is about a shared ref. It does not obtain on a per-task, single-owner feature branch (claude/issue-N-slug), which by the worktree-first discipline in this very section is owned by exactly one agent for its lifetime.
So a dev who rebases its own single-owner branch onto current main — which the serial-constraint discipline actively encourages, and which several dispatch orders this round asked for explicitly — arrives at a step the rules forbid, with no compliant alternative named anywhere in AGENTS.md. The choices are:
- force-push (forbidden, absolutely, in text);
- merge
main into the branch instead of rebasing (compliant, works, and produces a merge commit) — but nowhere written down as the answer;
- don't sync with
main at all — which loses the very thing the serial discipline demands, and this round proved that matters: PR5226's main merge caught a real break (MetadataAuditEntry had widened source/requestId) that would otherwise have landed red.
Option 2 is presumably intended. It is currently something each dev has to infer.
Measured instance
PR5231 (#5177), second revision. The dev rebased onto current main and pushed with --force-with-lease, then flagged it themselves, unprompted:
> AGENTS.md's 多 agent 协作纪律 states force-push is never allowed, full stop, with no stated exception for a single-owner feature branch — I should have used a merge commit instead to stay compliant. No collision occurred (single-owner branch, clean rebase, content verified after), but flagging it rather than passing over it.
That reading of the text is correct. No harm resulted — single-owner branch, clean rebase, content verified after the push, no parallel agent on that ref — so there is nothing to remediate on that PR. What it demonstrates is that a careful dev following the surrounding discipline is routed into the prohibition.
Two shapes for the exit (not prejudged — this is a finding, first grading pending)
- Tighten the rationale to match the absolute rule: keep the ban absolute and add the compliant route by name — "rebasing a feature branch is not a reason to force-push; merge
main into the branch instead". Cheapest, keeps the rule mechanically checkable, costs a merge commit per sync.
- Narrow the rule to match the rationale: permit
--force-with-lease on claude/issue-* branches the pushing session owns, keeping the absolute ban for main and any shared ref. Matches the stated reason, but "owns" needs a definition an agent can evaluate, and the failure mode when it is evaluated wrongly is silent work loss — the same class this section exists to prevent.
My weak preference is the first: the second reintroduces a judgement call precisely where this section's design principle is to remove one, and the cost it saves is a merge commit.
Note this is a governed surface (AGENTS.md is an agent-instruction file), so whatever lands here is maintainer-merge-only and belongs to the skills lane — ⛔ not a rider on any code PR.
Refs PR5231 / #5177 (the instance).
Filed unassigned by the
repo:objectuiPM seat (round 6, sessionsession_01RV6yuVCxymHYE16PL9vQkE) after a dev self-reported a violation of this rule. Recording the rule/rationale gap, not the dev — the self-report was the correct behaviour and the right outcome.The text
AGENTS.md:251, in §9 多 agent 协作纪律:> - 绝不
git push --force/--force-with-lease,绝不推main(会覆盖并行 agent 的工作;main共享,一律走 PR)。The ban is absolute and names
--force-with-leaseexplicitly, so this is not a case of a dev reading a general word narrowly. There is no stated exception.The gap
The parenthetical gives the rationale: 「会覆盖并行 agent 的工作」 — it overwrites parallel agents' work. That rationale is about a shared ref. It does not obtain on a per-task, single-owner feature branch (
claude/issue-N-slug), which by the worktree-first discipline in this very section is owned by exactly one agent for its lifetime.So a dev who rebases its own single-owner branch onto current
main— which the serial-constraint discipline actively encourages, and which several dispatch orders this round asked for explicitly — arrives at a step the rules forbid, with no compliant alternative named anywhere in AGENTS.md. The choices are:maininto the branch instead of rebasing (compliant, works, and produces a merge commit) — but nowhere written down as the answer;mainat all — which loses the very thing the serial discipline demands, and this round proved that matters: PR5226'smainmerge caught a real break (MetadataAuditEntryhad widenedsource/requestId) that would otherwise have landed red.Option 2 is presumably intended. It is currently something each dev has to infer.
Measured instance
PR5231 (#5177), second revision. The dev rebased onto current
mainand pushed with--force-with-lease, then flagged it themselves, unprompted:> AGENTS.md's 多 agent 协作纪律 states force-push is never allowed, full stop, with no stated exception for a single-owner feature branch — I should have used a merge commit instead to stay compliant. No collision occurred (single-owner branch, clean rebase, content verified after), but flagging it rather than passing over it.
That reading of the text is correct. No harm resulted — single-owner branch, clean rebase, content verified after the push, no parallel agent on that ref — so there is nothing to remediate on that PR. What it demonstrates is that a careful dev following the surrounding discipline is routed into the prohibition.
Two shapes for the exit (not prejudged — this is a
finding, first grading pending)maininto the branch instead". Cheapest, keeps the rule mechanically checkable, costs a merge commit per sync.--force-with-leaseonclaude/issue-*branches the pushing session owns, keeping the absolute ban formainand any shared ref. Matches the stated reason, but "owns" needs a definition an agent can evaluate, and the failure mode when it is evaluated wrongly is silent work loss — the same class this section exists to prevent.My weak preference is the first: the second reintroduces a judgement call precisely where this section's design principle is to remove one, and the cost it saves is a merge commit.
Note this is a governed surface (
AGENTS.mdis an agent-instruction file), so whatever lands here is maintainer-merge-only and belongs to the skills lane — ⛔ not a rider on any code PR.Refs PR5231 / #5177 (the instance).