用途：开发并交付 Gimbal 的 CLI/服务端与 macOS 应用，覆盖应用实现、发布恢复和已发布安装。范围、评审与完成标准以仓库的 AGENTS.md 和 docs/definition-of-done.md 为准；可执行检查与发布以 Justfile 和 .github/workflows/ 为准。
快速反馈：编辑循环使用 just dev，先运行受影响测试并观察目标行为再提合并。提交钩子运行暂存文件检查与小型未缓存单元测试包，目标一秒、预算三秒；超时打印警告并记录未完成检查而非阻止交付，但真实正确性失败仍需处理。just warm-hook 在提交路径外准备编译器缓存。生成器、安装、全仓库分析和浏览器构建不进入钩子。
PR CI 按变更文件选择检查：文档做指令/链接检查，自动化做脚本/钩子检查，应用变更跑受影响单元测试。main 在分发前有一个完整应用门禁。不要因提交、合并或打标签而重复未变化的检查；已有证据须注明来源并覆盖结论，出现新失败或输入变化才重跑相关检查。
原生 UI 变更需用一次性目录观察实际应用与 macOS 系统菜单栏，不要用 ~/.gimbal/desktop；用 gimbal upload-artifact 上传所需截图。构建或 HTTP 响应本身不能证明像素。源码构建与应用生命周期见 development.md，目录刷新见 model-catalog.md。
自动交付：在用户授权内合并，然后按 Automatic release 从 main 到 Release 运行。非文档变更在 main 上检查一次，打标签、为支持平台构建、签名/公证并发布到更新源与 Homebrew tap；仅文档变更不发布应用。需验证已发布版本与渠道，合并的 PR 或排队运行不算已发布。复用流水线的精确源码检查，不要在合并或打标签后再加本地构建。
时间策略见 scripts/release-performance.json：main 到发布目标五分钟、上限十分钟；排队/重试计入，各阶段耗时单独报告。发布性能只观察运行并对超时开 issue，不使应用测试失败或停止发布。
发布失败时重跑失败的已打标签 Release 作业，或在 main 上派发 Automatic release 复用现有标签；重试前先检查失败阶段，避免重复已成功的应用检查。凭据、规则、手动主/次版本标签、签名恢复与插件兼容见 distribution.md。常规交付无需新增凭据或权限变更。
本地安装：使用公开 Homebrew cask（gimbal 与 gimbal-app），检查已安装版本与实际可执行文件/应用路径。裸 go install 会缺少内置 Web 控制台。按需刷新受影响的已发布技能及其支撑引用，并与维护中的源码比对。被要求时需提供本地安装与运行时证明，但这不是每次合并的额外步骤。
报告应说明观察到的目标行为、源码修订、相关检查、发布状态与剩余证明缺口，并区分源码证明、分发产物证明与已安装 UI 证明。签名/凭据细节保留在分发参考中，不复制进常规流程。