The fork tree, browsable, and each fork chooses how it follows #10990

A fork owner can now pick one of three ways to follow the parent from the fork's forks page. The new third mode, don't follow (dont-follow), is skipped by converge. The family tree on that page already existed on main, with parents above and children below, each linked.

The mode

• src/core/fork_follow.ts: FORK_FOLLOW_MODES is the chain's two modes (tell-me, take-updates) plus dont-follow. A migration rebuilds fork_follow with every row kept, so its CHECK admits the new mode. It is pinned, and listed as a rebuild in test/schema-additive.test.ts. The release before reads dont-follow as "not take-updates".
• setFollowMode in src/actions/follow.ts takes all three for a plain fork. A spawned forge's chain still takes only two and refuses dont-follow with invalid_mode, because a forge that wants to follow nothing severs. Cross-forge following (#423) is untouched.
• When the parent's default branch moves, follow in src/core/following.ts skips a dont-follow fork entirely: nothing is fast-forwarded or merged, and no fork.diverged event is raised. followDivergence in src/crew/converge.ts never converges one.

MCP

• following now returns mode.
• follow_mode accepts all three modes on a plain fork. I extended this existing tool rather than adding a follow tool; mcp-size passes and the docs/MCP.md table is regenerated.
• fork_tree names dont-follow in each node's follow.

Page

• On /:owner/:name/forks, the fork's admin sees the same Following card the repository page shows, above the family tree, without its link back to the forks page. Readers see only the tree.
• The card's single two-way toggle is gone. In its place are buttons for the other two modes ("Follow automatically", "Only propose updates", "Stop following"), each going through the confirm step.
• "Propose upstream" is now Offer this change, the existing proposeUpstream.
• A diverged fork's badge in the tree now gives its counts: "diverged · 3 ahead · 3 behind".
• Nothing new needed removing: the forks page reuses the one card, and the toggle it replaced is deleted.

Tests and docs

• test/fork-follow-mode.test.ts: when the parent moves, a dont-follow fork is neither moved nor told, while a tell-me fork beside it still catches up. This fails if the skip in follow is removed.
• test/fork-tree-web.test.ts: three generations on the forks page, all three mode switches for the owner and none for a reader, the confirm and POST for dont-follow, "Offer this change", and the MCP round trip.
• test/spawn-chain-mode.test.ts: a spawned forge refuses dont-follow.
• One existing test changed, because the issue renames the button: fork-tree-web asserted "Propose upstream". docs/features/follow-mode.md is rewritten for three modes.

Not done

• No screenshots. The three-generation tree at phone and desktop widths still has to be taken from the preview.
• No crew issue when an automatic take conflicts. The steering comment asks for an issue listing the files and assigned to a builder. Converge already opens one for diverged forks, but I did not change or re-test that path.
• "Take green updates" is not gated on the check. Automatic takes still merge whatever git merges cleanly.
• No plan on the issue. I had no keep_plan tool in this run.

Checks run: gate, type check, design-lint, mcp-size, and the follow, fork-tree, forks-timing, schema and MCP-table tests all pass. In the wider related set (2,409 passing), two tests fail with or without this change: guest-contribute needs outbound network that the sandbox refuses, and prompts depends on the time of day.

To try it: fork a repository and fork that fork. Open the middle fork's /forks page as its owner and switch the mode. Commit to the fork, then press "Offer this change".

🤖 Generated with Claude Code

Closes #608

A fork owner can now pick one of three ways to follow the parent from the fork's forks page. The new third mode, don't follow (dont-follow), is skipped by converge. The family tree on that page already existed on main, with parents above and children below, each linked.

The mode

• src/core/fork_follow.ts: FORK_FOLLOW_MODES is the chain's two modes (tell-me, take-updates) plus dont-follow. A migration rebuilds fork_follow with every row kept, so its CHECK admits the new mode. It is pinned, and listed as a rebuild in test/schema-additive.test.ts. The release before reads dont-follow as "not take-updates".
• setFollowMode in src/actions/follow.ts takes all three for a plain fork. A spawned forge's chain still takes only two and refuses dont-follow with invalid_mode, because a forge that wants to follow nothing severs. Cross-forge following (#423) is untouched.
• When the parent's default branch moves, follow in src/core/following.ts skips a dont-follow fork entirely: nothing is fast-forwarded or merged, and no fork.diverged event is raised. followDivergence in src/crew/converge.ts never converges one.

MCP

• following now returns mode.
• follow_mode accepts all three modes on a plain fork. I extended this existing tool rather than adding a follow tool; mcp-size passes and the docs/MCP.md table is regenerated.
• fork_tree names dont-follow in each node's follow.

Page

• On /:owner/:name/forks, the fork's admin sees the same Following card the repository page shows, above the family tree, without its link back to the forks page. Readers see only the tree.
• The card's single two-way toggle is gone. In its place are buttons for the other two modes ("Follow automatically", "Only propose updates", "Stop following"), each going through the confirm step.
• "Propose upstream" is now Offer this change, the existing proposeUpstream.
• A diverged fork's badge in the tree now gives its counts: "diverged · 3 ahead · 3 behind".
• Nothing new needed removing: the forks page reuses the one card, and the toggle it replaced is deleted.

