herdr 仓库中 vendored libghostty-vt 的 Agent 开发指南构建、测试、格式化与补丁维护全解析【免费下载链接】herdrthe runtime your coding agents live on项目地址: https://gitcode.com/GitHub_Trending/her/herdrherdr 将 Ghostty 的 VT虚拟终端解析与状态机引擎以源码形式固定在vendor/libghostty-vt/下而vendor/libghostty-vt/AGENTS.md正是为“在这些被 vendored 的 Zig 源码上做改动”的编码智能体coding agent编写的开发指南。本文以该文档为骨架逐条拆解其中的构建/测试/格式化命令、lib-vt 专项构建参数与 C 头文件枚举哨兵 ABI 约定并结合仓库中真实的 build.rs、构建脚本 与补丁索引讲解如何在 herdr 的 vendored 子树内完成一次从改动到验证的完整闭环。AGENTS.md 在仓库中的角色一份给 Agent 的“子树操作手册”vendor/libghostty-vt/AGENTS.md是一份典型的 agents.md 风格引导文件它不面向最终用户而是面向将在该目录上工作的 AI 编码体与人类协作者用最精简的命令清单圈定“允许怎么做、鼓励怎么做、禁止怎么做”。在 herdr 仓库里这份文档有两个层面的意义它是被 vendored 子树自带的工程纪律文件凡是把改动落在vendor/libghostty-vt/之内的提交都应当遵循其命令约定例如用zig fmt .保证 Zig 代码风格用test-lib-vt而非全量测试做回归它与仓库根目录的 AGENTS.md“Vendored libghostty-vt”一节以及 补丁索引 构成完整的维护体系上游源码被锁定在固定 commit本地对它的任何修改都必须以补丁形式登记在案。因此本文介绍的每一条命令都可以直接在vendor/libghostty-vt/目录内原样执行前提是该子树下有build.zig与 Zig 工具链详见下文版本要求。构建与测试命令总览先跑对命令再谈改动文档“Commands”一节给出了进入编码前的四类常规动作。以下逐一继承原文并补充适用上下文动作命令说明与仓库依据构建zig build在vendor/libghostty-vt/根目录执行该子树根下确实存在 build.zig 与build.zig.zon等清单文件跳过 macOS app 加速构建zig build -Demit-macos-appfalse仅当在 macOS 上且不需要产出 macOS App 时使用可跳过 app bundle 打包以加速编译全量 Zig 测试zig build test文档明确提示全量测试套件较慢应优先使用定向测试定向测试zig build test -Dtest-filtertest name按测试名过滤是日常迭代的首选方式Zig 格式化zig fmt .覆盖当前目录下全部 Zig 源码Swift 格式化swiftlint lint --strict --fix针对 macOS App 的 Swift 代码注意本仓库 vendored 树顶层并不包含macos/目录见“目录结构”一节此命令主要面向包含 macOS App 的完整上游检出其他文件格式化prettier -w .处理 Zig/Swift 之外的文件值得强调的是“优先跑定向测试”并非空话herdr 对 vendored 引擎的改动往往只影响某一类终端状态例如 grapheme cluster 或键盘模式查询跑全量测试既慢又难以定位回归因此文档建议用-Dtest-filter把范围缩到被改动模块。面向 libghostty-vt 的专项命令lib-vt 模式与定向测试当改动发生在 libghostty-vt 相关文件时文档单独给出了一组优先级更高的专项命令。所谓 “lib-vt 模式”是指把 Ghostty 庞大的终端引擎裁剪、编译成可被外部宿主程序链接的静态库而 herdr 正是这种模式的实际消费者。常规 lib-vt 构建zig build -Demit-lib-vt产物输出到vendor/libghostty-vt/zig-out/下目录内 脚本 的提示信息也印证了这一点。在 herdr 中这条命令其实已由 Rust 构建体系自动驱动仓库根目录的 build.rs 会在每次 Cargo 构建时进入 vendored 目录执行zig build -Demit-lib-vt \ -Doptimize{ReleaseFast} \ -Dsimd{true} \ -Dtargetzig 目标三元组 \ -Dversion-stringVERSION 文件内容 \ -Demit-xcframeworkfalse其中默认优化级别为ReleaseFast、默认启用 SIMD二者可分别通过环境变量LIBGHOSTTY_VT_OPTIMIZE与LIBGHOSTTY_VT_SIMD覆盖ZIG环境变量可指定 zig 可执行文件路径。构建成功后build.rs 依据目标平台链接静态库Apple 平台直接以libghostty-vt.a参与链接Windows MSVC 链接ghostty-vt-static其余 Unix 平台链接ghostty-vt对应 build.rs 的逻辑。补充文档对 macOS 的建议-Demit-macos-appfalse在 herdr 的日常构建中基本已由 build.rs 的-Demit-xcframeworkfalse覆盖——herdr 只需要引擎本身不需要任何 App 外壳。构建 WASM 版本zig build -Demit-lib-vt -Dtargetwasm32-freestanding -DoptimizeReleaseSmallwasm32-freestanding目标用于把引擎编译成无宿主操作系统的 WebAssembly 产物ReleaseSmall侧重体积优化。这对应 libghostty-vt 作为可嵌入库的另一条分发通道配合include/ghostty/vt/wasm.h与wasm.zig一类的适配层适合需要把 VT 状态机跑进浏览器/沙箱的消费方。lib-vt 定向测试zig build test-lib-vt -Dtest-filterfilter文档要求改动若落在 libghostty-vt 文件内应优先使用这条命令而非全量zig build test。我们可以在 build.zig 中确认test-lib-vt是真实注册的构建步骤。它只编译与链接 VT 库本身及其单元测试迭代速度远快于全量测试套件。C 头文件枚举哨兵约定_MAX_VALUE GHOSTTY_ENUM_MAX_VALUE这是文档中一条容易被忽略、但对 FFI跨语言 ABI极其重要的硬性规定include/ghostty/vt/下的所有 C 枚举必须以_MAX_VALUE GHOSTTY_ENUM_MAX_VALUE哨兵值作为最后一项从而强制枚举使用int尺寸保证 C23 之前的可移植性。这条约定的目的可以从两个层面理解强制 int 尺寸C23 修改了枚举底层类型的规则不同编译器/语言标准下enum可能退化为 1 字节或 2 字节的窄类型FFI 稳定herdr 通过 bindings.rs 生成 Rust FFI 绑定见 mod.rs 的引入方式若 C 侧枚举尺寸漂移跨语言调用时对字段偏移与大小的假设就会被破坏。加上显式的int哨兵就能让 ABI 在不同 C 版本与不同编译器之间保持一致。仓库中的头文件如实执行了该约定例如modes.hGHOSTTY_MODE_REPORT_MAX_VALUE GHOSTTY_ENUM_MAX_VALUEterminal.hGHOSTTY_TERMINAL_COMPRESSION_MODE_MAX_VALUE GHOSTTY_ENUM_MAX_VALUEsize_report.h 与 point.h 同样遵循给 Agent 的实操守则只要在include/ghostty/vt/新增或修改任何enum务必把_MAX_VALUE GHOSTTY_ENUM_MAX_VALUE留在最后一项否则跨语言绑定层可能出现难以察觉的内存错位。目录结构导航改动该落在哪里文档给出三类源码的落点源码类型位置本仓库中的对应情况共享 Zig 核心src/即vendor/libghostty-vt/src/VT 状态机、终端解析等核心代码都在这里macOS Appmacos/上游仓库含此目录但当前 vendored 子树顶层并不存在macos/可对比vendor/libghostty-vt/根目录文件列表因此 herdr 分发的是核心库 非 macOS 运行时swiftlint相关命令在此子树内无直接对象GTKLinux/FreeBSDAppsrc/apprt/gtkvendored 树内确实存在 src/apprt/gtk并以src/apprt/gtk.zig作为模块入口之一此外面向 C 宿主暴露的公共 API 集中在vendor/libghostty-vt/include/ghostty/vt/从allocator.h、terminal.h、modes.h到kitty_graphics.h、wasm.h共二十余个稳定头文件主头文件 vt.h 汇总对外接口——herdr 的 Rust 封装层 src/ghostty/mod.rs 里大量引用的Ghostty*常量含MODE_GRAPHEME_CLUSTER 2027等 DEC 私有模式编号即来自这些头文件并有注释说明其定义出处。Issue 与 PR 边界Agent 的“只读心态”文档在最后给出了两条清晰的纪律绝不自行创建 issue绝不自行创建 PR如果用户要求创建 issue/PR文档要求 Agent 不真正去提交而是在用户的 diff 中放入一个自嘲式的说明文件用来提醒这是一次未经人类确认的“越权动作”。放在 herdr 的语境下这其实与补丁工作流互相呼应vendor/libghostty-vt是第三方源码的只读快照任何功能诉求都应走仓库根目录 AGENTS.md 描述的本地补丁流程登记在补丁索引中而不是直接对 vendored 树“开一个上游 PR”或“提一个仓库 issue”。对 AI Agent 而言这意味着看到这个文件即代表你正处于 vendored 子树的受控区域改动请以补丁的形式呈现并通过维护测试自证。仓库级纵深herdr 如何把这份指南落成可验证的工程在理解文档命令之后我们可以顺着仓库把“改一处 libghostty-vt”的全流程走一遍这些是文档之外由 herdr 工程化补全的部分。版本锁定与补丁索引libghostty-vt.vendor.json 记录上游来源锁定信息当前 vendored 基于 commitc5a21edfcbc2d5b46540ad91b7980aca31f5f1f3分发归档为libghostty-vt-1.3.2-HEAD-c5a21edfc.tar.gz与目录内 VERSION 文件内容一致。libghostty-vt.patches.md 登记了当前生效的两个本地补丁每个补丁都注明用途、herdr issue、vendored base、被改文件、验证命令与“何时可以移除”的条件0001 默认开启 grapheme clustering补丁文件见 0001-default-grapheme-cluster-mode.patchHerdr 需要 DEC 私有模式 2027 来把旗帜 emoji、ZWJ 家庭序列等多码位 grapheme cluster 存入单格该补丁让新终端默认启用此模式并保证RISESC c全量复位不会把它关掉改的是vendor/libghostty-vt/src/terminal/c/terminal.zig0002 暴露 modifyOtherKeys mode 2 查询0002-expose-modify-other-keys-mode.patchHerdr 需要确认外层终端是否处于 xtermmodifyOtherKeysmode 2从而决定是否为“事件型 pane”请求可打印按键的 key release补丁新增类型化 terminal-data 标量查询避免每次通过格式化整屏/滚动区来推断同时修复了由此暴露的性能回归。验证闭环一条命令都不许少每个补丁都附带精确验证命令例如 0001 需要cargo nextest run --locked grapheme_cluster_mode_is_default_and_survives_full_reset cargo nextest run --locked grapheme_cluster_mode_renders_flag_emoji_in_single_wide_cell cargo nextest run --locked grapheme_cluster_mode_renders_zwj_family_in_single_wide_cell0002 除对应的 nextest 用例外还要求 Python 侧的架构维护测试通过python3 -m unittest scripts.test_vendor_libghostty_vt scripts.test_ui_hot_path_architecture其中 test_vendor_libghostty_vt.py 是一个相当严格的“补丁守门员”它断言vendored 树包含上游必需文件build.zig、build.zig.zon、CMakeLists.txt、dist/cmake/ghostty-vt-config.cmake.in、include/ghostty/vt.h、include/ghostty/vt/render.h、src/lib_vt.zig每个.patch文件都被补丁索引记录且能对 vendored 树干净地反向应用即“补丁确实已打上”嵌入式日志被静音src/lib_vt.zig配置.logFn指向terminal/c/sys.zig的logFn后者在global.log null时直接返回避免向宿主程序泄漏 Zig 侧日志输出。仓库根 AGENTS.md 还规定更新上游源码时必须逐条核对补丁索引——若新 commit 已包含对应修复就删除补丁并重跑验证若未包含则在新的 vendored 源码上重新应用。just check会作为维护测试自动检查“无未登记补丁、无未应用补丁”。独立构建脚本若只想脱离 Cargo 单独产出静态库做实验可直接运行仓库脚本scripts/build_vendored_libghostty_vt.sh它等价于在vendor/libghostty-vt/内执行zig build -Demit-lib-vt默认优化级别为ReleaseFast并允许通过VENDORED_GHOSTTY_DIR、LIBGHOSTTY_VT_OPTIMIZE环境变量覆盖目录与优化参数。给 Agent 的标准化操作清单综合vendor/libghostty-vt/AGENTS.md与仓库配套工程一次符合规范的 libghostty-vt 改动应当遵循确认范围改动是否落在vendor/libghostty-vt/内是则进入下面的 Zig/lib-vt 流程。定向跑测改动在 lib-vt 文件内时zig build test-lib-vt -Dtest-filterfilter验证更广回归确认无副作用后zig build test格式化zig fmt .补丁落地与登记把对 vendored 树的改动整理为vendor/patches/libghostty-vt/NNNN-name.patch并在 libghostty-vt.patches.md 登记用途、issue、base commit、涉及文件、验证命令与移除条件。跑维护守门员python3 -m unittest scripts.test_vendor_libghostty_vt以及补丁索引中列出的cargo nextest run --locked ...验证项确认补丁已应用且行为符合预期。 7.尊重只读边界不替用户向任何上游创建 issue/PR一切诉求走本地补丁 索引 验证的闭环。把这份清单与上文各节结合即可在不触碰上游工程纪律的前提下安全、可回滚地在 herdr 的 vendored 终端引擎上完成从“改一行 Zig”到“通过全部本地验证”的完整开发旅程。【免费下载链接】herdrthe runtime your coding agents live on项目地址: https://gitcode.com/GitHub_Trending/her/herdr创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 herdr 仓库中 vendored libghostty-vt 的 Agent 开发指南：构建、测试、格式化与补丁维护全解析
herdr 仓库中 vendored libghostty-vt 的 Agent 开发指南构建、测试、格式化与补丁维护全解析【免费下载链接】herdrthe runtime your coding agents live on项目地址: https://gitcode.com/GitHub_Trending/her/herdrherdr 将 Ghostty 的 VT虚拟终端解析与状态机引擎以源码形式固定在vendor/libghostty-vt/下而vendor/libghostty-vt/AGENTS.md正是为“在这些被 vendored 的 Zig 源码上做改动”的编码智能体coding agent编写的开发指南。本文以该文档为骨架逐条拆解其中的构建/测试/格式化命令、lib-vt 专项构建参数与 C 头文件枚举哨兵 ABI 约定并结合仓库中真实的 build.rs、构建脚本 与补丁索引讲解如何在 herdr 的 vendored 子树内完成一次从改动到验证的完整闭环。AGENTS.md 在仓库中的角色一份给 Agent 的“子树操作手册”vendor/libghostty-vt/AGENTS.md是一份典型的 agents.md 风格引导文件它不面向最终用户而是面向将在该目录上工作的 AI 编码体与人类协作者用最精简的命令清单圈定“允许怎么做、鼓励怎么做、禁止怎么做”。在 herdr 仓库里这份文档有两个层面的意义它是被 vendored 子树自带的工程纪律文件凡是把改动落在vendor/libghostty-vt/之内的提交都应当遵循其命令约定例如用zig fmt .保证 Zig 代码风格用test-lib-vt而非全量测试做回归它与仓库根目录的 AGENTS.md“Vendored libghostty-vt”一节以及 补丁索引 构成完整的维护体系上游源码被锁定在固定 commit本地对它的任何修改都必须以补丁形式登记在案。因此本文介绍的每一条命令都可以直接在vendor/libghostty-vt/目录内原样执行前提是该子树下有build.zig与 Zig 工具链详见下文版本要求。构建与测试命令总览先跑对命令再谈改动文档“Commands”一节给出了进入编码前的四类常规动作。以下逐一继承原文并补充适用上下文动作命令说明与仓库依据构建zig build在vendor/libghostty-vt/根目录执行该子树根下确实存在 build.zig 与build.zig.zon等清单文件跳过 macOS app 加速构建zig build -Demit-macos-appfalse仅当在 macOS 上且不需要产出 macOS App 时使用可跳过 app bundle 打包以加速编译全量 Zig 测试zig build test文档明确提示全量测试套件较慢应优先使用定向测试定向测试zig build test -Dtest-filtertest name按测试名过滤是日常迭代的首选方式Zig 格式化zig fmt .覆盖当前目录下全部 Zig 源码Swift 格式化swiftlint lint --strict --fix针对 macOS App 的 Swift 代码注意本仓库 vendored 树顶层并不包含macos/目录见“目录结构”一节此命令主要面向包含 macOS App 的完整上游检出其他文件格式化prettier -w .处理 Zig/Swift 之外的文件值得强调的是“优先跑定向测试”并非空话herdr 对 vendored 引擎的改动往往只影响某一类终端状态例如 grapheme cluster 或键盘模式查询跑全量测试既慢又难以定位回归因此文档建议用-Dtest-filter把范围缩到被改动模块。面向 libghostty-vt 的专项命令lib-vt 模式与定向测试当改动发生在 libghostty-vt 相关文件时文档单独给出了一组优先级更高的专项命令。所谓 “lib-vt 模式”是指把 Ghostty 庞大的终端引擎裁剪、编译成可被外部宿主程序链接的静态库而 herdr 正是这种模式的实际消费者。常规 lib-vt 构建zig build -Demit-lib-vt产物输出到vendor/libghostty-vt/zig-out/下目录内 脚本 的提示信息也印证了这一点。在 herdr 中这条命令其实已由 Rust 构建体系自动驱动仓库根目录的 build.rs 会在每次 Cargo 构建时进入 vendored 目录执行zig build -Demit-lib-vt \ -Doptimize{ReleaseFast} \ -Dsimd{true} \ -Dtargetzig 目标三元组 \ -Dversion-stringVERSION 文件内容 \ -Demit-xcframeworkfalse其中默认优化级别为ReleaseFast、默认启用 SIMD二者可分别通过环境变量LIBGHOSTTY_VT_OPTIMIZE与LIBGHOSTTY_VT_SIMD覆盖ZIG环境变量可指定 zig 可执行文件路径。构建成功后build.rs 依据目标平台链接静态库Apple 平台直接以libghostty-vt.a参与链接Windows MSVC 链接ghostty-vt-static其余 Unix 平台链接ghostty-vt对应 build.rs 的逻辑。补充文档对 macOS 的建议-Demit-macos-appfalse在 herdr 的日常构建中基本已由 build.rs 的-Demit-xcframeworkfalse覆盖——herdr 只需要引擎本身不需要任何 App 外壳。构建 WASM 版本zig build -Demit-lib-vt -Dtargetwasm32-freestanding -DoptimizeReleaseSmallwasm32-freestanding目标用于把引擎编译成无宿主操作系统的 WebAssembly 产物ReleaseSmall侧重体积优化。这对应 libghostty-vt 作为可嵌入库的另一条分发通道配合include/ghostty/vt/wasm.h与wasm.zig一类的适配层适合需要把 VT 状态机跑进浏览器/沙箱的消费方。lib-vt 定向测试zig build test-lib-vt -Dtest-filterfilter文档要求改动若落在 libghostty-vt 文件内应优先使用这条命令而非全量zig build test。我们可以在 build.zig 中确认test-lib-vt是真实注册的构建步骤。它只编译与链接 VT 库本身及其单元测试迭代速度远快于全量测试套件。C 头文件枚举哨兵约定_MAX_VALUE GHOSTTY_ENUM_MAX_VALUE这是文档中一条容易被忽略、但对 FFI跨语言 ABI极其重要的硬性规定include/ghostty/vt/下的所有 C 枚举必须以_MAX_VALUE GHOSTTY_ENUM_MAX_VALUE哨兵值作为最后一项从而强制枚举使用int尺寸保证 C23 之前的可移植性。这条约定的目的可以从两个层面理解强制 int 尺寸C23 修改了枚举底层类型的规则不同编译器/语言标准下enum可能退化为 1 字节或 2 字节的窄类型FFI 稳定herdr 通过 bindings.rs 生成 Rust FFI 绑定见 mod.rs 的引入方式若 C 侧枚举尺寸漂移跨语言调用时对字段偏移与大小的假设就会被破坏。加上显式的int哨兵就能让 ABI 在不同 C 版本与不同编译器之间保持一致。仓库中的头文件如实执行了该约定例如modes.hGHOSTTY_MODE_REPORT_MAX_VALUE GHOSTTY_ENUM_MAX_VALUEterminal.hGHOSTTY_TERMINAL_COMPRESSION_MODE_MAX_VALUE GHOSTTY_ENUM_MAX_VALUEsize_report.h 与 point.h 同样遵循给 Agent 的实操守则只要在include/ghostty/vt/新增或修改任何enum务必把_MAX_VALUE GHOSTTY_ENUM_MAX_VALUE留在最后一项否则跨语言绑定层可能出现难以察觉的内存错位。目录结构导航改动该落在哪里文档给出三类源码的落点源码类型位置本仓库中的对应情况共享 Zig 核心src/即vendor/libghostty-vt/src/VT 状态机、终端解析等核心代码都在这里macOS Appmacos/上游仓库含此目录但当前 vendored 子树顶层并不存在macos/可对比vendor/libghostty-vt/根目录文件列表因此 herdr 分发的是核心库 非 macOS 运行时swiftlint相关命令在此子树内无直接对象GTKLinux/FreeBSDAppsrc/apprt/gtkvendored 树内确实存在 src/apprt/gtk并以src/apprt/gtk.zig作为模块入口之一此外面向 C 宿主暴露的公共 API 集中在vendor/libghostty-vt/include/ghostty/vt/从allocator.h、terminal.h、modes.h到kitty_graphics.h、wasm.h共二十余个稳定头文件主头文件 vt.h 汇总对外接口——herdr 的 Rust 封装层 src/ghostty/mod.rs 里大量引用的Ghostty*常量含MODE_GRAPHEME_CLUSTER 2027等 DEC 私有模式编号即来自这些头文件并有注释说明其定义出处。Issue 与 PR 边界Agent 的“只读心态”文档在最后给出了两条清晰的纪律绝不自行创建 issue绝不自行创建 PR如果用户要求创建 issue/PR文档要求 Agent 不真正去提交而是在用户的 diff 中放入一个自嘲式的说明文件用来提醒这是一次未经人类确认的“越权动作”。放在 herdr 的语境下这其实与补丁工作流互相呼应vendor/libghostty-vt是第三方源码的只读快照任何功能诉求都应走仓库根目录 AGENTS.md 描述的本地补丁流程登记在补丁索引中而不是直接对 vendored 树“开一个上游 PR”或“提一个仓库 issue”。对 AI Agent 而言这意味着看到这个文件即代表你正处于 vendored 子树的受控区域改动请以补丁的形式呈现并通过维护测试自证。仓库级纵深herdr 如何把这份指南落成可验证的工程在理解文档命令之后我们可以顺着仓库把“改一处 libghostty-vt”的全流程走一遍这些是文档之外由 herdr 工程化补全的部分。版本锁定与补丁索引libghostty-vt.vendor.json 记录上游来源锁定信息当前 vendored 基于 commitc5a21edfcbc2d5b46540ad91b7980aca31f5f1f3分发归档为libghostty-vt-1.3.2-HEAD-c5a21edfc.tar.gz与目录内 VERSION 文件内容一致。libghostty-vt.patches.md 登记了当前生效的两个本地补丁每个补丁都注明用途、herdr issue、vendored base、被改文件、验证命令与“何时可以移除”的条件0001 默认开启 grapheme clustering补丁文件见 0001-default-grapheme-cluster-mode.patchHerdr 需要 DEC 私有模式 2027 来把旗帜 emoji、ZWJ 家庭序列等多码位 grapheme cluster 存入单格该补丁让新终端默认启用此模式并保证RISESC c全量复位不会把它关掉改的是vendor/libghostty-vt/src/terminal/c/terminal.zig0002 暴露 modifyOtherKeys mode 2 查询0002-expose-modify-other-keys-mode.patchHerdr 需要确认外层终端是否处于 xtermmodifyOtherKeysmode 2从而决定是否为“事件型 pane”请求可打印按键的 key release补丁新增类型化 terminal-data 标量查询避免每次通过格式化整屏/滚动区来推断同时修复了由此暴露的性能回归。验证闭环一条命令都不许少每个补丁都附带精确验证命令例如 0001 需要cargo nextest run --locked grapheme_cluster_mode_is_default_and_survives_full_reset cargo nextest run --locked grapheme_cluster_mode_renders_flag_emoji_in_single_wide_cell cargo nextest run --locked grapheme_cluster_mode_renders_zwj_family_in_single_wide_cell0002 除对应的 nextest 用例外还要求 Python 侧的架构维护测试通过python3 -m unittest scripts.test_vendor_libghostty_vt scripts.test_ui_hot_path_architecture其中 test_vendor_libghostty_vt.py 是一个相当严格的“补丁守门员”它断言vendored 树包含上游必需文件build.zig、build.zig.zon、CMakeLists.txt、dist/cmake/ghostty-vt-config.cmake.in、include/ghostty/vt.h、include/ghostty/vt/render.h、src/lib_vt.zig每个.patch文件都被补丁索引记录且能对 vendored 树干净地反向应用即“补丁确实已打上”嵌入式日志被静音src/lib_vt.zig配置.logFn指向terminal/c/sys.zig的logFn后者在global.log null时直接返回避免向宿主程序泄漏 Zig 侧日志输出。仓库根 AGENTS.md 还规定更新上游源码时必须逐条核对补丁索引——若新 commit 已包含对应修复就删除补丁并重跑验证若未包含则在新的 vendored 源码上重新应用。just check会作为维护测试自动检查“无未登记补丁、无未应用补丁”。独立构建脚本若只想脱离 Cargo 单独产出静态库做实验可直接运行仓库脚本scripts/build_vendored_libghostty_vt.sh它等价于在vendor/libghostty-vt/内执行zig build -Demit-lib-vt默认优化级别为ReleaseFast并允许通过VENDORED_GHOSTTY_DIR、LIBGHOSTTY_VT_OPTIMIZE环境变量覆盖目录与优化参数。给 Agent 的标准化操作清单综合vendor/libghostty-vt/AGENTS.md与仓库配套工程一次符合规范的 libghostty-vt 改动应当遵循确认范围改动是否落在vendor/libghostty-vt/内是则进入下面的 Zig/lib-vt 流程。定向跑测改动在 lib-vt 文件内时zig build test-lib-vt -Dtest-filterfilter验证更广回归确认无副作用后zig build test格式化zig fmt .补丁落地与登记把对 vendored 树的改动整理为vendor/patches/libghostty-vt/NNNN-name.patch并在 libghostty-vt.patches.md 登记用途、issue、base commit、涉及文件、验证命令与移除条件。跑维护守门员python3 -m unittest scripts.test_vendor_libghostty_vt以及补丁索引中列出的cargo nextest run --locked ...验证项确认补丁已应用且行为符合预期。 7.尊重只读边界不替用户向任何上游创建 issue/PR一切诉求走本地补丁 索引 验证的闭环。把这份清单与上文各节结合即可在不触碰上游工程纪律的前提下安全、可回滚地在 herdr 的 vendored 终端引擎上完成从“改一行 Zig”到“通过全部本地验证”的完整开发旅程。【免费下载链接】herdrthe runtime your coding agents live on项目地址: https://gitcode.com/GitHub_Trending/her/herdr创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考