launch-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 或 jam 游戏。说明省略了此部分及原因；不要留空。
  • itch — 仅 itch.io 上传要求：构建大小、页面设置、年龄标签。 不包含主机平台和 Steamworks 条目。
  • steam — Steamworks：商店页面、depot 构建、成就、系统 要求、通用内容规则。不包含主机平台认证条目。
  • console — 完整的平台认证（TRC / XR / Lotcheck）、存档数据规则、 控制器映射规则、年龄评级机构。等级最高。

  **根据上述 cert_tier 值分支，而非平台名称。**检查目标平台会将 itch 项目和 steam 项目视为相同，会混淆 none 和未设置，并会根据 mobile 进行判断，而 mobile 根本不是 cert_tier 的取值。请使用配置中定义的词汇。

如果因配置缺失而无法确定某个条目的适用范围，请将其标记为 NOT ASSESSED — platform/stage unknown。不要默默地将其列入清单：否则，一个 rigor: standard、仅面向单个平台的项目会收到一份约含 150 个条目的检查清单，要求满足 PC 和 主机平台 和移动平台认证以及年龄评级，其中约 140 项无法评估。

---

阶段 1：解析参数

读取启动日期或 dry-run 模式参数。Dry-run 模式会生成检查清单，但不会创建签核条目或写入文件。没有参数时，按常规模式运行，目标日期未设置（Target Launch: not set）——只有参数为 dry-run 时才使用 dry-run 模式。

---

阶段 2：收集项目背景

• 阅读 CLAUDE.md，了解技术栈、目标平台和团队结构
• 阅读 production/milestones/ 中最新的里程碑
• 阅读 production/releases/ 中任何现有的发布检查清单
• 如果存在，阅读 design/live-ops/content-calendar.md 中的内容日历

---

阶段 3：扫描代码库健康状况

本阶段的每项扫描都是在查找问题，因此扫描结果为零命中时，按定义存在歧义：这可能表示“已搜索，未发现问题”，也可能表示“没有可搜索的内容”。在发布门禁中，这两者意味着相反的结论，而绿色复选框却会把它们显示得一模一样。

每次扫描前都先确定扫描范围，并报告扫描数量。 每行应写为 scanned [N] files, [M] hits，或 NOT ASSESSED — [code root unresolved | no source files | no asset folder | directory empty]。 不能只打勾。代码根目录按引擎确定为 src/、Assets/ 或 Source/（根据 .claude/docs/code-root-resolution.md 确定）；资源位于 assets/、Assets/ 或 Content/。

以下四个要点均适用此规则：每项都以相同方式搜索占位资源、TODO、调试输出和硬编码测试值；根目录为空或不存在时，每项都会返回零命中。例如，没有 assets/ 目录时，占位资源扫描会返回零命中，而只打勾就会把“所有占位美术资源都已替换”标记为绿色。

• 统计 TODO、FIXME、HACK 注释及其位置
• 检查生产代码中是否残留 console.log、print() 或调试输出
• 检查占位资源（搜索 placeholder、temp_、WIP_）
• 检查硬编码的测试／开发值（localhost、测试凭据、调试标志）

在清单中也要体现这一区别。 扫描结果为 NOT ASSESSED 的项目应写为 - [?]，而不是 - [ ]。未勾选的方框表示仍有工作要做；[?] 表示无人能够检查，只有其中一种情况可以通过完成工作来消除。凡出现 [?] 的地方，都要附上图例： [?] = not assessed — the input to this check was absent。

---

阶段 4：生成发布清单

# Launch Checklist: [Game Title]
Target Launch: [Date or DRY RUN]
Generated: [Date]

---

## 1. Code Readiness

### Build Health
- [ ] Clean build on all target platforms
- [ ] Zero compiler warnings
- [ ] All unit tests passing
- [ ] All integration tests passing
- [ ] Performance benchmarks within targets
- [ ] No memory leaks (verified via extended soak test)
- [ ] Build size within platform limits
- [ ] Build version correctly set and tagged in source control

### Code Quality
- [ ] TODO count: [N] (zero required for launch, or documented exceptions)
- [ ] FIXME count: [N] (zero required)
- [ ] HACK count: [N] (each must have documented justification)
- [ ] No debug output in production code
- [ ] No hardcoded dev/test values
- [ ] All feature flags set to production values
- [ ] Error handling covers all critical paths
- [ ] Crash reporting integrated and verified

### Security
- [ ] No exposed API keys or credentials in source
- [ ] Save data encrypted
- [ ] Network communication secured (TLS/DTLS)
- [ ] Anti-cheat measures active (if multiplayer)
- [ ] Input validation on all server endpoints (if multiplayer)
- [ ] Privacy policy compliance verified

