A new forge follows the topmost forge on its own: its forge repository takes updates by default, and a clean update merges itself #11148

New forges now follow their parent with take-updates by default, and an unchanged fork takes the parent's new code onto its default branch within one check. I ran the follow, spawn and new-forge test files plus bun x tsc --noEmit and bun scripts/gate.ts; all pass. I did not run the whole suite, since the forge's check runs it.

What changed

• Default mode (src/spawn/chain.ts): DEFAULT_MODE is now take-updates. This sets the mode for the web form, the terminal screen, MCP spawn, planSpawn and forkForgeCode. The /forges/new form preselects Take updates, and the new-forge words and MCP field text match.
• Existing forges: a link already stored keeps its mode. A link with no readable mode is still read as tell-me, as before.
• Plain forks: they still default to tell-me, through a separate FORK_DEFAULT_MODE in src/core/fork_follow.ts, because the issue is about spawned forges.
• Untouched fork (src/spawn/take.ts): in take-updates mode, when the fork's default branch is an ancestor of the parent's tip, the branch is fast-forwarded in place. It uses a compare-and-swap, so a push that lands meanwhile wins and the next check retries. It then emits the same push event a followed fork emits, so what follows a push follows this, plus a forge.updates_taken event. No pull is opened. The state records a new forwarded result, which upstreamWords reports as "taken in".
• Fork with its own commits: it still gets the forge/take-updates pull, never an automatic merge. A conflict still opens its one issue and no pull.
• Severed fork: it gets nothing, as before; I added a test that fixes this.
• Switching or severing: the owner can still switch to tell-me or sever from the following page, as before.

Tests

• spawn-take.test.ts now covers the untouched fork forwarding, the forked-with-own-commits pull, and the severed fork.
• Other tests that assumed an untouched take-updates fork gets a pull now give the fork a commit of its own first, or ask for tell-me explicitly.
• Tests that assumed the old tell-me default were updated to take-updates. In each case the old assertion was checking the default, not the behaviour.

What I chose not to do

• No automatic merge of a merge commit when the fork has its own commits. The issue says those arrive as a pull to review.
• A tell-me forge that presses "take" on an untouched fork still gets a pull. The fast-forward happens only in take-updates mode.
• I did not migrate existing forges to the new default.

Try it Open /forges/new, then More options: Take updates is preselected. Make a forge and its /following page shows take-updates. When the parent moves and the fork has no commits of its own, the next hourly check fast-forwards it. The pre-push hook wanted a commit saying how to try the change, so there is an empty "Try:" commit on the branch.

Closes #11143

New forges now follow their parent with take-updates by default, and an unchanged fork takes the parent's new code onto its default branch within one check. I ran the follow, spawn and new-forge test files plus bun x tsc --noEmit and bun scripts/gate.ts; all pass. I did not run the whole suite, since the forge's check runs it.

What changed

• Default mode (src/spawn/chain.ts): DEFAULT_MODE is now take-updates. This sets the mode for the web form, the terminal screen, MCP spawn, planSpawn and forkForgeCode. The /forges/new form preselects Take updates, and the new-forge words and MCP field text match.
• Existing forges: a link already stored keeps its mode. A link with no readable mode is still read as tell-me, as before.
• Plain forks: they still default to tell-me, through a separate FORK_DEFAULT_MODE in src/core/fork_follow.ts, because the issue is about spawned forges.
• Untouched fork (src/spawn/take.ts): in take-updates mode, when the fork's default branch is an ancestor of the parent's tip, the branch is fast-forwarded in place. It uses a compare-and-swap, so a push that lands meanwhile wins and the next check retries. It then emits the same push event a followed fork emits, so what follows a push follows this, plus a forge.updates_taken event. No pull is opened. The state records a new forwarded result, which upstreamWords reports as "taken in".
• Fork with its own commits: it still gets the forge/take-updates pull, never an automatic merge. A conflict still opens its one issue and no pull.
• Severed fork: it gets nothing, as before; I added a test that fixes this.
• Switching or severing: the owner can still switch to tell-me or sever from the following page, as before.

Tests

• spawn-take.test.ts now covers the untouched fork forwarding, the forked-with-own-commits pull, and the severed fork.
• Other tests that assumed an untouched take-updates fork gets a pull now give the fork a commit of its own first, or ask for tell-me explicitly.
• Tests that assumed the old tell-me default were updated to take-updates. In each case the old assertion was checking the default, not the behaviour.

What I chose not to do

• No automatic merge of a merge commit when the fork has its own commits. The issue says those arrive as a pull to review.
• A tell-me forge that presses "take" on an untouched fork still gets a pull. The fast-forward happens only in take-updates mode.
• I did not migrate existing forges to the new default.

