Please address the comments from this code review:

## Overall Comments
- In `MaaToolkit/MacOS/MaaToolkitMacOS.h` there are two consecutive `#pragma once` directives; you can drop the duplicate to keep the header clean.
- The `switch` statements in `MacOSPermission.mm` fall through to `return false` for unknown `MaaMacOSPermission` values; consider adding a default case with logging or an assertion so invalid enum values are surfaced rather than silently treated as "no permission".

## Individual Comments

### Comment 1
<location path="source/MaaToolkit/MacOS/MacOSPermission.mm" line_range="32-25" />
<code_context>
+    }
+}
+
+bool MacOSCheckPermission(MaaMacOSPermission perm)
+{
+    switch (perm) {
+    case MaaMacOSPermissionScreenCapture:
+        return CGPreflightScreenCaptureAccess();
+    case MaaMacOSPermissionAccessibility:
+        return AXIsProcessTrusted();
+    }
+    return false;
+}
+
</code_context>
<issue_to_address>
**suggestion:** Consider handling or logging unexpected `MaaMacOSPermission` values explicitly in the switch statements.

These three functions (`MacOSCheckPermission`, `MacOSRequestPermission`, `MacOSRevealPermissionSettings`) currently fall through to `return false` for any value outside the known enum cases. Adding a `default` that logs (or asserts in debug) would surface unexpected enum values and make enum/implementation mismatches easier to detect instead of silently treating them as "no".

Suggested implementation:

```
bool MacOSCheckPermission(MaaMacOSPermission perm)
{
    switch (perm) {
    case MaaMacOSPermissionScreenCapture:
        return CGPreflightScreenCaptureAccess();
    case MaaMacOSPermissionAccessibility:
        return AXIsProcessTrusted();
    default:
        NSLog(@"[MaaToolkit][MacOSPermission] Unexpected MaaMacOSPermission value in MacOSCheckPermission: %d",
              static_cast<int>(perm));
#ifdef DEBUG
        NSAssert(false, @"Unexpected MaaMacOSPermission value in MacOSCheckPermission: %d",
                 static_cast<int>(perm));
#endif
        break;
    }
    return false;
}

```

You should apply the same pattern to `MacOSRequestPermission` and `MacOSRevealPermissionSettings`:

- In each function’s `switch (perm)`:
  - Add a `default:` case that:
    - Logs the unexpected enum value (e.g. with `NSLog` and `static_cast<int>(perm)` to avoid `%d` with enum types).
    - Optionally `NSAssert(false, ...)` under `#ifdef DEBUG` (or whatever debug/assert macro your codebase uses).
    - Uses `break;` so that the function still falls through to the existing `return false;` after the `switch`.
- Ensure you do not remove the existing `return false;` after the `switch`, so behavior for unexpected values remains "no" but is now visible in logs (and in debug builds, via an assertion).
</issue_to_address>

Please address the comments from this code review:

## Overall Comments
- In `MaaToolkitMacOS.h` you have two consecutive `#pragma once` directives; the second one is redundant and can be removed for clarity.
- In `MaaToolkit.cppm` you replaced the `MaaToolkitProjectInterface*` exports with the new macOS permission APIs; if this wasn’t intentional, consider re‑adding the project interface exports and simply appending the new macOS exports to avoid breaking existing module consumers.

## Individual Comments

### Comment 1
<location path="include/MaaToolkit/MaaToolkitDef.h" line_range="11-17" />
<code_context>
 typedef struct MaaToolkitDesktopWindow MaaToolkitDesktopWindow;
 typedef struct MaaToolkitDesktopWindowList MaaToolkitDesktopWindowList;
+
+enum MaaMacOSPermissionEnum
+{
+    MaaMacOSPermissionScreenCapture = 1,
+    MaaMacOSPermissionAccessibility = 2
+};
+
+typedef int32_t MaaMacOSPermission;
</code_context>
<issue_to_address>
**issue (bug_risk):** Align enum underlying type with MaaMacOSPermission typedef to avoid ABI/type mismatches

`MaaMacOSPermissionEnum` currently defaults to `int` as its underlying type, while `MaaMacOSPermission` is explicitly `int32_t`. This mismatch can cause ABI issues, especially across FFI boundaries. Please either declare the enum with an explicit underlying type (`enum MaaMacOSPermissionEnum : int32_t { ... };`) or make `MaaMacOSPermission` a typedef of the enum (`typedef MaaMacOSPermissionEnum MaaMacOSPermission;`) to keep them aligned.
</issue_to_address>

