WebShip · topic-deploy

让 topic-deploy 成为 /topic 专属入口

这不是一句命名建议，而是一条路由纪律：/topic 负责生成与部署；/status、/links 和裸 topic/token 只做状态查询，不再混流。

入口单一查询与生成分离失败必须给证据群里真实消息必须有回复

目标状态

/topic：唯一生成/部署入口。
/status / /links：统一走“先查状态再回答”。
裸 topic/token：视为状态查询触发词，而不是生成请求。
为什么失败 / 为什么 404 / 为什么没回：先查最近日志或 reply-meta，再做证据化解释。

执行硬规则

命中 /status、/links、裸 topic/token 时，先提取第一个 kebab-case token 作为 TOPIC。
然后执行：
WEB_SHIP_TOPIC='<TOPIC>' bash scripts/ship-links.sh
如果提取不到 topic，直接回复 FAILED + 原因。
/topic 的回复顺序固定：结果 → 证据 → 下一步。

为什么这样更稳

入口分工清楚后，群里不会再因为“查链接”和“重新部署”混在一起而出现误触发、误解释、误 404。

好处：可预测、可解释、可复盘。

失败处理

失败不是一句口头判断，而是一个带证据的状态结论。优先读取最近 ship log 或 reply-meta，再说明是哪一步没产出。

禁止：无证据猜测失败原因。

群内行为

这里只有系统维护消息才允许静默。真实用户的 deploy/status 消息，一律必须给可见回复。

原则：topic-deploy 是执行台，不是沉默观察员。

建议落地文案

/topic        → 生成 / 更新 / 部署
/status TOPIC → 查询这个 topic 当前可打开的链接
/links TOPIC  → 输出这个 topic 的版本页、latest、history
TOPIC token=... → 按状态查询处理，不进入生成链路
为什么失败 / 为什么 404 / 为什么没回
             → 先读最近 ship log / reply-meta，再做证据化解释

结论：把 topic-deploy 收紧为 /topic 专属入口，不是“少一个命令”，而是让生成、查询、解释三条路径各自稳定。