Showcase detail
Release Proof Runbook
把内容更新后的 build、发布、线上抽查和证据留存压成一套可回看的发布闭环，而不是停在“本地看起来没问题”。
所属类别
发布 / 站点维护
适用版本
0.9.x
预计配置时间
20 到 35 分钟
最后验证
2026-04-03
Key signals
适合谁：适合频繁维护内容站、文档站或静态站的编辑者、站长与项目主理人
安全标签：文件写入 + 生产发布 + 线上只读核查
维护状态：样板维护中
Value and proof
这页先证明它真的解决问题
它先证明这次更新真的上线了、关键页面真的可访问，再谈发布效率。 能把一次发布拆成 build、自查、部署、线上抽查和证据记录五步，让“已经发了没”不再靠口头确认。
结果证明
典型场景下能把“本地完成但线上没更新”这类问题提前暴露在发布当轮，而不是几小时后才被用户发现。
为什么强
强项不在自动发得更快，而在把 Deploy Proof Checklist 的核查顺序和 Memory Ledger 的留痕能力绑成稳定闭环。
预期效果
输出一轮可回看的发布记录，明确这次改动是否已上线、哪些页面被核查，以及是否存在部署延迟或回归问题。
不保证项
不保证生产平台永远即时生效，但能显著降低“本地通过却线上异常”长期无人发现的概率。
Input / output
真实输入输出要能支撑复刻判断
允许脱敏，但不能改写结果逻辑。用户要看得出来这不是宣传文案，而是有真实工作流证据。
真实输入示例
输入一轮站点改动、固定的 build / deploy 命令，以及 4 到 6 个关键页面抽查 URL。
真实输出结果
输出一份发布记录：本地自查结果、部署地址、关键页面状态码和是否需要继续追查的备注。
语言支持
中文优先，适合文档型与内容型站点维护流程
包名称
Release Proof Runbook Pack
Representative scenarios
代表性场景先讲真实任务，不讲抽象概念
Showcase 的说服力来自具体使用场景，至少要让用户一眼看出在哪些任务里值得复刻。
Prerequisites
复刻前必须满足的前置条件
如果前置条件说不清，演示再漂亮也不应让用户误以为能直接复制成功。
Safety controls
高风险能力必须配套写出风险控制
凡是联网、外部账号、文件写入或更高权限的能力，都要告诉用户怎样安全停下。
Boundaries
这类场景不适合直接复刻
适用边界和已知失败场景必须和能力证明同样醒目，否则 Showcase 会误导用户。
Reproduction steps
可复刻路径要按步骤写，而不是只放结果截图
分享包的任务是让陌生用户也能理解准备项、顺序和停点，不是让人照抄作者环境。
Package contents
第一版分享包至少要承载这些内容
适合把内容站发布从“本地完成”推进到“线上已验证”的维护流程。 需要手动调整的部分：需要人工决定哪些页面属于本轮关键抽查范围，并在异常时判断是否继续重发或先回滚。
Related skills
这个 Showcase 依赖的 Skill 组合
这里应该解释为什么这些 Skill 是必需的，以及它们各自承担的职责，而不是只列名字。
Required skill
Memory Ledger
把长期决策、每日过程和行为日志分层记录，减少上下文断裂和“说过但没记下”的损耗。
用途
在长期维护站点、内容库或项目代理时，把持续性信息落到文件，而不是靠会话记忆硬撑。
安全说明
记录应聚焦任务决策与可审计动作，不应把敏感凭证或私密原文随手写进共享日志。
Required skill
Deploy Proof Checklist
把构建、部署、线上回归和证据留存固定成一套发布核查清单，避免“本地好了就算发完”。
用途
在内容站、文档站或静态站发布前后，把 build、deploy 和线上验证串成可回看的最小闭环。
安全说明
以构建、只读核查和证据留存为主；真正的生产写操作应单独确认并保留发布记录。
Author and maintenance
作者与维护信息
用于演示站点维护类 Showcase 如何把发布证明、风险边界和留痕闭环一起讲清楚。
作者
agent101 editorial sample
反馈路径
通过站内审核与维护反馈持续修订。
维护状态
样板维护中
最后验证
2026-04-03
Excluded content
公开分享时必须明确不包含的内容
这部分写清楚，才能避免用户把作者没提供、也不该提供的内容误当成缺漏。