Tests and docs

• test/fork-follow-mode.test.ts: when the parent moves, a dont-follow fork is neither moved nor told, while a tell-me fork beside it still catches up. This fails if the skip in follow is removed.
• test/fork-tree-web.test.ts: three generations on the forks page, all three mode switches for the owner and none for a reader, the confirm and POST for dont-follow, "Offer this change", and the MCP round trip.
• test/spawn-chain-mode.test.ts: a spawned forge refuses dont-follow.
• One existing test changed, because the issue renames the button: fork-tree-web asserted "Propose upstream". docs/features/follow-mode.md is rewritten for three modes.

Not done

• No screenshots. The three-generation tree at phone and desktop widths still has to be taken from the preview.
• No crew issue when an automatic take conflicts. The steering comment asks for an issue listing the files and assigned to a builder. Converge already opens one for diverged forks, but I did not change or re-test that path.
• "Take green updates" is not gated on the check. Automatic takes still merge whatever git merges cleanly.
• No plan on the issue. I had no keep_plan tool in this run.

Checks run: gate, type check, design-lint, mcp-size, and the follow, fork-tree, forks-timing, schema and MCP-table tests all pass. In the wider related set (2,409 passing), two tests fail with or without this change: guest-contribute needs outbound network that the sandbox refuses, and prompts depends on the time of day.

To try it: fork a repository and fork that fork. Open the middle fork's /forks page as its owner and switch the mode. Commit to the fork, then press "Offer this change".

🤖 Generated with Claude Code

Only one of the three failing checks came from this pull, and it's fixed and pushed. The other two pass here, both on this branch and when merged with the current main, so I couldn't reproduce them and left them alone.

The one I caused: "rule header-width" failed because I added a comment line longer than 160 columns at src/actions/fork_tree.ts:27, the doc comment on TreeFollow. I wrapped it into a block comment, which changes no behaviour.

The two I couldn't reproduce:

• "each return of the public door and of answered is floored" (test/security-sweep.test.ts): this pull doesn't touch the public door or answered.
• The 15 "a shared red …" cases (#8287, #8786, in test/sentinel-shared-settle.test.ts): this pull doesn't touch the sentinel.

Both files pass here on their own and after a trial merge with main (since aborted). If either fails again in the forge's check, the cause is probably in the check run itself, not this pull's code.

Before pushing I ran scripts/gate.ts and bun x tsc --noEmit, both clean. test/header-width.test.ts, test/fork-tree-web.test.ts and test/fork-follow-mode.test.ts all pass.

🤖 Generated with Claude Code

I couldn't make any of the 16 failing tests fail here, and none of them touch code this pull changes. Since the check builds this branch together with main, I merged the current main into the branch and pushed it so the next check runs on a tree that already has everything.

What I checked:

• "each return of the public door and of answered is floored" lives in test/security-floor-doors.test.ts, which exists only on main. It reads src/http/server.ts, which this pull doesn't change. It passes on current main and on the merged branch.
• The 15 "a shared red …" cases (#8287, #8786, test/sentinel-shared-settle.test.ts) pass on current main and on the merged branch. This pull doesn't touch the sentinel. The same file failed in a different shard on both runs, so the cause is most likely in how the check runs it, not in this code. If it fails again, it's worth looking at whether it fails on main's own check.
• The only failure this pull caused was in the previous run, a header comment over 160 columns in src/actions/fork_tree.ts. That fix was already pushed and doesn't appear in this log.
• On the merged branch, bun scripts/gate.ts and bun x tsc --noEmit are clean. These seven test files pass (48 tests): header-width, fork-tree-web, fork-follow-mode, schema-additive, spawn-chain-mode, security-floor-doors and sentinel-shared-settle.

About this pull itself: a fork can choose not to follow its parent. The merge with main in the setting is respected, and MCP can read and set the choice. The /forks page shows the family tree with how far each fork is ahead of or behind its parent. Its owner sees a Following card with the three modes, and an "Offer this change" button when the fork is ahead.

To try it on the preview: fork a repository, fork that fork, then open the middle fork's /forks page as its owner.

🤖 Generated with Claude Code

The two fixed Bun.sleep(300) waits in the dont-follow test in test/fork-follow-mode.test.ts are gone. The test now waits on a signal from the follow handler itself: the sibling tell-me fork reaching synced.

That signal is enough because nothing about a dont-follow fork happens later:

• commitToBranch announces the push before it returns, and the event bus calls follow straight away, not on a later tick.
• follow in src/core/following.ts decides to skip a dont-follow fork in the same pass of its loop that starts the sibling's fast-forward. A skipped fork gets no follow-up work at all.
• So once the sibling has settled, follow has nothing left to do for the skipped fork, and the "not moved, not told" checks that follow it are final. A comment in the test says this.

No product code changed. One fixed sleep is still in the file, in the older "tell-me leaves a fork … diverged" test, which is on main and not part of this pull. I left it alone.

Checked before pushing: scripts/gate.ts and bun x tsc --noEmit are clean, and test/fork-follow-mode.test.ts passed three runs in a row (8 pass, 0 fail each).

🤖 Generated with Claude Code