---

## 2. Content Readiness

### Assets
- [ ] All placeholder art replaced with final assets
- [ ] All placeholder audio replaced with final audio
- [ ] Audio mix finalized and approved by audio director
- [ ] All VFX polished and performance-verified
- [ ] No missing or broken asset references
- [ ] Asset naming conventions enforced

### Text and Localization
- [ ] All player-facing text proofread
- [ ] No hardcoded strings (all externalized for localization)
- [ ] All supported languages translated and verified
- [ ] Text fits UI in all languages (text fitting pass complete)
- [ ] Font coverage verified for all supported languages
- [ ] Credits complete, accurate, and up to date

### Game Content
- [ ] All levels/maps playable from start to finish
- [ ] Tutorial flow complete and tested with new players
- [ ] All achievements/trophies implemented and tested
- [ ] Save/load works correctly for all game states
- [ ] Difficulty settings balanced and tested
- [ ] End-game/credits sequence complete

---

## 3. Quality Assurance

### Testing
- [ ] Full regression test suite passed
- [ ] Zero S1 (Critical) bugs open
- [ ] Zero S2 (High) bugs open (or documented exceptions) — at `workflow: full` instead: zero S2 (High) and S3 (Medium) bugs open, no exceptions
- [ ] Soak test passed (the longest soak `/soak-test` runs, or longer by hand if a play session lasts longer)
- [ ] Multiplayer stress test passed (if applicable)
- [ ] All critical user paths tested on every platform
- [ ] Edge cases tested (full storage, no network, suspend/resume)

### Platform Certification

**Emit ONLY the block matching `platform.cert_tier`** (resolved in the resolved-config block at the top of this skill — see
the `platform.cert_tier` rule above). Do not emit this section's other blocks, and
do not fall back to emitting all of them.

**At `none`** — omit the section and say so in one line:
`Platform Certification: omitted — cert_tier is 'none' (internal/jam release).`

**At `itch`:**
- [ ] Build size within itch.io upload limits
- [ ] itch.io page complete (cover art, screenshots, description, tags)
- [ ] Age/content tags set honestly
- [ ] Downloadable vs browser build decided and tested

**At `steam`:**
- [ ] Steamworks SDK integrated and tested
- [ ] Store page complete (capsule art, trailer, description, system requirements)
- [ ] Depot build uploaded and installs cleanly from a fresh account
- [ ] Achievements functional
- [ ] Steam common content rules reviewed

**At `console`:**
- [ ] TRC/TCR/Lotcheck submission prepared
- [ ] Save-data rules compliant (corruption, full storage, user switching)
- [ ] Controller-mapping rules met, platform-correct button prompts
- [ ] Suspend/resume verified
- [ ] Age ratings obtained (ESRB, PEGI, regional)

**Every tier**, because these are not certification-gated:
- [ ] Accessibility: minimum standards met (remapping, text scaling, colorblind)

> **Emit this section gated by tier, never as one ungated list.** PC *and*
> Console *and* Mobile rows emitted at every tier contradict the `cert_tier` rule
> at the top of this skill, which says an `itch` project gets no console and no
> Steamworks items.

### Performance
- [ ] Target FPS met on minimum spec hardware
- [ ] Load times within budget on all platforms
- [ ] Memory usage within budget on all platforms
- [ ] Network bandwidth within targets (if multiplayer)
- [ ] No frame hitches in critical gameplay moments

---

## 4. Store and Distribution

### Store Pages
- [ ] Store page copy finalized and proofread
- [ ] Screenshots current and per-platform resolution
- [ ] Trailers current and approved
- [ ] Key art and capsule images finalized
- [ ] System requirements accurate (PC)
- [ ] Pricing configured for all regions
- [ ] Pre-purchase/wishlist campaigns active (if applicable)

### Legal
- [ ] EULA finalized and approved by legal
- [ ] Privacy policy published and linked
- [ ] Third-party license attributions complete
- [ ] Music/audio licensing verified
- [ ] Trademark/IP clearance confirmed
- [ ] GDPR/CCPA compliance verified (data collection, consent, deletion)

---

## 5. Infrastructure

### Servers (if multiplayer/online)
- [ ] Production servers provisioned and load-tested
- [ ] Auto-scaling configured and tested
- [ ] Database backups configured
- [ ] CDN configured for content delivery
- [ ] DDoS protection active
- [ ] Monitoring and alerting configured

### Analytics and Monitoring
- [ ] Analytics pipeline verified and receiving data
- [ ] Crash reporting active and dashboard accessible
- [ ] Server monitoring dashboards live
- [ ] Key metrics tracked: DAU, session length, retention, crashes
- [ ] Alerts configured for critical thresholds

