把分析结果发布成一个网址，团队就有了实时数据系统吗？
没有。Publish Artifact to Sites 的原文第一件事就把这个边界说清楚：发布的是快照，不会自动添加实时数据源连接。
这条边界决定了后续所有设计：访问权限怎么设、版本怎么管、交接时该说什么。
不是把一段草稿丢上网
发布之前，报告或看板流程应当已经产出完整的规范化结构与受控数据快照，并通过验证。
这个 Skill 负责接住合格产物，组织打包、版本保存、部署和核验。它不负责分析，也不负责判断数字对不对。
因此，发布成功不能替代分析验证。一个错误数字，不会因为有了分享链接就更可信；反过来，一次成功的部署也不能证明数据是最新的。
同一份逻辑产物，复用同一个站点
原文建议：一个逻辑报告或看板对应一个 Site；后续更新发布新版本，而不是每次重新建一个零散网址。
这个约定把两个问题分开了：
- “报告是谁”：稳定的身份，对应固定的地址和访问策略。
- “当前是哪一版”：每次发布产生一个版本，对应一个数据截止时间。
如果不这样分，团队的聊天记录里会散落着十几个链接，没人说得清哪个是最新、哪个还能打开。
更新成功之后仍要核对部署状态。原文的要求是轮询到终态，而不是把“开始发布”当成“已经可访问”。
有链接，不代表访问范围正确
原文要求读取当前访问策略，并严格验证是否只有创建者有权限。
这里有一组容易混淆的权限：
| 权限 | 控制什么 |
|---|---|
| 读者访问 | 谁能打开页面看内容 |
| 演示编辑 | 谁能在页面上修改文字与布局 |
读者权限和编辑权限是两件事。把页面分享给更多读者，不应该顺带给出编辑能力；反过来，给创建者编辑能力，也不应该扩大读者范围。
原文还规定：启用编辑时，指定创建者可以修改文字和布局，或发起刷新、导出交接；这些展示层面的覆盖保留在 Sites，不会反向同步到桌面端。这一点需要在使用前说清楚，否则团队会误以为编辑结果会回写到源文件。
自动发布有条件，不是普遍承诺
原文区分运行模式：
- 在明确识别的工作模式下，且完整的 Sites 生命周期工具可调用时，持久产物按自动路线发布。
- 桌面端非工作模式，则要求明确请求或接受分享建议。
原文也给出了失败处理：如果完整生命周期不可用，或在工作模式下重试一次后仍失败，应自动切换到所属工作流的自包含 HTML 模式，简要说明失败阶段，并且不能声称站点已经发布。如果用户明确只要 Sites，就如实报告阻塞，而不是擅自换交付面。
这是该仓库版本的路由规则，不代表任何具体环境已经具备相应权限，也不表示所有内容都可以自动公开。
最终交接要说明三件事
原文要求在交付时明确：
- 页面在哪里：可访问的地址。
- 数据截至什么时候：快照对应的时间点。
- 它是快照而非实时连接：后续数据变化不会自动反映。
第三点最常被省略，也最容易造成误用。业务方拿到链接后，会默认它是“当前数据”；如果实际是三周前的快照，基于它做的决定就会出错。
失败时还应说明失败阶段，并按允许的路线回退。
一个常见的误解链
这条链在实践中反复出现：
- “数据在仓库里，所以页面是实时的。”
- “页面能打开，所以数据是对的。”
- “链接发出去了，所以任务完成了。”
每一步都不成立。页面是快照，正确性来自前置验证，任务完成取决于接收者能否正确使用。
原文的设计恰好逐条对应：快照要有截止时间，验证要在发布之前，交接要说清边界。
设计自己的发布流程时
三个可以立刻用的检查：
- 发布前，产物是否已经通过验证，并带着受控的数据快照？
- 站点是否复用了同一地址，而不是每次新建？
- 交接信息里，是否同时写清了位置、截止时间和“非实时”？
发布能力解决的是“怎样共享一个已验证版本”，而不是一键变成实时 BI。更新、权限和证据边界，仍然需要明确的产品设计。