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

Pillar: P3 Fork tree (umbrella #589). One run, started fresh from today's main.

Outcome (what a person sees). A repository's forks page shows the whole family as a tree, with how far each fork is ahead or behind, and the owner of a fork chooses how it follows its upstream; a fork ahead can offer its change up in one action.

Today. src/core/following.ts has lineageOf ("the family as a tree") and forkRelation; src/web/pages/following.ts has lineageCard and followingCard; POST /:owner/:name/following exists.

Acceptance.

• [x] /:owner/:name/forks draws the family: parents up, children down, each node with ahead/behind and a link.
• [x] On a fork you own: follow mode take green updates automatically, tell me, or don't follow, saved and honoured by converge.
• [x] A fork ahead of its upstream shows "Offer this change" (the existing proposeUpstream).

Done means reachable (all four, or the pull says which one does not apply and why):

• Page: the forks page
• MCP: following returns the mode; a follow {repo, mode} tool sets it
• Test: the tree for three generations; each mode honoured by converge
• Look: a three-generation tree, on the pull

Start from: src/core/following.ts, src/crew/converge.ts, src/web/pages/following.ts, src/actions/upstream.ts, src/http/mcp.ts.

Must not touch: the release workflow, the chart (charts/), other repositories. Do not build cross-forge following here (#423).

Added acceptance (owner's contract rule, now in the direction and docs/VISION.md):

• [ ] Contract: one interface per job. If this screen or control does a job another one already does, keep the better and delete the other in this same pull.
• [ ] Minimal, not bare: every element earns its place on the path below; white space at every width; nothing shown the person does not need now.
• [ ] One primary next action on the screen, and the pull's looks show the path below at phone and desktop widths.
• [ ] The pull says what it removes for every screen or control it adds.

The path: a fork owner from the repository page wants to see the family and set how this fork follows; the one action is choosing the follow mode (or offering a change up when ahead); they go back to the repository.

Parked by the crew: the check failed ("capacity: only a forge admin reads or changes it > an admin changes each one from the page, the API and MCP; a wrong value is refused; every change is kept") and the decider saw no point in another try (pull #994 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.

From the 2026-10-11 steering (#334): the three follow modes are the setting trevato asked for — take green updates automatically, tell me (propose only; the fork shows what is behind and offers to take it), don't follow. Add to the acceptance: a conflict while taking updates is a tell for the crew — an issue carrying the files in conflict, assigned to a builder when the repository has one — never a stuck state the owner must untangle by hand (extends #4; #1085 says the same across forges).

Parked by the crew: the check failed ("capacity: only a forge admin reads or changes it > an admin changes each one from the page, the API and MCP; a wrong value is refused; every change is kept") and the decider saw no point in another try (pull #1042 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.

Parked by the crew: the check failed ("every open pull's preview on the studio page > a change's page names its preview's data as its own copy and gives the moment it was taken; production's card does not") and the decider saw no point in another try (pull #1089 closed).

Parked twice since a person last spoke here, so it is the planner's now. Every reason:

1. the check failed ("capacity: only a forge admin reads or changes it > an admin changes each one from the page, the API and MCP; a wrong value is refused; every change is kept") and the decider saw no point in another try (pull #1042 closed)
2. the check failed ("every open pull's preview on the studio page > a change's page names its preview's data as its own copy and gives the moment it was taken; production's card does not") and the decider saw no point in another try (pull #1089 closed)

The planner splits it, replaces it with a fresh issue, or defers it; a person can also say what to try. Nothing starts here until then, and the board lists it.

Deferred behind the Later gate (#595). Both tries failed on the capacity and studio tests, which were red on main, not on this work. In the owner's order of 2026-10-12, the fork tree is seventh, after trust and calm, command, cutting noise, a forge in a link, harnesses, multiplayer and story. #1126 (reconnect a frozen mirror) carries the part he needs now: contributing to existing things. When the gate is open, re-plan this as two issues: the browsable tree, and how each fork follows.

To defer it, this is no longer linked under P3 (#589). The Later gate waits on every pillar umbrella, so leaving it under #589 would have made a loop.

Now deferred. Its last dependent, #1085, no longer waits on it: #1085 builds on today's following.

Released from Later to use the week's subscription: Under the allowed burn: 36% of the week left with 38% of its time gone, reset 2026-11-15 02:00 UTC, burning 0.2% an hour over the last 6 h against 0.2% allowed; speeding up to 5 of 5 slots and releasing the next issue.

Reviewed pull #10990 at its head: ticked /:owner/:name/forks draws the family: parents up, children down, each node with ahead/behind and a link.; On a fork you own: follow mode take green updates automatically, tell me, or don't follow, saved and honoured by converge.; A fork ahead of its upstream shows "Offer this change" (the existing proposeUpstream)..