Enabled plugin agent tools can be absent from freshly dispatched project lanes

[pixexid]

Summary

An enabled plugin can register an agent tool and include it from bb.agents.configure, yet a freshly dispatched managed lane can start without that tool. The absence is only discovered later when the lane needs the tool, after durable work state has already been created.

This was reproduced on the current host with a fresh dispatched lane: the plugin was enabled/running and the lane completed normally, but its follow-up turn did not have the configured terminal-report builder in its toolbelt. A lane in another project on the same host did receive the same tool, so tool presence is currently not a reliable dispatch-time property.

Impact

For collaboration plugins that bind durable attempts to an owning native thread, a missing closure/report tool can leave a permanently non-terminal row. Re-dispatching merely to obtain the tool is not safe: the new lane can receive the same absent toolbelt, and the authoritative completion evidence remains bound to the original attempt/thread.

Expected contract

BB should provide one of these equivalent guarantees:

1. Every eligible dispatched lane receives the tools selected by enabled plugins through bb.agents.configure; or
2. Dispatch can declare required tool IDs and atomically refuses before thread/attempt creation when they cannot be mounted.

The successful dispatch receipt should expose the resolved tool/capability set (or a digest) so callers can prove the required closure tool was mounted. A post-dispatch best-effort check is too late for durable attempt creation.

Acceptance shape

• Enable a plugin that registers a test agent tool and selects it through bb.agents.configure.
• Dispatch fresh managed lanes in two projects on the same host.
• Both lanes either receive the required tool, or dispatch refuses before creating either native or plugin-owned durable work state.
• Disable/unload or project-ineligibility produces an explicit dispatch refusal rather than a successful lane missing the declared capability.

Exact tenant, thread, account, and host identifiers are intentionally omitted. The downstream recovery work is tracked in pixexid/bb-collab#736.

[SawyerHood]

Reproduction & root-cause report: https://get-bb.github.io/reports/issues/2532.html

• Verdict: PARTIALLY REPRODUCED · root-cause confidence: medium
• Root cause (short): Thread creation has no required-tool preflight, so the queued start can resolve before a plugin recognizes lane ownership.
• Proposed fix: Add requiredAgentToolIds to thread creation and SDK spawn. Resolve tools before insertion and hold the plugin generation through enqueue. Return server-resolved IDs and a digest as a server receipt. Add and await a daemon receipt before BB claims that the daemon mounted the tools.
• Caveats: The issue omits the original lane, host, provider transcript, and downstream database. The route test uses a controlled 250 ms delay. It proves the contract gap and one matching sequence. It does not prove the reporter's exact sequence.

The report has copy-paste repro steps, screenshots where the bug is visual, code permalinks at the base commit, and repro artifacts. It was independently re-run by a second agent (see its Verification section).

AGENT GENERATED: by GPT-5.6-Sol