dev lane: managed agents resolve a zero-byte `buzz` sidecar — `just dev` never replaces the Tauri stubs beside the app executable

[JGroutsis]

Describe the bug

On a clean just dev, every managed agent's buzz CLI is unresolvable or zero-byte, so buzz-cli skill commands fail silently — including buzz agents draft-create (conversational agent setup). Looks like a trigger behind the symptom family in #2459.

Causal chain (each step verified on disk):

1. _ensure-sidecar-stubs touches five zero-byte placeholders in desktop/src-tauri/binaries/ (the Tauri externalBin compile gate — intentional, per Windows: _ensure-sidecar-stubs Justfile recipe omits the .exe suffix Tauri requires for externalBin #2492).

2. Tauri dev copies those stubs beside the app executable in desktop/src-tauri/target/debug/ (arch suffix dropped). The real binaries are built into the WORKSPACE target/debug/ — desktop/src-tauri resolves to its own Cargo target dir, so nothing ever replaces the stubs.

3. build_augmented_path (managed_agents/runtime/path.rs) puts ~/.local/bin at entry 1 and exe_parent — the stub directory — at entry 5. A live agent's composed PATH:

   ~/.local/bin                                      <- only `buzz-dev` (see 4)
   .../Application Support/Buzz/node-tools/bin
   .../Application Support/Buzz/runtimes/node/.../bin
   ~/Projects/buzz/desktop/src-tauri/target/debug    <- five zero-byte stubs
   ...login shell PATH (no buzz anywhere)
   

   command -v buzz on that PATH: not resolvable (the stub is mode 644, zero bytes).

4. ensure_cli_symlink (nest.rs:366) gates on buzz_bin.exists() — which passes on the zero-byte stub — and links ~/.local/bin/buzz-dev to it. Dev builds deliberately link only buzz-dev, and agents invoke bare buzz (buzz-cli SKILL.md), so the human symlink cannot save the agent lane either.

Net: in the dev lane, the documented agent contract ("agents find the CLI via PATH augmentation", nest.rs:361-362) is broken by construction. desktop-standalone stages all five binaries; dev, staging, and production recipes do not. scripts/bundle-sidecars.sh is release-only (SRC_DIR="target/release"), so it cannot serve just dev as written.

Steps to reproduce

1. just dev — wait for desktop + managed agents to come up
2. ls -la desktop/src-tauri/target/debug/buzz — 0 bytes, mode 644
3. Ask any managed agent to run buzz --help — command not found / silent failure (agent-visible buzz-cli actions like buzz agents draft-create fail)

Expected behavior

A managed agent spawned by the dev-lane desktop can resolve and execute a real buzz CLI via its augmented PATH, per the contract in nest.rs.

Version and platform

• Buzz version: v0.5.2 (also confirmed on v0.5.0/v0.5.1; relevant recipes/code unchanged on current main by inspection)
• OS: macOS 15 (Darwin 24.6.0, Apple Silicon)

Logs / additional context

Duplicate search: closest are #2492 (Windows stub suffix — documents the stubs as intentional compile gates, different failure) and #2459 (lost agent replies when the agent's buzz CLI write fails — unconfirmed trigger, consistent with this). Open PRs #2655 / #3069 touch bundled/packaged sidecar preference for releases; neither appears to close the dev-lane staging gap.

Questions before we write any code:

1. Do fix(desktop): prefer packaged sidecars in release builds #2655 / fix(desktop): prefer bundled sidecars in releases #3069 already own this, or is the dev-lane staging gap separate?
2. What is the intended dev-lane contract: should just dev stage debug sidecars into the exe-parent dir, or are dev agents expected to obtain buzz another way?
3. Should ensure_cli_symlink's .exists() gate test executability/non-zero size so it never links to a stub?

Happy to PR the minimal fix for whichever contract you confirm. Our local workaround (post-just dev staging of the five workspace-target binaries into the exe-parent dir, fail-closed) restores agents immediately, so no urgency on our side.