【免费下载链接】OpenAliceYour one-person Wall Street. An AI trading agent covering equities, crypto, commodities, forex, and macro — from research through position entry, ongoing management, to exit.项目地址https://gitcode.com/gh_mirrors/op/OpenAlice点击查看免费下载OpenAlice 是一个面向原生编码 Agent CLI 的本地交易工作区Alice 负责启动 Workspace 并注入交易上下文独立的 UTA 进程持有券商凭据与所有交易写入。本文以仓库中的 docs/development-workflow.md 为核心骨架系统讲解其维护者工作流分支车道划分、三种交付模式的合并权限、PR 生命周期与主题标签契约、本地反馈阶梯、CI 反馈车道、dev→master晋升、beta/stable 发布治理、紧急热修复、外部贡献审查与风险门禁。读完本文你将能准确执行从会话开始到发布验收的全链路操作并理解每条命令背后的治理约束。该指南是 OpenAlice 治理体系的灵魂文档它拥有维护者工作流的全部细则而 AGENTS.md 只保留每次会话开始必须遵守的精简规则docs/README.md 则是全部 Owner Guide 的索引。三者的关系是AGENTS.md 是入口workflow 指南是详细程序各子系统 Owner Guide 承载持久化的事实。分支车道Branch LanesOpenAlice 的分支拓扑将日常集成与用户可见发布源分离并让发布动作始终由人从master手动触发dev—— 集成车道与可测试预览环境常规开发在此整合。合并进dev的安装器变更会通过可变的raw/.../dev/install端点与匹配的--channel dev载荷选择器被实际演练。也就是说推送到dev本身就是一条仅限 CLI 的滚动发布车道详见下文 CI 反馈车道。master—— 发布源/用户面车道与默认 GitHub 分支dev合并到master只确立可发布源码并不选择版本或发布 Release。发布自动化从master手动派发必须显式携带beta或stable通道与 tag。tag 版本与两个产品包清单根package.json与packages/cli/package.json必须一致候选工作才能开始。每个被接受的 tag 只能更新属于自己的可变产品别名新接受的发布还可以刷新共享的通道中立install引导。Release操作的publish-npm只分发一个已经发布的 stable 版本。它可以复用集成好的dev或master工具链但不能创建版本、重建构件或变更产品通道。其首次发布/重试契约见 docs/cli-package-managers.md。Release操作的verify-npm从dev或master校验完整的 npm OIDC 包集合不打 tag、不构建、不上传包。npm 发布使用工作流的身份OIDC而不是轮换的仓库 token。archive/dev-pre-beta6历史快照分支禁止修改或删除。local遗留的共享 worktree 分支不是默认工作流在决定保留还是退役前必须先审计其未合并提交。常规工作的起点是当前dev使用聚焦的特性分支并开 PR 回到dev。永远不要对dev或master强推force-push或删除。会话开始Session Start每次开始编辑前先同步远端并确认 checkout 状态git fetch origin git status -sb git log --oneline origin/dev..HEAD git log --oneline origin/master..HEAD然后确立 checkout 的所有权保留无关的脏文件不要 stash、reset 或把它们吸收进任务里除非明确授权。共享 worktree如果另一个活跃会话共用同一个 worktree不要在其脚下切换分支应串行化工作或使用独立的 checkout/sandbox。HEAD 在dev先快进fast-forward再开分支。HEAD 在特性分支先查明其 PR 是仍打开、已合并、关闭未合并还是不存在再继续。HEAD 在master或意外历史分支确认任务是晋升/热修复还是应回到dev。这套规则的目的是任何时刻都清楚我站在哪个车道、该把增量送到哪里避免把无人认领的分支或脏状态带进下一个任务。交付模式Delivery Modes交付模式控制的是合并权限merge authority而不是实现质量。三种模式共享同一条实现与评审标准差异只在于增量何时、以何种形式进入dev或master。特性分支迭代保持Feature-branch iteration hold特性分支迭代是一条显式的自然语言指令而不是第三种交付模式或配置 schema。例如维护者可以说把这个留在特性分支上迭代到我满意为止。该保持独立适用于串行或并行工作覆盖其正常的 PR 时机但不改变实现或评审标准。保持生效期间把连贯的工作保留在一条基于dev的命名分支上由一个集成者负责该分支并行协作者使用临时分支或 worktree以提交交接而非抢占推送把验证过的增量提交并推送到特性分支但暂不向dev开 PR 或合并在规范的plans/topic.md如 PLANS.md 所述的规划文件中用普通文字保持多会话范围与验收进展的最新状态在增加范围前继续检查已知 CI 或集成失败并周期性地并入当前dev但不重写共享分支历史持续保持直到维护者明确说可以开 PR或明确废弃该分支。当维护者接受分支时先与当前dev调和对累积 diff 运行完整的按比例验证然后开常规 PR 到dev。继续干活、一次交互式跟进或一次成功的本地增量都不意味着保持自动结束。被保持的分支也不是预览或发布车道dev与master保留它们原有的集成与晋升所有权。串行 / 交互模式Serial / interactive当用户正在主动请求、评审并引导具体工作时这是默认模式从当前dev开分支工作中解释关键设计取舍实现并运行按比例验证发布下一个增量之前检查上一个串行 PR 的检查结果及其合并后的dev运行已完成的失败必须先修复再叠加工作仍待定的运行记录在案即可不必等待开 PR 到dev确认预期的 base 与 head然后立即合并——除非用户要求评审暂停、声明特性分支迭代保持或此前 CI 已有已知失败删除已合并的特性分支回到更新后的dev。关键认知PR 是把完成增量持久集成进dev并记录其 diff 的载体不是同步的 CI 或审批暂停。在此模式下远端 CI 是滞后一个增量的反馈——它在合并后继续运行必须在下一个串行发布前被检查。自主 / 主题贡献模式Autonomous / topic contribution该模式只在出现/goal或明确要求自主发现并贡献改进时激活。GitHub 的 PR 列表是面向社区的产品表面不要把内部 Agent 任务拆解镜像成每个发现一个 PR。自主工作应汇集成一个评审者能理解为一个产品结果的一致主题用一句话定义主题记录其验收边界与非目标从最新dev在一条主题分支上开始在第一个验证过的增量之后打开Draft PR除非特性分支迭代保持把 PR 推迟到维护者接受保持一个集成者负责该分支并行协作者使用临时分支/worktree 交接提交而不是竞相推送主题分支把相关改进做成原子化、可独立理解、可回滚的提交保持 Draft PR 正文与已包含增量、验证、开放风险、剩余主题工作同步默认在开始下一个社区面向的主题之前先完成、冻结并提交当前主题供验收在维护者明确接受该主题之前不得合并。PR 是主题的验收表面提交仍是调试与评审单元。一个大型 diff 只要服务于一个清晰的验收叙事就不必拆分。只有在工作有真正不同的产品目标、需要独立回滚/安全/发布边界、或维护者明确授权并发主题时才另开 PR。绝不因为某个内部任务或 Agent 结束就创建另一个 PR。后续的交互消息不会追溯授权合并主题 PR。在其最新 CI 待定时可以继续相关增量新推送会取代旧运行但已完成的失败必须先理解并修复再增加范围。主题 PR 标签标签是交付契约的一部分不是事后积压清理。在添加第二个增量之前每个自主主题 PR 必须具备workflow:parallel恰好一个描述变更为何存在的主要theme:*标签至少一个描述谁拥有被变更表面的area:*标签当变更触及交易写入、持久化配置、凭据、破坏性操作、安全边界或大量跨表面结构时必须加review:deep。优先使用一个主要 area。只有主题有意跨越所有者边界时才增加第二个不要为偶然的文件触及累积 area 标签。受控 theme 标签标签用途theme:demoDemo 保真度、fixtures 或模拟交互theme:safety正确性、校验、破坏性操作或交易安全theme:accessibility键盘、辅助技术或交互语义theme:reliability失败恢复、重试、加载或韧性theme:localization界面本地化或翻译的产品文案受控 area 为area:app-shell、area:collaboration、area:demo、area:devtools、area:market-data、area:onboarding、area:settings、area:trading、area:workspace。如果反复没有合适的 area应有意添加一个并在同一治理变更中更新本指南。标签是对 PR 正文的补充不能替代问题证据、验证记录或明确的残余风险说明。review:deep只标识评审深度永远不算批准。返回dev前应在 GitHub 上核实标签确实存在。常规 PR 流程Routine PR Flowgit switch dev git pull --ff-only origin dev git switch -c type/short-description # 实现并验证 git add intentional-files git commit -m terse outcome git push -u origin HEAD gh pr create --base dev --head $(git branch --show-current) # 串行模式确认 PR base/head 后不等待待定 CI。 gh pr merge number --merge --delete-branchPR 正文应包含## Summary - what changed and why ## Included increments - [ ] atomic outcome represented by one or more named commits ## Verification - exact automated and manual checks run ## Boundary touch - trading, auth, credentials, migrations, runtime, packaging, or none ## Non-goals - adjacent work intentionally left out增量清单与非目标是自主主题 PR 的必填项小型串行 PR 可选。分支增长时请同步更新清单不要让评审者仅凭提交标题去重构主题。不要附加 Agent 厂商广告或自动 co-author 尾注。对人提供的报告、设计或评审的致谢应通过 CONTRIBUTORS.md 与指向塑造该工作的 issue/PR 的链接完成。本地反馈阶梯Local Feedback Ladder常规开发从能证伪变更的最小门禁开始默认不购买整个 monorepo 的完整测试套件变更形态本地门禁单一 owner 内的叶子变更pnpm test:changed或显式test:select交集、所属 owner 的 typecheck、真实受影响的表面单一 owner 内的共享变更匹配的pnpm test:owner:*套件或包本地测试、所属 owner 的 typecheck、真实受影响的表面跨 owner、共享测试/构建基础设施、依赖/配置变更、或影响不确定根与适用的包/UI typecheck、完整pnpm test、每个触及表面的验收pnpm test:changed使用 Vitest 的变更文件依赖选择针对新拉取的origin/dev同时包含已提交与工作区变更。它是常规特性分支反馈工具不是发布门禁。静态导入可被发现动态导入、生成契约、注册表、隐式运行时耦合以及零测试选择都需要显式的 owner/area/package/path 选择或升级。包清单、Vitest/Vite 配置、别名或测试 harness 的变更必须运行完整套件因为它们可能改变每个 owner 的收集行为。typecheck 必须覆盖变更的代码根npx tsc --noEmit覆盖src/UI 使用cd ui npx tsc -bWorkspace 包使用各自的 typecheck 命令。一条没包含变更代码的绿色命令不算证据。UI 与运行时行为仍需要真实的浏览器、启动器、包或原生表面——变更测试选择不能替代该验收。在 PR 中记录确切命令与真实表面结果。当一个 owner 的影响面比静态依赖闭包更宽时使用匹配的pnpm test:owner:*套件。pnpm test作为第三行以及手动派发/stable 车道的显式封闭式完整套件后备。完整命令目录、包本地契约、选择器组合与副作用规则见 docs/testing.md。从实现上看这套命令目录与选择器由 scripts/run-tests.mjs 与 scripts/test-lanes.mjs 承载run-tests.mjs解析--lane、--owner、--area、--package、--path、--changed等维度见 run-tests.mjs同一维度内 OR、不同维度间 AND默认车道为hermetic零文件结果会失败关闭而非假装通过。各 product owner 套件在根 package.json 中映射为pnpm test:owner:*别名alice、ui、uta、connector、runtime-cli、desktop、repo-tooling系统级命令test:system:installer、test:system:remote等永不进入pnpm test。CI 反馈车道CI Feedback LanesPull-request CI 与滚动的 dev CLI 发布分别提供变更级与合并后集成反馈。它们的阻塞权限取决于交付车道**常规集成 PRbase 非master**只跑一条干净的 Ubuntu 车道workflow 契约、根 typecheck、完整 workspace 构建。稳定的build-and-test检查名通过要求构建成功并有意跳过完整测试车道保持绿色。PR 必须记录来自上文阶梯的适用 owner 级测试、typecheck、浏览器、Electron、remote、installer 或原生运行时证据——托管 CI 不是同一置信度的二次购买。目标是master的 PR自动运行受信任的 source-contract/typecheck 门禁与原生 Windows dev-stack smoke。封闭式 Ubuntu 套件、完整 workspace 构建与 macOS build-and-test 复跑只在维护者显式派发 Full Source Validation或启动 stable Release它调用同一完整工作流时运行。Windows 桌面与 Broker Pack 打包留在单独的 package 工作流中。本地开发负责 macOS/Linux 的变更测试选择托管 runner 是刻意的原生主机或发布候选工具不是每个本地检查的二次购买。精确 beta 版本专用 PR 的快速车道当master目标 PR 的完整 diff 恰好是根package.json与packages/cli/package.json中同步的、向前的 betaversion值时它走发布准备快速车道保留受信任分类器、workflow 契约、根 typecheck 与稳定聚合检查名跳过 source build/完整测试车道与 CLI 安装器、Broker Pack、桌面/跨平台 PR 矩阵因为没有任何运行时实现变化。随后 beta Release 工作流从确切masterSHA重建并验收每个最终带版本候选。分类器从受信任的 base 提交读取并失败关闭stable 版本、多余字节或路径、不匹配、非法版本与分类器错误都会保留常规 master PR 门禁。同一 PR 的被取代运行会被取消只有最新 head 的结果是可行动证据。中央 CI 聚合为精确 beta 版本 PR 持有 workflow 契约与根 typecheckDesktop Package Smoke 只保留其受信任分类器然后跳过昂贵的宿主包矩阵与 Windows Broker Pack 车道。这些包车道预留给master目标的实现 PR 与手动验证常规集成使用匹配的本地未签名包 smoke。串行模式下devPR 可在按比例本地验证后合并远端检查仍在待定。发布下一个串行 PR 前检查该 PR 的检查与随之产生的devpush 运行。已完成的产品或契约失败会阻塞进一步叠加直到被理解并修复待定状态本身不阻塞。托管 runner 的资源失败不会被重复转换成产品风险抓取日志在本地或最小原生车道上复现受影响的契约然后修复或移除有噪声的常规检查而不是盲目重试整个矩阵。自主主题 PR 保持打开等待接受。待定运行不阻塞相关提交但只有最新 head 是证据已完成的失败在修复前阻塞更多范围。CI 从不授予合并权限。推送到dev是仅限 CLI 的滚动发布车道不运行通用 CI 工作流、不构建 Electron、不构建 Docker。六个原生 CLI 候选由一份共享服务端输入组装macOS/Linux 候选在激活一个原子 dev manifest 前运行打包的 Guardian/Alice、Web、Workspace、PTY 与发布所属 Git 验收Windows x64/ARM64 在 Linux 上交叉构建其原生 runner 验收是手动或 stable 专属的因此 Windows 队列不是 dev/beta 发布依赖。原生排练native rehearsal先保留构件可在安装器/夹具修复后重放验收。更重的 UTA/Connector 恢复与外部 Broker Pack 夹具在 Linux x64 上运行一次手动 Full Source Validation 与最终 Release 车道保留更宽的原生宿主覆盖。安装器或分布式 CLI 工作在本地用确定性的干净容器 HTTP 安装证明检出树。常规devPR 不购买该夹具的第二个托管副本。合并后devpush 构建每个原生候选将raw/.../dev/install下载到干净宿主以--channel dev安装并验证实时预览通道的 provenance、命令、服务器控制面与幂等复用。托管 checkout、Bun 宿主、包管理器与托管 SSH 候选验收从master/手动边界开始。beta 晋升使用记录的本地验收、自动 source 门禁、Windows dev-stack smoke 与最终 Release 工作流的构件验收它不等待重复的托管 macOS/Linux 完整套件。stable 候选在候选构建的同时对其精确派发提交运行 Full Source Validation。最终发布要求完整工作流成功无需单独的串行派发。真实产品失败仍会停止或撤回候选托管 runner 饥饿与已知的非产品夹具超时不会通过重复变成产品风险。常规集成没有托管变更路径白名单。串行开发使用上述本地阶梯仅在这些表面变化时补充pnpm test:system:remote、真实浏览器、OrbStack、安装器、未签名 Electron/包与原生运行时验收。远端验收从用户已通过普通 SSH 可达的宿主开始CI 与仓库脚本不配置或管理云供应商。在 PR 中记录命令与结果。stable Release 在构建构件的同时重新建立完整 source 矩阵即使常规集成与 beta 使用了更轻的托管反馈。这些车道约束不是纸面声明而是由测试强制执行的契约scripts/ci-workflow.spec.ts 断言devPR 只触发 Dev PR Clean Build单 jobpnpm install --frozen-lockfile、pnpm test:contract:workflow、pnpm build不含npx tsc --noEmit与pnpm test15 分钟超时断言 Full Source Validation 只对masterPR 与workflow_dispatch触发、其重 job 必须显式手动门禁并断言 beta 分类器从BASE_SHA读取见 ci-workflow.spec.ts。分类器本身由 scripts/classify-beta-release-prep.mjs 实现它要求变更恰好是两份清单的M修改且版本是向前的新 betavX.Y.Z-beta或vX.Y.Z-beta.N不匹配即失败关闭。对应工作流文件为 .github/workflows/ci.yml 与根 package.json 中pnpm test:contract:workflow所指的契约。包签名边界Package signing boundary打包证据与发布签名证据是两个不同的门禁常规本地工作与 PR 包 smoke 以CSC_IDENTITY_AUTO_DISCOVERYfalse构建解包/未签名构件。它们验证资源布局、Guardian 启动、托管运行时、Workspace CLI 验收与平台特定行为不触碰签名身份或公证服务。签名/公证构建只在以下情况运行带版本发布候选、显式发布排练、或直接涉及签名、公证、自动更新元数据、发布发布的变更。开发 Agent不得仅仅因为 Electron 或打包代码变更就运行签名包。应将签名报告为发布专属残余风险并使用与受影响表面匹配的未签名包 smoke。临时展开的 app 是一次性测试构件。优先使用 smoke runner 的隔离自动清理路径仅当调查或真人测试者确实需要时才保留一个。这条边界把昂贵、带凭据、外部限速的发布工作移出交互式开发循环同时保留相同的运行时与资源布局覆盖。CI/CD 优化次序CI/CD optimization order优化可测量的等待时间但不要压垮置信车道常规集成保持一条干净的构建/类型/契约车道表面专属验收放在开发机上避免在devpush只拥有发布上重复 PR 验收精确 beta 准备只做受信任的版本/契约/类型检查让 Release 一次性验收最终构件取消被取代的工作并在剩余 job 间缓存依赖、构建与安全的未签名包输入在购买更大的 runner 前先测量队列时间对安装/构建/测试时间保持完整 stable 候选验收、签名与发布被门禁beta 晋升可使用记录的本地验收加轻量自动 master 门禁。任何 CI 优化 PR 都应包含前后计时证据并指名其保留、移动或移除的置信门禁。合并与清理Merge and Cleanup正常合并方式是merge commitgh pr merge number --merge --delete-branch仅当维护者要求、或分支含噪声/可丢弃历史时才用 squash。无论何种方式确认mergedAt已针对期望的 head SHA 设置确认远端特性分支已删除切到dev并运行git pull --ff-only origin dev合并被证实后再删除本地特性分支后续工作从新分支开始绝不从已合并分支。关闭未合并的分支不会因为很旧就安全删除保留它直到维护者接受有意废弃。遗留local分支local早于当前的特性分支/PR 工作流。默认不要把新工作路由经过它也不要直接用它作为 PR head。退役前与dev对比把独有提交映射到已合并/打开/关闭的 PR并询问维护者任何未合并工作。如果多个 Agent 确实共享一个 checkout分支切换必须串行化。永久分支变通方案不能替代显式的 worktree 所有权。晋升dev到master晋升是人指导的发布源决策不是发布触发器。不要仅仅为了让公开别名赶上而把未完成的后续工作合并到master先在活跃的dev环境中完成并测试它。git fetch origin git log --oneline origin/master..origin/dev git diff --stat origin/master..origin/dev gh pr create --base master --head dev --title Promote dev to master合并晋升前针对完整晋升 delta 运行常规 build/test 门禁添加包含工作所需的 entry-path、trading、runtime 或 package smoke遵循 CLI 安装器指南要求 checkout 安装器/远程 job 与合并后的 live dev-channel job 绿色并在人机交互流程变化时本地走一遍交互式安装器确认 CI 与发布工作流触发器仍匹配分支策略。晋升后维护者可在源码就绪时从master准备一个聚焦的仅版本分支并把其 PR 目标指回master。这个维护者主导的发布准备 PR 是常规 base 为dev的狭窄例外。把这份仅发布提交留在master直到发布与其公开表面被接受然后只通过一个聚焦的dev目标 PR 把同步的根与 CLIversion值复制回dev不要合并无关master变更也不要把记账变成第二条实现车道。源码运行时身份与该值无关OPENALICE_LAUNCHERdev与electron-dev选择dev通道而package.json提供显示/构建基线。从master手动运行Release工作流选择release操作并同时提供通道与 tagbeta接受vX.Y.Z-beta或vX.Y.Z-beta.Nstable只接受vX.Y.Z。工作流拒绝已存在 tag、通道/tag 不匹配、或与根或packages/cli包不一致的版本。它把被接受的候选与最终 tag 绑定到派发提交 SHA。精确向前 beta 的仅版本 PR 使用上文的有界 CI 快速车道。stable 版本准备刻意不使用它保留常规 master PR 门禁。stable Release 从同一提交并行调用完整 source-validation 工作流与构件构建发布同时等待两者。masterpush 不会触发 full-source 工作流启动 stable 候选前也无需单独派发该套件。手动派发的 beta Release 从确切派发 SHA 重建并验收自己的最终候选快速车道从不提供发布构件。beta 与 stable 是串行公开检查点不是一次发布运行的一对输出。beta 之后修复可继续在dev上进行通过常规晋升门禁然后作为另一个可选编号 beta 或直接作为 stable 发布。只有 beta 源码无需任何改动时后续 stable 意图才可使用该确切源码。即便如此stable 仍是独立的人为版本决策与工作流派发绝不因为某个候选构建通过就同时创建 beta 与 stable。发布工作流在创建 tag 与 GitHub Release 之前会针对确切 master 候选重复确定性安装器与托管远端验收。上一发布与 notes 基线来自同一通道因此 stable 之后发 stable 仍证明上一 stable 到新 stable的旅程。两个通道都发布不可变的带版本字节包括在 tag/Release 存在前冻结的安装器快照。新 beta 发布只能替换beta*.yml、beta/manifest.json与共享通道中立install只有 stable可以替换latest*.yml、manifest.json、公开桌面别名与已选入的包管理器元数据。手动mirror操作是仅恢复用途它运行当前master工具链要求所选通道上已存在且活跃的 tag消费发布所属的安装器快照永不重写共享安装器或覆盖不可变安装器字节。因此 mirror 修复只适用于由该通道感知工作流创建的发布其 GitHub Release 同时拥有安装器快照与 checksum 边车旧发布在此修复契约之外。桌面晋升证据包括 Apple Silicon、Intel macOS 与 Windows 上的真实 N-1 状态旅程。PR 包 job 用上一发布 app 播种状态验证解包候选能迁移、写入并重启。版本发布在每次快速包验收与 updater 字节验证通过时即保留最终签名 macOS ZIP 或 Windows NSIS 安装器然后在下游平台 job 运行 N-1 旅程——因此失败的升级 job 可复用保留候选而无需重复打包、签名或公证。publish-release仍要求每个平台的升级回执并在发布前验证每个 updater YAML 引用、大小、SHA-512 与 blockmap。缺失回执或不匹配的更新元数据必须阻止 tag 与公开资产被创建。发布桌面矩阵为每个原生宿主调用一个可复用平台流水线。每个流水线的升级 job 只依赖自己的构建 job不等待其他桌面架构。调用方的聚合成功包含 stable 升级结果因此发布仍要求每个原生平台。构建与升级保持分离 job 以支持选择性重试。beta 运行当前候选检查不含 stable 专属 N-1 job。要不重建地重试已保留的 stable 桌面候选Release操作的verify-desktop接收candidate-run、source-sha、tag、previous-tag与一个desktop-targetmacOS-arm64、macOS-x64或Windows-x64channelstable。派发版本拥有验证器显式 source SHA 拥有产品。选择要求本仓库已完成的 master Release 与唯一未过期构件。它随后验证确切字节、运行安装后 N-1 旅程并上传绑定两个身份的回执。不打包、签名、打 tag 或发布。缺少candidate-manifest.json的历史构件无法使用该路径。在此实现阶段重试回执仅是诊断证据最终发布尚不接受来自不同运行的回执。对非发布流水线验证rehearse-desktop在派发分支上构建未签名桌面候选并运行相同的 stable N-1 检查。把candidate-run传给同一 source 的第二次排练会恢复这些字节而非重建。verify-desktop-rehearsal用上述单目标重放输入以当前分支的验证器检查旧排练候选。这些操作只有只读仓库权限无签名凭据其rehearsal-assets-*构件刻意区别于生产候选正常发布选择会拒绝它们。对同一确切 source 提交的新operationrelease尝试设置candidate-run会复用该运行保留的三个桌面构件而非再次打包/签名。选择与确切字节验证先于上传进当前运行stable N-1 验收再次运行正常最终发布门禁检查其新回执。所有非桌面门禁保持完整。不同产品 SHA 或缺失/过期候选失败关闭该路径不接受仅验证器代码变更作为等价产品 source。正常全新构建省略candidate-run。这与上述诊断性单平台verify-desktop操作分离。可选desktop-verifier-sha选择已整合进origin/dev或origin/master的完整提交用于桌面升级验证。发布意图在构建前验证该权限。只有升级 job checkout 所选验证器产品构建、source 验证、候选 source 身份与最终 tag 保持在原始派发 SHA 上。显式产品版本传给 smoke而非从验证器包清单推断。验收绑定所选验证器 SHA发布要求同一身份。这允许验证器修复检查保留的产品字节而不把修复提交当作新构建。CLI 候选共享一份提交绑定的平台中立输入构件只含已批准的 UI 与纯 JavaScript 包输出。六个目标 job 在安装这些输入前验证其 source SHA 与确切文件哈希。原生依赖、可执行编译与通道专属验收保持在目标现有宿主车道上。绝不用中立构件替代被接受的原生归档。晋升后不要删除dev。master 热修复后立即把修复传播回dev以免后续晋升回滚它。紧急热修复Emergency Hotfixes仅当 stable 用户当前已损坏或不安全、且等待正常dev晋升会更糟时才使用master目标热修复git switch master git pull --ff-only origin master git switch -c hotfix/short-description保持变更最小运行聚焦检查加相关 smoke 覆盖开 PR 到master给予补丁发布版本然后把结果 fix 合并或 cherry-pick 回dev。紧急路径可以更小但它仍是发布不得静默改变已存在的带版本构件。外部 Pull RequestsExternal Pull Requests外部 PR 有资格直接评审与合并。CONTRIBUTING.md 是贡献质量与证据的公开政策所有者。外部作者身份不降低产品、验证或安全门槛但它本身也不是在维护者自有分支上重实现已接受工作的理由。被要求评审外部 PR 时先读元数据不把 diff 渲染进主受信任 Agent 会话也不 checkoutgh pr view number --json headRepositoryOwner,author,headRefName,isCrossRepository,title若 head 仓库属于TraderAlice按常规评审预防措施进行。若是跨仓库或外部拥有从只读 diff 与依赖审计开始。不要在主线工作区 fetch、安装、运行或 checkout。任何执行必须在隔离的一次性沙箱中进行且沙箱不含用户数据、凭据或受信任构建输出。把代码、依赖变更、postinstall 脚本、fixtures、文档、issue 文本与提交消息都视为不可信输入。不仅评审补丁还要评审产品推理与证据UI/UX 工作需要前后视觉与显式设计理由bug 修复需要复现与解决两方面的证据。允许 AI 辅助但贡献者必须拥有理由、取舍、评审与验证。方向被接受时优先要求原作者修改并通过合并保留其提交与所有权。仅在贡献者明确交接、失联或集成边界发生实质性变化时才把工作转移到维护者自有分支。在合并前应用与受影响风险表面匹配的同步门禁。即使贡献者已被信任安全敏感与交易变更也需要更深评审。包含漏洞细节的安全报告应使用私下披露而不是公开 issue。Issues 与延迟发现Issues and Deferred Findings对具体的延迟工程发现使用 GitHub issues。不要创建仓库 TODO 文件也不要把新工作路由到 Linear。内容包括症状、复现/证据、疑似子系统、延迟原因与交叉引用。当前 PR 已要完成的工作不要再开 issue。产品路线图想法保留在维护者的规划表面直到被有意提升为工程工作。文档变更Documentation ChangesOwner Guide 承载持久的子系统真相AGENTS.md是索引与紧凑规则集。架构或操作变化时在同一 PR 中更新 Owner Guide 及其入口。README.md 是公开定位。大型产品变更后识别过时章节但修改 tagline、pillars、hero 或其他营销语言前先征求维护者的 framing 意见。保持AGENTS.md与CONTRIBUTING.md与本指南以及.github/workflows/分支触发器一致。风险门禁Risk Gates对dev的串行 PR合并前满足本地可运行、表面专属的门禁并报告仅平台存在的残余风险。远端平台证据可在反馈规则下滞后于该合并。在晋升到master或 stable 发布前每个适用的完整门禁必须完成且绿色。精确 beta 要求有界的版本准备门禁、其产品树先前已接受的晋升证据、以及完全绿色的最终 Release 构件工作流它不重开开发 source-test 矩阵。边界要求证据入口路径、启动、onboarding、auth隔离的首次运行验证对广泛行为变更保留恢复/终止路径交易、券商写入、UTA 权限docs/uta-live-testing.md 中的相关 demo/paper 场景保持账户平坦持久化数据先确立旧形态是否已发布已发布 → 幂等迁移 spec 重新生成索引 备份行为未发布 → 直接替换 隔离状态验证桌面、Guardian、PTY、IPC、托管运行时受影响平台上的匹配 dev/Electron/package smokeUI/API 契约严格 UI 类型、真实浏览器路由、匹配 demo handlerCLI 引导安装器遵循 CLI 安装器指南发布前对真实下载路径运行本地pnpm test:system:installer公开贡献者/发布工作流交叉核对AGENTS.md、CONTRIBUTING.md与 GitHub Actions 触发器如果某个必需门禁无法运行请在 PR 中记录确切的残余风险绝不用无关的绿色测试代替。这也是贯穿全部车道的总原则托管 CI 不购买第二次相同置信度测试选择不能替代真实表面验收绿色命令若未包含变更代码就不算证据。与分支车道、交付模式、发布治理一起它构成了 OpenAlice 从一条提交到一个 stable Release的完整可信路径。与之配套的还有一条历史教训v0.85 曾因桌面升级后旧 Broker Pack 激活失败而确立了 N-1→N 发布门禁记录在 docs/incidents/2026-07-28-broker-pack-upgrade-gap.md——这正是风险门禁表中桌面 N-1 状态旅程的现实来源。赞分享【免费下载链接】OpenAliceYour one-person Wall Street. An AI trading agent covering equities, crypto, commodities, forex, and macro — from research through position entry, ongoing management, to exit.项目地址https://gitcode.com/gh_mirrors/op/OpenAlice点击查看免费下载相关推荐opencodex 跨平台 CI 与发布门禁Linux/Windows 双平台质量门 仅发布 CI 通过提交的 Release 工作流opencodex 跨平台 CI 与发布门禁Linux/Windows 双平台质量门 仅发布 CI 通过提交的 Release 工作流 opencodexReth 协作工作流全解分支模型、发布流程与 CI 检查流水线Reth 协作工作流全解分支模型、发布流程与 CI 检查流水线 本文基于 reth 仓库的 docs/workflow.md https://link.git区块链OBLITERATUS 贡献指南风险驱动质量门禁、签名提交与发布认证的完整工程实践OBLITERATUS 贡献指南风险驱动质量门禁、签名提交与发布认证的完整工程实践 OBLITERATUS 是一个研究型工具它会 突变模型权重 、评估行为、人工智能模型安全模型评测上一篇Dramatiq开源项目教程下一篇如何优化japanese-reranker-cross-encoder-small-v1性能调优与最佳实践创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考