pstack 的 shipping playbook为什么 CI 绿色不等于安全新手也能看懂的验证栈落地指南【免费下载链接】pstack-claudeClaude Code, Codex, Copilot, Pi, OpenCode, Gemini, and Prime Agent versions of Potetos pstack. Rigorous agent workflows with Cursor primitives translated for other harnesses.项目地址: https://gitcode.com/GitHub_Trending/ps/pstack-claudepstack shipping playbook 是什么pstack是 Poteto 的一套 AI Agent 工作流技能栈本文以 pstack-claude 移植版为例它为 Claude Code、Codex 等编码智能体提供严格的做事规范。其中shipping playbook发运手册是poteto-mode下最讲究的一套流程当一个 PR 栈全部变绿之后如何安全地把代码真正合入主干。核心结论一句话先说绿色不等于安全——CI 通过、机器人点赞都不代表这个版本真的可以落地。下面带你拆解 pstack 的验证栈思路。为什么绿色检查不是发运安全门槛很多团队的发运流程是这样的CI 全绿 → 机器人 approve → 点击 merge。pstack 认为这里有四个经典陷阱陷阱说明 旧版本的绿绿色检查跑在旧的 head 上代码之后又改了绿的是上一个版本 机器人不是法官审批机器人和 Bugbot 会指出真问题也会报噪音approve 不等于验证⚡ 竞态窗口从看状态到点合并之间分支可能被 rebase、可能被并发修改⏰ 自动合并不受控--auto或 merge queue 在入队时的检查证明不了未来某个版本已通过验证pstack 在 SKILL.md 中把这条写成了不可妥协的规则Green is not safe. Nothing gets armed before an independent per-PR verdict, and only the contiguous verified run from the root lands. 绿色不安全。在拿到每个 PR 的独立裁决之前什么自动合成都不能挂上只有从根开始连续验证过的运行区间才能落地。验证栈的五个核心概念1️⃣ 独立裁决写代码的人不能给自己验货shipping.md 第 2 步要求每个 PR 派一个独立的子智能体在自己的 worktree 里用真实的产品界面驱动技能实际跑一遍功能然后给出三种裁决之一PASS—— 通过PASSNOTES—— 通过但有备注FAIL—— 不通过裁决会连同一组指纹一起记录head SHA、base SHA、base 分支、以及 base 到 head 差异的git patch-id。这样即使之后重写历史也能判断旧裁决是否还适用。2️⃣ 连续验证区间断一截全停验证要连片。从最底层未合并的 PR 开始往上走遇到第一个没有 PASS 的 PR 就停下那个位置叫天花板ceiling。上面有验证过的子 PR、下面有没验证的父 PR子 PR 不能合。因为子 PR 的正确性依赖父 PR 的代码父级没验过子级的一切都是空中楼阁。3️⃣ 先取消再改写防止半路截胡改写分支rebase、force-push、改 base之前必须先取消所有挂起的自动合并请求和队列成员身份。pstack 用ship-pr inspect和ship-pr cancel-pending这对标准操作见 merge-safety.md并且必须读到明确的cancelled结果才动手。取消失败、状态不可用、或者取消过程中有人恰好合了——先停下来核对真实状态绝不硬推。4️⃣ 带头条件的合并消灭最后一秒竞态真正执行合并时pstack 要求用服务端的头条件约束例如 GitHub 的gh pr merge pr --squash --match-head-commit 验证过的 head SHA意思是如果 head 已经不是我验证过的那个 SHA合并直接失败。这堵住了读完状态到点合并之间分支又变了的竞态窗口。需要注意的是merge-safety.md 诚实地指出这个头条件不原子地保护 base 分支并发改 base 的情况要靠流程协调不能假装原子。5️⃣ 落地确认COMPLETE 只是提示不是证据合并成功之后还不能直接推进。pstack 要求读回 PR 的 MERGED 状态、最终 head、目标 base 和 merge commit拉取目标分支用git merge-base --is-ancestor确认 merge commit 真的在目标分支历史里再检查合并后的实际内容。任何一项与验证记录对不上整条链立即停。如何落地Babysit 管前半程Shipping 管后半程pstack 把 PR 的生命周期切成两半边界非常清晰PR 建好 ──▶ [Babysit 值班] ──▶ merge-ready ──▶ [Shipping 发运] ──▶ 确认落地 修冲突/评论/CI 独立验证 带条件合并 不碰合并动作 不挂自动合并 逐层推进前半程babysit.md 负责把 PR 驱动到 merge-ready。规则是只盯最底层未合并的那个 PR、冲突要上报而不由值班者代改、值班循环永远没有合并权限——用户明确说要合才路由给 Shipping。后半程shipping 的 11 步解析 forge → 逐 PR 独立验证 → 找连续验证区间 → 取消挂起合并 → 只准备最底层 PR → 复核证据 → 带条件合并 → 用持久化门禁武装自动合并 → watcher 守前沿 → 确认落地 → 停在天花板。自动合并--auto、merge queue只有在仓库规则层面强制了将要落地的版本必须携带独立裁决 必需 CI时才能启用——检查挂在入队那一刻是不够的因为版本之后会变。没有这种持久化门禁就保持人工守护式合并。配套工具链watch-pr 与 ship-prpstack 把这套流程做成了可执行的工具而不是口头约定watch-prPR 状态监视器位于 watch-pr/cli.ts。它轮询单个 PR、关联栈或不可变队列栈输出结构化裁决READY/WAITING/BLOCKER/ADVANCE/COMPLETE并负责 blocker 分类冲突交给拓扑负责人评论和 CI 交给 PR 负责人人工审批节点则进入等待。ship-pr合并安全操作器落地记录解析逻辑见 shipping.ts。它统一了落地修订LandingRevision仓库 PR 号 head OID base 分支 base OID这个数据结构watcher 和它共享同一份记录保证取消和观察看到的是同一个版本。验证的真来自项目本地的驱动技能用 /create-verification-skill 为你的仓库生成一个verify技能它记录如何启动真实应用、像用户一样操作、并留存证据截图、终端记录、副作用检查。shipping 的独立验证子代理就靠它跑真实表面而不是看测试编译。给新手的三条实践建议给裁决绑定指纹。任何验证通过都记录 head SHA base patch-id改写历史后能用 patch-id 判断审查是否还有效而不是凭感觉。把机器人评论当不可信数据。pstack 的 bugbot-triage.md 给出了三分类fix/dismiss/ask——跳过一条噪音评论很便宜跳过一条真实的数据或安全 bug 很贵拿不准就问人尤其是安全、鉴权、计费、迁移类发现。从确认落地开始练。即使不做完整 11 步合并后养成习惯读回 MERGED 状态 → 确认 merge commit 在目标分支历史里 → 检查合并结果内容。这三步就能拦下大部分以为合了其实没合的事故。延伸阅读资料路径Shipping 完整 11 步plugins/pstack/skills/poteto-mode/playbooks/shipping.md合并与重堆安全plugins/pstack/skills/poteto-mode/references/merge-safety.mdBabysit 值班手册plugins/pstack/skills/poteto-mode/playbooks/babysit.mdpoteto-mode 入口与原则plugins/pstack/skills/poteto-mode/SKILL.mdwatch-pr 命令实现plugins/pstack/skills/poteto-mode/scripts/watch-pr/技能与命令参考docs/reference.md安装与快速上手README.md 一句话总结pstack 的 shipping playbook 把发运从一次点击变成一条可审计的证据链——独立裁决、连续区间、带条件合并、落地确认每一环都有回滚和停下的理由。绿色只是起点验证栈才是终点。【免费下载链接】pstack-claudeClaude Code, Codex, Copilot, Pi, OpenCode, Gemini, and Prime Agent versions of Potetos pstack. Rigorous agent workflows with Cursor primitives translated for other harnesses.项目地址: https://gitcode.com/GitHub_Trending/ps/pstack-claude创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考