release-checklist

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys rigor,workflow,project.stage,cert_tier,automation

自动化模式：解析 modes.automation（project.local.yaml → project.yaml → 默认值 collaborative）。每次调用 AskUserQuestion 和 每次文件写入都遵循 .claude/docs/automation-modes.md （collaborative 总是询问 · guided 仅询问重大事项 · autonomous 记录并继续； automation_always_ask 类别始终询问）。

上方已解析——直接使用。若没有代码块 → 默认值见 .claude/docs/config-resolution.md。

发布清单

根据项目范围调整此清单。 对每个平台都列出所有项目，会让读者养成跳过清单的习惯，从而失去关卡的作用：

• project.stage — 本项目尚未进入的阶段，其项目不在范围内；应明确说明，而不是将其列出并留空。

• modes.rigor — 在 minimal 模式下，删除那些唯一依据只是本项目已选择不采用的流程负担的项目。

• platform.cert_tier — 仅列出本项目目标等级的认证项目。若该值未设置，应询问哪些平台在范围内，而不是列出所有项目——未设置意味着需要提问，并不代表可以列出每一条认证流程。如果无法确定，标记该部分为 NOT ASSESSED — cert tier unknown。未设置不等于 none： none 是一项决定，未设置则是缺少决定，两者不能产生相同的输出。应根据此键的四个可能值进行分支判断——none | itch | steam | console——而不是根据平台名称。完整要求表位于 .claude/docs/effects-map.md 的 ## platform.cert_tier 部分——只读该部分（Grep 其标题，然后进行有界 Read）；整个文件不是运行时输入。

  • none — 完全不输出认证部分。 适用于内部发布、alpha 或游戏创作活动游戏。说明省略该部分的原因；不要留空。
  • itch — 仅包含 itch.io 上传要求：构建大小、页面设置、年龄标签。不包含主机和 Steamworks 项目。
  • steam — Steamworks：商店页面、 depot 构建、成就、系统要求、通用内容规则。不包含主机认证项目。
  • console — 完整的平台认证（TRC / XR / Lotcheck）、存档数据规则、控制器映射规则、年龄评级委员会。要求最严格的等级。

  根据上述 cert_tier 值进行分支判断，而不是根据平台名称。 按目标平台进行判断，会把 itch 项目和 steam 项目视为相同，将 none 与未设置混为一谈，还会使用 mobile 作为判断依据，但它根本不是 cert_tier 的取值。应使用配置定义的词汇。

若因配置缺失而无法确定某个项目的范围，将其标记为 NOT ASSESSED — platform/stage unknown。不要默默将其纳入：否则，一个 rigor: standard 的单平台项目可能会收到一份约 150 项的清单，要求 PC 和主机 和移动端认证以及年龄评级，其中约 140 项无法评估。

---

第 1 阶段：解析参数

读取用于指定目标平台的参数（pc、console、mobile 或 all）。如果未指定平台，则默认为 all。

该参数决定设备要求，绝不决定认证流程。 认证由此技能顶部已解析配置块中的 platform.cert_tier 决定—— 参见上方的 platform.cert_tier 规则。这是两个不同的维度，只是碰巧共享了一个词：pc/console/mobile 表示硬件形态，而 none|itch|steam|console 表示认证体系。两者只有 console 一致——itch 和 none 完全没有设备区块，而 mobile 也不是 cert_tier 的取值。因此，输出设备区块并不能说明应输出哪个认证区块，而 all 也不代表可以输出每一条认证流程。

---

第 2 阶段：加载项目上下文

