网站发布总闸

方向

Yummy Future 的"发布/上线"不是一个人的事：Jack 这一侧（由 Claude 经手）走四条路——临时页发到 Cloudflare、给同事的活服务开隧道、官网 yummy-future.com 上生产、门店集群拉新版本； **Hao 和 Rohan 两人还共同运维着整块门店基础设施**（五条门店隧道、店内应用、设备远程升级、 GCP 服务器、订单/收款接口），那是公司真正收钱跑店的面，此前完全不在任何技能的地图上—— 08-29 门禁事故正是 Claude 未经他们俩点头动了这块面。 这份 PRD 把 cloudflare-publish 扩建成发布总闸：Claude 侧四条车道由它机械分流并核对门禁； Hao + Rohan 的面画进同一张图、立死"写动作必须他们点头"的规矩——总闸不指挥他们怎么干活， 只保证任何会话看一张图就知道每块面归谁、动之前要过谁。不新建技能，只扩建这一个。

deployment 这个域目前只有这一份主 PRD，还没有子 PRD——地图留空，等真的拆出子 PRD 时由脚本生成。

建什么

输入：一句"把 X 发布出去"的请求（一张临时页 / 一个活服务 / 官网 / 门店集群）。
输出：

• 扩建后的 skills/cloudflare-publish/SKILL.md，里面写清楚四条车道各自的入口命令、跑在哪个引擎上、必须过哪几道门；
• 它和四个邻居技能（remote-server-ops、share-and-feedback、wefunder-campaign-deploy、combine-web-pages）的描述里，双方都点名了彼此的边界；
• 重新扫描技能库后，发布这个领域没有任何未声明的重叠；
• 两道打包硬门都过、.skill 重新打包出货。

什么算好：任何人拿着这份 SKILL.md，不用问人就能判断"我这次发布该敲哪条命令、会被哪几道门拦下来"—— 官网上生产不会再有人手滑敲裸命令。

四条车道（分流图）

三道闸各是什么（建的人照这里找，不用猜）： cf_write_gate = 全局钩子 ~/.claude/hooks/cf_write_gate.py（不在本仓库里），拦 Cloudflare 生产写命令，放行手续写在它的拦截消息里； 访问名单双签 = 任何"谁能访问什么"的名单/门禁变更，先把完整名单摆出来， Jack 和 hao@yummyfuture.wiki 两人都点头才许执行，变更后两头验收（该拦的拦住、该进的能进）， 正本定义在 ~/.claude/yf-production-assets.md 死规矩第 1 条； ui-test-gate = 同名技能的三道锁（用例签字→自动化跑绿→真浏览器过一遍）。

焦点读：眼睛先落在这五个盒子上，认出要动的东西属于哪一块——前四条照那格的入口命令做， 第五块先去找 Hao/Rohan；卡在哪道门被拦下来，就是本该被拦下来，不是绕过去的理由。

功能 → 检查

每一条的可跑命令和期望输出都在附录页 deployment-PRD-appendix.html。

不碰

• 这份 PRD 不执行合并本身——批准后才是下一张活。
• 不动 wefunder-campaign-deploy 和 remote-server-ops 各自内部怎么干活，只声明两者跟这扇门的边界。
• 不指挥 Hao + Rohan 的门店基础设施面内部怎么部署——他们的流程归他们，本闸只把这块面画进图、立"动之前先过他们"的规矩。
• 不改任何 Cloudflare 生产配置，也不改 deploy-netlify.sh 本身。
• 不建新技能，也不给 cloudflare-publish 改名。