Please address the comments from this code review:

## Overall Comments
- In `source/modules/MaaToolkit.cppm` the MacOS permission exports replace the existing `MaaToolkitProjectInterface*` exports instead of being added alongside them; if that replacement is unintentional, it will silently drop the project interface APIs from the C++20 module and likely break existing consumers.
- The MaaToolkit macOS permission C APIs currently return `false` both when permissions are actually denied and when called on non-Apple platforms (stub branch), which makes it hard for callers to distinguish a genuine permission state from an unsupported-platform error; consider adding a separate error signal (e.g., a dedicated enum, error code, or log-accessible flag) so bindings can handle these cases differently.

## Individual Comments

### Comment 1
<location path="source/binding/NodeJS/src/apis/global.d.ts" line_range="6-7" />
<code_context>

             resize_image(image: ArrayBuffer, width: number, height: number): ArrayBuffer
+
+            macos_check_permission(perm: MacOSPermission): boolean
+            macos_request_permission(perm: MacOSPermission): Promise<boolean>
+            macos_reveal_permission_settings(perm: MacOSPermission): boolean
         }
     }
</code_context>
<issue_to_address>
**suggestion (bug_risk):** TypeScript declarations don’t indicate that these APIs may be unavailable on some builds/platforms

In native code these functions can throw (`throw_toolkit_unavailable`) when the toolkit isn’t available, and they’re effectively macOS-only, but the TS types present them as always-available boolean-returning APIs.

If these may run on non-macOS/toolkit-less builds, consider reflecting that in the typings (e.g. a documented capability flag or a typed error/union) so callers don’t assume universal availability.

```suggestion
        const Global: {
            get version_from_macro(): string
            config_init_option(user_path: string, default_json?: string): void

            resize_image(image: ArrayBuffer, width: number, height: number): ArrayBuffer

            /**
             * Indicates whether the macOS permissions toolkit is available on this build/platform.
             *
             * When `false` or `undefined`, the macOS-specific permission APIs below may not be
             * present and native calls may throw a toolkit-unavailable error if invoked indirectly.
             */
            readonly macos_permissions_available?: boolean

            /**
             * Check the current status of a macOS permission.
             *
             * This API is only available when `macos_permissions_available === true` and on
             * supported macOS builds. Callers should feature-detect by checking
             * `macos_permissions_available` and that this function is defined before calling.
             */
            macos_check_permission?: (perm: MacOSPermission) => boolean

            /**
             * Request a macOS permission from the user.
             *
             * This API is only available when `macos_permissions_available === true` and on
             * supported macOS builds. Callers should feature-detect by checking
             * `macos_permissions_available` and that this function is defined before calling.
             */
            macos_request_permission?: (perm: MacOSPermission) => Promise<boolean>

            /**
             * Reveal the system settings UI for managing a macOS permission.
             *
             * This API is only available when `macos_permissions_available === true` and on
             * supported macOS builds. Callers should feature-detect by checking
             * `macos_permissions_available` and that this function is defined before calling.
             */
            macos_reveal_permission_settings?: (perm: MacOSPermission) => boolean
        }
```
</issue_to_address>

### Comment 2
<location path="docs/en_us/2.4-ControlMethods.md" line_range="138" />
<code_context>

+> [!TIP]
+>
+> MaaFramework is not responsible for requesting or guiding permissions; clients must implement these functionalities themselves. MaaToolkit provides a set of helper functions for this purpose; please refer to [test/macos_test](https://github.com/MaaXYZ/MaaFramework/tree/main/test/macos_test).
+
 ### MacOS Screencap
</code_context>
<issue_to_address>
**nitpick (typo):** Consider clarifying the phrase "requesting or guiding permissions" for more natural grammar.

You could instead say something like: "requesting permissions or guiding users through permission prompts" to make the sentence flow more naturally while preserving the meaning.

```suggestion
> MaaFramework is not responsible for requesting permissions or guiding users through permission prompts; clients must implement these functionalities themselves. MaaToolkit provides a set of helper functions for this purpose; please refer to [test/macos_test](https://github.com/MaaXYZ/MaaFramework/tree/main/test/macos_test).
```
</issue_to_address>