diff --git a/docs/agent-specs/2026-06-21-tier2-agentic-engine-架构设计-review.md b/docs/agent-specs/2026-06-21-tier2-agentic-engine-架构设计-review.md
index ece444fe..1564042a 100644
--- a/docs/agent-specs/2026-06-21-tier2-agentic-engine-架构设计-review.md
+++ b/docs/agent-specs/2026-06-21-tier2-agentic-engine-架构设计-review.md
@@ -35,6 +35,18 @@ tier2 要越过这道天花板,目标品类是合成、经营、挂机、经济
 
 **因此本文据 A 路触发 supersession**:`tech-decisions.md` §1.1 与 `引擎与运行时.md` 需要更新——tier2 全自治生成主线引擎改为 Phaser/Pixi,并把旧的"Cocos+MCP = headless 可行"明确纠正为事实错误(MCP 实为编辑器扩展);Cocos 保留在"渠道/App 离线导出 + 人在环"的边界、不进 tier2 loop。这两处 canonical 的同步,作为本文定稿后的一个独立动作执行。
 
+## 三·补 渠道发布能力:放弃 Cocos 不丢渠道
+
+§3 把 Cocos 留在"渠道导出"这个轴上时,留了一个必须正面回答的疑问:Phaser/Pixi 生成的游戏到底能不能发到微信/抖音/快手小游戏,还是只能留在绘境自己的 web 游戏流?这一条经过硬核实,结论是:**Phaser/Pixi 的渠道发布是一项可建的一等能力,不是墙;放弃 Cocos 没有丢掉渠道发布能力本身。**
+
+理由是几个被检验后大半蒸发的"Cocos 优势"。微信官方明确 weapp-adapter 只是参考实现、不再维护,并钦定"开发者应基于自己选用的引擎实现自己的 adapter"——自研 adapter 是官方正路,Cocos 的"一键"不过是把这件事在引擎内做完了。它一键省掉的三步(adapter 垫片、分包、拉起开发者工具上传)全部是一次性可固化进产线的工程脚手架、不是每款重写;仓内 W-CH-α spike 已经为结构完全相同的 LittleJS 把这条路推到 P0 实证可行(adapter v0 启动起来收到合成触摸、验证门 6/6、还逮到一个真 bug)。更要紧的是几个"看着像 Cocos 优势、其实平权"的点:变现 SDK(广告/支付/排行榜/登录)是 `wx.*` 原生调用、所有引擎都得手动接、Cocos 也不例外;快手没有任何引擎的专用导出、所有引擎都走"微信格式包→快手兼容转换"、完全平权。甚至有一处反而 Phaser 占优——Cocos 的渠道构建需要 Win/Mac 构建机,而纯代码引擎(Phaser/esbuild)全 Linux 可打包,对一条要服务器化、无人化的生成产线这是反向收益,仓内 W-CH-α 已实证全 Linux 出渠道包。
+
+诚实的让步只有一处:国内小游戏生态的成熟度和爆款案例,Cocos 明显领先,Phaser 在国内小游戏圈是"能用但非主流",社区方案偏旧(2018–2023)、踩坑要自己填。但这影响的是"省多少力",不是"能不能发"。
+
+还有一条必须写进来、与引擎无关的真墙:渠道侧禁止动态生成代码(微信/抖音会剥离远程代码、明禁 eval 类 JS 解释器),只允许"包内固定模板代码 + 远程纯数据配置"。所以 tier2 自治生成的富游戏要上渠道,必须从 web feed 的"即时热发任意生成游戏"降级为"精选款固化进壳版本、走平台提审"——这是渠道的本质约束、Cocos 同样撞,不是 Phaser 的劣势,但它定义了 tier2→渠道的产品形态:web feed 拿热发的长尾,渠道拿精选的爆款。
+
+落点:渠道发布不构成保留 Cocos 的理由;真正待补的是把仓内 W-CH-α 的 P1 真机七门用 Phaser 的真包跑完(首屏、广告回调这些只能真机裁),而它当前卡的是创始人的三件套(微信 AppID + Win/Mac + 安卓千元机),是日历闸门、不是技术阻断。
+
 ## 四、产物形态:为什么 tier2 是"真引擎工程",而不是声明式 JSON
 
 现有 Tier0/1 生产线的产物是一份声明式的 `gameDefinition`——轻量 ECS-lite 结构,玩法逻辑塞在窄窄的 `behavior.code` 字符串里、由 `gd-runtime` 解释执行。它对便宜模型友好、已双证能稳产单系统轻游戏,但有一个根本的表达力上限:装不下一款肥鹅级的真富游戏。