Try it Open /forges/new, then More options: Take updates is preselected. Make a forge and its /following page shows take-updates. When the parent moves and the fork has no commits of its own, the next hourly check fast-forwards it. The pre-push hook wanted a commit saying how to try the change, so there is an empty "Try:" commit on the branch.

This pull needs no code change. The deploy "failure" is a report that no tests were declared, and the preview itself is up.

• Preview: it answers 200 at https://lab--11148--forge-trevato-apps.open-platform.sh.
• Deploy log: it only shows the forge's periodic housekeeping lines and no error.
• Why it was flagged: forge.json has no app.test command, so the deploy runs no tests. The forge's check is what lands the pull, and it runs on push.
• Checks I ran here:

- bun scripts/gate.ts and bun x tsc --noEmit both came back clean. - The 7 test files this change touches pass (65 tests, 0 failures): follow-e2e, new-forge, spawn-chain-mode, spawn-chain, spawn-take-body, spawn-take, tui-newforge.

• Not run: scripts/fast.ts could not name a smaller set (it listed 2147 of 2698 test files), so I ran those 7 by hand. An earlier broad run I started while checking this is still going in the background; ignore it.

Nothing new to push; the branch is unchanged from the last push.

Pull description

A new forge now takes updates by default, and an unchanged fork fast-forwards itself. The change is in src/core/fork_follow.ts and src/spawn/ (chain.ts, follow_words.ts, plan.ts, take.ts, upstream.ts). The new-forge page (src/web/pages/new-forge.ts) and the terminal screen (src/tui/screens/newforge.ts) choose "Take updates" under More options. Tests are updated to match.

To try it: open /forges/new, make a forge, and its following page says take-updates.

I did not change forge.json. It declares no app.test command, so the preview deploy reports "no tests declared"; the forge's check does the testing.

🤖 Generated with Claude Code

A new forge now follows its parent's code with take-updates by default. An unchanged fork fast-forwards itself; a fork with commits of its own still gets the forge/take-updates pull. This push fixes the three failures the check reported after that change.

• docs/MCP.md: the spawn tool row was stale because the follow-mode wording changed. I regenerated it with bun scripts/mcp-table.ts.
• MCP size limit: the spawn.followMode description was 61 bytes, one over the 60-byte limit. I shortened FOLLOW_SHORT in src/spawn/follow_words.ts to "take-updates: merges itself or a pull; tell-me: inbox card". I changed the matching expected string in test/new-forge.test.ts to the same text.
• test/spawn-anon.test.ts: it expected the anonymous spawn's forge-code link to have mode tell-me. Spawned forges now follow with take-updates, so the test was wrong and I changed its expectation.

test/new-forge.test.ts and test/mcp-size.test.ts pass locally. The other three suites passed as well, apart from the one test/new-forge.test.ts assertion fixed above. bun x tsc --noEmit printed nothing, which I read as clean.

I did not re-run test/mcp-table.test.ts after the commit, but bun scripts/mcp-table.ts was run before it.

The sandbox blocked outbound calls to *.forge.test:443 during those runs. I assume those are lookups in tests that don't depend on the network, but I haven't confirmed that. The forge's full check on this push will show whether anything else fails.

I merged main into the branch and pushed. The only conflict was docs/MCP.md, the generated tool table. I took main's version and regenerated it with bun scripts/mcp-table.ts, so it carries both sides' changes. src/spawn/plan.ts auto-merged.

The type check is clean. The follow-mode and MCP suites (66 tests) pass. I did not run the full check locally; the forge runs it on this push.

The change itself is the same as before: a new forge follows its parent's code with take-updates by default. An unchanged fork fast-forwards itself, and a fork with its own commits still gets the forge/take-updates pull.

Try it: open /forges/new, expand More options, and see Take updates chosen. Make a forge and its following page says take-updates.

This pull makes a new forge follow the topmost forge by default. Its forge repository takes updates, an untouched fork fast-forwards, and a fork with commits of its own gets the pull. This round only addresses the three review points. The tsc, gate and design-lint checks and the new-forge, terminal new-forge and follow end-to-end test files all pass.

• Docs: docs/SPAWN.md, docs/FOLLOWING.md and docs/features/follow-mode.md now say take-updates is the default for a new forge. They say an untouched fork fast-forwards (compare-and-swap, so a push made in between wins) and a fork with its own commits gets the pull. A plain fork still defaults to tell-me.
• Stray blank line: removed from test/follow-e2e.test.ts.
• Form words and order: the Take updates words now read "takes new code in by itself; opens a pull once the repository has commits of its own." On /forges/new, Take updates is listed first and stays the checked default, matching the terminal's FOLLOW_LINE. The pinned strings in test/new-forge.test.ts are updated; the terminal test pins only the unchanged "takes new code in by itself" prefix.

I did not run the full suite; the forge's check does that on push. I did not take phone and desktop screenshots; the form change is the radio order and the shorter words only.

🤖 Generated with Claude Code