fix: derive executable name from plugin ID for raw binary installs

.claude/agent-memory/archgate-developer/MEMORY.md

@@ -0,0 +1,3 @@
+# Memory Index
+
+- [proto raw-binary rename](project_proto-raw-binary-rename.md) — proto renames non-archive downloads to the plugin ID; derive exe name via get_plugin_id(), never hardcode

.claude/agent-memory/archgate-developer/project_proto-raw-binary-rename.md

@@ -0,0 +1,12 @@
+---
+name: proto-raw-binary-rename
+description: proto renames non-archive (raw binary) downloads to the plugin ID on disk — locate_executables must derive the exe name from get_plugin_id()
+metadata:
+  type: project
+---
+
+proto (moonrepo) renames a raw, non-archive prebuilt download to the **plugin ID** when moving it into the install dir (`tool.get_file_name()` in `crates/core/src/flow/install.rs`). The user-chosen ID from `proto plugin add <id> ...` decides the on-disk filename, e.g. `claude-code.exe`.
+
+**Why:** Claude Code ships as a raw binary (no archive), so hardcoding any exe name in `locate_executables` breaks whenever the plugin ID differs. This caused the Windows "Unable to symlink binary" / `missing_alternate_binary` regression shipped in v0.2.0–v0.3.0 (PR #1 renamed the exe to `claude` on a wrong premise).
+
+**How to apply:** In `locate_executables`, always use `get_plugin_id()` + `env.os.get_exe_name(&id)` and `ExecutableConfig::new_primary` — same pattern as moonrepo's own `moon` plugin (tools/moon in moonrepo/plugins), which documents this exact behavior in a comment. Never hardcode the exe filename for raw-binary tools.

Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "claude_plugin"
-version = "0.1.0"
+version = "0.3.1"
 edition = "2021"
 license = "MIT"
 publish = false

src/proto.rs

@@ -77,14 +77,17 @@ pub fn locate_executables(
 ) -> FnResult<Json<LocateExecutablesOutput>> {
     let env = get_host_environment()?;
 
-    let exe_name = if env.os == HostOS::Windows {
-        "claude.exe"
-    } else {
-        "claude"
-    };
+    // Claude Code releases are raw binaries, not archives. When proto installs
+    // a non-archive download, it renames the file on disk to the plugin's
+    // configured ID (e.g. `claude-code.exe` for `proto plugin add claude-code`),
+    // so the executable name must be derived from the ID at runtime.
+    let id = get_plugin_id()?;
 
     let mut exes = HashMap::default();
-    exes.insert("claude".to_string(), ExecutableConfig::new(exe_name));
+    exes.insert(
+        "claude".to_string(),
+        ExecutableConfig::new_primary(env.os.get_exe_name(&id)),
+    );
 
     Ok(Json(LocateExecutablesOutput {
         exes,