---

## 6. Community and Marketing

### Community Readiness
- [ ] Community guidelines published
- [ ] Moderation team briefed and tools ready
- [ ] Discord/forum/social channels set up
- [ ] FAQ and known issues page prepared
- [ ] Support email/ticketing system active

### Marketing
- [ ] Launch trailer published
- [ ] Press/influencer review keys distributed
- [ ] Social media launch posts scheduled
- [ ] Launch day blog post/dev update drafted
- [ ] Patch notes for launch version published

---

## 7. Operations

### Team Readiness
- [ ] On-call schedule set for first 72 hours post-launch
- [ ] Incident response playbook reviewed by team
- [ ] Rollback plan documented and tested
- [ ] Hotfix pipeline tested (can ship emergency fix within 4 hours)
- [ ] Communication plan for launch issues (who posts, where, how fast)

### Day-One Plan
- [ ] Day-one patch prepared (if needed)
- [ ] Server unlock/go-live procedure documented
- [ ] Launch monitoring dashboard bookmarked by all leads
- [ ] War room/channel established for launch day

---

## Go / No-Go Decision

**Overall Status**: [READY / CONDITIONAL / NOT ASSESSED / NOT READY]

First match wins: **NOT READY** if Blocking Items is not empty; else **NOT
ASSESSED** if any item is `- [?]`, any section came out `NOT ASSESSED`, or any
item is still unconfirmed — neither ticked on evidence or on a Phase 4b answer,
nor marked N/A, nor listed below (name each; group by section when there are
many); else **CONDITIONAL** if Conditional
Items is not empty; else **READY**. NOT ASSESSED outranks CONDITIONAL and READY —
an item nobody could check is not a passed one — and ranks below NOT READY, so a
known blocker is never buried behind it.

### Blocking Items
[Every FAIL or unresolved finding: a check that found a problem — FIXMEs, debug
output, placeholder assets, hardcoded dev values, an open S1 bug, a failing
build or test — with no documented workaround and no explicitly accepted risk]

### Conditional Items
[Every shortfall with a documented workaround or an explicitly accepted risk —
e.g. a HACK with its documented justification, an S2 with a documented
exception (below `workflow: full`, which allows none). Name the workaround, or
who accepted the risk]

### Sign-Offs Required
- [ ] Creative Director — Content and experience quality
- [ ] Technical Director — Technical health and stability
- [ ] QA Lead — Quality and test coverage
- [ ] Producer — Schedule and overall readiness
- [ ] Release Manager — Build and deployment readiness

---

阶段 4b：确认只有人才能确认的事项

上述大多数事项都无法从代码库中确定——值班安排、EULA、按键操作、定价、某人进行过的浸泡测试。若不询问，这些事项就都会保持未确认状态，整体状态也只能是 NOT ASSESSED，因此请提出询问。

对于七个部分中的每一部分，收集尚未通过扫描或文件确认的事项（阶段 3 的统计结果以及阶段 2 中阅读过的内容不再询问），并且每部分提出一个 AskUserQuestion，按编号列出这些事项。每项的回答为是／否／尚未／不适用。选项：Yes — all of them / Not yet — none of them / N/A — this section does not apply / Some differ — I'll answer per item（随后用户会逐项回答每个编号项目）。没有待询问事项的部分则跳过。

• 是 → 勾选 - [x]，并标记为 (confirmed by the user)
• 否或尚未 → 属于未通过的项目：列入阻塞项，或在用户说明了变通方案或接受风险时列入有条件项目
• N/A → 写为 - N/A — [item]，并从整体状态中排除
• 未回答的项目仍保持未确认，状态中应列出该项目

这些都是只有用户才能回答的事实问题，因此无论在 collaborative 还是 guided 模式下都要询问，绝不能代用户作答。在 autonomous 模式和 dry-run 中，跳过此阶段并说明原因：原本要询问的事项仍保持未确认，整体状态为 NOT ASSESSED。

然后根据回答填写 Go / No-Go 部分。

---

阶段 5：保存清单

向用户展示已完成的清单和摘要（整体状态、项目总数、阻塞项数量、有条件项目数量、未评估项目数量、部分内容不完整的部门）。

如果不处于 dry-run 模式，请询问：“可以将其写入 production/releases/launch-checklist-[date].md 吗？”

收到答复前，不要创建任何内容，连 production/releases/ 目录也不要创建。 如果用户回答可以，则写入文件；写入时会同时创建目录。

阶段 6：后续步骤

• 如果 project.stage 不是 Release（而是 Polish、更早的阶段，或未设置），请先运行 /gate-check release——这是发布前的就绪检查。
• 通过 /team-release 协调签核和部署。