• 阅读 CLAUDE.md，了解项目上下文、版本信息和目标平台。
• 阅读 production/milestones/ 中当前的里程碑，了解此版本应包含哪些功能和内容。
• 阅读 production/qa/bugs/ 中未关闭的错误：像 /bug-triage 那样，grep production/qa/bugs/*.md 中的 **Severity** 和 **Status** 行。除非错误的 Status 为 Closed 或 Verified Fixed，否则视为未关闭。错误条目使用 /gate-check release 针对已解析 workflow 应用的阈值：在 full 模式下，未关闭的 S1、S2 或 S3 错误会导致对应条目失败；在 standard 和 minimal 模式下，只有未关闭的 S1 错误会导致条目失败，未关闭的 S2 或 S3 错误则会作为风险列入 Rationale。每个导致失败的错误都要在 Rationale 中列为阻塞项。production/qa/bugs/ 中没有错误文件 → 错误条目应标记为 NOT ASSESSED — no bug records——绝不能记为零或勾选，因为没有记录与确认无错误不能在清单中得到相同结果；错误通过 /bug-report 提交。

---

第 3 阶段：扫描代码库

每次计数都要注明分母。 这些扫描用于查找问题， 因此 0 可能表示“已搜索，未发现问题”，也可能表示“没有可供搜索的内容”， 而在发布门禁中，这两种结果截然不同。报告 scanned [N] source files: [M] TODO, [M] FIXME, [M] HACK——或者，在代码 根目录（src/、Assets/ 或 Source/；根据 .claude/docs/code-root-resolution.md 确定）尚未解析时，报告 NOT ASSESSED — code root unresolved；如果该目录不存在或其中没有 源文件，则报告 NOT ASSESSED — no source files found to scan。单独的 0 不是有效结果。

扫描未解决的问题：

• 统计 TODO 注释
• 统计 FIXME 注释
• 统计 HACK 注释
• 记录其位置和严重程度

如有测试输出目录或 CI 日志，请检查其中是否有测试结果。 如果未发现任何结果，请明确说明——Test results: NOT ASSESSED — no test output or CI logs found——而不是省略这一行。缺少测试结果与测试通过不能在发布清单中得到相同结果。

---

阶段 4：生成发布检查清单

## Release Checklist: [Version] -- [Platform]
Generated: [Date]

### Codebase Health
- Scanned: [N] source files (or `NOT ASSESSED — [reason]`, per Phase 3)
- TODO count: [N] ([list top 5 if many])
- FIXME count: [N] ([list all -- these are potential blockers])
- HACK count: [N] ([list all -- these need review])

### Build Verification
- [ ] Clean build succeeds on all target platforms
- [ ] No compiler warnings (zero-warning policy)
- [ ] All assets included and loading correctly
- [ ] Build size within budget ([target size])
- [ ] Build version number correctly set ([version])
- [ ] Build is reproducible from tagged commit

### Quality Gates
- Open bugs (`production/qa/bugs/`): [N] S1, [N] S2, [N] S3 -- or `NOT ASSESSED — no bug records`
- [ ] Zero open S1 (Critical) bugs
- [ ] Zero open S2 (High) and S3 (Medium) bugs, no exceptions -- this row at `workflow: full` only; at `standard`/`minimal` open S2/S3 bugs go in the Rationale as risks
- [ ] All critical path features tested and signed off by QA
- [ ] Performance within budgets:
  - [ ] Target FPS met on minimum spec hardware
  - [ ] Memory usage within budget
  - [ ] Load times within budget
  - [ ] No memory leaks over extended play sessions
- [ ] No regression from previous build
- [ ] Soak test passed (4+ hours continuous play)

### Content Complete
- [ ] All placeholder assets replaced with final versions
- [ ] All TODO/FIXME in content files resolved or documented
- [ ] All player-facing text proofread
- [ ] All text localization-ready (no hardcoded strings)
- [ ] Audio mix finalized and approved
- [ ] Credits complete and accurate

根据参数添加设备部分。这些部分不包含认证或商店 SDK 项——这些项目由下一小节中的 platform.cert_tier 控制，在此重复会让 itch 项目收到 Steamworks 条目。

对于 pc：

### Platform Requirements: PC
- [ ] Minimum and recommended specs verified and documented
- [ ] Keyboard+mouse controls fully functional
- [ ] Controller support tested (Xbox, PlayStation, generic)
- [ ] Resolution scaling tested (1080p, 1440p, 4K, ultrawide)
- [ ] Windowed, borderless, and fullscreen modes working
- [ ] Graphics settings save and load correctly

对于 console：

### Platform Requirements: Console
- [ ] Platform-specific controller prompts display correctly
- [ ] Suspend/resume works correctly
- [ ] User switching handled properly
- [ ] Network connectivity loss handled gracefully
- [ ] Storage full scenario handled

对于 mobile：

### Platform Requirements: Mobile
- [ ] App store guidelines compliance verified
- [ ] All required device permissions justified and documented
- [ ] Privacy policy linked and accurate
- [ ] Data safety/nutrition labels completed
- [ ] Touch controls tested on multiple screen sizes
- [ ] Battery usage within acceptable range
- [ ] Background behavior correct (pause, resume, terminate)
- [ ] Push notification permissions handled correctly
- [ ] In-app purchase flow tested (if applicable)
- [ ] App size within store limits

移动端商店条目有意保留在此处。 platform.cert_tier 仅建模为 none|itch|steam|console，没有移动端类别，因此 App Store / Play Store 合规性无法由它控制。将这些条目留在设备部分是有意为之，并非疏忽——不要 通过发明 mobile 类别来“修正”，这正是 cert_tier 规则警告不要使用的错误术语。

认证——仅输出与 platform.cert_tier 匹配的部分（在此技能顶部的已解析配置部分中解析）。不要输出本小节的其他部分，也不要因为平台参数是 all 就退而输出所有部分。

当值为 none 时——完全不输出认证部分。在其位置准确输出以下一行，让省略项清晰可见，而不是看起来像缺少了某个部分：

Certification: omitted — cert_tier is 'none' (internal build, alpha or jam release).

当值为 itch 时：

### Certification: itch.io
- [ ] Build size within itch.io upload limits
- [ ] itch.io page complete (cover art, screenshots, description)
- [ ] Age/content tags set honestly
- [ ] Downloadable vs browser build decided and tested
- [ ] Butler channel names correct for each platform uploaded

当值为 steam 时：

### Certification: Steamworks
- [ ] Steamworks SDK integrated and tested
- [ ] Depot build uploaded and installs cleanly from a fresh account
- [ ] Achievements functional
- [ ] Cloud saves functional
- [ ] Steam Deck compatibility verified (if targeting)
- [ ] Steam common content rules reviewed

当值为 console 时：

### Certification: Console
- [ ] TRC/TCR/Lotcheck requirements checklist complete
- [ ] First-party certification submission prepared
- [ ] Platform-specific achievement/trophy integration tested
- [ ] Parental controls respected
- [ ] Save-data rules compliant (corruption, full storage, user switching)
- [ ] Age ratings obtained (ESRB, PEGI, regional)

如果 cert_tier 未设置，请询问适用的平台，而不是输出所有轨道；如果无法确定，则输出 ### Certification: NOT ASSESSED — cert tier unknown 并说明原因。未设置不等于 none——none 是一个决定，未设置则表示缺少决定。

**认证条目应放在此处的一个由 cert_tier 控制的小节中。**不要 将它们放入 PC、Console 和 Mobile 设备部分：这些部分由命令参数选择，且默认值为 all，因此，使用 /release-checklist 且不带参数的 itch 项目会收到 Steamworks SDK 条目 以及 Lotcheck 条目，而这违反了此技能顶部的 cert_tier 规则。

**此文件中的 console 有两种不同含义。它既是设备部分的参数值， 也是 cert_tier 的值，四个词中有一个词因此出现冲突。标题 **For \console`:` 是由参数控制的，并非由类别控制——不要将其解读为 认证已经按类别限定。

商店和发布部分（所有平台）：

### Store / Distribution
- [ ] Store page metadata complete and proofread
  - [ ] Short description
  - [ ] Long description
  - [ ] Feature list
  - [ ] System requirements (PC)
- [ ] Screenshots up to date and per-platform resolution requirements met
- [ ] Trailers up to date
- [ ] Key art and capsule images current
- [ ] Age rating obtained and configured:
  - [ ] ESRB
  - [ ] PEGI
  - [ ] Other regional ratings as required
- [ ] Legal notices, EULA, and privacy policy in place
- [ ] Third-party license attributions complete
- [ ] Pricing configured for all regions

### Launch Readiness
- [ ] Analytics / telemetry verified and receiving data
- [ ] Crash reporting configured and dashboard accessible
- [ ] Day-one patch prepared and tested (if needed)
- [ ] On-call team schedule set for first 72 hours
- [ ] Community launch announcements drafted
- [ ] Press/influencer keys prepared for distribution
- [ ] Support team briefed on known issues and FAQ
- [ ] Rollback plan documented (if critical issues found post-launch)

### Go / No-Go: [READY / NOT ASSESSED / NOT READY]

First match wins: **NOT READY** if any blocking item fails; else **NOT ASSESSED**
if any section or item came out `NOT ASSESSED` (name each one); else **READY**. NOT
ASSESSED outranks READY — an unassessed section is not a passed one — and ranks
below NOT READY, so a known blocker is never buried behind it.

**Rationale:**
[Summary of readiness assessment. List any blocking items that must be
resolved before launch. If NOT READY, list the specific items that need
resolution and estimated time to address them.]

**Sign-offs Required:**
- [ ] QA Lead
- [ ] Technical Director
- [ ] Producer
- [ ] Creative Director

---

阶段 5：保存检查清单

向用户展示检查清单，并提供：检查清单条目总数、已知阻塞项数量（FIXME/HACK 计数、已知 Bug）。

询问：“我可以将其写入 production/releases/release-checklist-[version].md 吗？”

如果可以，请写入文件；如有需要，创建目录。

---

阶段 6：后续步骤

• 如果尚未完成，起草更新日志或补丁说明（/changelog、/patch-notes）——发布门禁会检查这些内容。
• 运行 /gate-check release——Polish → Release 门禁会读取此检查清单。
• 通过后：运行 /launch-checklist，然后通过 /team-release 协调发布。