[Lemon-miaow]

找不到 interface 爆炸了

Sourcery 摘要

修正 macOS 应用包的项目目录定位，确保能够正确发现内置的接口配置。

错误修复:

• 修复 macOS 应用包内自带 interface.json 时项目目录定位错误的问题，避免运行时找不到接口配置。

功能增强:

• 调整运行时项目目录解析逻辑，根据 interface.json 的位置，在应用包目录与可执行文件目录之间进行选择。

测试:

• 新增 macOS 项目目录解析测试，覆盖应用包内外存在 interface.json 的场景。

Original summary in English

Summary by Sourcery

修正 macOS 应用包的项目目录定位，确保内置 interface 配置能够被正确发现。

Bug Fixes:

• 修复 macOS 应用包内自带 interface.json 时项目目录定位错误，避免运行时找不到 interface 配置。

Enhancements:

• 调整运行时项目目录解析逻辑，使其根据 interface.json 的位置在应用包目录与可执行文件目录之间选择。

Tests:

• 新增 macOS 项目目录解析测试，覆盖应用包内外存在 interface.json 的场景。

[sourcery-ai]

嗨——我发现了 3 个问题

Prompt for AI Agents

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="src-tauri/src/commands/utils.rs" line_range="306-310" />
<code_context>
-        if let Some(project_dir) = bundle.parent() {
-            return Ok(project_dir.to_path_buf());
+    if !exe_dir.join("interface.json").exists() {
+        if let Some(project_dir) = macos_app_bundle(exe_path)
+            .as_deref()
+            .and_then(std::path::Path::parent)
+        {
+            return Some(project_dir.to_path_buf());
         }
     }
</code_context>
<issue_to_address>
**Bundled resources resolve from wrong root**

When a macOS bundle contains `interface.json` in `Contents/MacOS` while `maafw` or project resources remain beside the `.app`, or the bundle sits beside its own project, `project_dir_for_executable` returns `Contents/MacOS` as the project root, so `get_maafw_dir` and `AppConfigState` resolve libraries, configuration, and project resources from the wrong directory; users see missing resources or the wrong project.

Resolve the project root from the neighboring project/resource layout instead of treating `Contents/MacOS` as the project root solely because it contains `interface.json`.
</issue_to_address>

### Comment 2
<location path="src-tauri/src/commands/utils.rs" line_range="306-310" />
<code_context>
-        if let Some(project_dir) = bundle.parent() {
-            return Ok(project_dir.to_path_buf());
+    if !exe_dir.join("interface.json").exists() {
+        if let Some(project_dir) = macos_app_bundle(exe_path)
+            .as_deref()
+            .and_then(std::path::Path::parent)
+        {
+            return Some(project_dir.to_path_buf());
         }
     }
</code_context>
<issue_to_address>
**Bundled interface is not found**

When a macOS bundle contains `interface.json` only in `Contents/Resources`, without a corresponding entry in `Contents/MacOS`, `project_dir_for_executable` checks only `Contents/MacOS/interface.json` and returns the directory outside the `.app`, so startup looks for the interface in the wrong place and reports it missing.

Check `Contents/Resources` for `interface.json` when resolving the project directory.
</issue_to_address>

### Comment 3
<location path="src-tauri/src/commands/utils.rs" line_range="301" />
<code_context>
+    project_dir_for_executable(&exe_path).ok_or_else(|| "无法获取 exe 所在目录".to_string())
+}
+
+fn project_dir_for_executable(exe_path: &std::path::Path) -> Option<PathBuf> {
+    let exe_dir = exe_path.parent()?;

</code_context>
<issue_to_address>
**Corrupt bundled interface blocks fallback**

When a macOS bundle contains an incomplete, unreadable, or malformed `Contents/MacOS/interface.json` while a valid interface exists beside the bundle, `get_exe_directory` selects the executable directory based only on the file’s existence. `AppConfigState::load_interface` then returns on a read or parse error without trying the valid neighboring project interface, leaving the interface unavailable to callers.

Validate that the bundled interface can be read and parsed before selecting that directory, and fall back to the neighboring project directory if loading it fails.
</issue_to_address>

---

Sourcery 对开源项目免费使用——如果你喜欢我们的评审，欢迎考虑分享 ✨

• X
• Mastodon
• LinkedIn
• Facebook

Original comment in English

Hey - I've found 3 issues

Prompt for AI Agents

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="src-tauri/src/commands/utils.rs" line_range="306-310" />
<code_context>
-        if let Some(project_dir) = bundle.parent() {
-            return Ok(project_dir.to_path_buf());
+    if !exe_dir.join("interface.json").exists() {
+        if let Some(project_dir) = macos_app_bundle(exe_path)
+            .as_deref()
+            .and_then(std::path::Path::parent)
+        {
+            return Some(project_dir.to_path_buf());
         }
     }
</code_context>
<issue_to_address>
**Bundled resources resolve from wrong root**

When a macOS bundle contains `interface.json` in `Contents/MacOS` while `maafw` or project resources remain beside the `.app`, or the bundle sits beside its own project, `project_dir_for_executable` returns `Contents/MacOS` as the project root, so `get_maafw_dir` and `AppConfigState` resolve libraries, configuration, and project resources from the wrong directory; users see missing resources or the wrong project.

Resolve the project root from the neighboring project/resource layout instead of treating `Contents/MacOS` as the project root solely because it contains `interface.json`.
</issue_to_address>

### Comment 2
<location path="src-tauri/src/commands/utils.rs" line_range="306-310" />
<code_context>
-        if let Some(project_dir) = bundle.parent() {
-            return Ok(project_dir.to_path_buf());
+    if !exe_dir.join("interface.json").exists() {
+        if let Some(project_dir) = macos_app_bundle(exe_path)
+            .as_deref()
+            .and_then(std::path::Path::parent)
+        {
+            return Some(project_dir.to_path_buf());
         }
     }
</code_context>
<issue_to_address>
**Bundled interface is not found**

When a macOS bundle contains `interface.json` only in `Contents/Resources`, without a corresponding entry in `Contents/MacOS`, `project_dir_for_executable` checks only `Contents/MacOS/interface.json` and returns the directory outside the `.app`, so startup looks for the interface in the wrong place and reports it missing.

Check `Contents/Resources` for `interface.json` when resolving the project directory.
</issue_to_address>

### Comment 3
<location path="src-tauri/src/commands/utils.rs" line_range="301" />
<code_context>
+    project_dir_for_executable(&exe_path).ok_or_else(|| "无法获取 exe 所在目录".to_string())
+}
+
+fn project_dir_for_executable(exe_path: &std::path::Path) -> Option<PathBuf> {
+    let exe_dir = exe_path.parent()?;

</code_context>
<issue_to_address>
**Corrupt bundled interface blocks fallback**

When a macOS bundle contains an incomplete, unreadable, or malformed `Contents/MacOS/interface.json` while a valid interface exists beside the bundle, `get_exe_directory` selects the executable directory based only on the file’s existence. `AppConfigState::load_interface` then returns on a read or parse error without trying the valid neighboring project interface, leaving the interface unavailable to callers.

Validate that the bundled interface can be read and parsed before selecting that directory, and fall back to the neighboring project directory if loading it fails.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

[Windsland52]

LGTM with two nits.

我核对了代码和 MaaEnd v3.0.0 官方 DMG 的实际布局：install.yml 会把 install/* 全部拷到 MaaEnd.app/Contents/MacOS/，所以 interface.json、locales/、maafw/、resource/ 都在 Contents/MacOS（Contents/Resources 只有 maaend.icns）。docs/macos-deployment.md 里的 --repair-layout 则把非 Mach-O 文件移到 Contents/Resources/MXU-portable，并在 Contents/MacOS 原位置留相对 symlink。两种布局下 exe_dir/interface.json 的 .exists() 都能命中，修复路径成立。

两个非阻塞建议：

1. exists() != 可用（同 Sourcery 的 Medium）。is_file() 可以挡掉“目录冒充 interface.json”，但它不解决 unreadable/corrupt 文件；如果要把 Sourcery #3 一并解决，需要 read/parse 失败时显式回退，而不只是 is_file()。至少建议 is_file() + 一条 log::info! 记录最终选中的 project root，便于排查 bundled-vs-external 的歧义。

2. 隐式约定：bundle 内有 interface.json 就表示整个项目根是 Contents/MacOS——maafw/、dist/、import、locales 都会在 bundle 内解析。建议在 docs/macos-deployment.md 补一句：bundle 内自带 interface 意味着项目应完全自包含，不要再与包外资源混用。

CI/测试备注：当前 build.yml 只有 pnpm tauri build，没有 cargo test；新增的 macOS-only 测试不会被 CI 执行，这次 CI 绿只代表编译通过。合并前在 macOS 本地跑一次 cargo test macos_project_dir_follows_interface_location 会更稳。

另外，Sourcery 的两条 High 我认为基本是 overstatement：--repair-layout 的常规迁移路径会给移动过的文件留 symlink，Contents/Resources/interface.json 无 MacOS 入口的场景不会出现；mixed layout 也不在现有文档契约内。补充一点：planBundleLayout() 只扫描 Contents/MacOS，如果 Contents/Resources/MXU-portable 里已有 interface 而 MacOS 没有 symlink，--repair-layout 也不会补；所以不要按“绝不可能”处理，但也不是本 PR 的阻塞项。