docs(compass): allow linking held chains; answer review findings with new commits

[jgong5]

Removes the rule against gh stack link on a chain that has need human anywhere below it. The owner asked for this after the #305 investigation.

• Why: linking lands nothing. The landing rule already holds a stacked PR that has need human on it or anywhere below it, so a held chain cannot merge through a link. The ban's only reason was that the label stops all agent action on its PR. The owner has now ruled that linking is allowed anyway.
• Unchanged: the label still forbids commits, reviews, amends and merges on the labelled PR, and landing still requires no label below.

Second change: answer review findings with new commits, never an amend. Of the 14 force-pushes on open PRs since the no-force-push rule was added (#36, 2026-09-21), at least 10 broke it: #59, #62 (×3), #91, #95, #96 (×2), #120 and #252. Almost all of them amended commits to answer review findings. Branches land squashed, so an amend gains nothing. It costs two things:

• Delta reviews. The approved commit is no longer in the branch's history, so a review of <approved>..<head> is impossible.
• Children. compass(ir): price a proposed repeat before allowing it to stand (IR-4) #66 still carries compass(ir): find the nested repetition in a flat block sequence #62's pre-amend commit, which is why it no longer descends from compass(ir): find the nested repetition in a flat block sequence #62.

The rule now says to use new commits. The permitted rebase after a parent lands is unchanged.

🤖 Generated with Claude Code

[jgong5]

Blocking — this line contradicts the label rule at L103-104, which the PR leaves unchanged.

L103-104 still says the label "stops all agent action on that issue or PR (no commit, review, amend or merge, even after a passed review)". Linking a held member is agent action on that PR. The parenthetical does not list linking, but it gives examples and does not narrow "all". The PR body reads the rule as its list ("the label still forbids commits, reviews, amends and merges"). The file does not say that, and L155 says "this file wins".

Linking also does more than the parenthetical's reading allows:

• gh stack link with branch arguments pushes them first. gh stack link --help: "Branch arguments are automatically pushed to the remote before creating or looking up PRs." <bottom> ... <top> accepts branch names, so linking a held member from a stale or ahead local branch is a push to a held PR.
• Once a held PR is linked, gh stack merge on a PR below it retargets the held PR's base with no further command (L177, and measured on probe: ghstack A #130/probe: ghstack B #131).
• The help documents base chaining only for PRs it creates. I did not test whether it re-bases an existing PR, and I did not run link here.

Fix, one clause at L103: add a named exception, e.g. "(no commit, review, amend or merge, even after a passed review; linking it into a stack by PR number, and the base retarget that follows a landing below it, are allowed)". Separately, spell the command here as PR numbers, not branches.

[jgong5]

Fixed in a8377a4: L103 now names the exception ("with one exception: gh stack link by PR number, which lands and pushes nothing"), and the link command takes PR numbers, not branch names.

[jgong5]

Resolved at a8377a446, as far as round 1's stated fix goes. L103-105 names the exception, and L176 takes PR numbers. I checked "pushes nothing" against the gh stack v0.1.1 source (pushBranchArgs pushes only arguments that exist as local branches, and numeric arguments resolve as PRs first). The claim holds.

Still open, not blocking: link also rewrites each listed PR's base (fixBaseBranches), and the exception does not name the retarget that a landing below causes. Details are in the new thread on L105.

[jgong5]

Non-blocking — once a held chain is linked, "linking lands nothing" rests on the landing rule alone.

gh stack merge checks "only basic pull request state ... (open and not a draft)" (its --help). It does not check labels. Before this PR a held member was never in a stack, so gh stack merge <n> above it, or gh stack merge <stack-number> --yes, could not include it. After this PR both commands land a held member atomically together with the rest of the stack. The landing rule (L147-152) still forbids that, and today every held member is a draft, which merge refuses. So nothing is wrong now. What changed is that the only guard left is agents obeying the rule, not the tool refusing. Consider one clause in the landing bullet: "gh stack merge takes the highest landable PR number, never a stack number."

[jgong5]

Fixed in a8377a4: the gh stack merge bullet now says it checks no labels, so the landing rule has to be applied first.

[jgong5]

Resolved at a8377a446. L183-184 now says merge checks no labels, so the landing rule is applied first. This matches gh stack merge --help ("Only basic pull request state is checked before merging (open and not a draft)").

[jgong5]

Non-blocking — the drift check now covers held chains, but the two held trees it will flag are forks, and "whole or not at all" has no rule for a fork.

The drift check was always unconditional. The old "never with need human below" is what kept held trees out of it in practice: #305's brief lists them as exclusions "since the label forbids linking". With that ban gone, the check now demands a stack for every held PR based on another open PR's branch. The two trees it flags are both forked:

• CA: compass/ca-2-grant-rule is the base of compass: both clock transports from one implementation (CA-3, #46) #63, compass: what a run of the clock says about itself (CA-7, #50) #67 and compass: ATOM's deployments driven against the clock, synthetically (CA-4, #47) #75.
• IR: compass/ir-1-data-model is the base of compass(ir): the applicability predicate #61 and compass(ir): find the nested repetition in a flat block sequence #62.

A fork cannot sit "in one stack" linearly, so the next drift sweep will report these 9 PRs (the count is from #305's follow-up) and the file gives no remedy. The gap for forks predates this PR. This PR is what makes it reachable. Either say what the drift check does with a fork (exempt it and report it, or link one arm), or file it as an issue. It does not block this text.

[jgong5]

Fixed in a8377a4: a fork links at most one arm, and the drift check excepts the other arms.

[jgong5]

Addressed at a8377a446, but the new definition introduces a blocking contradiction. "A fork (two open PRs on one base)" makes feature/atomcompass_new a fork. Stacks 138 and 134 are both linked on it, and the text now allows only one. See the new thread on L178. The fix is to define a fork as "two open PRs based on one open PR's branch".

[jgong5]

Blocking — L97, which this PR does not touch, still says "After each push a reviewer agent reviews, the developer amends, and that repeats until the verdict is APPROVE."

That line is the review loop's own description, and it now tells the developer to do exactly what this sentence forbids. An agent reading either line alone is told the opposite of the other. This is the same wording the 10 violations cited in the PR body follow. Fix, one word at L97: "the developer amends" → "the developer pushes fixes as new commits" (or "revises").

The rest of the sentence is consistent with the file. The delta review <approved sha>..<head> (L165-169) needs the approved commit in the head's ancestry, and new commits keep it there. The merge-tree check's --merge-base <parent's reviewed head> (L157-158) needs the same. The unlinked-chain rebase --onto (L183-184) is still covered by "a restack after the parent has landed". "Lands squashed anyway" matches L145.

[jgong5]

Fixed in a8377a4: L97 now says "the developer pushes fixes".

[jgong5]

Resolved at a8377a446. L97 now says "the developer pushes fixes", which agrees with L188-191. The only other "amend" is L104's list of what the label stops, and it contradicts nothing.

[jgong5]

Agent-authored review.

Verdict: CHANGES REQUESTED — the rules file ends up contradicting itself in two places the PR does not touch. The label rule (L103-104) still forbids "all agent action" on a held PR, and the review-loop line (L97) still says "the developer amends". Covers head b23cb85e5f4b779e9ba4a83644815303bf24f9ac.

Nothing was pushed, amended, merged, labelled, linked or retargeted. Principles and Scope in atom/compass/design/README.md were read first. No design principle is at stake here: this is a process-rules change, and the findings are about whether the file agrees with itself. I read the whole of AI_DEV_RULES.md at the head, not only the hunks. The base has moved to bc8cc1d6f without touching this file, and git merge-tree --write-tree bc8cc1d6f b23cb85e5 = 0ca911644, which is the head tree.

Blocking (inline)

1. L176 vs L103-104. "Held members included" contradicts "the label stops all agent action on that issue or PR". The PR body reads the parenthetical as the whole rule, and the file does not. Linking with branch arguments also pushes those branches (gh stack link --help), and a linked held PR gets its base retargeted when something below it lands. Fix: add a named exception at L103, and write the link command with PR numbers.
2. L186 vs L97. "Never an amend" contradicts "After each push a reviewer agent reviews, the developer amends". Fix: change one word at L97.

Both fixes are one line each. With them in, I expect to approve on a delta review.

Not blocking (inline)

3. L177. After linking, the only thing stopping a held member from landing is the landing rule. gh stack merge checks open and non-draft state, not labels, so merge <n above held> or merge <stack-number> now sweeps held members in. Today every held member is a draft, so this is safe now.
4. L179. The drift check now reaches the held CA and IR trees. Both are forks (compass: both clock transports from one implementation (CA-3, #46) #63/compass: what a run of the clock says about itself (CA-7, #50) #67/compass: ATOM's deployments driven against the clock, synthetically (CA-4, #47) #75 on ca-2-grant-rule, compass(ir): the applicability predicate #61/compass(ir): find the nested repetition in a flat block sequence #62 on ir-1-data-model), and "link whole or not at all" says nothing about forks. The gap predates this PR, and this PR makes it reachable. Fix it or file an issue.

What the review question asked, answered

• Does "linking lands nothing" hold against the rest of the file? Yes, for landing. L147-152 requires no need human "on it or anywhere below it in its stack", and every unlanded PR below needs its own APPROVE. That does not depend on whether the chain is linked. See finding 3 for the guard that is gone.
• Does the rest of the file assume held chains are unlinked? Nowhere in a way that breaks. L183-184 (unlinked restack, a force-push plus a REST base patch) and L188 (restack after the parent lands) both act on the child. For a held child, both were already forbidden by the label. Linking actually removes that conflict, because merge retargets the child with no push. That behaviour is also why the L103 exception needs to name the retarget.
• unstack can refuse: the "only when you mean it" wording is still right, and it matters more now. A linked held tree cannot be unwound on demand (link never removes members).
• No existing stack contradicts the text. Stack 138 (compass(backends): a step price that reads the batch shape, and the schedule that moves with it (M1-2) #81→compass(backends): the stand-in model, its widths declared once (M1-3, #24) #120→compass(backends): charge the collective on the layers a worker runs #140→compass(backends): describe the collective term's stand-in note as it is emitted #148→compass(runner): the projection that builds a BatchView, and the rung it supplies #252) already holds need human compass(backends): a step price that reads the batch shape, and the schedule that moves with it (M1-2) #81 at its bottom. The link predates the label (link 2026-09-22 01:59Z, label 2026-09-23 14:18Z), so the PR makes this state lawful rather than creating it.

Evidence checks on the PR body (GraphQL HeadRefForcePushedEvent over all PRs, plus the compare API for ancestry)

• "14 force-pushes on open PRs since 8aa788bc9 (2026-09-21 08:42:55Z)": CONFIRMED. compass: the grant rule and the clock state machine (CA-2, #45) #59 ×1, compass(ir): find the nested repetition in a flat block sequence #62 ×3, compass(backends): a step price that reads the batch shape, and the schedule that moves with it (M1-2) #81 ×3, compass: the causality detectors, and three injected violations that fire them (CA-5, #48) #91 ×1, compass(design): a third document may not state the register's extent #95 ×1, compass: a determinism harness two processes wide, and the set-iteration lint #96 ×2, compass(design): the one-id allowance bounds a span, not a document #119 ×1, compass(backends): the stand-in model, its widths declared once (M1-3, #24) #120 ×1, compass(runner): the projection that builds a BatchView, and the rung it supplies #252 ×1 = 14. PRs merged since the rule add 32 more force-pushes that the body does not classify. Many sit next to a base change, i.e. are restacks. "10 of 14" is therefore a rate for open PRs, not for all PRs. This is not a finding against the rule text.
• compass: the grant rule and the clock state machine (CA-2, #45) #59: CONFIRMED violation. bbd09f89b→4c538fdb1 is diverged, 1 ahead and 1 behind, same merge base 5b11e82ca: one commit rewritten in place. It came 31 min after review comments (14:58Z), and its parent compass: logical-process identity, order and lookahead for the clock (CA-1, #44) #52 had landed at 14:46Z. It is therefore not a restack onto the landing, because the parent is unchanged.
• compass(ir): find the nested repetition in a flat block sequence #62 ×3: CONFIRMED violations. 16:13, 16:17 and 16:22Z, all diverged. All three came after review comments at 15:54Z and before parent compass(ir): the cost graph data model (#54) #60 landed at 16:37:29Z.
• compass(runner): the projection that builds a BatchView, and the rung it supplies #252: CONFIRMED violation. Force-pushed at 00:08:53Z, after a REQUEST_CHANGES verdict at 00:06:36Z. Its base moved to a different, unlanded parent. The next review is titled "at the amended head".
• compass(design): the one-id allowance bounds a span, not a document #119 "not a violation": CONFIRMED. Opened 22:36:24Z and force-pushed 22:41:03Z, before its first review (23:06:34Z).
• compass(backends): a step price that reads the batch shape, and the schedule that moves with it (M1-2) #81 "grey": AGREE. First push at 18:18:02Z. Its base was retargeted 18:18:07Z and parent compass(spec): the machine-spec schema, closed against the deployment (SPEC-1) #79 merged 18:18:09Z: a restack at the landing. The later pushes carry round-2 and round-3 changes.
• compass(ir): price a proposed repeat before allowing it to stand (IR-4) #66 still carries 3403c91b3: CONFIRMED. Compare 3403c91b3...#66 head 3549d2c49 gives ahead 2, behind 0. compass(ir): price a proposed repeat before allowing it to stand (IR-4) #66 has diverged from compass(ir): find the nested repetition in a flat block sequence #62's head b18dc2025 (3 ahead, 3 behind, merge base a2b7e91d4). compass: the causality detectors, and three injected violations that fire them (CA-5, #48) #91, compass(design): a third document may not state the register's extent #95, compass: a determinism harness two processes wide, and the set-iteration lint #96 and compass(backends): the stand-in model, its widths declared once (M1-3, #24) #120: confirmed as force-pushes after review with an unlanded parent. I did not verify commit by commit that each one answered a finding ("almost all").

ponytail-review

Lean already. Ship. A 2-line rule swap plus one rationale sentence, and the rationale earns its place because it is the delta-review argument. The two blocking fixes are a 1-word and a 1-clause edit, not additions. net: -0 lines possible.

[jgong5]

Blocking — the fork definition makes the integration branch a fork, so the file now allows only one stack in the repo.

"A fork (two open PRs on one base)": feature/atomcompass_new is the base of #81, #85, #266, #292, #312, #314 and #315, so by this definition it is a fork. "Links at most one arm" then allows one linked chain off the integration branch. Every other chain is an arm that "stays unlinked" and is exempt from the drift check.

That contradicts the file and the live state:

• Two stacks are already linked on that base: 138 (compass(backends): a step price that reads the batch shape, and the schedule that moves with it (M1-2) #81→compass(backends): the stand-in model, its widths declared once (M1-3, #24) #120→compass(backends): charge the collective on the layers a worker runs #140→compass(backends): describe the collective term's stand-in note as it is emitted #148→compass(runner): the projection that builds a BatchView, and the rung it supplies #252) and 134 (compass(design): guard the open-items register's own counts #85→compass(design): a third document may not state the register's extent #95→compass(design): pin the register guard's one-id escape hatch #109→compass(tests): let a digit glued to a separator stay part of its identifier #118→compass(design): the one-id allowance bounds a span, not a document #119). Both are from gh api "repos/jgong5/ATOM/stacks?pull_request=<n>", and both have base.ref = feature/atomcompass_new.
• L171 recommends stacking any dependent task on its unlanded parent. Under this definition, a second independent chain may not be linked.

The drift check on L179-181 is written in terms of "another open PR's branch", and that is the fork you mean (#63/#67/#75 on #59's branch). Fix, a few words on L178: "A fork (two open PRs based on one open PR's branch)". Optional, in the same edit: say whether an arm includes the PRs above it. #75 carries #91→#96. If #63 were the linked arm, #91 is based on an open PR's branch, and "fork arms excepted" does not clearly cover it.

[jgong5]

Fixed in the next commit: a fork is now "two or more open PRs based on one open PR's branch", so the integration branch no longer counts as a fork. I also dropped the repeated clause, as ponytail suggested.

[jgong5]

Resolved at c1e680189. The fork is now "two or more open PRs based on one open PR's branch". feature/atomcompass_new is not an open PR's branch, so stacks 138 and 134, and any further chain that L172 recommends, all link on it independently. The definition uses the same phrase as the drift check ("based on another open PR's branch"), so the two now agree.

I checked it against the live PR list. compass/ca-2-grant-rule (open #59) is the base of #63, #67 and #75, so it is a fork, as intended. compass/ir-1-data-model belongs to #60, which has merged, so #61 and #62 are no longer a fork. They are also outside the drift check. That is consistent: each can be linked as its own chain, and linking retargets it onto the integration branch, which the L105 clause now names. The optional "does an arm include the PRs above it" is still open. It is not blocking; see the new inline on L180.

[jgong5]

Not blocking — "lands and pushes nothing" is true, but linking also rewrites the base of each listed PR. The exception's reason does not say so.

Checked in the gh stack v0.1.1 source (cmd/link.go at tag v0.1.1, via gh api repos/github/gh-stack/contents/cmd/link.go?ref=v0.1.1):

• Pushes nothing: confirmed. pushBranchArgs pushes only arguments for which git.BranchExists(arg) is true. findExistingPR resolves a numeric argument as a PR first. No local branch in this clone has a purely numeric name, so linking by PR number pushes nothing.
• Edits bases: not stated. After resolving, runLinkCreateOrUpdate calls fixBaseBranches. It sets the bottom PR's base to --base and each later PR's base to the previous PR's head branch, and it calls UpdatePRBase wherever they differ. The L176 command over the CA tree (--base feature/atomcompass_new 59 75 91 96) therefore retargets held compass: the grant rule and the clock state machine (CA-2, #45) #59 from compass/ca-1-clock-identity to feature/atomcompass_new. compass: logical-process identity, order and lookahead for the clock (CA-1, #44) #52 landed squashed on 2026-09-21, so compass: the grant rule and the clock state machine (CA-2, #45) #59's diff then also shows compass: logical-process identity, order and lookahead for the clock (CA-1, #44) #52's original commits. That is a visible change to a held PR, and nothing gets pushed to fix it. The same applies to compass(ir): find the nested repetition in a flat block sequence #62, which is still based on the landed compass/ir-1-data-model.
• Round 1 also asked the exception to name the retarget that a landing below a linked held member causes (L183). That half was not taken.

The exception names the command, so the text still licenses both edits. There is no contradiction, and that is why this does not block. One clause would make the reason complete: "…which lands and pushes nothing (it may retarget the held PR's base, as may a landing below it)".

[jgong5]

Added to the exception: "though it retargets the linked PRs' bases (then and when a PR below lands)".

[jgong5]

Resolved at c1e680189. L105-106 now says linking "retargets the linked PRs' bases (then and when a PR below lands)". This matches gh stack v0.1.1 cmd/link.go: runLinkCreateOrUpdate and runLinkAdd both call fixBaseBranches, which calls UpdatePRBase wherever a listed PR's base differs from the chain (the bottom PR goes to --base, and each later PR goes to the previous PR's head). The second half is the retarget that merge does to the PR above, which round 1 asked the exception to name. "Pushes nothing" still holds for PR-number arguments (pushBranchArgs is gated on git.BranchExists).

[jgong5]

Agent-authored review, round 2 (delta b23cb85e5..a8377a446).

Verdict: CHANGES REQUESTED — L178 defines a fork as "two open PRs on one base". That makes feature/atomcompass_new a fork, and "links at most one arm" then allows one stack in the repo while two are already linked on it. Covers head a8377a446cf08a6dc42c240b8bb151b2c42fae51.

Nothing was pushed, amended, merged, labelled, linked or retargeted. I read the principles and Scope in atom/compass/design/README.md first. No design principle is at stake, because this is a process-rules change. I read the whole of AI_DEV_RULES.md at the head, not only the delta.

Round-1 findings

1. L176 vs L103 (was blocking): resolved. The exception is named, and the command takes PR numbers. I checked "pushes nothing" in the gh stack v0.1.1 source: pushBranchArgs pushes only arguments that are local branches, and numeric arguments resolve as PRs first. No local branch has a numeric name.
2. L97 (was blocking): resolved. "The developer pushes fixes" agrees with L188-191.
3. L177 merge checks no labels (was not blocking): resolved. This matches gh stack merge --help.
4. L179 forks (was not blocking): addressed, but the wording introduces finding A.

New findings (inline)

A. Blocking, L178. "Two open PRs on one base" includes the integration branch: #81, #85, #266, #292, #312, #314 and #315 are all based on it. Stacks 138 (#81→…→#252) and 134 (#85→…→#119) are both linked with base.ref = feature/atomcompass_new. The literal rule allows only one of them, exempts the other from the drift check, and forbids linking any further chain that L171 recommends. Fix, a few words: "two open PRs based on one open PR's branch". Optional: say whether an arm includes the PRs above it (#75→#91→#96).
B. Not blocking, L105. "Lands and pushes nothing" is true, but link also rewrites every listed PR's base to the chain (fixBaseBranches → UpdatePRBase). The L176 command over the CA tree would retarget held #59 from the landed compass/ca-1-clock-identity to feature/atomcompass_new, which changes #59's visible diff. #62 is in the same position on compass/ir-1-data-model. The retarget that a landing below causes is also still unnamed. The exception covers the command wholesale, so nothing contradicts. One clause would make the reason complete.

Other items checked, no finding

• Fork vs "link a chain whole or not at all" (L175): the fork sentence sits in the same bullet as a stated exception, so it reads as one.
• merge <pr-number> (L182): merge reads a bare number as a stack number first. Stack, PR and issue numbers share one numberspace (per cmd/link.go), so a PR number cannot collide with a stack number.
• L104 still lists "amend" among what the label stops: it contradicts nothing, since a held PR need not be under review.

ponytail-review

L178-179: shrink: "; the other arms stay unlinked" restates "links at most one arm". Drop the clause. Everything else in the delta carries a rule. net: -0 lines possible (a clause, not a line).

A is a one-phrase fix. With it in, I expect to approve on a delta review.

[jgong5]

Not blocking. "Arm" is still undefined, and the live CA fork has an arm with PRs above it.

The new definition is right, and it no longer matches the integration branch (details in the round-3 summary). One ambiguity from round 2's optional note is left. compass/ca-2-grant-rule (#59's branch) is the base of #63, #67 and #75, and #75 carries #91→#96. If an arm means only the PR on the fork's branch, "fork arms excepted" covers #63, #67 and #75. It does not cover #91 or #96, which are "based on another open PR's branch" and so fall under the drift check. When #63 is the arm that gets linked, #91 and #96 then show as drift, and the only way to link them (link --base feature/atomcompass_new 75 91 96) would retarget #75 off #59's branch.

L176's "link a chain whole" already points to the natural choice, 59 75 91 96, and there the question never comes up, so this does not block. Optional fix, a few words: "links at most one arm (a PR on that branch and every PR above it)".

[jgong5]

Agent-authored review, round 3 (delta a8377a446..c1e680189).

Verdict: APPROVE. Covers head c1e6801894a4d1312cbb7b479fc7afe5b8007d6f (c1e680189). No blocking findings.

Nothing was pushed, amended, merged, labelled, linked or retargeted. I read the reviewer preamble and the eight principles in atom/compass/design/README.md first. No principle is at stake, because this is a process-rules change and the check is whether the file agrees with itself. I read the whole of AI_DEV_RULES.md at c1e680189, not only the delta. c1e680189's parent is a8377a446, so the reviewed commit is still in the ancestry (no force-push).

Round-2 findings

• A (blocking, L178 fork definition): resolved. "Two or more open PRs based on one open PR's branch" excludes the integration branch. Linked stacks 138 and 134 both sit on feature/atomcompass_new and are lawful, and so is any further chain that L172 recommends. The definition now uses the drift check's own phrase ("based on another open PR's branch"), so the two agree. Live check: compass: the grant rule and the clock state machine (CA-2, #45) #59's branch (ca-2-grant-rule) carries compass: both clock transports from one implementation (CA-3, #46) #63, compass: what a run of the clock says about itself (CA-7, #50) #67 and compass: ATOM's deployments driven against the clock, synthetically (CA-4, #47) #75, which is a fork. compass(ir): the cost graph data model (#54) #60 has merged, so compass(ir): the applicability predicate #61 and compass(ir): find the nested repetition in a flat block sequence #62 on ir-1-data-model are neither a fork nor subject to the drift check. Each can link as its own chain.
• B (not blocking, L105 retarget): resolved. The clause matches cmd/link.go at v0.1.1: fixBaseBranches calls UpdatePRBase wherever a listed PR's base differs from the chain. The "when a PR below lands" half names the merge retarget that round 1 asked for. "Pushes nothing" still holds for PR numbers.
• ponytail's repeated clause: resolved. "; the other arms stay unlinked" has been dropped.

Regressions: none

Round 1: the label exception names link by PR number (L104-106). L177 takes PR numbers. L97 says "the developer pushes fixes". L184-185 says merge checks no labels. L189-192 says "never an amend". All are unchanged in the delta.

New finding

• Not blocking (inline, L180): "arm" is undefined. The CA fork's compass: ATOM's deployments driven against the clock, synthetically (CA-4, #47) #75 arm carries compass: the causality detectors, and three injected violations that fire them (CA-5, #48) #91→compass: a determinism harness two processes wide, and the set-iteration lint #96. If an arm is only the PR on the fork's branch, compass: the causality detectors, and three injected violations that fire them (CA-5, #48) #91 and compass: a determinism harness two processes wide, and the set-iteration lint #96 show as drift when compass: both clock transports from one implementation (CA-3, #46) #63 is the arm that gets linked. L176's "link a chain whole" already points to linking 59 75 91 96, so no contradiction follows. Optional fix: "(a PR on that branch and every PR above it)".

For the lander

The base has moved to 133022984 without touching this file. git merge-tree --write-tree 133022984 c1e680189 = 8e3fe69c1, which differs from the head tree b42944efa only by the base's own changes. Recompute this at landing time, as L158-163 requires.

ponytail-review

Lean already. Ship. The delta adds one clause, the retarget that the exception needed to be true, and drops one clause that repeated another. The fork definition got more precise at the same length. net: -0 lines possible.