[HugoXK]

Refresh a Bot's own tree prompt at each turn
Fixes #723
The tree writes a Bot's tree block into its system prompt when it is created or placed, and refreshes only the parent's prompt at a turn boundary (for the Child-load line). A rename or role edit made in the core (roster.updateBot) therefore never reached the changed Bot's own prompt or its coordinator's child list: the coordinator kept calling the old name, message_bot("Travel") answered "No Bot named Travel", and the renamed Bot still read "You are Travel" — until a restart or another placement ran refreshAll.
plugins/tree/index.js now refreshes the running Bot's own prompt at turn.start / turn.end as well, beside the existing parent refresh. writeBlock skips an unchanged block, so a turn whose prompt is already current costs one string compare. list_children / find_bots already read the live records; this aligns the prompt with them.
plugins/tree/test/tree.test.js creates Work under Chief, renames it to Trips through the plugin API, then fires turn.start for Chief (its child list must say Trips) and for Trips (its own head must name it). It fails without the change (Chief's prompt still lists Work). docs/subsystems/tree.md records the refresh.
Role-label sync from the core role into the stored tree role is a separate change (it needs a decision about how a core role and a tree role reconcile); this PR fixes the stale name that breaks addressing.
Ran at the tip: npm run verify (green, TZ=UTC), ARCH_DOCS_BASE=upstream/main node core/scripts/check-arch-docs.mjs. Not run: smoke (this macOS box has no setsid, so dev/bench.sh cannot start dsh web), Desktop, real-model steward.

[Birfy]

Verdict: PASS at 40ceef2
Written-by: Reviewer

The change is small, in the right place, and pinned by a case that fails without it. plugins/tree/index.js now runs the same refresh for the Bot itself as for its parent at a turn boundary (refreshPrompts), so a rename made in the core reaches the Bot's own head and, because promptFor reads the child list live, the coordinator's list too — the coordinator is refreshed on its own boundary as well, not only when the child happens to start a turn.

What I checked in the code:

• refreshPrompts guards with tree.isMember(id) and refreshPrompt itself checks nodes[id], so a non-tree Bot, a remote Bot or a deleted id is a no-op rather than a throw.
• The parent refresh is kept (refreshParentPrompt), so the Child-load line still updates exactly as before; nothing is lost by moving to the combined function.
• writeBlock skips an unchanged block (tree.js:78), so the extra call per turn costs one string compare; a prompt that already matches is not rewritten.
• promptFor is built from the live snapshot, so the rename lands on the very next boundary; the test asserts both directions (coordinator's - Trips: Work stuff and the Bot's own You are Trips).

Ran: (tip 40ceef28, TZ=UTC, tree from codeload)

cd plugins/tree && node --import ./test/resolve.mjs --test --test-concurrency=2 "test/*.test.js"
  -> # tests 103 / # pass 103 / # fail 0
cd plugins/tree && node --import ./test/resolve.mjs --test test/tree.test.js
  -> # tests 87 / # pass 87 / # fail 0

Red:

index.js reverted to `refreshParentPrompt` only (new test kept) -> 86/87, the only failure is `a rename made in the core reaches the tree prompts on the next turn`

Not run: npm run verify end to end and check-arch-docs here (no origin/main ref in this sandbox; docs/subsystems/tree.md is in the PR and CI's arch-docs job is green at this tip).

Non-blocking, one gap this PR does not cover and does not need to:

1. A renamed Bot's descendants carry the old name in their trace (promptFor → traceOf). They repaint it at their own next turn boundary, so it heals within one turn per Bot, but a child that reads its own prompt mid-round still sees the old ancestor name. Worth a follow-up if the team ever addresses ancestors by name in that window.
2. A rename does not touch the renamed Bot's own children immediately — same window, same self-healing path.

[Birfy]

Reviewer: the PASS above is for 40ceef28, and it still stands for that tree — but this branch is now dirty against main, so it cannot enter the queue.

Reason: #726 landed (main a718f345) while this branch was based on 647704f8. Both touch the same two places — the new case is inserted at plugins/tree/test/tree.test.js:65 in each, and both rewrite the same line of docs/subsystems/tree.md — so the merge conflicts even though the changes are independent.

I withdrew the auto-merge I had set, on purpose: a rebase produces a new tip, and a new tip voids this PASS, so arming the queue would let it merge an unreviewed tree.

What unblocks it: rebase 40ceef28 onto current main 7af7c948 (the tree fix #726 and the prompt fix here do not overlap in behaviour, only in those two hunks), push, and say so here. I re-judge the new tip immediately — the tree suite is 103/103 on this tree and 103/103 on main, so the rebase should stay green.

[Birfy]

Written-by: Dev

Rebased and superseded by #778, on a branch this repository owns. The PASS at 40ceef28 cannot be used here: the branch is in HugoXK/FlyBot, where we have no push access (permissions.push: false, blob creation answers 404), and PUT /pulls/720/update-branch refuses it with 422 merge conflict between base and head — #726 landed in the same two hunks (plugins/tree/test/tree.test.js, docs/subsystems/tree.md).

#778 is the same change (carried over with Co-authored-by: HugoXK) rebased onto d83d762d, tree suite 90/90, with the rename case red when the Bot's own refreshPrompt is removed. It needs a fresh PASS at its own tip.