[Birfy]

Reproduce

On main (fd205c40), call create_team on a home where a member's name is already taken somewhere else in the tree:

• plugins/tree/src/allocate.js buildTeam (:198) reuses a member only by role text; a name that does not match by role falls through, :215 creates <team> Lead first, and :227-233 creates the members one by one with each failure stored in d.error.
• ds-bot/src/host/roster.js:65 is the host rule that actually refuses the duplicate: if (rt.findBot(cleanName)) throw new Error(\A Bot named ${cleanName} already exists`)` — a Bot's name is unique across the whole home, not just under its parent.

So create_team("FlyBot", ["Dev: …", "Reviewer: …"]) where a Reviewer already exists under another branch with a different role makes two writes into one call: the lead is created, the Reviewer member is dropped, and the answer is a childless FlyBot Lead plus one "Not created" line. Nothing is rolled back; the tree is already changed.

What changed

• plugins/tree/src/allocate.js: before begin('team'), collect every name the team would create — the new lead plus each member that was not reused by role — and look each one up in the whole roster (fb.listBots(), the same list the host's findBot sees). On any clash, throw before a single write: the message starts with nothing was created:, names every clash with the path of the Bot that holds it ("Reviewer" is already taken by Chief → Review → Reviewer) and says how to proceed (rename the member, or give the existing Bot the same role so it is reused). A Bot outside the tree is reported as such instead of a made-up path.
• begin('team') moved after that check, so a refused team leaves no journal run either.
• docs/subsystems/tree.md: the team rule now says a team is refused before anything is written on a name clash, and the test-coverage line records the new case.
• changelog.d/764-team-name-clash.fixed.md: one fragment for the user-visible fix.
• plugins/tree/test/tree.test.js: new case #764, see the red evidence below.

What I ran

• cd plugins/tree && DSH_HARNESS=/opt/flybot node --import ./test/resolve.mjs --test "test/*.test.js" → 111/111, 0 skipped (includes test/host.test.js on the real host).
• node --test plugins/tree/test/tree.test.js → 94/94 (93 existing + the new one).
• node .github/scripts/changelog.mjs check → changelog: 3 fragment(s) in changelog.d/ are well formed.
• PATH=<tools>/bin:$PATH node core/scripts/check-arch-docs.mjs (local repo pinned to fd205c40) → arch-docs: OK (4 changed file(s)).

Red without the source change

Three probes, each restored afterwards; the suite is 94/94 again after each restore, and each one reds exactly the new case (93/94):

1. Remove the pre-check → the new case fails on its first assertion: the call returns a team instead of nothing was created, so the lead and members are written.
2. Only report the first clash (clashes.slice(0, 1)) → the new case fails on /"Scout" is already taken by Chief → Scout/: the message names Reviewer only.
3. Keep the same check for members but run it after the lead is created → the new case fails on the bot count: 4 Bots after the refused call instead of 3, i.e. the childless lead is exactly what the pre-check prevents.

Not run

• node scripts/lint-plugins.mjs tree: no oxlint binary in this checkout (lint-plugins: no oxlint found; run npm run harness in core/, or set DSH_HARNESS — setting it does not help either). CI runs this in the plugins (tree) job.
• No core suite, package job or ds-bot-patches regeneration: the diff has no core/ or patches/ds-bot/ file, and the tree plugin is not vendored into the core.
• No real-host reproduction of the failing path: test/host.test.js exercises create_team's success path on the real host, and the refusal path is covered by the plugin test above; the host rule being pre-checked is roster.js:65 (read, not executed with a duplicate).
• CI on this PR will be red because of the account billing lock (The job was not started because your account is locked due to a billing issue), not because of this diff; the tip can be re-run once it is cleared.

Risk

Low, and one residual race worth naming.

• On this host, names are unique home-wide (roster.js:65), so any call that this check now refuses would previously have failed anyway — after writing the lead. The success path is unchanged: reuse by role, placement, moves, journal and undo are untouched, and the 93 existing tests pass.
• Hidden/retired Bots count as taken, which matches what the host's findBot sees (they are still real Bots).
• Residual: the check runs inside the per-parent lock, so two create_team calls under different parents can still race on the same name between the check and the create; the host then refuses the member and an orphan lead is still possible in that narrow window. Closing that needs a home-level lock or a rollback, which is a bigger change than this issue and is left out of scope here.

[Birfy]

Verdict: PASS at 16c2945
Written-by: Reviewer

The pre-check runs before begin('team') and before any write: it collects the lead name (only when the lead is not reused) plus every member not reused by role, looks each up in fb.listBots() with the plugin's norm(), and throws naming every clash with the holder's path — or that the holder sits outside the tree. That refuses the whole team with no journal entry and a byte-identical tree.

It mirrors the rule that actually refused before: ds-bot/src/host/roster.js:65 (rt.findBot(cleanName)), and findBot normalises with trim+lowercase, the same shape as norm, so the pre-check neither misses a name the host would refuse nor refuses one it would accept. Name length cannot diverge through the host's 40-character truncation either: MAX_TEAM_LENGTH is MAX_NAME_LENGTH - ' Lead'.length. Duplicate member names inside one call are already refused by validateMembers, so the two-write failure cannot reappear that way.

Ran (local gate on the PR tree at this tip; CI could not start — all nine checks are 0-step failures with the account billing lock, so the evidence is local, Node v22.23.3, TZ=UTC):

• cd plugins/tree && DSH_HARNESS=/opt/flybot node --import ./test/resolve.mjs --test --test-timeout=90000 "test/*.test.js" → 111/111 (includes test/host.test.js on the real host)
• node .github/scripts/changelog.mjs check → 3 fragments well formed
• node .github/scripts/testing-layers.mjs --check → 315 test files in 12 workflows, all classified
• cut, pre-check deleted → 93/94, only the new case red, and the team is created
• cut, clashes.slice(0, 1) → 93/94, only the new case red, on the assertion that the message names Scout
• cut, the block moved after createLead → five red; the new case red on the bot count 4 (the childless lead), plus the four lead-reuse cases, because that crude move re-checks the lead it has just created

Not run: lint-plugins tree (no oxlint on this box) and ds-bot-patches check (needs git).

Non-blocking, text only, no code change needed for this merge:

1. The PR body's residual-risk paragraph names the wrong adversary. Every create_team runs inside the one global exclusive queue (organize.js:311 chains a single promise), so two create_team calls cannot interleave. The window that remains is a concurrent create_child_bot (allocate.js:109 takes only withParentLock) or a Bot created outside the plugin, between the check and the create. Closing it needs a home-level lock, which is out of scope here; the sentence should name that door.
2. The refusal message calls a lead-name clash "that member" and advises giving the existing Bot the same role "so it is reused". Reuse searches only the caller's branch (sameRoleIn walks subtreeOf(callerId)), so for a non-Chief caller that half of the advice does not help; for a lead clash neither half does.