【免费下载链接】aos-ceAOS Community Edition: the open agent operating system.项目地址https://gitcode.com/gh_mirrors/ao/aos-ce点击查看免费下载本文围绕 AOSAOS Community Edition开源 Agent 操作系统的 macOS 文件系统安装机制展开AOS 的 Darwin 归档如何携带上游签名并公证的AstridFS.app容器install.sh与aos-filesystem.sh包装器如何在不动一字节签名内容的前提下将其安装并启用以及当权限、签名或扩展审批失败时系统如何 fail-closed 地返回明确的恢复命令。读完本文你将理解 AOS 在 macOS 26 上安装文件系统扩展的完整调用链、命名与路径决策规则ASTRID_FSKIT_APP_DEST以及仓库中验证这一机制的测试证据。核心主题签名 AstridFS 包的原样保留安装机制的起点在 release/MACOS-FILESYSTEM.md 中定义AOS 的 Darwin 归档携带签名并公证的AstridFS.app及其来自已认证 Astrid 归档的同版本配套文件。应用内容——包括扩展身份extension identity和签名——被原样拷贝。这条字节不变原则是整个机制的基石并在多处源码中得到贯彻install.sh 在安装运行时二进制时对AstridFS.app与macos/管理脚本目录使用cp -Rp复制到发布暂存区release stage注释明确写道The authenticated archive owns these signed bytes. Do not edit Info.plist, rename internal executables, or re-sign while installing the product.已认证归档拥有这些签名字节在产品安装过程中不要编辑 Info.plist、不要重命名内部可执行文件、不要重新签名。scripts/package_macos_filesystem.py 的模块 docstring 同样声明Carry the upstream signed filesystem bundle without modifying its contents.原样搬运上游签名文件系统包不修改其内容。发布文档强调No icon or Info.plist is patched after signing.签名之后不修补任何图标或 Info.plist。换句话说AOS 仓库中不存在对 AstridFS 的本地签名/公证流程——签名与公证由上游 Astrid 归档的认证流水线完成AOS 一侧只负责搬运 校验 安装。归档构成与打包阶段packaging打包校验器必需成员清单scripts/package_macos_filesystem.py 是 Darwin 归档的 macOS 文件系统打包入口其stage(source, destination, required)函数定义了两个层次的校验入口检查source/AstridFS.app必须是一个常规目录regular directory不接受符号链接。若缺失requiredTrue时抛出Darwin runtime archive is missing AstridFS.apprequiredFalse时静默跳过且不创建输出目录即 GNU/musl 归档可以不含此成员见后文。必需成员清单required_members应用本体与扩展.appex的 Info.plist、MacOS 二进制、_CodeSignature/CodeResources必须全部存在AstridFS.app/Contents/Info.plist AstridFS.app/Contents/MacOS/AstridFS AstridFS.app/Contents/_CodeSignature/CodeResources AstridFS.app/Contents/Extensions/AstridFSAppEx.appex/Contents/Info.plist AstridFS.app/Contents/Extensions/AstridFSAppEx.appex/Contents/MacOS/AstridFSAppEx AstridFS.app/Contents/Extensions/AstridFSAppEx.appex/Contents/_CodeSignature/CodeResources无符号链接规则对AstridFS.app内rglob(*)遍历每一个成员任何符号链接或非目录/文件的条目都会触发unsupported filesystem bundle member错误。测试 scripts/test_package_macos_filesystem.py 的test_rejects_missing_signature_and_links专门验证删除CodeResources后stage抛错把它替换为符号链接后stage依然抛错。校验通过后打包器执行三类拷贝全部使用shutil.copy2保留字节与文件模式modeAstridFS.app整体 →destination/AstridFS.appmacos/manage-macos-fskit.sh、macos/validate-macos-fskit.sh→destination/macos/仓库内的 scripts/aos-filesystem.sh →destination/macos/aos-filesystem.sh发布归档中的落位scripts/package-release.sh 将 Darwin 专属成员写入归档清单包括runtime/bin/AstridFS.app/Contents/MacOS/AstridFS runtime/bin/AstridFS.app/Contents/Extensions/AstridFSAppEx.appex/Contents/MacOS/AstridFSAppEx runtime/bin/macos/manage-macos-fskit.shscripts/test-package-release.sh 则用diff -r对比归档内AstridFS.app与源运行时的逐字节一致性并断言归档成员清单包含runtime/bin/AstridFS.app/Contents/_CodeSignature/CodeResources和runtime/bin/macos/aos-filesystem.sh——即打包后签名资源仍在、管理脚本随包。发布目录immutable release 下的保留路径install.sh是最终安装器。它将验证过的归档内容提交到一个不可变发布目录immutable release directory$AOS_HOME/releases/version/。相关文件落位归档成员发布目录中的位置AstridFS.app$release_dir/runtime/bin/AstridFS.appmacos/manage-macos-fskit.sh等$release_dir/runtime/bin/macos/aos-filesystem.shruntime/bin/macos/aos-filesystem.sh安装器实际调用入口install.sh 中的分支只有bundle/runtime/bin/AstridFS.app存在时才执行cp -Rp因此非 Darwin 归档GNU、musl天然跳过该成员[scripts/test-install.sh](https://link.gitcode.com/i/89da58cb6d7761edc5845506c273984f)的 fixture 也用diff -r断言发布目录中的AstridFS.app与运行时源逐字节一致。docs/runtime-migration.md 与 crates/unicity-aos-bootstrap/src/migration.rs 中的迁移逻辑也认识AstridFS.app与macos/这两个发布目录成员其测试 fixture 会构造AstridFS.app/Contents/Info.plist并植入符号链接来验证拒绝行为说明旧版本安装升级时的迁移路径同样以签名字节 管理脚本为输入。安装包装器 aos-filesystem.sh命名、复用与预校验scripts/aos-filesystem.sh 是产品侧的安装入口仅 25 行但承载了文档中三条关键策略。策略一产品名与文件系统名解耦/Applications/AOS.app是product-owned产品自有的外层安装名容器内部的文件系统、扩展身份和签名始终属于 Astrid。包装器默认目标即/Applications/AOS.appif [ -z ${ASTRID_FSKIT_APP_DEST:-} ]; then ASTRID_FSKIT_APP_DEST/Applications/AOS.app if [ -e /Applications/AstridFS.app ]; then if [ -e /Applications/AOS.app ]; then echo Both AOS.app and AstridFS.app exist; select the managed provider with ASTRID_FSKIT_APP_DEST. 2 exit 1 fi ASTRID_FSKIT_APP_DEST/Applications/AstridFS.app fi fi策略二复用既有 AstridFS.app避免双重注册若用户机器上已存在/Applications/AstridFS.app上游独立安装的提供程序包装器不会在AOS.app再注册一次同一 provider而是将安装目标切回既有的AstridFS.app。只有两个路径同时存在时安装器才拒绝行动并要求用户通过环境变量显式选择fail-closed退出码非零——这与发布文档中 it does not remove either app不删除任何一方的表述一致。策略三替换前必须通过上游签名/身份校验ASTRID_FSKIT_BIN_DIR${ASTRID_FSKIT_BIN_DIR:-$manager_dir/..} export ASTRID_FSKIT_APP_DEST ASTRID_FSKIT_BIN_DIR case ${1:-} in install|update) if [ -e $ASTRID_FSKIT_APP_DEST ] || [ -L $ASTRID_FSKIT_APP_DEST ]; then /bin/bash $manager_dir/manage-macos-fskit.sh validate fi ;; esac exec /bin/bash $manager_dir/manage-macos-fskit.sh $要点只有install与update子命令、且目标位置已存在常规路径或符号链接时才先调用manage-macos-fskit.sh validate——即替换现有目标前必须通过上游签名/身份校验器。目标不存在则直接走全新安装路径。无论何种子命令最终都exec到manage-macos-fskit.sh $由上游管理脚本执行实际的安装、启用与校验。ASTRID_FSKIT_APP_DEST是文档明确的显式备选目标覆盖变量ASTRID_FSKIT_BIN_DIR默认指向管理脚本目录的上级即发布目录的runtime/bin。测试基础设施大量使用ASTRID_FSKIT_APP_DEST指向临时工作目录来避免触碰真实的/Applications例如 scripts/test-install.shASTRID_FSKIT_APP_DEST$work/AOS.app和 scripts/test-upgrade-self-heal.sh。安装器调用链与失败恢复install.sh 在提交不可变发布目录之后调用文件系统安装if [ -d $release_dir/runtime/bin/AstridFS.app ]; then filesystem_manager$release_dir/runtime/bin/macos/aos-filesystem.sh if ! /bin/sh $filesystem_manager install || ! /bin/sh $filesystem_manager enable; then echo AOS runtime is installed; macOS filesystem setup is incomplete. 2 echo Allow the Astrid filesystem extension in macOS settings, then run: 2 echo /bin/sh $filesystem_manager install 2 echo /bin/sh $filesystem_manager enable 2 exit 1 fi fi这里可以读到四条与发布文档一一对应的行为事实子命令序列是install然后enable先落盘/替换应用再启用文件系统扩展。失败时installed runtime is retained错误信息第一行就是 AOS runtime is installed——运行时本体已经提交到不可变发布目录文件系统扩展的失败不回滚运行时。返回非零安装器结果并给出显式重试命令安装器把两条可复制的命令install与enable的完整绝对路径调用打印到 stderr 后exit 1这正是文档中 explicit retry commands 的落地形式。无 sudo、无 Gatekeeper 绕过、无降级签名整条链路的安装/启用都通过上游manage-macos-fskit.sh完成AOS 侧脚本不出现任何提权、绕过公证或无签名兜底逻辑文档明确 No automatic sudo, Gatekeeper bypass, or fallback unsigned signing is performed.发布文档还给出两条适用边界macOS 26 与扩展审批是前置条件macOS 26 and extension approval are required. 扩展需要用户在 macOS 设置中批准安装器失败提示中的 Allow the Astrid filesystem extension in macOS settings 对应这一动作。已安装的旧 AOS 版本需要一次 AOS 升级才能拿到该机制Already-installed AOS versions need an AOS upgrade to receive it.——因为aos-filesystem.sh位于不可变的版本化发布目录$AOS_HOME/releases/version/runtime/bin/macos/下旧版本安装中没有这个新入口。网站基础安装器与 Oracle 首次安装引导first-install bootstrap共用同一条runtime/bin/macos/aos-filesystem.sh路径。测试证据字节/模式保持与安装分发scripts/test_package_macos_filesystem.py 是这一机制的契约测试四个用例与发布文档末段 Fixture tests establish byte/mode preservation and installer dispatch, not Apple notarization 精确对应测试用例验证内容test_preserves_every_member_and_mode对 fixture 中每个文件断言拷贝后的read_bytes()与st_mode完全一致含 0755/0644 模式随后以ASTRID_FSKIT_APP_DEST指向AOS.app运行aos-filesystem.sh install断言管理脚本收到的调用日志恰为dest/AOS.app\|install——证明包装器把子命令与目标目录正确地分发给manage-macos-fskit.shtest_missing_required_apprequiredTrue且源缺失AstridFS.app时抛ValueErrorrequiredFalse时不创建输出目录test_existing_destination_validation_failure_stops_install目标已存在且manage-macos-fskit.sh validate以退出码 19 失败时aos-filesystem.sh install的返回码就是 19——预校验失败会直接终止安装test_rejects_missing_signature_and_links删除CodeResources或将其替换为符号链接后stage抛错拒绝打包无签名/含链接的 bundlefixture 中的manage-macos-fskit.sh是记录$ASTRID_FSKIT_APP_DEST与子命令的桩脚本测试由此可以精确观测包装器的分发行为而不触碰任何真实 macOS 系统。此外scripts/test-install.sh含AOS-compat.app目标与 scripts/test-upgrade-self-heal.sh 的端到端 fixture 也通过同一环境变量注入目标路径验证安装与升级自愈流程中的文件系统安装分支。必须重申文档给出的测试边界这些 fixture 测试证明的是字节/模式保持与安装分发而非 Apple 公证。生产环境的签名与挂载检查Production signature and mount checks remain necessary不在本仓库测试范围内本仓库也不存储任何 Apple 凭据。与 Command Center 的边界发布文档特意划清了一条边界受管理的AOS.app或AstridFS.app不是通用控制界面。菜单栏 Command Center 是另一个独立打包单元——share/AOS Command Center.appbundle identifier 为ai.unicity.aos.tray安装在当前用户$HOME/Applications而非系统级/Applications不与文件系统容器合并详见 release/MACOS-COMMAND-CENTER.md。文件系统扩展的身份、签名不因 Command Center 的存在而改变也不获得任何 UI 职责。这也解释了install.sh中两者互不干扰的安装分支文件系统走$release_dir/runtime/bin/...Command Center 走$release_dir/share/...。小结AOS 的 macOS 文件系统安装机制可以概括为五个设计要点签名字节主权在上游AstridFS.app由已认证的 Astrid 归档携带AOS 只校验成员完整性含拒绝符号链接与缺失签名并用copy2原样搬运发布目录不可变容器与macos/管理脚本落在$AOS_HOME/releases/version/runtime/bin/安装器从该目录调用aos-filesystem.sh命名解耦与 provider 复用外层名AOS.app属产品文件系统仍属 Astrid既有AstridFS.app被复用而非二次注册双路径并存时 fail-closed 要求ASTRID_FSKIT_APP_DEST显式裁决替换前必验install/update遇到既有目标先跑validate校验失败即终止失败可恢复、不回滚运行时失败返回非零并打印installenable两条重试命令已安装的 AOS 运行时保留全程无 sudo、无 Gatekeeper 绕过、无未签名兜底前提是 macOS 26 且用户在系统设置中批准了扩展。赞分享【免费下载链接】aos-ceAOS Community Edition: the open agent operating system.项目地址https://gitcode.com/gh_mirrors/ao/aos-ce点击查看免费下载相关推荐aos-ce 的 macOS Command CenterAOS Command Center.app 的打包、Developer ID 签名与用户级安装aos ce 的 macOS Command CenterAOS Command Center.app 的打包、Developer ID 签名与用户级安装 本pnpm 如何捆绑并保留 node-gyp独立安装中原生依赖构建保障机制解析pnpm 如何捆绑并保留 node gyp独立安装中原生依赖构建保障机制解析 本文基于仓库变更记录 .changeset/tidy pandas pack.m包管理器开发工具CLInvm-windows安装包签名如何确保软件完整性与安全性nvm windows安装包签名如何确保软件完整性与安全性 在当今数字化时代软件安全性已成为开发者首要考虑的问题。nvm windows作为Windows平开发工具CLI上一篇从弱力到胶子Particle Clicker中的粒子物理史话下一篇MinDoc接口文档自动化与Swagger集成的实现思路创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 AOS macOS 文件系统安装机制：签名 AstridFS 包如何原样保留并落地 /Applications
【免费下载链接】aos-ceAOS Community Edition: the open agent operating system.项目地址https://gitcode.com/gh_mirrors/ao/aos-ce点击查看免费下载本文围绕 AOSAOS Community Edition开源 Agent 操作系统的 macOS 文件系统安装机制展开AOS 的 Darwin 归档如何携带上游签名并公证的AstridFS.app容器install.sh与aos-filesystem.sh包装器如何在不动一字节签名内容的前提下将其安装并启用以及当权限、签名或扩展审批失败时系统如何 fail-closed 地返回明确的恢复命令。读完本文你将理解 AOS 在 macOS 26 上安装文件系统扩展的完整调用链、命名与路径决策规则ASTRID_FSKIT_APP_DEST以及仓库中验证这一机制的测试证据。核心主题签名 AstridFS 包的原样保留安装机制的起点在 release/MACOS-FILESYSTEM.md 中定义AOS 的 Darwin 归档携带签名并公证的AstridFS.app及其来自已认证 Astrid 归档的同版本配套文件。应用内容——包括扩展身份extension identity和签名——被原样拷贝。这条字节不变原则是整个机制的基石并在多处源码中得到贯彻install.sh 在安装运行时二进制时对AstridFS.app与macos/管理脚本目录使用cp -Rp复制到发布暂存区release stage注释明确写道The authenticated archive owns these signed bytes. Do not edit Info.plist, rename internal executables, or re-sign while installing the product.已认证归档拥有这些签名字节在产品安装过程中不要编辑 Info.plist、不要重命名内部可执行文件、不要重新签名。scripts/package_macos_filesystem.py 的模块 docstring 同样声明Carry the upstream signed filesystem bundle without modifying its contents.原样搬运上游签名文件系统包不修改其内容。发布文档强调No icon or Info.plist is patched after signing.签名之后不修补任何图标或 Info.plist。换句话说AOS 仓库中不存在对 AstridFS 的本地签名/公证流程——签名与公证由上游 Astrid 归档的认证流水线完成AOS 一侧只负责搬运 校验 安装。归档构成与打包阶段packaging打包校验器必需成员清单scripts/package_macos_filesystem.py 是 Darwin 归档的 macOS 文件系统打包入口其stage(source, destination, required)函数定义了两个层次的校验入口检查source/AstridFS.app必须是一个常规目录regular directory不接受符号链接。若缺失requiredTrue时抛出Darwin runtime archive is missing AstridFS.apprequiredFalse时静默跳过且不创建输出目录即 GNU/musl 归档可以不含此成员见后文。必需成员清单required_members应用本体与扩展.appex的 Info.plist、MacOS 二进制、_CodeSignature/CodeResources必须全部存在AstridFS.app/Contents/Info.plist AstridFS.app/Contents/MacOS/AstridFS AstridFS.app/Contents/_CodeSignature/CodeResources AstridFS.app/Contents/Extensions/AstridFSAppEx.appex/Contents/Info.plist AstridFS.app/Contents/Extensions/AstridFSAppEx.appex/Contents/MacOS/AstridFSAppEx AstridFS.app/Contents/Extensions/AstridFSAppEx.appex/Contents/_CodeSignature/CodeResources无符号链接规则对AstridFS.app内rglob(*)遍历每一个成员任何符号链接或非目录/文件的条目都会触发unsupported filesystem bundle member错误。测试 scripts/test_package_macos_filesystem.py 的test_rejects_missing_signature_and_links专门验证删除CodeResources后stage抛错把它替换为符号链接后stage依然抛错。校验通过后打包器执行三类拷贝全部使用shutil.copy2保留字节与文件模式modeAstridFS.app整体 →destination/AstridFS.appmacos/manage-macos-fskit.sh、macos/validate-macos-fskit.sh→destination/macos/仓库内的 scripts/aos-filesystem.sh →destination/macos/aos-filesystem.sh发布归档中的落位scripts/package-release.sh 将 Darwin 专属成员写入归档清单包括runtime/bin/AstridFS.app/Contents/MacOS/AstridFS runtime/bin/AstridFS.app/Contents/Extensions/AstridFSAppEx.appex/Contents/MacOS/AstridFSAppEx runtime/bin/macos/manage-macos-fskit.shscripts/test-package-release.sh 则用diff -r对比归档内AstridFS.app与源运行时的逐字节一致性并断言归档成员清单包含runtime/bin/AstridFS.app/Contents/_CodeSignature/CodeResources和runtime/bin/macos/aos-filesystem.sh——即打包后签名资源仍在、管理脚本随包。发布目录immutable release 下的保留路径install.sh是最终安装器。它将验证过的归档内容提交到一个不可变发布目录immutable release directory$AOS_HOME/releases/version/。相关文件落位归档成员发布目录中的位置AstridFS.app$release_dir/runtime/bin/AstridFS.appmacos/manage-macos-fskit.sh等$release_dir/runtime/bin/macos/aos-filesystem.shruntime/bin/macos/aos-filesystem.sh安装器实际调用入口install.sh 中的分支只有bundle/runtime/bin/AstridFS.app存在时才执行cp -Rp因此非 Darwin 归档GNU、musl天然跳过该成员[scripts/test-install.sh](https://link.gitcode.com/i/89da58cb6d7761edc5845506c273984f)的 fixture 也用diff -r断言发布目录中的AstridFS.app与运行时源逐字节一致。docs/runtime-migration.md 与 crates/unicity-aos-bootstrap/src/migration.rs 中的迁移逻辑也认识AstridFS.app与macos/这两个发布目录成员其测试 fixture 会构造AstridFS.app/Contents/Info.plist并植入符号链接来验证拒绝行为说明旧版本安装升级时的迁移路径同样以签名字节 管理脚本为输入。安装包装器 aos-filesystem.sh命名、复用与预校验scripts/aos-filesystem.sh 是产品侧的安装入口仅 25 行但承载了文档中三条关键策略。策略一产品名与文件系统名解耦/Applications/AOS.app是product-owned产品自有的外层安装名容器内部的文件系统、扩展身份和签名始终属于 Astrid。包装器默认目标即/Applications/AOS.appif [ -z ${ASTRID_FSKIT_APP_DEST:-} ]; then ASTRID_FSKIT_APP_DEST/Applications/AOS.app if [ -e /Applications/AstridFS.app ]; then if [ -e /Applications/AOS.app ]; then echo Both AOS.app and AstridFS.app exist; select the managed provider with ASTRID_FSKIT_APP_DEST. 2 exit 1 fi ASTRID_FSKIT_APP_DEST/Applications/AstridFS.app fi fi策略二复用既有 AstridFS.app避免双重注册若用户机器上已存在/Applications/AstridFS.app上游独立安装的提供程序包装器不会在AOS.app再注册一次同一 provider而是将安装目标切回既有的AstridFS.app。只有两个路径同时存在时安装器才拒绝行动并要求用户通过环境变量显式选择fail-closed退出码非零——这与发布文档中 it does not remove either app不删除任何一方的表述一致。策略三替换前必须通过上游签名/身份校验ASTRID_FSKIT_BIN_DIR${ASTRID_FSKIT_BIN_DIR:-$manager_dir/..} export ASTRID_FSKIT_APP_DEST ASTRID_FSKIT_BIN_DIR case ${1:-} in install|update) if [ -e $ASTRID_FSKIT_APP_DEST ] || [ -L $ASTRID_FSKIT_APP_DEST ]; then /bin/bash $manager_dir/manage-macos-fskit.sh validate fi ;; esac exec /bin/bash $manager_dir/manage-macos-fskit.sh $要点只有install与update子命令、且目标位置已存在常规路径或符号链接时才先调用manage-macos-fskit.sh validate——即替换现有目标前必须通过上游签名/身份校验器。目标不存在则直接走全新安装路径。无论何种子命令最终都exec到manage-macos-fskit.sh $由上游管理脚本执行实际的安装、启用与校验。ASTRID_FSKIT_APP_DEST是文档明确的显式备选目标覆盖变量ASTRID_FSKIT_BIN_DIR默认指向管理脚本目录的上级即发布目录的runtime/bin。测试基础设施大量使用ASTRID_FSKIT_APP_DEST指向临时工作目录来避免触碰真实的/Applications例如 scripts/test-install.shASTRID_FSKIT_APP_DEST$work/AOS.app和 scripts/test-upgrade-self-heal.sh。安装器调用链与失败恢复install.sh 在提交不可变发布目录之后调用文件系统安装if [ -d $release_dir/runtime/bin/AstridFS.app ]; then filesystem_manager$release_dir/runtime/bin/macos/aos-filesystem.sh if ! /bin/sh $filesystem_manager install || ! /bin/sh $filesystem_manager enable; then echo AOS runtime is installed; macOS filesystem setup is incomplete. 2 echo Allow the Astrid filesystem extension in macOS settings, then run: 2 echo /bin/sh $filesystem_manager install 2 echo /bin/sh $filesystem_manager enable 2 exit 1 fi fi这里可以读到四条与发布文档一一对应的行为事实子命令序列是install然后enable先落盘/替换应用再启用文件系统扩展。失败时installed runtime is retained错误信息第一行就是 AOS runtime is installed——运行时本体已经提交到不可变发布目录文件系统扩展的失败不回滚运行时。返回非零安装器结果并给出显式重试命令安装器把两条可复制的命令install与enable的完整绝对路径调用打印到 stderr 后exit 1这正是文档中 explicit retry commands 的落地形式。无 sudo、无 Gatekeeper 绕过、无降级签名整条链路的安装/启用都通过上游manage-macos-fskit.sh完成AOS 侧脚本不出现任何提权、绕过公证或无签名兜底逻辑文档明确 No automatic sudo, Gatekeeper bypass, or fallback unsigned signing is performed.发布文档还给出两条适用边界macOS 26 与扩展审批是前置条件macOS 26 and extension approval are required. 扩展需要用户在 macOS 设置中批准安装器失败提示中的 Allow the Astrid filesystem extension in macOS settings 对应这一动作。已安装的旧 AOS 版本需要一次 AOS 升级才能拿到该机制Already-installed AOS versions need an AOS upgrade to receive it.——因为aos-filesystem.sh位于不可变的版本化发布目录$AOS_HOME/releases/version/runtime/bin/macos/下旧版本安装中没有这个新入口。网站基础安装器与 Oracle 首次安装引导first-install bootstrap共用同一条runtime/bin/macos/aos-filesystem.sh路径。测试证据字节/模式保持与安装分发scripts/test_package_macos_filesystem.py 是这一机制的契约测试四个用例与发布文档末段 Fixture tests establish byte/mode preservation and installer dispatch, not Apple notarization 精确对应测试用例验证内容test_preserves_every_member_and_mode对 fixture 中每个文件断言拷贝后的read_bytes()与st_mode完全一致含 0755/0644 模式随后以ASTRID_FSKIT_APP_DEST指向AOS.app运行aos-filesystem.sh install断言管理脚本收到的调用日志恰为dest/AOS.app\|install——证明包装器把子命令与目标目录正确地分发给manage-macos-fskit.shtest_missing_required_apprequiredTrue且源缺失AstridFS.app时抛ValueErrorrequiredFalse时不创建输出目录test_existing_destination_validation_failure_stops_install目标已存在且manage-macos-fskit.sh validate以退出码 19 失败时aos-filesystem.sh install的返回码就是 19——预校验失败会直接终止安装test_rejects_missing_signature_and_links删除CodeResources或将其替换为符号链接后stage抛错拒绝打包无签名/含链接的 bundlefixture 中的manage-macos-fskit.sh是记录$ASTRID_FSKIT_APP_DEST与子命令的桩脚本测试由此可以精确观测包装器的分发行为而不触碰任何真实 macOS 系统。此外scripts/test-install.sh含AOS-compat.app目标与 scripts/test-upgrade-self-heal.sh 的端到端 fixture 也通过同一环境变量注入目标路径验证安装与升级自愈流程中的文件系统安装分支。必须重申文档给出的测试边界这些 fixture 测试证明的是字节/模式保持与安装分发而非 Apple 公证。生产环境的签名与挂载检查Production signature and mount checks remain necessary不在本仓库测试范围内本仓库也不存储任何 Apple 凭据。与 Command Center 的边界发布文档特意划清了一条边界受管理的AOS.app或AstridFS.app不是通用控制界面。菜单栏 Command Center 是另一个独立打包单元——share/AOS Command Center.appbundle identifier 为ai.unicity.aos.tray安装在当前用户$HOME/Applications而非系统级/Applications不与文件系统容器合并详见 release/MACOS-COMMAND-CENTER.md。文件系统扩展的身份、签名不因 Command Center 的存在而改变也不获得任何 UI 职责。这也解释了install.sh中两者互不干扰的安装分支文件系统走$release_dir/runtime/bin/...Command Center 走$release_dir/share/...。小结AOS 的 macOS 文件系统安装机制可以概括为五个设计要点签名字节主权在上游AstridFS.app由已认证的 Astrid 归档携带AOS 只校验成员完整性含拒绝符号链接与缺失签名并用copy2原样搬运发布目录不可变容器与macos/管理脚本落在$AOS_HOME/releases/version/runtime/bin/安装器从该目录调用aos-filesystem.sh命名解耦与 provider 复用外层名AOS.app属产品文件系统仍属 Astrid既有AstridFS.app被复用而非二次注册双路径并存时 fail-closed 要求ASTRID_FSKIT_APP_DEST显式裁决替换前必验install/update遇到既有目标先跑validate校验失败即终止失败可恢复、不回滚运行时失败返回非零并打印installenable两条重试命令已安装的 AOS 运行时保留全程无 sudo、无 Gatekeeper 绕过、无未签名兜底前提是 macOS 26 且用户在系统设置中批准了扩展。赞分享【免费下载链接】aos-ceAOS Community Edition: the open agent operating system.项目地址https://gitcode.com/gh_mirrors/ao/aos-ce点击查看免费下载相关推荐aos-ce 的 macOS Command CenterAOS Command Center.app 的打包、Developer ID 签名与用户级安装aos ce 的 macOS Command CenterAOS Command Center.app 的打包、Developer ID 签名与用户级安装 本pnpm 如何捆绑并保留 node-gyp独立安装中原生依赖构建保障机制解析pnpm 如何捆绑并保留 node gyp独立安装中原生依赖构建保障机制解析 本文基于仓库变更记录 .changeset/tidy pandas pack.m包管理器开发工具CLInvm-windows安装包签名如何确保软件完整性与安全性nvm windows安装包签名如何确保软件完整性与安全性 在当今数字化时代软件安全性已成为开发者首要考虑的问题。nvm windows作为Windows平开发工具CLI上一篇从弱力到胶子Particle Clicker中的粒子物理史话下一篇MinDoc接口文档自动化与Swagger集成的实现思路创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考